Du planst ein Software-Projekt? Dann hast du bestimmt ein paar konkrete Vorstellungen, wie es am Ende aussehen soll!
Warum du die Anforderungen trotzdem nicht in ein Pflichtenheft schreiben und stumpf abarbeiten lassen solltest, erklären wir dir hier.
Spoiler: Du sparst Geld und erhältst bessere Qualität.
Übrigens belegen wir die zentralen Aussagen in diesem Blogartikel immer mit Quellen!
Klassische Wasserfall-Entwicklung
- Anforderungsanalyse
- Design (User Interface und Software-Architektur)
- Programmierung
- Testen
- Wartung
Auf den ersten Blick erscheint das vollkommen intuitiv. Ist es nicht logisch, dass erst die Anforderungen zu 100 % feststehen müssen, bevor die Software entwickelt wird? Hierfür werden ausführliche Pflichtenhefte verfasst.
Das Wasserfall-Modell wirkt wie ein geordneter, messbarer und nachvollziehbarer Vorgang. Außerdem bedient es ein Management-Bedürfnis nach Rechenschaft: Bevor das Projekt freigegeben wird, müssen alle Aspekte feststehen. Wehe dem- oder derjenigen, die Dinge übersieht, wodurch letzten Endes Mehrkosten entstehen! Lieber hat man planbare Kosten und eine Software, deren Funktionen exakt dem entsprechen, wie es gewünscht war.
Mängel der Wasserfall-Entwicklung
Leider schafft es die Wasserfall-Entwicklung nicht, diese Hoffnungen und Bedürfnisse zu erfüllen.
Das Projekt verläuft weder geordneter noch nachvollziehbarer. Und schon gar nicht entsteht dabei ein System, das exakt den Kundenvorstellungen entspricht, zu genau dem angesetzten Preis.
Auch wenn sich Manager*innen gerne davon freisprechen würden: Die Nutzer*innen wissen anfangs nicht wirklich, was sie wollen – oder sie haben Schwierigkeiten, ihr Wissen passend zu artikulieren. Selbst wenn bereits zu Beginn sehr viele Anforderungen feststehen, kann man nicht verhindern, dass viele Details erst im Laufe des Projekts ersichtlich werden. Und selbst wenn: Wer soll all diese Details überblicken können?1
Entscheidungen sollten allgemein eher spät als früh getroffen werden. Im Laufe des Projekts nimmt das Wissen über die Anforderungen und die Entwicklung zu, sodass Entscheidungen dann auf mehr validen Informationen basieren. Das erhöht die Chance, bessere Entscheidungen zu treffen.
Gleichzeitig wirken während eines Projektes verschiedene Kräfte. Dadurch ändern sich die Anforderungen ständig und vergangene Absprachen werden unnütz.2
Softwareentwicklung ist inhärent unvorhersehbar.
Was hilft? Ein iteratives und inkrementelles Vorgehen!3
Das nennt man auch Agile Softwareentwicklung.
Die Agile Softwareentwicklung
Was ist Agile Softwareentwicklung?
„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.“ 4
- Man darf natürlich weiterhin Prozesse nutzen und Tools einsetzen. Im Zweifel sollte man jedoch auf die persönliche Interaktion und gemeinsame Absprachen setzen, um Probleme zu lösen. Ein starrer Prozess führt nicht zu vergleichbar guten und konstruktiven Lösungen.
- Was bringt eine ausführliche Dokumentation, wenn die Software nicht nutzbar ist? An und für sich haben Entwurfsdokumente für die Anwender*innen keinen Mehrwert. Daher sollte der Projektfortschritt nur an der bereits nutzbaren Software gemessen werden, die bisher im Projekt entstanden ist.
- Wie vorhin ausgeführt, zeigt die Praxiserfahrung: Im Vorhinein festgelegte Leistungsumfänge bleiben nicht stabil. Um eine sinnvolle Software zu entwickeln, ist eine enge Zusammenarbeit mit dem Kunden und den Anwender*innen nötig. Andernfalls läuft man Gefahr, dass die Software nie eingesetzt wird. Ganz nach dem Motto: “Hauptsache, man hat den Vertrag erfüllt.”
- Die Reaktion auf Veränderungen steht nicht für Beliebigkeit, sondern für Flexibilität. Angestrebte Meilensteine sollten trotzdem erreicht werden. Jedoch muss man etwa ein Nichterreichen ehrlich erkennen. Außerdem kommen stets zuvor vergessene oder neu entstehende Anforderungen auf, die gegen bestehende Anforderungen abgewogen werden müssen.
Wenn du mehr darüber erfahren willst, empfehlen wir dir das Buch „Agile Softwareentwicklung: Werte, Konzepte und Methoden“ von Bleek und Henning.
Solltest du jetzt also auf Agile Softwareentwicklung setzen?
Nicht jeder kann und sollte auf eine agile Softwareentwicklung setzen. In welchen Projekten und bei welchen Kunden man es tun sollte – und wo nicht – das erklären wir dir hier!
Du solltest nicht agil entwickeln, wenn…
- dein Prozess ganz strikt vorgegeben ist. Hier stellt sich die Frage gar nicht. Agilität – no bueno. Das kann etwa bei Behörden der Fall sein.
- Aber nicht alle Behörden! Als das US-Verteidigungsministerium in den 80er-Jahren festgestellt hat, dass 75 % ihrer Projekte fehlschlugen, haben sie ihre Vorgaben angepasst. Im Jahr 1994 haben sie ganz klar festgehalten, dass sie eine iterative und inkrementelle Entwicklung präferieren!5
- du in lebenskritischen Bereichen entwickelst. Dort solltest du nicht auf Agilität setzen. Die Beweisbarkeit der Korrektheit ist wichtiger als ein Minimum Viable Product (MVP).
- du in einer hierarchischen Kultur, geprägt von Gehorsam und Kontrolle arbeitest. Agile Methoden sind auf eine positive Fehlerkultur und Bereitschaft zur Kommunikation angewiesen. Ohne sie ist die Agile Softwareentwicklung nicht möglich.6
Du solltest agil entwickeln, wenn…
- du eher nutzen- statt kostenorientiert bist.
- du ehrliche Risikoeinschätzungen präferierst.
- du neugierig und lernbereit bist.
- du Innovation benötigst.
- Mit den häufigen Iterationen wirst du eine Software erhalten, die näher an den Marktbedürfnissen dran ist. Neue Erkenntnisse und Veränderungen können so direkt berücksichtigt werden.
Das solltest du mitnehmen
Jetzt weißt du, wann es sinnvoll sein kann, auf die traditionelle Wasserfall-Entwicklung zu setzen und wann du lieber auf die Agile Softwareentwicklung setzen solltest.
Die Wasserfall-Entwicklung wirkt zwar wie ein geordneter, messbarer und nachvollziehbarer Vorgang – ist es aber nicht. Die Hoffnung nach kontrollierbaren Kosten und einem die Kundenanforderungen genau erfüllenden Endprodukt werden nicht erfüllt.
Denk also dran:
- Wenn du lieber vernünftige Ergebnisse sehen willst, statt einen wortwörtlich befolgten Plan…
- Wenn du ehrliche Risikoeinschätzungen präferierst, statt “ja” und “Amen”
- Wenn du und deine Organisation neugierig und lernbereit sind…
- Wenn Innovation gefragt ist…
Dann mach’s agil!
Du willst mehr über uns und unsere Prozesse erfahren?
Wobei können wir dich unterstützen?
Neues Projekt
Du hast eine Idee für eine digitale Lösung und suchst einen Partner, der dich begleitet?
Verstärkung für dein Projekt
Du hast bereits eine Anwendung und suchst Verstärkung in der Entwicklung?
1 Larman, C.; Basili, V. R., Iterative and incremental developments. A brief history 2003, S. 52–55.
2 Larman, C.; Basili, V. R., Iterative and incremental developments. A brief history 2003, S. 52–55.
3 Noura Abbas; Andrew M. Gravell; Gary B. Wills, Historical Roots of Agile Methods: Where Did “Agile Thinking” Come From? 2008.
4 Beck et al., Manifesto for Agile Software Development 2001.
5 Larman, C.; Basili, V. R., Iterative and incremental developments. a brief history 2003, S. 52–54
6 Wolf, H.; Bleek, W.-G., Agile Softwareentwicklung 2011, S. 176–181
7 Vijayasarathy, L. R.; Butler, C. W., Choice of Software Development Methodologies: Do Organizational, Project, and Team Characteristics Matter? 2016
8 Wolf, H.; Bleek, W.-G., Agile Softwareentwicklung 2011, S. 182–186
