SCRUM als Beispiel für neue Vorgehensmodelle in der Anwendungsentwicklung

In meinem letzten Blog habe ich die klassische Vorgehensmodelle in der Anwendungsentwicklung vorgestellt und deren Weiterentwicklung. Sowie sich die IT-Architektur und die Werkzeuge zur Softwareentwicklung weiterentwickelt haben, haben sich auch die Vorgehensmodelle weiterentwickelt. In diesem Blog möchte ich auf neue Vorgehensmodelle eingehen, insbesondere auf SCRUM.

Evolution der klassischen Vorgehensmodelle

In meinen vorangegangen Blogs wurde deutlich, dass es immer wichtiger ist Änderungen der Geschäftsprozesse schnell und flexibel in der IT umzusetzen. Dank einer SOA und Modellgetriebener Softwareentwicklungswerkzeuge wie Visual Composer kann die Orchestrierung der Geschäftsprozesse in adäquater Zeit realisiert werden.

Nicht erst mit Werkzeugen zur Anwendungsmodellierung wie Visual Composer ist es möglich schneller und flexibler Anwendungen zu erstellen. Die Kapselung einzelner Funktionen in Programmbibliotheken hat zur Wiederverwendbarkeit und damit zur schnelleren Anwendungserstellung geführt genauso wie die Objektorientierung. Parallel hierzu wurden auch die Vorgehensmodelle weiterentwickelt und haben eine Evolution durchlaufen wie im letzten Blog beschrieben. Die Komplexität und der Umfang heutiger Software Projekte tragen ebenfalls dazu bei, dass neuere Vorgehensmodelle wie bspw. Test-Driven Development oder Extreme Programming präferiert werden, damit die Projekte in Time, Budget and Quality erfolgreich abgeschlossen werden.

Diese neuere Vorgehensmodelle werden in den letzten Jahren bereits erfolgreich eingesetzt von den Global Playern der IT Welt wie zum Beispiel Microsoft, SAP oder IBM. So kann man immer wieder in der Fachpresse Berichte lesen über die Vorteile dieser Vorgehensmodelle in der Anwendungsentwicklung. Dabei wird sehr oft herausgestellt, dass sich das iterative Vorgehen dieser neuen Modelle und deren Agilität bewährt haben und einen signifikanten Beitrag zum Projekterfolg beitragen. Im Folgenden möchte ich Ihnen eines dieser neuen Vorgehensmodelle vorstellen, dass auch die SAP verwendet. Es handelt sich dabei wie bereits am Anfang erwähnt um SCRUM. Nachdem ich Ihnen die Grundlagen von SCRUM vorgestellt habe, werde ich dessen Einsatz bei der Anwendungsentwicklung auf Basis einer SOA und Visual Composer diskutieren.

Was ist SCRUM?

SCRUM wurde eingeführt und etabliert von Takeuchi, DeGrace, Schwaber und anderen in den späten 1990er Jahren. Die Konzepte von SCRUM sind ziemlich einfach. SCRUM ist eine grobe Skizze eines Prozesses, basierend auf iterative Entwicklung und drei Meetings. Es besteht aus drei Rollen, drei Dokumente und drei Meetings, die in der nächsten Abbildung dargestellt sind.

Die drei Rollen sind Product Owner, Team und SCRUM Master:

  • Der Product Owner stellt die Stakeholders dar wie Kunden, Marketing, etc. Der Product Owner hat dafür zu sorgen, dass er die Interessen der Stakeholder vertritt.
    Er definiert auch die Anforderungen basierend auf den User Stories des Kunden und stellt das Projektbudget zur Umsetzung dieser Anforderung zur Verfügung. Außerdem nimmt er die Arbeitsergebnisse des Teams ab.
  • Das Entwicklungsteam wird einfach nur als Team bezeichnet. Das Team ist verantwortlich für die Realisierung des Projekts und dessen Arbeitsergebnisse.
  • Der SCRUM Master ist verantwortlich für den SCRUM Prozess, die Ausführung der Meetings und die Anpassung von SCRUM an das Projekt und die Organisation.

