In 14 Tagen zum Lastenheft

Kennen Sie die Situation: entweder gibt es in einem Projekt kein erwähnenswertes Lastenheft oder es gibt einen Berg von Dokumenten, den Sie nur mit einer Schubkarre bewegen können. Beide Situationen sind denkbar schlecht. Woher wissen Sie ohne Lastenheft, was es zu entwickeln gilt? Und was nutzt Ihnen ein Lastenheft, das so umfangreich ist, dass es niemand lesen und das in der Folge auch niemand Freizeichnen mag? Nachfolgend möchte ich Ihnen von meiner aktiven Zeit als Troubleshooter berichten, in der ich über 10 Jahre lang internationale Entwicklungsprojekte retten durfte. Stets galt es die Lasten an das zu entwickelnde System zu prüfen, um eine sinnvolle Strategie für die folgenden, harten Verhandlungen mit den Stakeholder zu entwickeln. Meist war das Ziel, das Projekt in den nächsten sechs Monaten wieder auf die Beine zu stellen und zum Erfolg zu führen. Ich brauchte also einen Weg, um innerhalb von 14 Tagen ein freigegebenes Lastenheft in der Hand halten zu können.

Was gehört in ein Lastenheft?

Ein Lastenheft ist das „Wünsch-Dir-Was“ des Kunden. Es beschreibt die technischen Anforderungen an ein zu entwickelndes System. Es gibt zwei Arten von Anforderungen, wobei der Unterschied einfach, aber wesentlich ist: Die Projektanforderungen und die Systemanforderungen. Projektanforderungen sind Anforderungen, die während des Projektes relevant sind, direkt nach dem Abschluss jedoch uninteressant werden. Typische Projektanforderungen sind Budgets, Terminpläne, Meilensteine, Kapazitäten etc. Systemanforderungen hingegen sind die Anforderungen, die auch nach Abschluss des Entwicklungsprojektes bestehen bleiben. Anders ausgedrückt: Die Anforderungen an das Projekt vor zehn Jahren interessieren heute niemanden mehr, aber das technische System mit seinen Systemanforderungen ist auch nach 10 Jahren noch in Betrieb. In ein Lastenheft gehören demzufolge die technischen Anforderungen an das System. Die Projektanforderungen hingegen sollten im Projektauftrag und gegebenenfalls in einem Projekthandbuch festgehalten werden.

Und was gehört in ein Pflichtenheft?

Ein Pflichtenheft hat eine andere Funktion als ein Lastenheft. Es ist sozusagen die Antwort eines Projektes auf das Lastenheft. In einem Pflichtenheft werden die Anforderungen aus dem Lastenheft geklärt, also abgelehnt, übernommen oder weiter detailliert. Das Pflichtenheft kann klassisch als „System Requirements Specification“ oder im agilen Umfeld als „User-Stories“ und „Epics“ vorliegen. Lastenheft und Pflichtenheft dürfen nicht miteinander vermischt werden: Das Lastenheft liegt in der Verantwortung des Kunden, also bspw. beim Produktmanagement oder im Marketing, und das Pflichtenheft ist die Antwort des Entwicklungsprojektes. Bei Vermischungen der beiden Spezifikationen entstehen zwei Probleme: Zum einen verlieren Sie die Möglichkeit zwischen gewünschten und umzusetzenden Anforderungen zu treffen. Zum anderen sind Lastenhefte und Pflichtenhefte oftmals rechtliche Bestandteile eines Vertrags – hier sollten Sie unbedingt rechtliche Probleme vermeiden.

In 14 Tagen zum freigegebenen Lastenheft

Wenn Sie als Systemingenieur ein Lastenheft schreiben, dauert dies in der Regel zwischen zwei und sechs Monaten. Um dies in zwei Wochen zu schaffen und eine Freigabe zu erhalten, brauche ich einen anderen, pragmatischeren Weg. Und so habe ich ein Vorgehen entwickelt, mit dem ich in 14 Tagen, fünf Schritten und mit zwei Regeln zu einem freigegebenen Lastenheft komme.

• Schritt 1: Erfassen
  In einem Kickoff-Workshop mit dem Projektteam sammle und visualisiere ich, was das System und was die Anforderungen an das System sind. In Checklisten halten wir anschließend fest, welche Dokumente und Unterlagen existieren.

• Schritt 2: Sortieren
  In Schritt 2 gilt es die Inhalte zu strukturieren. Hier sichte ich alle Informationen und bewerte, was sinnvoll ist. Danach fülle ich mein Lastenheft-Template, arbeite ich das Ergebnis auf und prüfe die Anforderungen, die Grammatik etc.

