Agile Methoden im Pflichtenheft-Verlag

Kosten und Projektlaufzeit für neue digitale Produkte geraten trotz detaillierter und hart erarbeiteter Pflichtenhefte gern aus den Fugen – ebenso die sich anschließenden Diskussionen über Nachbesserungen und Mehrkostenübernahmen. Dem Konzept des Pflichtenheftes setzt die Software-Entwicklung seit den 90er Jahren so genannte Agile Methoden entgegen. Die Steuerungs- und Kommunikationsmethoden agiler Vorgehensweisen stellen traditionell arbeitende Verlagsteams vor besondere Herausforderungen; doch sie können eine Brücke zwischen den unterschiedlichen Kulturen inhalte-getriebener Verlage und technologie-getriebener Medienunternehmen schlagen. 

Schwachpunkt Kontrollierbarkeit

Die klassische Vorgehensweise in der Planung von Software-Produkten besteht aus den Komponenten: Anforderungen festlegen, Pflichtenheft schreiben, Entwicklung, Testen, Nachbesserungen, Abnahme.

Sie wird auch Wasserfall-Modell genannt. Es ist eine Art des Projektmanagements, mit denen die meisten Menschen vertraut sind. Es gibt einen klaren Anfang, einen klaren Umfang zu erbringender Leistung, eine Zeitschiene zur Fertigstellung und zur Abnahme der fertigen Entwicklung sowie zur Nachbesserung. Das klingt logisch und einfach.

Schematische Darstellung der Wasserfallmethode

Das Modell einer Software-Entwicklung nach der Wasserfallmethode.

Es setzt jedoch voraus, dass das gewünschte Produkt komplett ausdefiniert ist, wenn es an die Programmierung geht. Die Erstellung eines Pflichtenheftes ist nicht nur eine unattraktive Aufgabe, die viel Sorgfalt, Voraussicht und Vorstellungskraft bis ins Detail verlangt, sie dauert darüber hinaus je nach Komplexitätsgrad des gewünschten Produkts unter Umständen sehr lange.

Der Auftraggeber bekommt dann irgendwann eine Beta-Version präsentiert. In dieser Phase hat der Auftraggeber endlich die Möglichkeit, herauszufinden, ob das theoretisch Erdachte die nötige Benutzerfreundlichkeit und den wirklich benötigten Funktionsumfang bringt. Jetzt erst trifft Vision auf Umsetzung und das Ergebnis, kann ernüchternd sein.

In den meisten Fällen beginnen [diese] Kunden erst dann zu begreifen, was sie möchten, wenn sie mit einer Interpretation ihrer Vorstellungen, etwas durch Herstellung eines Prototyps, konfrontiert wurden. Die Anforderungen solcher Kunden sind komplex, da ihre Erfordernisse nicht nur vieldeutig und unklar sind, sondern sich auch ständig ändern. (Ken Schwaber: Scrum im Unternehmen, Microsoft Press, 2008)

Solche Erfahrungen können für alle Beteiligten strapaziös und frustrierend sein. Und genau so verhält es sich mit den meisten digitalen Projekten. Um ein Produkt gedanklich entwickeln zu können, muss man schon eine Menge an Wissen über die Funktionsweise solcher Produkte, über Standards, über Technologien, über Usability usw. mitbringen. Die meisten Mitarbeiter im Verlag haben dieses Wissen nicht. Und trotzdem ist es wichtig, dass sie ihren speziellen Beitrag zu digitalen Entwicklungen leisten, seien es die Inhalte, das Wissen über die Zielgruppe, das Wissen über die Geschäftsmodelle oder das Wachen über die Markenführung.

Alternativen zur Wasserfallmethode

Bei Wasserfallmethoden werden alle Anforderungen, Architekturen und die Infrastruktur vollständig beschrieben, bevor die Teams Funktionalität entwickeln. Komplexität versucht man mit Planbarkeit zu begegnen.