Die drei Dokumente sind das Product Backlog, das Sprint Backlog und die Sprint Results:

  • Im Product Backlog sind alle Anforderungen gesammelt und priorisiert in einer Liste wie in traditionellen Projekten.
  • Die Entwicklung wird in kleinen Iterationen durchgeführt, welche in der SCRUM Terminologie als Sprint bezeichnet werden. Jeder Sprint ist eine kleine und überschaubare Iteration. Es beinhaltet Design, Entwicklung und Testen. Ein Sprint dauert etwa zwei bis vier Wochen.
    Das Ziel jedes Sprints ist ein getestetes und stabiles Arbeitsergebnis, welches dem Kunden übergeben werden kann und vom Kunden sofort produktive genutzt werden kann. Zu Beginn eines Sprints sucht sich das Team die wichtigsten Anwendungsfälle aus dem Product Backlog aus, die innerhalb des Sprints fertiggestellt werden können. Die Liste dieser Anwendungsfälle wird als Sprint Backlog bezeichnet. Der Sprint Backlog wird zwischen dem Product Owner, dem SCRUM Master sowie dem Team selbst ausgehandelt.
  • Die Anwendungsfälle, welche während des Sprint realisiert werden, sind im Sprint Results dokumentiert.

Die drei Meetings sind das Sprint Planning Meeting, das Daily SCRUM Meeting und das Sprint Review Meeting:

  • Jeder neue Sprint beginnt mit einem Sprint Planning Meeting. Das Team, der Product Owner und der SCRUM Master entscheiden über das Sprint Backlog zum einen basierend auf den Anforderungen, die vom Product Ower priorisiert wurden und zum anderen auf das was das Team zusagen kann. Das Meeting besteht aus zwei Teilen. Morgens präsentiert der Product Owner die wichtigsten Anforderungen dem Team. Am Ende des Morgens wählt das Team die Anwendungsfälle aus, die in diesem Sprint realisiert werden. Am Nachmittag plant das Team den Sprint.
  • Während des gesamten Projekts moderiert der SCRUM Master jeden Tag ein 15-minütiges Daily SCRUM Meeting zum Austausch, was in den letzten 24 Stunden erreicht wurde und um Probleme zu diskutieren, die angegangen werden müssen. Das folgende wird diskutiert:
    • Was hat jedes Team Mitglied in den in den letzten Tagen erreicht?
    • Welche Probleme sind aufgetreten, die zum Überprüfen des Iteration Plans oder dem Entwurf führen können?
    • Was wird jedes Team Mitglied in den nächsten Tagen arbeiten?
  • Das wichtigste Ziel dieser täglichen Meetings ist es die Fortschritte zu eruieren, und alle Probleme zu identifizieren, welche Aufmerksamkeit oder sogar die Anpassung des Sprint Backlog benötigen. SCRUM empfiehlt die Fortschritte mit Burndown Charts, die später vorgestellt werden, festzuhalten.
    Auf Basis des Fortschritts können zusätzliche Anwendungsfälle aus dem Product Backlog zum Sprint Backlog hinzugefügt werden. Oder – im Falle von Verzögerungen – Anwendungsfälle aus dem Sprint Backlog zurück in das Product Backlog genommen werden und in einer späteren Iteration angegangen werden.
  • Am Ende eines jeden Sprints treffen sich der SCRUM Master, das Team und der Product Owner (mit den anderen Stakeholder) wieder um die erreichten Ergebnisse während der Iteration zu überprüfen. Dieses Meeting wird als Sprint Review bezeichnet.
Planungshorizont in SCRUM

Der Horizont für eine detaillierte Planung ist kurz und berücksichtigt nur eine einzige Iteration, das heißt in SCRUM Terminologie einen Sprint. Anstatt einen großen Plan zu erstellen, welcher alle Aufgaben, Aufwände und Ressourcen für das gesamte Projekt berücksichtigt, werden zu Projektbeginn nur sehr grobe High-Level Annahmen getroffen. Mehr Planungsdetails und die Zuweisungen der Arbeitspakete werden zu Beginn jeder Iteration festgelegt, jedoch nur für die Anwendungsfälle, die vom Team ausgewählt wurden in der aktuellen Iteration fertigzustellen.
Dies ist ein großer Unterschied zu den traditionellen Projekten auf Basis des Wasserfallmodells, die Pläne und Meilensteine in einem viel größeren Umfang ausarbeiten. Dieser Aspekt des Wasserfallmodells macht Änderungen des finalisierten Plans relativ unflexibel und teuer, vor allem gegen Ende des Projekts. In einem SCRUM-Ansatz basierten Projekt akzeptiert das Projektmanagement Änderung des Plans als eine grundlegende Notwendigkeit und verschwendet keine Aufwände bei der Planung über den Horizont des aktuellen Sprints, denn es gibt zu viele Unsicherheiten. Ein langfristiger Plan würde ohnehin Änderungen unterliegen. Und das wichtigste: Ein solch detaillierter, langfristiger Plan für die Zukunft führt in der Regel nur zu irreführende Annahmen und falschem Maß an Vertrauen, dem niemand vertrauen sollte.

