Softwareentwicklung:
Scrum: Stärken und Schwächen eines Vorgehensmodells

von Werner Fritsch (werner.fritsch@crn.de), Anton Dechko

Share
16.07.2010

Jedes Softwareentwicklungsprojekt sieht hinsichtlich Größe, Komplexität oder verwendeter Technologie anders aus. Die zahlreichen Vorgehensmodelle geben unterschiedliche Antworten auf Fragen zur Gewährleistung der Qualität, zum effektiven Einsatz der Entwickler und zur transparenten Organisation. Eine gewichtige Stimme hört auf den Namen Scrum.

Keine Beiträge im Forum. » Diskussion starten!

Quelle: Fotolia

Scrum gehört zu den sogenannten agilen Methoden und damit zu den leichtgewichtigen Vorgehensweisen in Softwareentwicklungsprojekten. Leicht- und schwergewichtige Modelle unterscheiden sich in der Anzahl der definierten Prozesse und der Toleranz gegenüber den für Prozesse und Dokumentationen festgelegten Anforderungen. Die zentrale Frage ist, wie viel Aufwand für Verwaltung und Dokumentation in einem Projekt getrieben werden soll. Eine häufige, aber falsche Vorstellung vertritt die Auffassung, dass formalisierte Modelle altmodisch, bürokratisch und unflexibel sind. Agile Ansätze gelten, ebenso falsch, als weitgehend frei von Verpflichtungen.

Leichtgewichtige Vorgehensmodelle stellen die Personen ins Zentrum, schwergewichtige hingegen die Abläufe. Quelle: SaM

In realen Entwicklungsprojekten geht es immer um Planung und Dokumentation. Schwere Modelle kümmern sich darum so früh wie möglich, setzen auf detaillierte Budgetierung sowie ein umfassendes Risikomanagement. Einmal festgelegte Prozesse werden danach nur noch implementiert. Bei leichten Modellen geschieht dies parallel zur Entwicklung und kann auch später noch angepasst werden. Ein zeitlicher Überblick entsteht in der Folge aus den empirischen Daten der Teamgeschwindigkeit und durch aktives Scope-Management, also der Beurteilung von Inhalten und deren Umfang. Die führt zu Vorteilen, ist aber auch mit Nachteilen verbunden. Auf einer übergeordneten Ebene lassen sich diese folgendermaßen darstellen.

Vorteile in kleinen und mittleren Projekten

Scrum ist populär. Denn Scrum ist einfach, unverkennbar durch seine Terminologie und auf schnelle Ergebnisse orientiert. Gleichzeitig erlaubt dieser Ansatz eine leichte Einschätzung des Entwicklungsprozesses und sorgt so für Transparenz, auch bei Nichttechnikern. Tatsächlich liefert der Ansatz, auch wenn man ihn nicht als umfassendes, in sich geschlossenes Prozessmodell betrachten kann, zahlreiche Vorteile für kleine und mittlere Projekte mit etwa drei bis 15 Entwicklern.

Leicht- und schwergewichtige Vorgehensmodelle der Softwareentwicklung haben unterschiedliche Vor- und Nachteile. Quelle: SaM

Scrum verfügt über wenige Rollen, Dokumente und Aktivitäten. Es dauert einen Tag, sie zu lernen, auszuprobieren und den kompletten Prozess zu verstehen. Mit derartig geringen Startinvestitionen und einem derartig minimalen Aufwand für die Etablierung ist dieses Vorgehensmodell sehr attraktiv. Ein typischer Sprint, so wird der Zyklus genannt, in dem neue, lauffähige Funktionalitäten ausgeliefert werden, dauert zwei, drei, oder vier Wochen und hat immer die gleich Länge. Am Ende sieht der Anwender immer ein funktionierendes Stück Software und wird gleichzeitig ermutigt, Feedback zu geben. Und dies, ohne zu befürchten auf Ablehnung zu stoßen, da seine Wünsche nicht in den Anforderungen stehen.

Anforderungen in Scrum werden durch sogenannte User Stories gehandhabt. Dabei handelt es sich um eine kurze Beschreibung von gewünschten Funktionen oder Fähigkeiten. Diese müssen immer klein genug sein, um nicht den kompletten Sprint für ihre Umsetzung zu benötigen. Sie müssen zudem strikt priorisiert werden, um weniger wichtige Anforderungen aus einem Sprint auszuschließen. Der Nutzen eines derartigen Ansatzes liegt darin, dass der Anwender kein spezielles, formalisiertes Wissen benötigt, um Anforderungen zu benennen und als sogenannter Product Owner auftreten zu können. Zudem werden Fortschritte durch den granularen Ansatz am Ende eines Sprint sofort sichtbar und vorhersehbar für die Zukunft.

Es gibt zwei kritische Fragen, die eine IT-Abteilung gerne und oft zu hören bekommt: Was macht Ihr gerade? Und warum dauert das so lange? Scrum beantwortet die erste Frage an der sogenannten Scrum Wall. Dabei handelt es sich tatsächlich um eine Wand im Büro. An dieser wird jede Aufgabe samt Bearbeitungsstatus einer bestimmten Person mit einem Post-it-Sticker zugeordnet. Die zweite Frage wird durch sogenannte Story Points und den Planning Poker beantwortet. Story Points sind Einheiten für die Größe einer zu entwickelnden User Story (Funktion). Die Vergabe erfolgt als Schätzung durch das Team. Nach dem ersten Sprint lässt sich erkennen, wie viele Story Points umgesetzt wurden. Dies wird dann Velocity genannt. Nach einigen Sprints entwickelt sich die Velocity so zu einer sehr verlässlichen Metrik über den Umfang dessen, was ein Team je Sprint an Funktionen umsetzen kann.

