Agil vs. Wasserfall

• Detaillierte Produktanforderungen und Dokumentation ermöglichen neuen Programmierern einen schnellen und einfachen Einstieg.
• Die Dokumentation gibt einen klaren Umfang für das Projekt vor und ermöglicht es den Projektmanagern, interessierten Parteien Budgets, Zeitpläne und wichtige Meilensteine mitzuteilen.

• Für Kunden kann es schwierig sein, alle ihre Anforderungen zu Beginn des Projekts zu umreißen, was zu Lücken in der Dokumentation führt.
• Eine minimale Zusammenarbeit mit dem Kunden während des Entwicklungsprozesses kann zu kostspieligen Änderungen führen, wenn das Produkt die Erwartungen nicht erfüllt.
• Tester melden später im Prozess Probleme und Fehler, die zu einer alternativen Programmarchitektur hätten führen können.

Im Gegensatz zur Entwicklung mit der Wasserfallmethode zeichnet sich die agile Entwicklung durch ihren iterativen Ansatz für das Projektmanagement aus. Anstatt zu Beginn langwierige Projektanforderungen zu entwerfen, zerlegt ein agiles Team das Produkt in bestimmte Funktionen und bearbeitet jedes einzelne unter einer bestimmten Zeitvorgabe, die als Sprint bezeichnet wird.

Agiles Projektmanagement erfordert ein funktionsübergreifendes, selbstorganisierendes Team, das in der Regel aus fünf bis neun Mitgliedern besteht. Gemeinsam entwickeln sie in jedem Sprint eine funktionsfähige Software, die sich mit anderem funktionalen Code aus früheren Iterationen kombinieren lässt. Am Ende der Sprint-Timebox demonstriert das Team seine Arbeit den Stakeholdern, um Feedback zu erhalten, und ermöglicht ihnen einen flexiblen Ansatz für die Softwareentwicklung. Da das Team Zugang zu häufigem Feedback hat, kann es die Produkt-Roadmap während des Entwicklungszyklus anpassen, um sicherzustellen, dass die Funktionalität wirklich den Erwartungen der Benutzer entspricht. Bei einem Wasserfall-Ansatz fällt die Kundenbeteiligung in der Regel mit der Lieferung des Endprodukts zusammen, was kostspielig sein kann, wenn Anforderungen falsch interpretiert oder falsch dokumentiert werden.

Es gab 17 Personen, die das Wasserfall-Projektmanagementsystem als äußerst ineffektiv fanden, und im Jahr 2001 gipfelten ihre Ideen zum Softwareentwicklungsprozess in einem Werk, das als „Agile Manifesto“ bekannt wurde. Dieses Dokument hebt spezifische Werte und Prinzipien hervor, die innerhalb der Arbeitsabläufe der Softwareentwicklung priorisiert werden sollten, und hat eine Reihe beliebter agile Frameworks hervorgebracht, wie Scrum, Kanban, Funktion Driven Development (FDD) und Extreme Programming. Seitdem erfreut sich die agile Entwicklung von Software zunehmender Beliebtheit, insbesondere im Vergleich zum Wasserfallmodell.

Inspiriert durch das Rugby-Spiel, legt flexibles Scrum den Schwerpunkt auf Teamarbeit, um Ziele zu erreichen, ähnlich wie Stürmer in einem Gedränge zusammenarbeiten müssen, um in den Besitz eines Rugby-Balls zu gelangen. Die Fähigkeiten des agilen Scrum-Teams variieren, aber sie umfassen in der Regel die folgenden Rollen:

• Product Owner: Dieses Teammitglied vertritt die Bedürfnisse sowohl des Kunden als auch des Unternehmens. Durch das Erstellen von User Stories kann das Team verstehen, wie eine Funktion zur Lösung eines bestimmten Problems beitragen kann, und diese Storys formulieren dann den Rückstand an Aufgaben, die das Team bewältigen muss. Diese Person priorisiert die Geschichten auch nach ihrem Wert für den Kunden, was sich theoretisch in einem Wert für das Unternehmen niederschlagen sollte. Der Product Owner führt das Team zwar auf diese Weise, legt aber keine Fristen fest oder weist das Team an, wie die Arbeit geliefert werden soll.
• Scrum Master: Dieses Teammitglied erleichtert den gesamten Prozess der agilen Entwicklung. Ähnlich wie ein Projektmanager hält diese Person das Team bei der Arbeit und stellt sicher, dass das Team während des Projekts konzentriert bleibt. Sie können auch als neutrale Partei fungieren, um Meinungsverschiedenheiten zwischen Teammitgliedern zu vermitteln. So können die Teammitglieder beispielsweise unterschiedlicher Meinung darüber sein, wie viel sie in einem bestimmten Sprint übernehmen sollen. Insbesondere Product Owner können Teams unter Druck setzen, sich zu mehr zu verpflichten, als sie innerhalb eines bestimmten Zeitrahmens liefern können. In diesen Fällen können Scrum-Master die Teammitglieder an den Umfang ihrer Rolle im Team erinnern.

