≡ Menu

Software agil entwickeln mit Scrum

Irgendwann kursierte bei uns im Freundeskreis mal die Bemerkung, man wisse nicht so genau, “was ich eigentlich den ganzen Tag mache”. Das habe ich zum Anlass genommen, meine Tätigkeit mal von einem nicht-technischen Standpunkt aus zu betrachten. Ein für mich wesentlicher Bestandteil: Agile Softwareentwicklung mit Scrum.

Scrum beim Rugby

Gerade größere Softwareprojekte leiden unter dem Ruf, weder innerhalb des Zeitplans noch innerhalb des Budgets abgeschlossen zu werden — und wenn überhaupt, dann meist mit der schmerzhaften Einschränkung, dass dringend benötigte Funktionen nur teilweise umgesetzt wurden. Um dem entgegenzutreten, finden in der Branche immer häufiger agile Methoden Anwendung. (Manche gehen sogar so weit, agile Softwareentwicklung als Mainstream zu bezeichnen.)

Agile Softwareentwicklung versucht, typische Probleme bei der Entwicklung von Software zu vermeiden, indem Bürokratie vermieden und der Fokus auf die zu erreichenden Ziele gelegt wird.

Scrum (“Gedränge”) ist nur eine von vielen Möglichkeiten, Software agil zu entwickeln. Auf andere Methoden gehe ich hier nicht ein, weil sich mein Wissen über agile Methoden auf Scrum beschränkt. (Leider sind für mich agile Methoden im Allgemeinen und Scrum im Speziellen nicht immer klar voneinander abgegrenzt, eben weil ich bisher nur mit Scrum gearbeitet habe.) Scrum project management eliminates time spent going in the wrong direction sollte aber genauso für andere Ansätze gelten.

Scrum: In Sprints zu vorzeigbaren Ergebnissen

Nach der Scrum-Methode wird Software in sehr kleinen Schritten (“Sprints”, in der Regel zwei bis drei Wochen) entwickelt, ohne das gesamte Projekt von hinten bis vorne durchzuplanen. Ziel dieser iterativen Entwicklung ist es, möglichst schnell lauffähige Software zu erhalten.

Das ist weniger der Unlust am Planen geschuldet als vielmehr der Einsicht, dass die detaillierte Planung für einen größeren Zeitraum sowieso beliebig nutzlos sein wird. Im Alltag würde niemand auf die Idee kommen, sämtliche Mahlzeiten für das nächste halbe Jahr durchzuplanen, nur um sich möglichst ausgewogen und abwechslungsreich zu ernähren. So wie kaum jemand die Einzelheiten der Erziehung seines Kindes bis zur Volljährigkeit festlegen dürfte.

Man fängt also klein an und entwickelt einen Bruchteil der Software — der für sich genommen einen Nutzen darstellt. Ist der fertig, kann man darauf aufbauend eine gut informierte Entscheidung treffen, was als Nächstes zu tun ist.

Schneller sehen, wohin die Reise geht

Die Vorteile für den Auftraggeber dieses Rennens zur laufenden Software liegen auf der Hand: Er erhält schnelles Feedback und sieht, in welche Richtung sich das Produkt entwickelt — und ob das mit seinen Erwartungen übereinstimmt. Damit kann er während der Entwicklung Einfluss nehmen und z.B. einige Details noch weiter ausarbeiten und dafür weniger wichtige Dinge zurückzustellen oder ganz fallen zu lassen. Im schlechtesten Fall kann ein Projekt ganz eingestampft werden, bevor ein ganzes Jahr (oder zwei) vergangen und das Budget vollständig aufgebraucht ist.

Für das Team bietet Scrum schnelle Erfolgserlebnisse (auch durch die kurzen Feedback-Schleifen mit dem Auftraggeber), eigenständiges und selbstorganisiertes Arbeiten und vor allem die Möglichkeit, den eigenen Prozess und damit das Produkt zu verbessern. Wenn Fehler frühzeitig erkannt werden, die Richtung der Entwicklung noch geändert werden kann und in Retrospektiven regelmäßig über den vergangenen Sprint nachgedacht wird, erhöht das die Produktivität und verbessert das Endprodukt.

Natürlich ist auch Scrum kein Allheilmittel: Gerade die oben angesprochene hohe Verbreitung von agilen Methoden erhöht die Gefahr, Prozesse zu verwässern und “agil” als Marketing-Etikett zu missbrauchen. Scrum erfordert von allen Beteiligten viel Disziplin und den Mut, die eigene Arbeitsweise zu hinterfragen — und zwar nicht einmalig, sondern während des gesamten Projektes. Wer dazu bereit ist, wird Software nicht mehr anders als agil entwickeln wollen.

[Foto von royskeane, CC-Lizenz]

Comments on this entry are closed.

  • Benjamin Asen 6. März 2010, 08:54

    Schön und informativ geschrieben!

  • André 21. April 2010, 09:39

    Danke, freut mich zu hören!

  • Sebastian Schneider 7. November 2010, 22:19

    Hallo André,

    mal so ins Blaue gefragt, mit wie vielen Anforderungen startet ihr denn so im Backlog bei typischen Projekten?

    Grüße
    Sebastian

  • André 14. November 2010, 22:07

    Sebastian: Von einer sehr kleinen Anzahl ausgehend würde ich aus dem Bauch heraus sagen, dass es so zwischen einer Handvoll und einem Dutzend waren. Kommt natürlich auf die Projektgröße an.

    Und meist wächst die Anzahl der Anforderungen sprunghaft an, wenn man erstmal angefangen hat… ;-)