• Schritt 3: Lücken schließen
  In Schritt 3 schieße ich die sichtbar gewordenen Lücken, indem ich weitere Anforderungen recherchiere, sie bewerte, übertrage und anschließend wieder aufarbeite.

• Schritt 4: Prüfen
  In Schritt 4 reflektiere ich das Ergebnis, d.h. ich gebe das Lastenheft für einen Peer Review in die Hände der Wissensträger. Diese sollen es durchgehen und kommentieren. Sehr regelmäßig erhalte ich in diesem Schritt viele Zusätze und Informationen, aus denen ich neue Zwischenstände des Lastenhefts erstelle. Ein besonderer Vorteil dieser Phase ist, dass zum Ende alle Beteiligten das Lastenheft inhaltlich kennen und Ihre Anmerkungen bereits gemacht haben. Somit ist hier schon fast alles geklärt – und genau das ist meine Strategie.

• Schritt 5: Freigabe
  In Schritt 5 gilt es den finalen Stand zu erstellen. Diesen mehrfach geprüften Stand reviewen das Projektteam und ich gemeinsam in einem moderierten Workshop. Dabei wird im Review-Protokoll alles, was uns aufgefallen ist, festgehalten. Zusätzlich wird für jede Änderung eine Empfehlung abgegeben. Nachdem schließlich alle Änderungen aus dem Review-Protokoll übertragen sind, erfolgt automatisch das Release und die Freigabe. Somit liegen nun ein Lastenheft und ein Review-Protokoll mit allen abgestellten Auffälligkeiten vor. Da alle ihren inhaltlichen Beitrag geleistet haben, sind für den Release keine weiteren Unterschriften nötig.

Um mit diesen fünf Schritten innerhalb von 14 Tagen durchzukommen, nutze ich zwei klar kommunizierte Regeln:

1. Wer da ist, ist da. Wer nicht da ist, stimmt zu.
   Diese Regel verhindert, dass im Nachhinein von Personen, die nicht an den Workshops teilgenommen haben, das abgestimmte Lastenheft in Frage gestellt wird. Natürlich können die nachträglich, oft auch etwas lauter geäußerten Hinweise in späteren Releases berücksichtigt werden. Für den jetzigen Stand des Lastenhefts hat dies aber keinerlei Bedeutung.
2. Keine Rückmeldung ist Zustimmung.
   Zustimmung einzuholen ist selten einfach. Wenn ich Peer-Review-Stände mit der Bitte um Zustimmung herausgebe und nach einem vereinbarten Zeitraum keine Rückmeldung erhalte, wird das als Zustimmung gewertet. Auch hier können nachträgliche Rückmeldungen gerne in ein späteres Release aufgenommen werden.

Durch die beiden Regeln können Sie alle Beteiligten einfach entscheiden, wie wichtig ihnen das Lastenheft ist. In der Praxis funktioniert das sehr gut, allerdings setzt es auch eine gewisse Standhaftigkeit voraus.

Kann ein Lastenheft agil sein?

Ich werde oft gefragt, ob ein Lastenheft “agil” sein kann. Die Antwort ist einfach: Ein Lastenheft ist ein wichtiges Artefakt im Umfeld eines Entwicklungsprojektes. Als Systemingenieur kann ich es mit einer klassischen oder einer agilen Vorgehensweise erstellen. Wenn Sie es nach den Prinzipien des agilen Manifests erstellen, müssten Sie gedanklich lediglich das Wort „Software“ durch „Lastenheft“ ersetzen. Natürlich kann ein innerhalb von 14 Tagen erstelltes Lastenheft nicht den gleichen inhaltlichen Reifegrad haben, wie eins, das innerhalb von zwei bis sechs Monaten erstellt wird. Das ist aber auch nicht das Ziel, denn bei einem agilen Lastenheft steht die pragmatische Vorgehensweise im Vordergrund. Ich brauche schnell ein korrektes, freigegebenes Lastenheft, um damit in die Umsetzung gehen zu können. In der Praxis der agilen Lastenhefterstellung lassen sich über die Zeit mehrere Durchläufe starten und jeweils einen neuen Stand des Lastenheftes erzeugen. So fügt sich diese Vorgehensweise wunderbar in ein agiles Umfeld ein. Das Lastenheft bleibt dynamisch und beschreibt nach bestem Wissen und Gewissen den aktuellen Stand der Systemanforderungen – nicht mehr, aber nicht weniger!

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. 

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.