Andere Teammitglieder eines agilen Teams können variieren, aber sie umfassen in der Regel Benutzer aus verschiedenen Disziplinen, wie z. B. Design, Analyse, QA und Entwicklung. Diese Personen arbeiten gemeinsam, um zu entscheiden, wie viel Arbeit sie übernehmen und wie sie diese erledigen wollen.

Agile Methoden zeichnen sich auch durch die Art und Weise aus, wie das Team zusammenkommt. Es gibt spezielle Meetings, die den Workflow im gesamten Team erleichtern. Dazu gehört unter anderem Folgendes:

• Sprint-Planung: Bei diesem Meeting kommt das Team zusammen, um zu entscheiden, welche Storys Teil des aktuellen Sprints sein werden. Der Product Owner priorisiert die User Storys, aber der Rest des Teams muss sich darauf einigen, wie viele und welche User Stories in diesem festgelegten Zeitraum abgeschlossen werden können.
• Tägliches Standup: Diese kurzen Meetings werden auch als Daily Scrums bezeichnet. Während dieser Check-ins kommuniziert jedes Teammitglied seinen individuellen Fortschritt, z. B. abgeschlossene, anstehende Aufgaben und eventuelle Blocker oder Abhängigkeiten, die zu Verzögerungen führen könnten.
• Demo: Bei diesem Meeting wird die funktionierende Software vorgestellt, die das Team im Laufe des Sprints fertiggestellt hat, der in Schritten von zwei bis vier Wochen fertiggestellt werden kann. Der Produktverantwortliche bestimmt, ob eine Benutzerstory die Definition von „erledigt“ erfüllt. Wenn nicht, kann das Product Backlog bearbeitet werden, um alle fehlenden Informationen zu berücksichtigen. Dies ist auch eine Gelegenheit für das Team, es den Stakeholdern zu präsentieren, um Feedback zu erhalten.
• Rückblick: Diese Zeit ist für die Team-Introspektion reserviert, bei der das Team identifiziert, wie es seinen Workflow verbessern kann, um in Zukunft bessere Ergebnisse zu erzielen

• Das Teamdesign fördert mehr Zusammenarbeit.
• Die Produktentwicklung verfolgt einen adaptiven Designansatz.
• Da Code bei jeder Iteration in der Entwicklungsphase getestet wird, können Codefehler das zukünftige Design der Software beeinflussen.
• Steigert tendenziell die Kundenzufriedenheit, da häufiges Feedback zu einer verstärkten Priorisierung der Kundenbedürfnisse führt.
• Ermöglicht die kontinuierliche Integration, da jede Funktion ein eigenständiges, funktionsfähiges Software-Element darstellt.
• Diese schlanke Art der Softwareentwicklung kann zu niedrigeren Kosten führen, da das Risiko einer Fehlausrichtung von Kunden und Produkt geringer ist.

• Ein agiler Ansatz kann an umfassender Dokumentation mangeln. Dies erschwert das Onboarding neuer Entwickler, die Einhaltung von Projektzeitplänen für Stakeholder und die Bereitstellung genauer Kostenschätzungen.
• Skalierung kann schwierig sein.

Während die Entwicklungsteams bei beiden Projektmanagementansätzen erfolgreich waren, gibt es sicherlich mehr Schwung bei agilen Prozessen. Der Grund dafür ist unschwer zu erkennen, wenn man den Nutzen betrachtet, die es Unternehmen heute bieten kann. Es gibt zwar eine Reihe von Projektmanagement-Tools, mit denen Teams den Fortschritt verfolgen können, IBM kann jedoch auch Systeme bereitstellen, die es Entwicklern ermöglichen, agil zu programmieren.