Was ist agile Softwareentwicklung?
Viele Unternehmen wollen ihre Produkte heutzutage agil umsetzen. Bei der weiteren Planung stellt sich oft ein Unverständnis heraus, was sich hinter diesem Begriff verbirgt. Warum wir bei mindforce agile Vorgehensweise zu schätzen wissen und was sie dabei von der Sowjetunion lernen können, verraten wir Ihnen im folgenden.
Geschichtliche Hintergründe
Dass seit dem Untergang der Sowjetunion im Dezember 1991 auch die Planwirtschaft weitestgehend Geschichte ist, hört sich erstmal einleuchtend an. Umso erstaunlicher: Viele deutsche Unternehmen halten an diesem überholten Wirtschaftssystem fest. Bei der Projektplanung werden Aufgabenpakete geschnürt, die dann in den nächsten paar Jahren unverändert umgesetzt werden sollen. Bestenfalls folgt dann nach erfolgreichem “Abschluss” des Projekts eine Anpassung an die “unerwartet veränderten Marktbedingungen”. Schlimmstenfalls hat das Unternehmen viel Geld in den Sand gesetzt und ist pleite. Bekannt ist dieses Prinzip auch von diversen deutschen Großbauprojekten.
Agile Softwareentwicklung nach Scrum
Mindforce lebt in Projekten häufig eine agile Softwareentwicklung nach Scrum. Darunter verstehen wir ein Framework für Entwicklungen. In diesem sind die Rollen und Aufgaben der einzelnen genau Beteiligten festgelegt. Einheitliche Begrifflichkeiten beugen dabei Missverständnissen vor und schaffen Klarheit.
Wenn Sie aber noch nicht nach Scrum gearbeitet haben, lassen Sie sich nicht verunsichern: Das Framework lässt sich nach Absprache an die jeweiligen Rahmenbedingungen anpassen oder auf einige Elemente reduzieren. Sie müssen nicht erst alle Scrum-Begrifflichkeiten pauken, um agile Softwareentwicklung einzusetzen. Darum möchten wir Ihnen im folgenden eine kurze Beschreibung geben, wie und warum wir agil vorgehen.
Gute Gründe für agile Softwareentwicklung
Dabei müssen Sie sich noch nicht mal ein langjähriges Projekt vorstellen, um die Vorteile agilen Arbeitens zu erkennen. Auch bei vergleichsweise kleinen Projekten ist zu Beginn der Entwicklung noch nicht alles bekannt, was sich später als relevant herausstellt. Hinterher heißt es dann: “Hätten wir das doch nur früher gewusst!”
Beim agilen Vorgehen legen Sie zunächst nur fest, in welche Richtung es gehen kann. Genauer gesagt formulieren Sie als Product Owner Anforderungen an Ihr zu entwerfendes Produkt: “Ich möchte, dass das System folgendes kann: …” Diese Anforderungen beschreiben Sie immer aus einer bestimmten Sicht heraus: “Als Anwender im Vertrieb möchte ich, dass…” Wir nennen eine solche Beschreibung Userstory. Für den jeweiligen Anwender schreiben Sie dabei stellvertretend eine kurze Geschichte, welche Funktionalität er erwartet.
Damit sind konkrete Ziele definiert, die einzelne Projektbestandteile umfassen. Aus den Erfahrungen, die in der Projektlaufzeit gesammelt werden, können sich auch geänderte Anforderungen an das Projekt ergeben. Diese lassen sich leichter einplanen als bei einer monolithischen, “planwirtschaftlichen” Planung. Dieser Planungsprozess wird vom sogenannten Scrum-Master geleitet.
Planning, Review und Daily
Aus diesen Anforderungen werden dann einzelne Arbeitspakete geschnürt. Diese sollten inhaltlich so konkret formuliert sein, dass ein Entwickler sie anschließend eigenständig umsetzen kann. Bevor dies geschieht, ist jedoch eine entscheidende Phase zwischengeschaltet: Das Sprint-Planning. Dabei bezeichnet ein Sprint einen vorher festgelegten Zeitraum von beispielsweise zwei oder drei Wochen. Zu Beginn jeden Sprints treffen sich die Beteiligten und diskutieren über die Userstories: Sind sie eindeutig genug? Gibt es klar definierte Akzeptanzkriterien? Ergibt die Userstory überaupt Sinn, oder soll sie nochmal abgewandelt werden?
Anschließend schätzen die Entwickler mit dem Scrum-Master den Umfang der Userstories ab. Dabei bedienen sie sich einer groben Einteilung in Kategorien, z.B. 2h/4h/1d/2d. Eine Userstory, die noch mehr Zeit veranschlagt, zerteilen sie eher in kleinere Aufgaben. Alternativ sind auch T-Shirt-Größen (XS/S/M/L) oder abstrakte Punktwerte denkbar, die sich in die Zeiten übersetzen lassen.
Jeder Entwickler übernimmt nun Aufgaben, die ihn etwa für die Zeit des Sprints auslasten werden. Sollten Aufgaben übrig bleiben, wandern sie ins Backlog und später in den nächsten Sprint. Um den Fortschritt zu kontrollieren und auf etwaige Probleme reagieren zu können, treffen sich die Entwickler und der Scrum-Master jeden Morgen beim Daily. Darin erläutert jeder, was er am letzten Tag geschafft und sich für den aktuellen Tag vorgenommen hat.
Um den aktuellen Fortschritt nachzuvollziehen, nutzen wir in vielen Projekten ein Kanban-Board. Darin listen wir die Userstories ihrem Status nach auf. Eine mögliche Einteilung wäre “To do – In progress – In Review – Ready for Deployment – Done”. Am Ende jeden Sprints steht das Sprint-Review zur abschließenden Bestandsaufnahme: Wurden die geplanten Aufgaben umgesetzt, oder musste die Aufwandsschätzung revidiert werden? Welche Erkenntnisse gab es dabei, die vielleicht eine Neubewertung der Aufgaben im Backlog bedingen?
Fazit
Oft fragen unsere Ansprechpartner ganz begeistert an, ob wir agile Softwareentwicklung beherrschen. Das hört sich allerdings meist so an: “Wir möchten agil arbeiten, und nach 6 Sprints soll folgender Funktionsumfang vorhanden sein: …” Dabei ist ein wesentliches Merkmal agilen Vorgehens, dass niemand zu Beginn genau festlegen kann, wie das Endergebnis aussieht. Vielleicht kamen Userstories auf, die so zunächst gar nicht eingeplant waren? Diese haben dann womöglich andere Versionen ersetzt? Vielleicht sind dabei andere Funktionen ganz außen vor geblieben? Indem Sie offen für Veränderungen bleiben, sind Sie auch offen für Verbesserungen.