Alternativen zu der Wasserfallmethode bieten u.a. so genannte agile Methoden. Agilität beschreibt einige Prinzipien der Software-Entwicklung, deren Anspruch es unter anderem ist, Entwurfsphasen kurz zu halten, sich mit dem Auftraggeber eines Projekts regelmäßig über das weitere Vorgehen zu verständigen und es so zu ermöglichen, ein Produkt noch während seiner Entwicklung zu verändern. Darüber hinaus sind soziale und ethische Prinzipien Bestandteil verschiedener agiler Methoden.

Unabhängig davon, wie systematisch ein Entwicklerteam einer bestimmten Methode folgt, sollte es die Art und Weise der Zusammenarbeit mit dem Auftraggeber während der Entwicklung genau beschreiben können. Diese kann auf Erfahrung oder einer bestimmten Methode beruhen. Fragen in diesem Zusammenhang wären beispielsweise:

  • Wie werden die zu entwickelnden Funktionalitäten und Module abgestimmt, festgelegt und terminiert?
  • Wie und wie oft werden Arbeitsergebnisse überprüft und diskutiert?
  • In welchem Kreis werden die Ergebnisse präsentiert?

Fällt in diesem Zusammenhang der Begriff Pflichtenheft, heißt es aufpassen. Ken Schwaber schreibt in seinem Buch „Scrum im Unternehmen“ zu einem typischen Projektverlauf, die der so genannten Wasserfallmethode folgt:

  • 50% der Zeit wird für Entwicklung von Anforderungen, Architektur und Design aufgewendet
  • 35% der Anforderungen ändern sich während des Projektverlaufs
  • 65% der in den Anforderungen beschriebenen Funktionalität werden nie oder nur selten verwendet.

Wasserfallmethoden unterscheiden sich von agilen Methoden im Wesentlichen dadurch, dass ein agiles Projektmanagement eine Modifikation des geplanten Produkts noch während der Entwicklung möglich ist. Dies verlangt andere Vorgehensweisen bei Planung und Umsetzung der Programmierung.

Scrum – Ein Beispiel für eine agile Projektmanagement-Methode

Ken Schwaber hat zusammen mit Jeff Sutherland Anfang der 90er Jahre die agile Projektmanagement-Methode Scrum entwickelt. Scrum basiert auf den drei Säulen empirischer Prozesssteuerung: ein Prozess muss sichtbar, also transparent sein, er muss überprüfbar und er muss anpassbar sein. Überprüfung und Anpassung werden in bestimmten Zeitrahmen durchgeführt, die sich während der gesamten Entwicklung im gleichen Rhythmus wiederholen – den so genannten Sprints. Am Beginn eines Sprints wird festgelegt, welche Funktionalitäten innerhalb des Projekts bis zum Sprintende umgesetzt werden. Die fertigen Funktionalitäten werden am Ende des Sprints dem Auftraggeber und allen Stakeholdern (das sind alle im Unternehmen, die ein relevantes Interesse an der Entwicklung haben) präsentiert. Nachbesserungen und Modifikationen gehen in den nächsten Sprint ein, der immer einen Zuwachs an Funktionalität zum Ergebnis haben muss (Inkremente). Auf diese Weise bleiben Stakeholder und Entwickler in relativ kurzen Abständen in einem Austausch. Auftraggeber sind im Bilde über tatsächliche Fortschritte und Probleme, und das Produkt selbst kann sich im Laufe seiner Entwicklung bereits ändernden Anforderungen anpassen.

Vereinfachtes Modell der Vorgehensweise bei der agilen Methode SCRUM

Vereinfachtes Modell der Vorgehensweise bei der agilen Methode SCRUM.

