PFLICHTENHEFT ADE. SCHEIDEN? JUCHHE?
Es ist Freitag Nachmittag, der Schreibtisch ist fast von Papier befreit, das Wochenende ruft. Kurz vor dem Aufbruch dreht der Projektleiter in der Entwicklungsabteilung seine Runden. Mit einem lauten Klatsch landet ein monströser Papierhaufen vor meiner Nase: die letzten Änderungen seien nun endlich von allen Verantwortlichen abgesegnet worden. Die Heftklammern haben es nicht ganz durch den Stapel geschafft, einzelne Blätter haben sich gelöst und drohen mit Flucht. Allein die Änderungshistorie hat mittlerweile 24 Seiten und einige längst existierende Baugruppen sollen jetzt doch durch Dienstleister gestellt werden, weil das günstiger ist. Dadurch haben sich aber natürlich sämtliche Schnittstellen geändert, deren Dokumentation nun auch angepasst werden muss.
„Hab ich ja gleich gesagt, dass es so nicht funktionieren wird aber auf mich hört ja niemand! Naja, egal. Lesen werde ich die neue Fassung sowieso nicht, denn bis ich zur Hälfte durch bin, ändern die sowieso wieder alles.“
Wer kennt das nicht? Ein Pflichtenheft ist der Versuch, alle anfangs noch unbekannten Details eines Projekts oder Produkts auf Biegen und Brechen festzulegen und möglichst allen neuen Erkenntnissen zum Trotz bis zum bitteren Ende zu implementieren. Jede Änderung hat das Potenzial, das gesamte Projekt von den Schienen zu heben. Natürlich gibt es Situationen, in denen das durchaus Sinn macht. Ich denke an große Integrationsprojekte oder Projekte, die immer wieder auf die gleiche Art durchgeführt werden. In den meisten Fällen ist es aber sicher von Vorteil, sich den anfänglichen Festlegungsstress zu ersparen, um sich dann den laufenden Änderungsstress gleich mitzuersparen.
ALTERNATIVE
In agilen Projekten wird das Pflichtenheft vor allem durch den Backlog ersetzt, der je nach Bedarf von einer Reihe von Dokumenten begleitet wird. Unter dem Backlog versteht man eine Liste von Anforderungen, die nach der Reihenfolge ihrer zeitlichen Implementierung geordnet sind. Wie das genau aussieht, unterscheidet sich von Fall zu Fall und ist mitunter Thema vieler Diskussionen. Einen Artikel zum Thema „Requirements“ finden Sie hier.
Vor dem eigentlichen Start des Projekts werden normalerweise zusätzlich eine Reihe von Dokumenten und Planungsunterlagen erstellt. So kann durchaus auch ein Lastenheft entstehen, das sich möglichst stark darauf konzentriert zu beschreiben, was erreicht werden soll, eine Zielplanung also. Sollen von vornherein auch Schlüsseltechnologien und eine Systemarchitektur vorgegeben werden, machen unter Umständen Technikstudien und entsprechende Architekturdokumente Sinn. Auch kann darüber nachgedacht werden, einem großen Hauptprojekt mehrere kleinere Projekte vorauszuschicken, um das große Projekt besser planbar zu machen.
Ist der Startschuss gefallen, werden die Anforderungen des Backlog nach und nach in Zyklen (Sprints) abgearbeitet. Nach jedem Sprint geht man einen Schritt zurück und betrachtet das Erreichte mit kritischen Augen. Die aus dieser Betrachtung gewonnenen Erkenntnisse fließen sofort wieder in die vorhandenen oder auch in neue Anforderungen ein.
KONTROLLE
Dass diese Arbeitsweise aus Sicht der Entwicklung Sinn macht, ist einfach zu sehen aber was bedeutet das für den Auftraggeber? Wie kann der sicherstellen, dass am Ende des Budgets auch wirklich alle Ziele erreicht sind? Vor Beantwortung dieser Frage stelle ich eine andere: war das mit einem herkömmlichen Prozess jemals wirklich möglich oder haben wir einfach nur so getan und danach versucht, irgend jemandem die Schuld in die Schuhe zu schieben? So ist die Sicherheit der Budgeteinhaltung bei agilen Projekten mindestens genauso hoch, wie bei herkömmlich organisierten Projekten.
Tatsächlich verlagert sich im agilen Projekt die Verantwortung in Richtung Auftraggeber. Der bekommt neue Möglichkeiten, den Verlauf des Projekts einfacher zu steuern, muss dieser Verantwortung gleichzeitig aber auch gerecht werden. Der Product Owner darf und muss während der gesamten Projektdauer immer wieder mit dem Team festlegen, wohin die Reise im nächsten Sprint geht.
DER WEG
Genau hier setzt proaquila an. Wir üben mit Ihnen und Ihrem Team das Planen, Steuern und führen zusammen mit Ihrem Team die entsprechenden Werkzeuge ein. Zieldefinitionen, Backlog, Schätzungen, Sprint-Planung und Retrospektive sind nur einige der Themen, die Ihr Unternehmen nach unserer Zusammenarbeit zu einem agilen und noch mehr wettbewerbsfähigen Marktteilnehmer machen werden.
#anforderungen #pflichtenheft #lastenheft #requirements #agil #agilität #produktentwicklung #backlog #scrum #sprint #agilsein