Bekanntermaßen ist die strikte Abarbeitung eines Entwicklungsvorhabens streng gestaffelt nach Phasen eher schwierig. Das Hauptproblem besteht darin, dass eine vollständige und korrekte Erhebung der Anforderungen zu Projektbeginn nahezu unmöglich ist. Dieses hat mehrere Ursachen. Die wichtigsten sind:

  • Unvollständigkeit der Anforderungen zu Beginn des Projektes
  • Dynamische Änderungen während der Projektlaufzeit in den Geschäftsmodellen
  • lange Projektlaufzeiten, teilweise von mehreren Jahren.

Eine Tatsache ist, dass auch die Kunden und die späteren Nutzer der Software oft nur eine ungefähre Vorstellung davon haben, in welcher Form eine Software das bestehende Problem lösen soll. Darüber hinaus ist es schwierig, diese ungefähren Anforderungen den Entwicklern der Software zu vermitteln, beispielsweise sie für diesen Zweck auch vollständig und nachvollziehbar zu dokumentieren. Ein weiteres Problem ergibt sich aus der Dynamik der Geschäftsmodelle. Anforderungen und Rahmenbedingungen, welche zum Zeitpunkt der erstmaligen Analyse galten, sind nicht über die gesamte Projektlaufzeit konstant. Dabei ist zu beobachten, dass das Ausmaß an Dynamik im Laufe der Zeit zunimmt. Da die zu erstellenden Anwendungssysteme immer komplexer und umfangreicher werden, nehmen auch die Laufzeiten der Projekte zu. Dieses wirkt sich ebenso negativ auf die Möglichkeiten einer umfassenden Planung aus. Je länger die Zeitspanne zwischen dem Projektstart und der endgültigen Bereitstellung der Software ist, desto schwieriger wird es, die dann geltenden Kundenanforderungen zu erfüllen.
Die agilen Methoden sind nicht wie aus dem „Himmel gefallen“, sondern sie sind die Folge einer längeren zeitlichen Entwicklung (Bild 1):

BIld 1: Entwicklungsmethoden in historisch zeitlicher Folge.