Ausgangsbasis für die Projektentwicklung ist das so genannte Produkt-Backlog, das das Projekt beschreibt und zusammen mit dem so genannten Project-Owner, der von Auftraggeberseite das Projekt verantwortet, im Lauf des Projekts aktualisiert und ergänzt wird. Das Sprint-Backlog ist quasi der Fahrplan für die innerhalb eines Sprints zu entwickelnden Funktionen und wird vom Entwicklerteam selbst festgelegt. Ein Sprint umfasst 30 Tage. Während des Sprints trifft sich das Entwicklerteam zu einem „Daily Sprint“ für 15 Minuten, um Status und Probleme zu erörtern. In diesen einfachen Regeln verbirgt sich eine grundlegend andere Philosophie von Projekt- und Teammanagment, als sie beispielsweise in Wasserfallmethoden verfolgt wird. Wasserfallmethoden setzen auf Planbarkeit und Kontrollierbarkeit. Agile Methoden auf Dynamik, Anpassbarkeit und Transparenz.

Angebotseinholung unter agilen Bedingungen

Für Projekte einen zuverlässigen Kostenvoranschlag einzuholen, wenn kein Pflichtenheft zugrunde liegt, erscheint auf den ersten Blick unmöglich. Wenn man aber bedenkt, dass in vielen Projekten trotz eines Pflichtenheftes unerwartete Kosten für Nachbesserungen lauern, relativiert sich dies.

Man kann in der Kostenplanung den Spieß auch einfach umdrehen. Statt projektweise im Detail zu planen, legt man ein ungefähres Budget für das Geschäftsjahr zugrunde. Dieses Budget beruht auf einer Feineinschätzung eindeutiger Kostenpunkte und einer Grobschätzung über anstehende Projekte. Mit etwas Erfahrung ist es nicht besonders schwierig, eine solche Grobschätzung vorzunehmen. Und schließlich ist für die meisten Budgets die Antwort auf die Frage, wofür genau man bestimmte Investitionen tätigt, während der Planungsphase noch relativ diffus. Hier verhält es sich nicht anders wie mit den Pflichtenheften, die schnell zu Makulatur werden können innerhalb einer Entwicklung. Budgets können während eines Geschäftsjahrs ebenso zu Schall und Rauch werden, wenn sich die Marktbedingungen ändern oder Unternehmensteile auf- oder abgebaut werden.

In der Verhandlung mit dem technischen Dienstleister über den konkreten Projektaufwand muss selbstverständlich eine Beschreibung des Projekts vorliegen. Diese kann dann noch ergänzt und – wo nötig – spezifiziert werden. Es genügt, wenn der Geschäftspartner eine grobe und für beide Seiten unverbindliche Einschätzung über einen möglichen Gesamtaufwand für die Programmierung abgibt. Dieses wird im Laufe des Projekts in kurzen Abständen konkretisiert. Da unter agilen Bedingungen der Kunde jederzeit über den Fortschritt der Entwicklung im Bilde ist, ist eine flexible Budgetierung kein hohes Risiko, solange der angepeilte Kostenrahmen nicht exorbitant überzogen wird. Dies wird man jedoch in agilen Projekten frühzeitig merken; das Produkt oder möglicherweise auch der Kostenrahmen lassen sich dann frühzeitig anpassen. Festbeträge sind für beide Seiten schwer handhabbar und führen nur zu Konflikten.

Stundensätze, Dokumentationsformen für die programmierten Applikationen, Verwertungsrechte für den Code, Rabatte auf Jahresumsatzbasis lassen sich mit einer Rahmenvereinbarung, die für alle gemeinsam realisierten Projekte Anwendung findet, mit einem einmaligen Aufwand regeln.

Lernen, während wir handeln

Lernen, während wir handeln, und eine Idee weiterspinnen, während wir sie schon realisieren, liegt in der menschlichen Natur. Das nennt man Empirie. Empirie basiert auf der Sichtbarkeit eines Prozesses, auf dessen Überprüfung und auf dessen Anpassung. Egal, ob es sich um einen Prozess in einer Software oder um einen Prozess innerhalb eines Projektes handelt. Mit überschaubaren, begreifbaren Projekten, einer Interaktion und Kommunikation mit dem Team auf Augenhöhe, mit der Gewährung von Handlungsspielräumen für das Team und seiner Unterstützung, wann immer es dieser bedarf, kann man die Grundlage für Empirie schaffen, also Sichtbarkeit, Überprüfung, Anpassung.

Schreibe einen Kommentar

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