Agile Vorgehensmodelle wie zum Beispiel SCRUM lösen dieses Problem indem sie größere Projekte in Iterationen unterteilen und sich eigentlich nur um den Inhalt der aktuellen Iteration kümmern. SCRUM bietet die Möglichkeit Fakten-basierte Entscheidungen zu treffen für den unmittelbaren Bedarf. Und es erlaubt sogar die Änderung der grundlegenden Richtung des übergeordneten Projektziel zu Beginn eines jeden neuen Sprints, falls dies erforderlich wird, um veränderten Anforderungen Rechnung zu tragen und Maßnahmen einzuleiten zur Bewältigung unvorhergesehener Probleme.

Festhalten des Fortschritts eines Sprints mit Burndown Charts

SCRUM empfiehlt die Fortschritte der Entwicklungstätigkeiten und das Erreichen der vorgegebenen Ziele mit Burndown Charts festzuhalten. Das Burndown Chart ist eine graphische, pro Tag in den Daily SCRUM Meetings zu erfassende Darstellung des noch zu erbringenden Restaufwands pro Sprint. Der Restaufwand des Teams wird auf der vertikalen Achse aufgeführt, während die Zeit ist auf der horizontalen Achse dargestellt. Der Restaufwand kann in Einheiten von Stunden, Personentage oder Anzahl der Anwendungsfälle dargestellt werden. Im Idealfall fällt die Kurve kontinuierlich (daher Burndown) und der Restaufwand ist am Ende des Sprints Null. Das Chart lässt anhand der Verlängerung der negativen Steigung bereits während des Sprints einen Trend erkennen, ob der anfangs geschätzte Aufwand ausreicht.

Für ein besseres Verständnis und Visualisierung des SCRUM Vorgehensmodell empfehle ich das Video „SCRUM in under 10 minutes“ von Hamid Shojaee.

YouTube Preview Image
Oder ein weiterer sehr guter Beitrag zu den Grundlagen von SCRUM.
YouTube Preview Image

Herausforderungen für Projekt Manager mit agilen Vorgehensmodellen

Der Einsatz von agilen Vorgehensmodelle in der Anwendungsentwicklung hat mehrere Herausforderungen, vor allem für Projektmanager: Die Stakeholder wollen in der Regel wissen, wann das Projekt abgeschlossen sein wird und was genau Bestandteil des Projekts ist. In vielen Fällen akzeptiert der Kunde nur einen Festpreis-Vertrag. Dies erfordert, dass der Lieferant der Anwendung die Gesamtkosten des Projekts im Griff hat, auch wenn das Projekt nicht bis zum Ende im Detail geplant ist.

Sind agile Vorgehensmodelle überhaupt geeignet für verbindliche Gesamtkosten und Projektinhalte?

Zunächst einmal ist es wichtig, die Grenzen der vorgetäuschten Genauigkeit, die mit dem klassischen Wasserfall-Modell angeblich erreicht wird, aufzudecken: Dem ausgearbeiteten Projektplan eines komplexen IT-Projekt und den genaue Prognosen kann man nur Glauben schenken, wenn man erwartet, dass es keine Überraschungen zwischen heute und dem Projektende auftreten. Ich verweise an dieser Stelle Murphy’s Law „Was schief gehen kann, wird schief gehen.“

Einen Plan zu vertrauen, der über den Horizont der nächsten Wochen hinausgehen führt zu einer gefährlichen Blindheit. In der abschließenden Analyse kann gesagt werden, dass die prognostizierten Kosten signifikant Abweichen von den Erwartungen, auch wenn ein Projekt bis ins kleinste Detail geplant ist. Applikationsentwicklung ist viel komplexer. Die Dinge ändern sich in den Köpfen der Stakeholder, d.h. was sie wollen oder brauchen und somit die Anforderungen und in der Regel stellt die Technik mehr Probleme dar als erwartet.

In allen komplexen IT-Projekten müssen alle beteiligten Parteien akzeptieren, dass unvorhergesehene Probleme auftreten und das endgültig gewünschte Ergebnis kann nicht vollständig zu Beginn des Projekts verstanden werden. Daher liegt der Schwerpunkt von SCRUM (und alle anderen agilen Methoden) nicht auf der Perfektionierung der Präzision der Planung, sondern die Maximierung der Fähigkeit zur die Planung anzupassen und auf Veränderungen zu reagieren.