In den 1980er und frühen 1990er Jahren wurde ein großer Wert auf sorgfältige Projektplanung und formalisierte Qualitätssicherung gelegt. Die Entwicklung erfolgte oft in großen Teams. Im Ergebnis wurde oft mehr Zeit für die Planung der Entwicklung aufgewendet als für die tatsächliche Programmentwicklung und die nachfolgenden Tests. Trotz dieses sehr planvollen und stark phasengetriebenen Vorgehens waren die Ergebnisse nicht immer zufriedenstellend. Zu viele Projekte scheiterten oder konnten die Anforderungen und Wünsche der Kunden nicht erfüllen. Im Ergebnis wurden erstmalig Mitte der 1990 Jahre von „agilen“ Methoden gesprochen. Das Ziel war schnell formuliert: Die Entwickler sollten sich verstärkt um ihren eigentlichen Job der Programmentwicklung kümmern und nicht mehr so viel Zeit für den Entwurf und Dokumentation aufwänden. „Agilität“ steht also für die Fähigkeit, mit Änderungen umzugehen, d.h. schnell und flexibel auf Kundenanforderungen zu reagieren. Änderungen werden nicht mehr als störend aufgefasst, sondern tragen dazu bei, dass das Anwendungssystem frühzeitig in die richtige Richtung gesteuert wird. Ein wesentliches Ziel dieses Vorgehens ist es, möglichst in kurzer Zeit eine erste Version des späteren Endproduktes an den Kunden auszuliefern und bereits in sehr frühen Phasen des Entwicklungsprozesses mit Prototypen zu arbeiten. Frühe produktionsfähige Produktversionen sind zwar im Funktionsumfang eingeschränkt, sie geben jedoch den Anwendern die Möglichkeit rechtzeitig Feedback zu geben. Das Feedback ist wiederum die Ausgangsbasis, um mögliche Modifikationen zeitnah in den weiteren Projektverlauf einzuarbeiten.
Es gibt unterschiedliche Ansätze agiler Entwicklungsmethoden. Scrum gilt heute als sehr weit verbreitet, hat sich vielfach bewährt und ist gut akzeptiert. Einige agile Methoden im Überblick:

  • Extreme Programming: Extreme Programming, oder kurz XP wurde in den Jahren 1995-2000 von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. Der Name wurde dadurch geprägt, dass die gut bekannten Praktiken, beispielsweise iterative Entwicklung, „ins Extreme“ gesteigert wurden. Durch XP ist es möglich mehrere neue Versionen eines Programms an einem Tag zu entwickeln, zu integrieren und zu testen. Ziel ist es die Entwicklung der Software den gegebenen Bedingungen anzupassen und diese fortlaufend zu verbessern. Die Anforderungen werden in Form von User Stories zusammengefasst und anschließend als eine Folge von Aufgaben implementiert. Welche User Story als nächste in ein Release aufgenommen wird, bestimmt sich auf Grund von der zur Verfügung stehenden Zeit und der zugeordneten Priorität. Großer Wert wird auf paarweise Zusammenarbeit, d.h. Pair-Programming, gelegt. Die Ergebnisse werden auf diese Weise sofort überprüft. Mit Ihrem Programmierpartner unterstützen Sie sich jederzeit gegenseitig. Statt erst Programmcode zu schreiben und dann umfangreich nach möglichen Fehlern zu suchen, dreht man den Spieß einfach herum. Bevor man zum Code schreiben übergeht, werden Tests für die einzelnen Aufgaben entwickelt. Diese sollen mit Erfolg abgeschlossen werden, bevor neuer Code in das System integriert wird. Nach Fertigstellung einer Aufgabe ist diese auch sofort in das System zu übernehmen. Diese Art des Vorgehens wird als Test-Driven-Development bezeichnet. Die Prinzipien von XP sind daher: inkrementelle Planung, einfacher Entwurf und kleine Releases, kollektives Arbeiten, Pair-Programming, Test-Driven-Development und Kunde vor Ort. Mit dem letzten Aspekt ist gemeint, dass ein Kundenbevollmächtigter am Entwicklungsprozess kontinuierlich beteiligt wird. Dieser soll dem XP-Team ständig zur Verfügung stehen. Er ist dafür verantwortlich, dem Team die Systemanforderungen mitzuteilen und Akzeptanztests für das System durchzuführen. Der Kunde arbeitet gewissermaßen aktiv am Projekt mit.
  • Scrum: Das ist die häufigste angewendete agile Methode, welche als Rahmenwerk für agile Prozesse bekannt ist. Wir stellen sie etwas ausführlicher vor. Dabei handelt es sich um kein Modell, welches das agile Vorgehen konkret beschreibt bzw. konkrete Techniken vorgibt. Scrum gibt nur den Rahmen vor. Der Begriff „Scrum“ stammt aus der Sportart Rugby. Dabei stehen sich zwei gegnerische Mannschaften gedrängt („Scrum“ = „Gedränge“) gegenüber und versuchen den Ball zu erkämpfen. Ein selbstorganisiertes Entwicklerteam steht im Mittelpunkt von Scrum. Der Scrum Master bildet eine Schnittstelle zwischen dem Team und den Produktverantwortlichen. Er sorgt dafür, dass der Entwicklungsprozess reibungslos abläuft. Die Idee ist, dass bei umfangreichen Projekten der Erfolg nur durch ein regelmäßiges Feedback zu erreichen ist. Dadurch werden die Abweichungen vom Soll schnell erkannt und notwendige Anpassungen ermöglicht. Die gesamte Entwicklung wird in Iterationen mit einer Dauer zwischen einer und vier Wochen strukturiert und durchgeführt. Diese Iterationen werden als Sprints bezeichnet. Die Sprints haben eine feste Dauer und enden unabhängig davon, ob die Aufgabe abgeschlossen werden konnte oder nicht. Die Produktanforderungen des Kunden werden vor dem Sprint in einem Product Backlog gesammelt. Dieses wird fortlaufend vervollständigt. Das Team entscheidet über die Priorisierung der Anforderungen bzw. Aufgaben. Jeder Sprint endet mit der Überprüfung der Ergebnisse (Sprint Review) und Reflektion der Prozesse (Sprint Retrospektive). Am Ende jedes Sprints steht eine lauffähige, getestete und inkrementell verbesserte Software zur Verfügung. Scrum unterscheidet zwischen drei Rollen: Der Product Owner repräsentiert in Scrum die Kundenbedürfnisse. Im besten Fall ist er der Kunde selbst oder ein vom Kunden bevollmächtigter Vertreter. Er trifft eigenständig und zügig qualifizierte Entscheidungen über das Produkt. Er steuert die Softwareentwicklung und arbeitet mit dem Team während des ganzen Projekts eng zusammen. Der Product Owner koordiniert die Kundenanforderungen und priorisiert sie im Product Backlog. Er definiert Anforderungen und deren Akzeptanzkriterien und nimmt die Arbeitsergebnisse des Teams ab. Der Scrum Master ist der Coach für das Team. Er hilft den Team Mitgliedern Scrum richtig einzusetzen. Seine Rolle ist umso wichtiger, je weniger Erfahrung das Team mit Scrum hat. Der Scrum Master hat im Projekt keine spezifischen Verantwortlichkeiten und Aufgaben, die unmittelbar mit der Umsetzung desselben zu tun haben. Wenn ein Scrum Master seine Arbeit gut macht und das Team richtig zusammenarbeitet, wird er kaum noch benötigt. Das Team hilft sich in allen Situationen selbst. Das Scrum Team hat die zentrale Rolle, da es alle Arbeiten ausführt, die zur Umsetzung der Anforderungen notwendig sind. Es ist von Vorteil, wenn die Mitglieder in einem Scrum Team über ein breites Spektrum an Wissen verfügen. Dieses Wissen darf sich nicht in den Köpfen von Spezialisten konzentrieren, sondern es muss gemeinsames Wissen des gesamten Teams sein oder werden. Die Team Mitglieder bezeichnet man auch gerne als „generalistische Spezialisten“. Das Team organisiert sich selbst (empowered team), d.h. es entscheidet über eine Vielzahl von Dingen selbstverantwortlich. Hierdurch entsteht eine höhere Identifikation mit dem Projekt und das Verantwortungsgefühl steigt. Insbesondere schätzt das Team selbst die Aufwände für die einzelnen User Stories, und es übernimmt die Verantwortung, dass diese richtig konzipiert sind. Ein wichtiger Punkt ist das „commitment“ im jeweiligen Sprint auf bestimmte User Stories. Dabei entscheidet das Team, welche und wie viele User-Stories es im nächsten Sprint umsetzen kann. Jeder Mitarbeiter kann unabhängig von seiner Position eine der drei Rollen annehmen.
  • Ein zentrales Merkmal von Scrum sind regelmäßige, kompakte und ergebnisorientierte Meetings. Sprint Planning Meetings sind so genannte Start Meetings für den jeweiligen Sprint und diese werden in zwei Schritten ausgeführt. Dies sind die Festlegung des Inhalts des nächsten Sprints und die Erstellung des Sprint Backlogs. Das Sprint Review wird am Ende jedes Sprints durchgeführt und dient zur Überprüfung und Abnahme des Produkt-Inkrements durch den Product Owner. Dabei müssen Sie die Ergebnisse präsentieren und zeigen, dass die von Ihnen entwickelten Features funktionieren. Durch die regelmäßige Durchführung bekommen Sie immer sofort ein Feedback und eine Entwicklung in die falsche Richtung kann ausgeschlossen werden. Die Sprint Retrospektive zielt im Gegensatz zum Sprint Review auf eine Analyse der Zusammenarbeit während des vorangegangenen Sprints ab. Es ist für die Qualität nicht nur wichtig, dass die Features auch funktionieren, sondern für alle Beteiligten ist es auch äußert interessant, wie Sie die Ergebnisse erreicht haben. Welchen Programmieransatz haben Sie gewählt? Gibt es vielleicht eine einfachere Lösung zum Ziel? Aus der gemeinsamen Betrachtung ziehen Sie Schlüsse für den nächsten Sprint. Das Daily Scrum umfasst tägliche 15-minütige Meetings des Teams unter Beteiligung des Scrum Masters und eventuell des Product Owners. Diese dienen hauptsächlich dem Informationsaustausch des Teams untereinander. Hier wird Ihnen meist kein Sitzplatz zur Verfügung gestellt. Ganz im Sinne der Dynamik und der effizienten Arbeitsweise erfolgt die kurzfristige Zusammenkunft meist im Stehen. Eine Tasse Kaffee ist aber erlaubt 😊.
  • Grundsätzlich verfolgt jedes Scrum Meeting das Ziel die Ergebnisse zu analysieren und die daraus resultierenden Anpassungen unmittelbar umzusetzen. Ein wichtiges Kriterium für den Projekterfolg ist die Teamarbeit. Eine weitgehend reibungslose Zusammenarbeit zwischen den Teammitgliedern wird angestrebt. Bei der Teamgröße sollte man sich daher auf maximal zehn Mitglieder beschränken. Bewährt haben sich Teilteams von durchaus nur sechs Mitgliedern. Diese müssen Programmier-, Projekt- und Teamerfahrung haben.
  • Unified Process: Es handelt sich um ein iteratives und inkrementelles Framework für Softwareentwicklungsprozesse. Die bekannteste und umfassend dokumentierte Verfeinerung des vereinheitlichten Prozesses ist der Rational Unified Process.
  • Feature Driven Development (FDD): Es ist eine Sammlung von Methoden, Arbeitstechniken, Strukturen und Rollen für das agile Projektmanagement, welche den Begriff „Feature“ in den Mittelpunkt setzten. Die gesamte Entwicklung wird anhand eines Feature Plans organisiert und umgesetzt.
  • Agile Model Driven Development (AMDD): Ist eine agile Version des Models Driven Developments (MDD). MDD ist ein Ansatz zur Softwareentwicklung, bei dem umfangreiche Modelle erstellt werden, bevor der Quellcode geschrieben wird. Bei AMDD erstellen Sie nur minimale Modelle. Diese müssen gerade noch gut genug sein, um die Entwicklung voranzutreiben.
  • Dynamic Systems Development Method (DSDM): Das ist eine Erweiterung des Rapid Applications Development Ansatzes, welche die kontinuierliche Einbindung der Anwender betont. Die Methode wurde ursprünglich in den 1900er Jahren in Großbritannien durch das DSDM-Konsortium entwickelt, wird noch heute weiterentwickelt und erfolgreich eingesetzt.

Literatur und Links

[1] Bächle, M.; Kolb, A.: Einführung in die Wirtschaftsinformatik, 3. Auflage, Oldenburg Verlag, 2012

[2] Eeles, P: Architecture, Agile and DevOps, https://www.researchgate.net/publication/330202499_Architecture_Agile_and_DevOps