Agile Softwareentwicklung ist in der heutigen Zeit aus der Softwareentwicklung kaum mehr wegzudenken, und das aus gutem Grund. Durch die Erfahrung aus einer Vielzahl von Projekten hat sich herausgestellt, dass es sehr schwierig ist, am Projektanfang alle Informationen zu sammeln, wie das eigentliche Produkt am Ende aussehen soll. Dazu kommt, dass sich viele Anforderungen auch auf Kundenseite erst im Laufe des Projekts entwickeln, beispielsweise wenn er einen Einblick in die Möglichkeiten bekommt oder anfängt mit den Prototypen die Funktionalität zu testen. Trotzdem ersetzt aber auch ein agiler Prozess nicht eine initiale Planung und die grobe Darstellung darüber, welche Ziele man erreichen will. Nur so kann verhindert werden, dass man die Entwicklung in eine falsche Richtung startet oder dass in der Softwarearchitektur Fehler passieren, die später zu Mehrkosten führen. Wir empfehlen daher bei unseren Kunden eine dem Umfang des Vorhabens angepasste Anforderungsanalyse mit uns durchzuführen.
Aber wie sieht jetzt eine agile Softwareentwicklung aus? Grob beschrieben arbeitet man in meist kurzen und iterativen Entwicklungszyklen. Nach jedem Zyklus werden die Ergebnisse mit dem Kunden besprochen und es kann allenfalls die Richtung der Entwicklung angepasst werden. Dadurch werden die Anforderungen kontinuierlich angepasst und verfeinert und man kann auf unvorhergesehenes gut reagieren. Damit aber nicht jeder das Rad neu erfindet und seinen eigenen agilen Prozess definiert haben sich Standards dafür durchgesetzt. Eines der beliebtesten Frameworks für agile Softwareentwicklung ist Scrum, welches wir hier weiter beschreiben wollen. Wir zeigen, wie es funktioniert und warum es eine effektive Möglichkeit ist, Software zu entwickeln.
Was ist Scrum?
Scrum ist eine agile Methodik zur Erhöhung der Produktivität und Qualität in der Softwareentwicklung. Die Kernidee hinter Scrum ist, dass es große Softwareentwicklungsprojekte in kleinere, überschaubarere Teile zerlegt. Dies ermöglicht es Teams, sich auf bestimmte Aufgaben oder Funktionen in einem bestimmten Sprint zu konzentrieren, und gibt ihnen die Flexibilität, sich anzupassen, wenn neue Ideen oder Anforderungen auftauchen. Herzstück von Scrum ist das "Scrum Team", das aus drei wesentlichen Rollen besteht: dem Product Owner, dem Scrum Master und dem Development Team.
Wie funktioniert Scrum?
Im Zentrum steht ein sich wiederholender (iterativer) Entwicklungszyklus, der Sprint genannt wird, und der in der Regel 2 Wochen dauert. Damit die Entwicklung in den sogenannten Sprints absolviert werden kann müssen die Anforderungen zuerst aufbereitet und schriftlich festgehalten werden. Diese Aufgabe erledigt typischerweise der Product Owner, der den Überblick über die funktionale Entwicklung des Projekts hat. Dabei kann er einerseits mit einem Kunden zusammenarbeiten, der in verschiedenen Meetings mit ihm die Anforderungen erarbeitet oder der Kunde selbst kann in die Rolle des Product Owner schlüpfen. In einem nächsten Schritt werden diese Anforderungen in einem Backlog in Arbeitspakete aufgeteilt. Hierbei gibt es verschiedene Elemente, die zur Strukturierung zur Verfügung stehen. So kann man beispielsweise in Jira als oberstes Element ein «Epic» erstellen, dass einen ganzen Themenbereich umfasst (ein Beispiel dafür wäre die Warenverfolgung im internen Lager). Innerhalb eines Epic kann es dann verschiedene Stories geben. Eine solche würde beispielsweise die Interaktion zwischen dem Lagermitarbeiter mit dem System beschreiben, wenn er ein bestimmtes Produkt im Lager sucht. Die Story wird dann in Tasks (Aufgaben) unterteilt, beispielsweise die Entwicklung eines Suchfensters für Produkte aus dem Lager. Zusätzlich können dann auch noch Aufgaben in noch kleinere Pakete aufgeteilt werden, sogenannte Sub-Tasks.
Ziel dieser Struktur ist es das komplexe Anforderungen zu handhabbaren kleinen Arbeitspaketen heruntergebrochen werden können, von denen ein Programmierteam innerhalb von 2-Wochen einige vollständig umsetzen kann.
In einem nächsten Schritt kommt es zu der Sprint Planung. Hier «verhandelt» der Product Owner mit dem Scrum Master (und oft ist auch das Team dabei) welche Pakete in dem nächsten 2 Wochen-Sprint umgesetzt werden sollen. Hier versucht man mit Erfahrungswerten möglichst gut den Aufwand abzuschätzen. Eine intensive Planung ist nicht gedacht, da dies zu viel Zeit in Anspruch nehmen würde. Es gibt auch verschiedene Ansätze wie die Aufwandsabschätzung unterstützt werden kann, beispielsweise durch Sprint Planning Poker, auf das wir hier aber nicht eingehen möchten.
Während des Sprints trifft sich das Team regelmäßig (z.B. 15 Minuten Daily Meeting), um seine Fortschritte zu besprechen und den Plan bei Bedarf anzupassen. Am Ende des Sprints präsentiert das Team seine Arbeit dem Product Owner und gemeinsam wird geprüft ob alle Anforderungen erfüllt wurden. Je nach Ergebnis wirkt sich das auf den nächsten Sprint und dessen Planung aus (muss beispielsweise an einer Anforderung nachgebessert werden, war eine Anforderung umfangreicher als ursprünglich angenommen)?
Abschliessend hat das Team noch intern ein sogenanntes Retrospektive Meeting. Dabei wird intern reflektiert was gut gemacht wurde und wo eventuell Fehler passiert sind. Gemeinsam versucht man dann Verbesserungen zu finden, um die Fehler in Zukunft zu vermeiden und so mit jedem Sprint auch besser zu werden.
Warum ist Scrum effektiv?
Einer der Hauptvorteile ist, dass Kunden transparent eine schnelle Rückmeldung über den Fortschritt eines Projekts bekommen, spätestens am Ende eines kurzen Sprints von 2 Wochen. Darüber hinaus ist es für alle Beteiligten sehr leicht nachvollziehbar, was wird gerade umgesetzt und wie schnell geht die Entwicklung voran. Das schafft besonders für den Kunden eine hohe Transparenz und verhindert, dass es später Überraschungen gibt. Aber auch das Team erhöht seine Effizienz durch kleine Arbeitspakete, kann so jeder Entwickler innerhalb eines Sprints sich ein Paket aussuchen, dass ihn besonders interessiert oder wo er sich sehr gut auskennt.
Ein nicht zu unterschätzender Vorteil der hohen Einbindung des Kunden durch den iterativen Prozess ist auch die Weiterentwicklung der Anforderungen. Oftmals verändern sich Anforderungen über die Zeit eines Projekts. Das passiert einerseits dann, wenn Kunden sich neuer Möglichkeiten bewusstwerden, nachdem sie mit einem Prototyp interagiert haben. Auf der anderen Seite können aber auch Anforderungen wegfallen, da man in der neuen Oberfläche deren Nutzen nicht mehr sieht. Solche Entwicklungen sind am Anfang sehr schwer vorherzusehen und sind natürlich eine Stärke eines agilen Entwicklungsprozesses.
Abschliessend sei noch erwähnt, dass das kontinuierliche Testen der Zwischenschritte die Qualität der gesamten Lösung verbessert. Einerseits wird dadurch die Software allgemein öfters getestet und Fehler werden frühzeitig entdeckt. Dadurch können diese recht einfach behoben werden, ohne dass weitere Entwicklungen darauf aufbauen. Auch ist das Wissen über die Funktionen bei den Entwicklern noch frisch und man muss sich nicht erst viel später wieder in die Logik hineindenken.