Der Fokus der beteiligten Parteien muss darauf liegen nur die High-Level-Anforderungen und die wichtigsten Nutzungsszenarien im Voraus festzulegen. Während dem Kunden bestimmte Schlüsselfunktionalitäten zugesichert werden, muss trotzdem eine gewisse Flexibilität vorhanden sein, welche Funktionalitäten umgesetzt werden können. Am Ende muss es immer einen Kompromiss zwischen dem Entwicklungsteam und dem Kunden geben. Das Entwicklerteam verpflichtet sich, bestimmte High-Level-Anforderungen innerhalb eines bestimmten Zeitrahmens zu erfüllen. Aber der Kunde muss das Team auch mit einem gewissen Maß an Freiheit versehen damit abhängig vom tatsächlichen Fortschritt die Funktionalität verfeinert werden kann.

In SCRUM dauert jeder Sprint 15 bis 30 Tage. Die Länge des Sprint bzw. der Iteration sollte am Anfang des Projekts überprüft werden und unter Umständen angepasst werden zum Beispiel basierend darauf wie lange es dauert die gesamte Anwendung zu kompilieren und zu deployen. Eine komplexe Anwendung, die mehrere Stunden benötigt um kompiliert zu werden, benötigt eine Sprint Länge von fünf oder sechs Wochen auf Grund des langen Deploy-Prozess. An diesem Beispiel sehen Sie, dass auch eine gute Infrastruktur, die den Deploy Prozess schnell umsetzt und das Testen der Anwendung in wenigen ermöglicht, eine wichtige Komponente ist um ein agiles Projekt umzusetzen oder ein Projekt mehr agiler zu machen.

Es ist unnötig zu erwähnen, dass es wichtig ist, dass jeder Sprint eine vordefinierte Länge hat und alles was nicht abgeschlossen wurde muss in der nächsten Iteration fertiggestellt werden, außer wenn es sich bei diesem „fast fertig“ Szenario um ein Bestandteil handelt, das produktionsreif ist und dem Kunden einen Mehrwert darstellt.

Ist SCRUM bestens geeignet für die Anwendungsentwicklung mit Visual Composer basierend auf einer SOA?

Ich erinner mich, dass mein Freund Luis in der Vergangenheit einen Blog geschrieben mit dem Titel Visual Composer Apps delivered “On-Time”. Luis hat darin meinen Freund Mario zitiert, der Autor des ersten Visual Composer Buchs ist. Mario hat in diesem Buch geschrieben “Modeling is an art, with any art, there are many ways to do something…”. Ich stimme dieser These voll zu, aber ich denke, dass man ein Vorgehensmodell auswählen sollte, dass die Vorteile von SOA und Visual Composer voll ausnutzt. Wie ich in meinen vorhergehenden Blogs erwähnt habe, ist der Vorteil von SOA-basierten Anwendungen, die mit Visual Composer erstellt werden, die schnelle Anwendungserstellung. Meiner Meinung nach passt dies perfekt zum Vorgehen von SCRUM und dessen Sprint Konzept.

Fazit

Ich komme zu dem Fazit basierend auf meinen Erfahrungen, dass neue agile Vorgehensmodelle das Beste sind für die Anwendungsentwicklung mit Visual Composer und einer SOA, weil wie ich bereits erwähnt habe die Vorteile einer schnelle Anwendungsentwicklung ausnutzen kann. Das bedeutet, der Endanwender hat die Möglichkeit bereits zu einem frühen Zeitpunkt im Projekt die Anwendung Hands-on am System zu begutachten. Basierend auf dieser Hands-on Erfahrung kann er sehr früh dem Entwicklungsteam Feedback geben und das Entwicklungsteam kann gewährleisten, dass die Entwicklung in die richtige Richtung geht. Dies spart nicht nur Zeit und Geld, weil Missverständnisse der Anforderungen und falsche Erwartungen des Endanwenders in einer sehr frühen Projektphase beseitigt werden. Der iterative Ansatz stellt auch sicher, dass die Entwicklung in die richtige Richtung geht und somit zur gewünschten Qualität führt. Und schließlich das Projekt erfolgreich in Time, Budget und Quality abgeschlossen wird.



Diesen Blog finden Sie in englischer Sprache im SAP Community Network.
You can find this blog in englisch language on the internet sites of the SAP Community Network.

Getagged mit: , ,
Ein Kommentar auf “SCRUM als Beispiel für neue Vorgehensmodelle in der Anwendungsentwicklung
  1. Carmelina Kinter sagt:

    Gott sei Dank mal ein Blog, der echte informative Artikel veröffentlicht. Leider ist im deutschsprachigen Netz die Bloggerei nicht groß ausgeprägt, hier hat der User aber einen echten Mehrwert. Ich finde auch teilweise die Diskussionen sehr informativ. Da sieht man, dass sich jemand wirklich Arbeit gemacht hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*