Ein Vorgehensmodell strukturiert die Softwareentwicklung und dient dazu, Projekte auf Basis von Erfahrungen und bewährten Methoden erfolgreich zu meistern. Dazu beschreibt es die am Projekt beteiligten Rollen und legt deren Aufgaben und Aktivitäten für verschiedene Projektphasen fest. Des Weiteren bieten die Modelle standardisierte Methoden, Techniken und Werkzeuge, mit deren Hilfe definierte Ergebnisse erarbeitet werden können.
Sequentielle Vorgehensmodelle
Bei dieser Gruppe von Vorgehensmodellen arbeitet das Team in aufeinanderfolgenden, in sich abgeschlossenen Phasen. Die Ergebnisse einer Phase – meist ausführliche Dokumente oder Programme – sind bindende Vorgabe für die folgende. Rücksprünge in vorherige Abschnitte sind nicht zulässig. Der bekannteste Vertreter dieser Kategorie ist das Wasserfallmodell nach Winston W. Royce. Ähnlich bekannt ist das V-Modell , welches das sequentielle Vorgehen um den Aspekt der Qualitätssicherung erweitert.
Der wesentliche Vorteil der sequentiellen Vorgehensmodelle ist eine klare Struktur. Sie sind zudem relativ leicht verständlich. Bei stabilen Anforderungen und Rahmenbedingungen lassen sich entsprechende Projekte mit geringem Managementaufwand gut steuern und planen. Die Nachteile kommen jedoch bei lang laufenden Projekten mit sich verändernden Anforderungen und Rahmenbedingungen zum Tragen. Da jede Phase abgeschlossen sein muss, um eine weitere zu beginnen, können Ergebnisse aus einer früheren Phase kaum noch angepasst werden. Bereits geleistete Arbeit verliert ihren Wert. Der Kunde ist kaum in das Projekt eingebunden und kann sein Feedback erst am Ende des Prozesses einbringen. Erst dann entsteht für ihn auch ein Business-Nutzen. So bleibt lange Zeit unklar, ob er auch wirklich das bekommt, was er braucht oder «nur» das, was zu Beginn des Projektes spezifiziert wurde, als vielleicht noch ganz andere Voraussetzungen galten.
Iterative Modelle
Bei dieser Gruppe von Vorgehensmodellen werden Änderungen und Weiterentwicklungen als ein Bestandteil des Entwicklungsprozesses betrachtet. Dabei sind Rücksprünge in vorherige Aktivitäten zulässig. Bekannte Vertreter sind der Rational Unified Process (RUP) oder das Spiral-Modell.
Die Vorteile dieser Vorgehensweise: Das Team kann Risiken früher erkennen und auf veränderte Anforderungen schneller reagieren. Die inkrementelle Auslieferung wird erleichtert.
Allerdings entsteht bei den iterativen Methoden häufig mehr Arbeit durch das sehr komplexe Projektmanagement und den hohen bürokratischen Aufwand. Zudem sind die Ergebnisse nur schwer messbar.
Die Vor- und Nachteile dieser beiden Modelle lassen erkennen: Bei der Auswahl eines Modells ist es enorm wichtig, die projektspezifischen Rahmenbedingungen zu beachten und vorab zu klären, wie komplex das Projekt tatsächlich ist:
- Welchen Umfang hat das Projekt?
- Wie häufig ändern sich Anforderungen?
- Welche Risiken bestehen?
- Wie hoch ist der Management-Aufwand?
- Wann soll Nutzen entstehen?
- Werden Kunden ausreichend eingebunden?
- Wie viel Bürokratie erfordert das Vorgehen?
- Ist das Modell anpassbar?
Die „Complexity Matrix“ von Ralph Stacey widmet sich zwar eigentlich dem Thema Management und Führung, ist aber dennoch eine gute Anleitung, um nachzuvollziehen, wie komplex ein Projekt ist. Je sicherer und bekannter ein bestimmtes Vorgehen ist, je mehr das Team auf Erfahrungen zurückgreifen kann und ganz sicher weiß, was es tun soll, desto mehr kann es sich auf traditionelle Methoden verlassen. Je komplexer ein Projekt wird – und Software-Entwicklung ist als komplexer Vorgang meist in diesem Bereich anzusiedeln – desto mehr braucht es einen anderen Führungsstil und eine andere Arbeitsweise. Agil eben.
Agile Software-Entwicklung
Bei der Agilen Software-Entwicklung entsteht das Arbeitsergebnis in sehr enger und direkter Zusammenarbeit mit dem Auftraggeber. Die Spezifikation erfolgt sukzessive während der Umsetzung. Damit das Team sich auf seine Ziele und die konkrete Arbeit konzentrieren kann, wird versucht, mit einem geringen bürokratischen Aufwand und wenigen expliziten Regeln auszukommen. Dafür stehen Kommunikation und Feedback im Vordergrund. Diese Vorgehensweise soll es ermöglichen, gleichermaßen auf technische Schwierigkeiten und Probleme innerhalb des Teams während der Softwareentwicklung einzugehen.
Agile Werte
Konkreter wird diese Sichtweise im »Agilen Manifest« dargestellt, das im Jahr 2001 von führenden Vertretern der Agilen Softwareentwicklungsbewegung verabschiedet wurde. Zu den Unterzeichnern zählten neben den Scrum-Mitbegründern Mike Beedle, Ken Schwaber und Jeff Sutherland andere Größen der Szene wie Kent Beck (XP), Alistair Cockburn (Crystal), Ward Cunningham (XP), Martin Fowler (Thought Words), Ron Jeffries (XP), Andrew Hunt (Pragmatic Programmer), Robert C. Martin (Object Mentor) und Dave Thomas (Pragmatic Programmer).
Das »Agile Manifest« beginnt mit folgenden Wertungen:
- Individuen und Interaktionen sind wichtiger als Prozesse und Tools
- funktionierende Software ist wichtiger als umfassende Dokumentation
- Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen
- Reaktion auf Änderungen ist wichtiger als einen Plan zu befolgen
»Obwohl auch die Dinge auf der rechten Seite ihren Wert haben, schätzen wir die auf der Linken höher ein.«
Diese Kernaussagen sind bewusst knapp und etwas plakativ gehalten. Natürlich sind definierte Entwicklungsprozesse und hochentwickelte Entwicklungswerkzeuge durchaus wichtig. Sie sollten aber nur dort eingesetzt werden, wo sie tatsächlich einen Nutzen bringen. Wichtiger sind die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen, denn jede Entwicklung steht und fällt mit der Fähigkeit des Teams. Die Projektmitglieder sollen den agilen Prozess selbst bestimmen und ihn an die konkreten Bedürfnisse anpassen können.
Natürlich kann eine gut geschriebene Dokumentation hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Der Wissenstransfer von Mensch zu Mensch sollte Priorität haben, Dokumentationen nicht allein dem Selbstzweck dienen. Nach dem Agilen Manifest werden die einzelnen Entwicklungsphasen nicht streng getrennt, da dies in der Realität kaum möglich ist, wo sich Anforderungen und Rahmenbedingungen ständig ändern können. Vielmehr sollen Entwurf, Dokumentation – wo nötig – und Test eine Einheit bilden. Die Zufriedenheit des Kunden ist der wichtigste Maßstab für den Entwicklungserfolg. Dazu muss die Zusammenarbeit mit ihm im Fokus stehen. Denn erst, wenn ein Kunde das System einmal gesehen und angewendet hat, ist er wirklich in der Lage, seine Bedürfnisse explizit und im Detail zu formulieren und festzulegen, wo konkret Anpassungsbedarf besteht. Änderungswünsche oder die Unfähigkeit des Kunden, die kompletten Anforderungen zu Beginn der Entwicklung im Detail auszuformulieren, sollen nicht als mangelnde Fachkenntnis oder als »Dummheit« des Kunden aufgefasst werden.
Agile Prinzipien
Wie sieht all das in der konkreten Umsetzung im Arbeitsalltag aus? Hier helfen die Agilen Prinzipien. Sie sind die Leitsätze der Agilen Arbeit. Beispielhaft seien hier die wichtigsten genannt: Informationen sollten im Team, aber auch zwischen Kunde und Team direkt ausgetauscht werden, face-to-face. Nur so sind Rück- und Verständnisfragen möglich, um Missverständnisse von vornherein auszuschließen. Das Team organisiert sich selbst und trägt damit eine hohe Eigenverantwortung während der Planung und Umsetzung des Projekts.
Agile Mindset
Nicht nur in der Softwareentwicklung ist es von großem Vorteil, agil vorzugehen. Diese Arbeitsweise lässt sich auch auf den Führungsstil, auf die Kindeserziehung ja auf eine ganze Lebenseinstellung ausweiten. Linda Rising, die große Vertreterin und Vorreiterin dieser Lebens- und Arbeitsweise sagte beispielsweise zum Thema Kindererziehung in einem Vortrag, dass es nicht darum gehe, Kindern zu sagen, wie talentiert sie seien, sondern ihre Anstrengungen zu loben. Nur das fördere die agile Denkweise der kleinen Schlauköpfe: »Praise effort, let that be the experimental manipulation that will produce an agile mindest in your bright little girl.«
Wer ein »agile mindset« hat, also agil denken und leben kann, der glaubt daran, ein Leben lang lernen zu können und besser zu werden – auch und gerade, weil es möglich ist, Fehler zu machen. Herausforderungen werden angegangen und gemeistert, nicht vermieden.
Scrum
Neben Scrum gibt es noch zahlreiche andere Agile Vorgehensmodelle, zum Beispiel Extreme Programming (XP), Crystal oder Kanban. In einem nächsten Artikel hier im Blog erläutern wir die Ursprünge von Scrum und geben einen kurzen Überblick über die Begrifflichkeiten.
Kommentare