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

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.

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.