Agile Software-Entwicklung und agiles Projektmanagement

Agile Software-Entwicklung bei //SEIBERT/MEDIA

Vorgehensmodelle / Frameworks

• Scrum
  • Scrum-Rollen auf einen Blick
• Kanban
• Google Design Sprints

Methoden & Werkzeuge

• Kontinuierliche Integration (Continous Integration)
• Taskboards
  • Scrum Boards
• User Stories
• Agile Vorhersagen (Schätzungen)
• Agile Games

Workshops & Meetings

• Standup-Meetings
• Backlog Grooming
• Retrospektive / Futurespektive
• Review-Meetings
• Scrum of Scrums (bei mehreren Teams)

Tools

• Tools und agile Softwareentwicklung - ein Widerspruch?
• Jira in agilen Software-Entwicklungsprojekten
  • Jira in Scrum-Sprints
• Bonfire
• Confluence

Teamarbeit

• Literaturtipps zur Teamentwicklung
• Team Skills Matrix

Artefakte

• Architekturvision
• Burn-Down-Chart
• Definition of Ready
• Definition of Done
• Product Backlog
• Produktvision
• Impediment Backlog

Vertragsgestaltung

• Abrechnung von individuellen Softwareentwicklungsprojekten
• Initiale Beschätzung und kontinuierliche Budgetplanung

Scrum & Kanban bei //SEIBERT/MEDIA

Einschränkung

"Process is only a second-order effect. The unique people, their feelings, qualities, and communication are more influential. Some problems are just hard, some people are just difficult. These methods are not salvation." - Agile methodologist Alistair Cockburn

Man sollte agile Entwicklungsmethoden also nicht einsetzen, wenn es dafür keinen Bedarf gibt. Wenn man also erfolgreich mit dem Wasserfallmodell arbeitet, besteht kein Handlungsdruck. Wenn man aber Probleme und Herausforderungen erlebt, Zeitpläne gerissen und Budgets gesprengt werden, dann ist es Zeit, sich über agile und iterative Methoden Gedanken zu machen. Und genau da kann agile Software-Entwicklung auch helfen und eine neue Methode mit besseren Wegen aufzeigen.

Audio-Kurznachricht zum Thema

Wissenschaftlich fundierte Argumente für agile Softwareentwicklung

1. In a study of failure factors on 1.027 IT projects in the UK (only 13% didn’t fail), scope management related to attempting waterfall practices (including detailed up-front requirements) was the single largest contributing factor for failure, being cited in 82% of the projects as the numer one problem, with an overall weighted influence of 25%.
   We want the requirements to be stable, but they aren’t. Attempts to face this callenge by early detailed requirements analysis and freeze can rarely succeed, given the high rates of change. In the study of failure factors (...), such practices were associated with the largest contributing factor for failure, being cited in 82% of the projects as the number one problem. - Thomas, M.: IT Projects Sink or Swim. British Computer Society Review, 2001
2. In a study of 6.700 projects, it was found that four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with the late integration. - Jones, C.: Patterns of Software Failure and Success. International Thompson Press
3. In 1996 Barry Boehm published a well-known paper summarizing failures of the waterfall, with advice to use a risk-reducing IID approach combined with three milestones anchor points around which to plan and control; this advice was eventually adopted in the UP. - Boehm, B.: Anchoring the Software process. IEEE Software. July 1996
4. In a study of over 8.000 projects, 37% of the factors on challenged projects were related to requirements. - Jim Johnson et. al.: Chaos: Charting the Seas of Information Technology. Published Report, 1994
5. The cost of fixing a requirement defect increases non-linearly from early to late in the project. - Boehm, B., Papaccio, P.: Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering, 1988
6. Research of many projects showed that 45% of features were not used – with an additional 19% rarely used. - Johnson, J.: Keynote speech, XP 2002. Sardinia, Italy, 2002
7. Research now shows the waterfall is associated with higher risk, failure, and lower productivity. Interestingly – and unknown to many – the author of a key waterfall paper (Winston Royce) said the idea was only applicable for the most straightforward un-novel projects; and most interesing, he was himself a proponent of iterative and evolutionary development.
8. The waterfall lifecycle pushes many high-risk and difficult elements toward the end of a project, while IID methods, run by risk-driven iterations, surface and resolve the hardest and riskiest elements early.
9. Do not attempt to create a reliable plan or schedule that lays out all the iterations, what will happen in each and when, or all the detailed activities sequenced in a PERT chart. Similarly, do not attempt (at the start) to reliably estimate the overall cost or effort, or milestones of intermediate completion. (...) Such early attempts at predicticve planning are more successful on repititive manufacturing projects of low change and complexity, but not on inventive projects.
10. The waterfall has been called a fail-late lifecycle; one can have the illusion of an accurate schedule dureing the early, easier phases. - Larman, C.: Agile & Iterative Development. Addison-Wesley, 2004
11. Question: What are the most exciting, promising software engineering ideas or techniques on the horizon?
    Answer: I don’t think that the most promising ideas are on the horizon. They are already here and have been for years, but are not being used properly. - David L. Parnas
12. Data shows that iterative and evolutionary development is correlated with lower risk, higher productivity, and lower defect rates than waterfall methods.
13. Major and life-critical systems have been developed iteratively rather than using the waterfall. Examples including the USA Space Shuttle Flight control software, developed in 17 iterations, and the new Canadian air traffic control system.
14. Many prominent software engineering thought leaders have recommended avoiding the waterfall and adopting iterative development, including Harlan Mills, Frederick Brooks, Barry Boehm, James Martin, Tom DeMarco, Ed Yourdon, and more.
15. Each year, 23% of projects, averaging $1.1 million USD, fail. A two-year ROI analysis of investing $100.000 in iteraive skills transfer could show an NPV of $700.000 with IRR of 200%.
16. The original “waterfall paper” was misinterpreted and seldom read, its author actually endorsed iterative and evolutionary development, the waterfall associated with high risks, and the creator of the waterfall DOD-STD-2167 standard retrospectively says he would have promoted an iterative rahter than waterfall lifecycle.
17. There are at least seven reasons why the waterfall continued to be promoted, including lack of awareness of the growing evidence that it was not ideal, its simple definition, and all allure of simple progress tracking (such as “requirements complete”). - Larman, C.: Agile & Iterative Development. Addison-Wesley, 2004
18. In a survey of agile method results; 88% of organisations cited improved productivity, and 84% improved quality. The most frequently used agile methods were Scrum and XP. Regarding cost of development, 46% stated no chance and 49% stated it was less expensive with agile methods.
19. One of the most interesting results was the increase in business satisfaction with the new software: Overall 83% claimed higher satisfaction and 26% overall claimed “significantly better satisfaction.” # The most ferquently cited positive feature of agile methods (48%) was “respond to change rather than follow a predefined plan.” - Corporate Report: Agile Methodologies Survey Results. Shine technologies Pty Ltd., Victoria, Australia, 2003
20. In the CHAOS TEN list of the top ten factors for success, at least four of the top five factors are strongly related to IID practices:
    
    Jim Johnson et. al.: ChAOS: A Receipe for Success, 1998. Published Report. The Standish Group, 1998
    Grafik: Larman, C.: Agile & Iterative Development. Addison-Wesley, 2004
21. It’s amazing how much you can get done the day before a vacation. - McConnell, S.: Rapid Devolopment.

Lustig und ironisch über agile Software-Entwicklung