Wir machen das agil …, oder?
Bei der Software-Entwicklung gibt es verschiedene Vorgehensmodelle, einen Projektauftrag zu bearbeiten. Es gibt zum Beispiel das eher traditionelle Wasserfall-Modell, bei dem vor der Entwicklung alle Anforderungen von A bis Z detailliert durchdacht werden, und es gibt die modernere Herangehensweise, die agile Software-Entwicklung mittels Scrum. Agile Methoden haben ihren Ursprung in der Software-Entwicklung, werden aber mittlerweile für unterschiedlichste Anwendungszwecke eingesetzt. Bei der agilen Softwareentwicklung handelt sich um ein flexibles Modell, das anders als bei der Wasserfall-Methode während der Projektbearbeitung Änderungen jederzeit zulässt. Wir bei exensio nutzen das Beste aus beiden Welten, denn am Ende macht‘s die Mischung.
Die Entwicklung einer Software erstreckt sich meist über einen längeren Zeitraum. Hierfür entwickeln Auftraggeber und Auftragnehmer üblicherweise einen Projektablaufplan sowie eine genaue Projektbeschreibung. Das Projekt kann gemäß des Wasserfall-Modells durchgeführt werden, das heißt zu Projektbeginn werden alle Anforderungen und technischen Spezifikationen von A bis Z detailliert beschrieben und es wird ein Zeitraum festgelegt, innerhalb dem der Auftrag erledigt sein soll. Mit dieser detaillierten Auftragsbeschreibung kann das Software-Unternehmen dann an die Arbeit gehen, während der festgelegten Bearbeitungszeit ohne wesentlichen Austausch mit dem Auftraggeber das gewünschte Produkt entwickeln und es zum gewünschten Fertigstellungstermin liefern. Der Nachteil bei dieser Vorgehensweise ist, dass Änderungswünsche während der Software-Entwicklung per se nicht vorgesehen sind. Gibt es während der Fertigstellung dennoch welche, können sie nicht mehr oder nur sehr aufwändig implementiert werden. Meist ist dies dann mit einem hohen Aufwand und mit nicht kalkulierten Kosten verbunden. Denn beim Wasserfall-Modell werden Änderungswünsche über sogenannte Change Requests, was nichts anderes bedeutet als definierte Änderungsanforderungen, eingearbeitet. Dabei dokumentiert der Auftragnehmer die Änderungswünsche und legt sie samt Benennung der damit verbundenen Zeitaufwände und Kosten dem Auftraggeber zur Genehmigung vor. In Konzernen können solche Vorgänge lange dauern und – je nachdem wie zentral der Änderungswunsch ist – das Gesamtprojekt massiv beeinflussen. Wie die Erfahrung zeigt, kosten Change-Request-Prozesse viel Zeit und Nerven auf beiden Seiten.
Will man sich als Auftraggeber daher von vornherein die Möglichkeit offenhalten, Änderungen auch während der Entwicklungsphase flexibel vorzunehmen, um auf sich ändernde Anforderungen der Zielgruppe einzugehen, bietet sich eher ein agiles Vorgehen an. Denn es ermöglicht, die starre Organisation der Wasserfall-Methode durch ein offeneres Modell zu ersetzen, das Änderungen jederzeit zulässt. Dabei wird von vornherein die Projektdauer in sogenannte Sprints unterteilt, das heißt in Zeiteinheiten von beispielsweise vier oder zwei Wochen – oder in besonderen Fällen sogar von nur wenigen Tagen. Die Anforderungen werden in einem Backlog (einer Liste) erfasst – zunächst nur grob und vor der Umsetzung detailliert. Vor jedem Sprint werden die umzusetzenden Anforderungen festgelegt, priorisiert nach dem erzielten Kundennutzen. Nach jedem Sprint sorgt ein Sprint-Review für den Abgleich des Soll- und Ist-Zustands. -Generell kann das Backlog immer wieder angepasst werden – je nach neuen Erkenntnissen, Wünschen, Marktentwicklungen oder Ähnlichem. Ein „Untertauchen“ während der gesamten Entwicklungsphase, wie es das Wasserfall-Modell aufgrund seiner exakten Projektbeschreibung erlaubt, das während der Bearbeitung keine weitere Präzisierung mehr benötigt, ist hier also kein Thema. Dreh- und Angelpunkt der agilen Software-Entwicklung ist allerdings die konsequente Kommunikation zwischen Auftraggeber (in der Rolle des sogenannten Product Owners) und der Entwickler bzw. aller Team-Mitglieder. Alle Beteiligten müssen zu jeder Zeit vollkommen informiert sein, das gleiche Verständnis besitzen und wissen, wie sich die Dinge geändert haben und welche Erwartungen und Ziele es zu erfüllen gilt. Nur so können sie auf Veränderungen schnell und vor allem richtig reagieren. Das sollen die erwähnten Sprint-„Meetings“ sicherstellen. Eine latente Gefahr bei der agilen Vorgehensweise liegt mitunter in einem schwer zu kalkulierenden Gesamt-Arbeitsaufwand wegen einer möglicherweise zu skizzenhaften Beschreibung des gewünschten Endprodukts. Der verbleibende Spielraum kann den Auftraggeber ebenso teuer zu stehen kommen wie den Auftragnehmer. Darüber hinaus birgt die schrittweise Entwicklung die Gefahr, dass bereits umgesetzte Funktionen durch veränderte Anforderungen immer wieder angepasst werden müssen. Der ökonomische Wunsch „einmal implementiert und fertig“ ist schwierig umzusetzen.
Wir bei exensio haben uns daher für eine Mischform beider Methoden entschieden. Wir setzen einerseits auf eine Projektbeschreibung, die es so weit zu präzisieren gilt, dass wir ein realistisches Angebot machen können. Damit beugen wir unvorhersehbaren Kosten durch ein allzu offenes oder allzu starres Projektmanagement vor – ein wichtiger Aspekt sowohl für unsere Kunden als auch für uns als Unternehmen. Andererseits arbeiten wir aber wie bei der agilen Software Entwicklung mit Sprints und regelmäßigen Projektbesprechungen, die Änderungen während der Auftragsbearbeitung zulassen. Nach dem Motto: So detailliert wie nötig, so flexibel wie möglich.
Vor diesem Hintergrund möchten wir im Folgenden über unsere Erfahrungen berichten und das, was uns häufig begegnet, wenn es um die erwähnten Herangehensweisen geht. Es fällt uns beispielsweise auf, dass gerne von agilem Vorgehen gesprochen wird, ohne dass dieses wirklich agil ist.
Klar, agil hört sich modern an und ist in aller Munde. Wie schon angedeutet assoziieren Viele Agilität mit flexiblem und dynamischem Vorgehen, bei dem man schnell Ergebnisse erzielt und schnell auf sich verändernde Anforderungen reagieren kann. Daher wirbt so mancher in unserer Branche damit, dass er Bestandteile des agilen Vorgehens nutzt wie etwa das „Daily Meeting“, um den Anschein einer agilen Projektbearbeitung zu erwecken. Eine tägliche Besprechung abzuhalten bedeutet aber nicht zwangsläufig, dass ein Projekt agil bearbeitet wird.
Agiles Vorgehen wird manchmal auch als Grund vorgeschoben, um Anforderungen nicht genauer konkretisieren zu müssen. Ein Projekt tatsächlich agil durchzuführen, stellt diverse Anforderungen an die Mitarbeiter. Diese sind nicht immer gegeben. Und man muss wissen, dass agiles Vorgehen auch kritische Seiten hat. Das lässt sich beispielhaft an folgenden zwei Aspekten zeigen:
- Die Rolle des „Product Owners“, also des Auftraggebers bzw. der Person, die die Anforderungen an das zu erstellende Produkt mitdefiniert, ist zentral, denn sie liefert den kompletten fachlichen Input und gibt vor, in welcher Reihenfolge die Umsetzung zu erfolgen hat. Was beispielsweise aus Sicht des Auftraggebers einen besonders hohen Stellenwert innerhalb des Projekts hat, hat natürlich auch eine entsprechend hohe Priorität. Der Product Owner wird ständig gebraucht, um fachliche Fragen zu beantworten und Entscheidungen zu treffen. Überspitzt formuliert ist er die personifizierte Spezifikation, da er den Input im Laufe der Projektarbeit in den „Meetings“ mündlich beschreibt und konkretisiert. Er übernimmt damit die Funktion der schriftlich festgelegten Spezifikationen des Wasserfall-Modells.
Selten habe ich Kollegen bei Kunden kennen gelernt, die diese Rolle komplett hätten ausfüllen können. Jemanden zu finden, der das notwendige fachliche Know-how in entsprechender Breite und Tiefe besitzt, ist schwierig. Hinzu kommt, dass der Product Owner alle Stakeholder repräsentieren soll. Ob er das kann, hängt u.a. von der Anzahl und Heterogenität der Stakeholder ab. Aus meiner Sicht ist außerdem die Anforderung an ihn, permanent verfügbar zu sein, am schwersten zu erfüllen. Aussichtsreiche Kandidaten sind einem Projekt häufig nicht voll zugeordnet und müssen noch ihr Tagesgeschäft erledigen. Kommt das Projekt „on the top“, wird es schwierig, der Rolle des Product Owners gerecht zu werden. - Beim agilen Vorgehen ist Refactoring ein fester Bestandteil. Es bedeutet, ich baue immer wieder um, verbessere, passe an. Will man nun in einer Iteration, also dem, was man auch als Sprint bezeichnet, eine neue Anforderung implementieren, die einen technischen Umbau erfordert oder sinnvoll macht, wird dies auch getan, es gehört zum agilen Ansatz dazu. Je nachdem wie viele Umbauten innerhalb eines Projekts erfolgen sollen, hat das allerdings zur Konsequenz, dass mehr Aufwand und Kosten in diesen technischen Umbau fließen anstelle in die neue Funktionalität.
Das „ständige“ Refactoring ist auch dem Umstand geschuldet, dass Anforderungen oft erst spät im Projektverlauf konkretisiert werden. Was aus fachlicher Sicht als überaus positiv wahrgenommen wird, kann technisch einige Konsequenzen (insbesondere Aufwände) nach sich ziehen. So kann es notwendig sein, die technische Architektur der Lösung in größerem Umfang umzubauen. Dies zieht sowohl erhebliche Implementierungsaufwände nach sich als auch einen großen Testumfang.
Aus Sicht der reinen Lehre führen wir bei exensio keine rein agilen Projekte durch. Einer der zentralen Gründe ist das oben geschilderte Problem mit dem Product Owner. Ein weiterer Aspekt ist das Thema Festpreis, für dessen Kalkulation eine möglichst stabile Grundlage, das heißt eine halbwegs konkrete Projektbeschreibung erforderlich ist. Im Markt gibt es zwar Anbieter, die dieses Problem mit der Angabe sogenannter „agiler Festpreise“ zu lösen versuchen – übrigens eine Wortkombination, die in sich widersprüchlich ist. Entweder agil oder Festpreis. Entsprechend stellt auch diese Vorgehensweise den Anbieter vor eine schwierige Aufgabe.
Aus diesem Wissen heraus integrieren wir die für uns wertvollen Aspekte der agilen Methoden in unsere Projektarbeit und erzielen dadurch verschiedene positive Effekte:
- Wir unterteilen unsere Projekte in Iterationen bzw. Sprints mit dem Ziel, dem Kunden am Ende dieser Sprints etwas Vorzeigbares präsentieren zu können. Damit erhält der Kunde Zwischenergebnisse, die er bewerten kann. Sein Feedback fließt dann wieder ins Projekt ein.
- Die Anforderungen spezifizieren wir am Anfang schon, aber nicht zu detailliert. Die für das agile Vorgehen typischen „User Stories“ sind uns zu knapp, wir schreiben die etwas detaillierteren „Use Cases“, ohne es mit den Details zu übertreiben. Außerdem sind uns Wireframes, also bildhafte Entwurfsvorschläge der zukünftigen Benutzeroberflächen (User Interfaces), wichtig. Durch sie gewinnt der Kunde ein besseres Verständnis von der späteren Software-Anwendung.
Damit bleiben immer noch Fragen, die während der Bearbeitung zu klären sind. Dies bindet den Kunden während der Implementierung weiter ein. Gleichzeitig ziehen wir die Spezifikation während der Umsetzung nach.
- Auch wir führen „Daily Meetings“ durch, um die Kommunikation über Aktivitäten und Probleme im Projekt-Team zu fördern.
- Das Unterteilen in Sprints sowie das Priorisieren nehmen wir am Anfang ebenfalls grob vor und verfeinern sie später im Team, insbesondere wenn noch technische Aspekte einfließen.
- Den Überblick über die Aktivitäten und den Fortschritt dokumentieren wir über unseren adaptierten Scrum-Boards im Ticket-Managementsystem Jira.
Dieses Vorgehen hat sich mittlerweile bei vielen unserer Projekte bewährt. Und dennoch halten wir immer Ausschau nach weiteren Verbesserungsmöglichkeiten sowie nach Elementen und Techniken aus „anderen“ Methoden, die zu übernehmen oder zu adaptieren wir für sinnvoll halten.