Kein Projektmanager

Scrum funktioniert nur, wenn Teams sich dem Ansatz komplett verpflichten. Es gibt nicht viele verbindliche Praktiken unter Scrum, aber in Kombination und bei strikter Einhaltung sorgen sie für qualitativ hochwertige Ergebnisse. Viele Praktiken, etwa das tägliche Scrum Meeting oder die Scrum Wall, können nicht leicht in einer bestehenden Firmenkultur akzeptiert werden. Keine der Rollen von Scrum, auch nicht die des sogenannten Scrum Master, entspricht beispielsweise der des Projektmanagers. Unter Scrum organisiert sich ein Team selbst und bringt die Verantwortung für ein auslieferungsfähiges Produkt aus sich selber hervor. Die Aufgaben des Projektmanagements sind hier auf drei Rollen aufgeteilt. Die Kontrolle des Fortschritts und der Zielerreichung ist Aufgabe der Product Owner. Fehlerbehebung und die Einschätzungen der Technologiequalität übernimmt das Entwicklungsteam. Prozesseffizienz und Teamunterstützung sind Aufgaben des Scrum Master. Eine Aufteilung, die erst einmal akzeptiert werden will.

Der Ansatz schlägt daher nicht nur auf die Entwicklung durch. Er beeinflusst auch andere Geschäftsbereiche. Fachabteilungen oder Anwender, die als Product Owner auftreten, müssen für Fragen aus der Entwicklung auch tatsächlich zur Verfügung stehen. Und dies nicht erst dann, wenn Zeit dafür ist. Üblicherweise benötigen Entwicklungsteams im Schnitt mindestens eine Stunde am Tag, um ihre Fragen an die Anwender zu stellen. Dazu kommt die Zeit für andere projektbezogene Aufgaben. Letztlich müssen diese zu 100 Prozent für das Projekt verfügbar sein.

Unter Scrum ist es auch wichtig, dass die gemeinsame Arbeit am Code effektiv erfolgt. Kleine, schnelle Zyklen und immer neue Funktionalitäten dürfen die Produktqualität nicht gefährden. Daher muss jedes Team gut ausgestattet und erfahren sein. Testgetriebene Entwicklung, Konfigurationsmanagement oder automatisierte Testverfahren müssen reibungslos funktionieren.

Größere Projekte brauchen mehr Strukturierung

Ursprünglich war Scrum für die mündliche Kommunikation in kleinen Teams mit bis zu sieben Entwicklern in einem Büro gedacht. Größere Projekte, in denen sich die Entwickler auf mehrere Teams verteilen, benötigen mehr formalisierte Kommunikation und Koordinationsmechanismen jenseits des rein verbalen Austauschs. Hier werden Werkzeuge benötigt, um die vereinbarten Anforderungen und technischen Entscheidungen nachvollziehen zu können. In der Praxis übernehmen oft Wikis diese Funktion. Scrum kümmert sich weiterhin nicht groß darum, wie Aufgaben der Fehlerbehebung und Wartung bei bestehenden Softwareanwendungen anzugehen sind. Oder darum, wie der Support und die Entwicklung neuer Funktionen kombiniert wird. Letztlich werden hier dann doch zusätzliche Planungsmechanismen benötigt.

Eine weitere Schwäche ist die Tatsache, dass die Architektur eines Softwaresystems vom Team innerhalb jedes einzelnen Sprint festgelegt oder nachgebessert wird. Dies ist bei komplexen oder großen Projekten risikoreich und ineffektiv. Für sicherheitskritische oder bestimmten Standards verpflichtete Produkte ist ein derartiges Herangehen oft nicht akzeptabel. Hier muss in der Startphase zumindest ein verbindliches Dokument zu Architektur und Design aufgesetzt werden. Auch die Zusammenarbeit von verteilten Teams oder mit einem externen Dienstleister ist nicht unproblematisch. Praxisbeispiele haben aber gezeigt, dass sie möglich ist. Konkrete Vorgehensweisen müssen sich aber jeweils erst entwickeln. So kann die Scrum Wall beispielsweise in Videokonferenzen diskutiert werden. Und auch die vertraglichen Regelungen mit einem externen Dienstleister müssen im Falle von Scrum sehr genau durchdacht werden, mit einem Schwerpunkt auf den Produkt- und Projektzielen.

Weitere Informationen zu einigen Vorgehensmodellen für die Softwareentwicklung. Quelle: SaM

Zusammenfassend gesagt: Konkrete Projekte können sich stark voneinander unterscheiden. Die Auswahl eines geeigneten Ansatzes sollte sich daher immer an diesem konkreten Fall, konkreten Prioritäten, technischer Komplexität, der Teamgröße und anderen kritischen Faktoren orientieren. Die Erfolge von Scrum sind aber kein Zufall. Für kleinere Projekte sollte man dieses Vorgehensmodell auf jeden Fall in Betracht ziehen.

Anton Dechko ist Direktor Business Development bei der SaM Solutions GmbH in Gilching bei München.
Verwandte Artikel