Software Development

Eine der ersten Entscheidungen, vor denen wir bei jedem unserer Entwicklungsprojekte stehen, lautet: „Welche Entwicklungsmethodik sollen wir anwenden?

Dies ist ein Thema, das viele Diskussionen (und oft hitzige Debatten) auslöst.

Wenn Sie noch nicht mit Software-Entwicklungspartnern gearbeitet haben, ist eine Definition der Entwicklungsmethodik angebracht; sehr einfach ausgedrückt, es ist eine Möglichkeit, die Arbeit der Software-Entwicklung zu organisieren.

Hier geht es NICHT um einen Stil des Projektmanagements oder einen bestimmten technischen Ansatz, obwohl Sie diese Begriffe oft alle zusammengewürfelt oder austauschbar verwendet hören werden.

Wasserfall Methodik

Wasserfall ist ein linearer Ansatz zur Software-Entwicklung. Bei dieser Methodik ist die Abfolge der Ereignisse in etwas so

Anforderungen sammeln und dokumentieren
Design und Konzeption der Anwendung
Code- und Einheitentest
Durchführen von Systemtests
Durchführen von Benutzerakzeptanztests (UAT)
Beheben aller identifizierten Mängel und Probleme
Lieferung und Einsatz des fertigen Produkts

In einem echten Wasserfall-Entwicklungsprojekt stellt jede dieser Phasen eine bestimmte Stufe der Softwareentwicklung dar, und jede Stufe wird im Allgemeinen beendet, bevor die nächste beginnen kann. In der Regel gibt es auch ein Stage-Gate zwischen den einzelnen Phasen; beispielsweise müssen die Anforderungen vom Kunden geprüft und genehmigt werden, bevor mit dem Design begonnen werden kann.

Der Wasserfall-Ansatz hat gute und schlechte Seiten.

Mögliche Probleme und Einschränkungen:

Ein Bereich, der fast immer zu kurz kommt, ist die Wirksamkeit von Anforderungen. Das Sammeln und Dokumentieren von Anforderungen in einer für den Kunden sinnvollen Weise ist unserer Erfahrung nach oft der schwierigste Teil der Softwareentwicklung. Kunden werden manchmal durch Details eingeschüchtert, und bei diesem Ansatz sind spezifische Details, die früh im Projekt bereitgestellt werden, erforderlich.
Darüber hinaus sind Kunden nicht immer in der Lage, eine Anwendung aus einem Anforderungsdokument heraus zu visualisieren. Wireframes und Mockups können helfen, aber es steht außer Frage, dass die meisten Endbenutzer einige Schwierigkeiten haben, diese Elemente mit schriftlichen Anforderungen zusammenzufügen, um sich ein gutes Bild davon zu machen, was sie bekommen werden.
Ein weiterer potenzieller Nachteil der reinen Wasserfall-Entwicklung ist die Möglichkeit, dass der Kunde mit seinem gelieferten Softwareprodukt unzufrieden sein wird. Da alle Deliverables auf dokumentierten Anforderungen basieren, kann es sein, dass ein Kunde nicht sieht, was geliefert wird, bis es fast fertig ist. Dann aber können Änderungen schwierig (und kostspielig) zu implementieren sein.

Vorteilhaft ist:

Entwickler und Kunden einigen sich schon früh im Entwicklungslebenszyklus darauf, was geliefert wird. Das macht die Planung und das Design unkomplizierter.
Der Fortschritt lässt sich leichter messen, da der gesamte Umfang der Arbeit im Voraus bekannt ist.
Während der gesamten Entwicklungsarbeit ist es möglich, dass je nach aktiver Phase des Projekts verschiedene Mitglieder des Teams beteiligt sind oder mit anderen Arbeiten fortfahren. Zum Beispiel können Geschäftsanalytiker sich darüber informieren und dokumentieren, was zu tun ist, während die Entwickler an anderen Projekten arbeiten. Tester können Testskripte aus der Anforderungsdokumentation vorbereiten, während die Programmierung läuft.
Mit Ausnahme von Überprüfungen, Genehmigungen, Statusbesprechungen usw. ist eine Kundenpräsenz nach der Anforderungsphase nicht unbedingt erforderlich.
Da der Entwurf früh im Entwicklungszyklus abgeschlossen wird, eignet sich dieser Ansatz für Projekte, bei denen mehrere Softwarekomponenten (manchmal parallel) für die Integration mit externen Systemen entworfen werden müssen.
Schließlich kann die Software auf der Grundlage eines umfassenderen Verständnisses aller Softwareergebnisse vollständig und sorgfältiger entworfen werden. Dies ermöglicht ein besseres Software-Design mit geringerer Wahrscheinlichkeit des „Piecemeal-Effekts“, eines Entwicklungsphänomens, das auftreten kann, wenn Code-Stücke definiert und anschließend zu einer Anwendung hinzugefügt werden, wo sie vielleicht oder vielleicht auch nicht gut passen.
Da Funktionalistät und erwarteter Leistungsumfang abgegrenzt sind, ist es für den Ersteller leichter, den Aufwand zu schätzen und zu einem Festpreis anzubieten.

Agile Methoden

Agil ist ein iterativer, teambasierter Entwicklungsansatz. Es gibt verschiedene Varianten der agilen Entwicklung, die alle einige grundlegende Gemeinsamkeiten aufweisen. Dazu gehören u.a.:

Extreme Programming (XP)
Scrum
Kanban
Lean Software Development
Agile Unified Process

Agile Methoden legen den Schwerpunkt auf die schnelle Bereitstellung einer Anwendung in vollständigen funktionalen Komponenten.

Anstatt Aufgaben und Zeitpläne zu erstellen, wird die gesamte Zeit in Phasen, die als „Sprints“ bezeichnet werden, „zeitlich eingegrenzt“. Jeder Sprint hat eine festgelegte Dauer (normalerweise in Wochen) mit einer laufenden Liste von Deliverables, die zu Beginn des Sprints geplant werden. Die Deliverables werden nach dem vom Kunden festgelegten Geschäftswert priorisiert. Wenn nicht alle für den Sprint geplanten Arbeiten abgeschlossen werden können, werden die Arbeiten neu priorisiert, und die Informationen werden für die zukünftige Sprintplanung verwendet.

Wenn die Arbeit abgeschlossen ist, kann sie vom Projektteam und vom Kunden durch tägliche Builds und End-of-Sprint-Demos überprüft und bewertet werden. Agile verlässt sich auf ein sehr hohes Maß an Kundenbeteiligung während des gesamten Projekts, vor allem aber während dieser Überprüfungen.

Vorteile der agilen Methoden:

Einbeziehung des Auftraggebers und der Nutzer