Share ZU:
4 July 2017 @ Pedro Ferreira

Heisse Anforderungen und späte Änderungen

Das zweite agile Prinzip handelt nicht etwa von zu warmen Anforderungen an denen man sich die Finger verbrennt (die Überschrift enthält kein „ß“), sondern stellt in der Produktentwicklung vielmehr ein ungeschriebenes Gesetz dar.

Das agile Prinzip #2

„Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

Anforderungen im Lastenheft als Grundlage

Vor Beginn eines Projektes bekommt der potentielle Auftragnehmer zur Angebotsabgabe ein umfangreiches Lastenheft. Warum sollten dann nach Projektbeginn überhaupt späte Änderungen erwartet werden? Es ist doch alles spezifiziert was der Kunde haben will!?

Nach einer detaillierteren Analyse des Lastenheftes zeigen sich darin Lücken und veraltete Funktionsbeschreibungen. Der Kunde erwartet offensichtlich eine enge Zusammenarbeit mit dem Auftragnehmer, um die Konkretisierung von Softwarefunktionen zu besprechen. Das Lastenheft stellt also oft eine notwendige, aber keine hinreichende Voraussetzung für die Produktentwicklung dar.

Späte Anforderungen aufgrund Auslastung auf Kundenseite

In einem unserer jüngsten Kundenprojekte stellte sich heraus, dass der Kunde, der die Entwicklung eins Hardware- und Softwareprodukts beauftragt hat, während der Projektzeit mit anderen Projekten ausgelastet war. Dies hatte zur Folge, dass er erst spät im Projekt in Zusammenarbeit mit dem Auftragnehmer die im Lastenheft unvollständig beschriebenen Funktionsbeschreibungen erarbeitete. Des Weiteren fehlte dem Kunden bisher die Zeit, die erhaltenen Produktlieferungen ausgiebig zu testen bzw. auszuprobieren. Diese späte Auseinandersetzung mit den vorliegenden Produktlieferungen führte kurz vor Projektende zu vielen Änderungswünschen und mehreren Überarbeitungen der implementierten Funktionen. Dies lässt sich in Entwicklungsprojekten immer wieder beobachten.

Ungünstig für Auftragnehmer gut für Kunden

Aus Auftragnehmersicht werden späte Änderungen zunächst einmal kritisch betrachtet, da späte Änderungen in Hard- und Software immer die Gefahr von Seiteneffekten bergen und den Testaufwand (Regressionstests) gegen Projektende nochmal erhöhen. Die Diskussionen, ob man dem Kunden diesen ungeplanten Aufwand separat in Rechnung stellen soll, werden mit jedem Änderungswunsch lauter. Zusätzlich kommen allmählich Fragen vom Projektmanagement, warum denn immer noch an bestimmten Funktionen gearbeitet wird und diese noch nicht umgesetzt sind.

Für den Kunden haben späte Änderungen, vorausgesetzt diese sind kostenlos, Vorteile:

  • Sie kommen seinem Zeitmanagement entgegen, wenn er bisher mit anderen Projekten ausgelastet war.
  • Die Möglichkeit Funktionen aufgrund neuer Erkenntnisse zu optimieren oder wegen Gesetzesänderungen anzupassen.
  • Der Kunde kann zu einer bestimmten Änderung, gezielt die Aktualisierung des entsprechenden Kapitels der Dokumentation nachlesen, anstatt sich durch ein großes Dokument durcharbeiten zu müssen.

Doch auch der Auftragnehmer sollte bedenken, dass er mit der Bereitschaft diese späten Änderungen entgegenzunehmen, den Kunden positiv stimmen und die Wahrscheinlichkeit auf Folgeaufträge erhöhen kann.

Fazit

Dieses Projekt verdeutlichte wie eine agile Arbeitsweise zwischen Auftragnehmer und Kunde selbst in einer späten Projektphase ein effektives Arbeiten ermöglichte und für Kundenzufriedenheit sorgte.
Das Ganze kann nur noch übertroffen werden, wenn man diese Art der Zusammenarbeit mit dem Kunden bereits zu Projektbeginn etabliert und dadurch einer der agilen Werte gelebt wird: „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“.

Pedro Ferreira

Kontaktieren Sie Pedro Ferreira

Pedro Ferreira ist als Consultant und Trainer bei der HOOD GmbH im Bereich Requirements Engineering tätig. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehörigen Werkzeugen (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Erstellung von objektorientierten Modellen unter Einsatz der UML und das Spezifizieren von Testfällen. Erfahrungen konnte Pedro Ferreira bisher in der IT-, Automobil- und in der Luftfahrtindustrie sammeln. Als Trainer hat er sich auf die gute Formulierung von textuellen Anforderungen und auf die Methoden zur Erhebung von Anforderungen aus der UX Domäne spezialisiert.