Schlagwortarchiv für: Lastenheft erstellen

Bild zu Lastenheft und agile Methoden

Tolle Kombination: Lastenhefte und agile Methoden

Viele Projektleiter sind verunsichert, wenn sie ein Lastenheft mit ihren agilen Methoden bzw. Scrum vereinen sollen. Ist ein Lastenheft wirklich noch sinnvoll, wenn sich unsere Anforderungen ständig verändern? Wenn wir als Systemingenieure für das Erstellen eines Lastenheftes für ein komplexes System zwei bis sechs Monate brauchen, gibt es dann eine Möglichkeit, dabei agil vorzugehen? Und passt ein Lastenheft eigentlich mit Scrum zusammen?

Die Vorteile agiler Lastenhefte

Zunächst möchte ich eines vorwegnehmen: Ein Projekt ohne Lastenheft ist mit hoher Sicherheit zum Scheitern verurteilt. Das ist meine Erfahrung aus über 10 Jahren als Troubleshooter in der Automobilentwicklung.

Erst als ich mit den Teams begonnen habe, ein Lastenheft zu erstellen, ist allen klar geworden, was wirklich vom Auftraggeber gewünscht wurde. Dabei war es in allen Projekten und Unternehmen irrelevant, ob die Projekte klassisch oder agil verliefen und über Scrum gesteuert wurden. Das spricht eigentlich bereits für sich: Ja, du kannst bei der Erstellung eines Lastenheftes agil vorgehen!

Wenn über längere Zeit an einem Lastenheft gearbeitet wird, ist es sogar sehr sinnvoll, agile Methoden einzusetzen. Dadurch erhöht sich die Reife des Lastenheftes und oft sind die Teams auch deutlich schneller.

Ich selbst liebe es, mit agilen Methoden bei der Erstellung eines Lastenheftes zu arbeiten. Es spricht absolut nichts dagegen, sie einzusetzen. Ich nutze dazu folgende Methoden:

  • Sprints: Ich arbeite mit den Teams in Sprints von ein oder zwei Wochen.
  • Kanban: Wir nutzen ein gemeinsames Board und steuern die Aufgaben.
  • Design Pattern: Ich bringe meine Templates und Vorlagen mit in das Projekt.

 

Lastenhefte und Scrum? Unbedingt!

Das Lastenheft beschreibt das „Wünsch-Dir-Was“ des Auftraggebers, also der Person, die für das Projekt den Kunden darstellt. Das kann ein externer Kunde sein oder deine Marketing- und Produktmanagementabteilung. Diese Kunden bzw. Abteilungen bringen in einem Lastenheft ihre Wünsche nach bestem Wissen und Gewissen auf einen aktuellen Stand.

Aus meiner Sicht macht es dabei keinen Unterschied, wenn du Scrum als Management-Methode in deinem Projekt einsetzt – Scrum und Lastenhefte lassen sich sehr gut vereinbaren! Es ist also eher nebensächlich, ob dein Projekt klassisch oder über Scrum gesteuert wird: Beide Formen der Projektsteuerung profitieren von der Existenz eines Lastenheftes. Im Grunde handelt es sich hierbei nur um unterschiedliche Formen, ein Projekt umzusetzen.

Ziel eines Lastenheftes ist es, eine Basis für die Diskussion der Anforderungen zu liefern. Wenn dein Projekt beispielsweise mit Scrum gesteuert wird, ist das Lastenheft eine hervorragende Basis für das Produkt Backlog. Denn dort werden die oft sehr grob beschriebenen Anforderungen aus dem Lastenheft in die Storys übertragen und weiter diskutiert. Wenn dein Projekt Scrum einsetzt, ist also ein Lastenheft von deinem Auftraggeber sehr wertvoll.

Die erste deutsche Online-Bibliothek zum Thema Lastenhefte

Der Blog „Agile Lastenhefte“ eröffnet seine Online-Bibliothek mit Templates, Lernvideos, Tutorials und vielem mehr Templates und Checklisten sind und bleiben heißbegehrte Werkzeuge. Ob für einen Startpunkt, für den Abschluss – oder für Probleme mittendrin: Sie schaffen den nötigen Überblick, bilden Strukturen ab und ermöglichen sinnvolle Deadlines für Lastenhefte.

Stolpersteine bei der Erstellung eines Lastenheftes – Teil II

Im letzten Beitrag habe ich bereits zwei in der Praxis oft gesehene Stolpersteine bei der Erstellung eines Lastenheftes beschrieben und wie man diese effektiv überwinden kann. Im Folgenden gehe ich auf den dritten typischen Fehler und seine Lösung ein.

3. Es werden keine Rückmeldungen gegeben

Wenn die Erstellung eines Lastenheftes schließlich seinen Lauf nimmt, tauchen schnell die ersten Fragen auf. Zudem hat das Lastenheft vielleicht auch schon einen ersten Stand erreicht, der von anderen Experten gegengelesen werden kann.

In dieser Phase ist der für das Lastenheft Verantwortliche darauf angewiesen, das andere Kollegen und Experten seine Fragen beantworten und ihm ein Feedback liefern. Das geschieht aber häufig nicht und meist werden Ausreden wie „ich habe keine Zeit“ oder „das ist jetzt nicht wichtig“ herangezogen.

Was ist das Problem?

In dieser Phase passieren zwei Dinge: Zum einen erhält der Verantwortliche keine Rückmeldung. Somit kann er nur das im Lastenheft dokumentieren, was er für richtig hält. Durch die fehlenden Rückmeldungen ergeben sich in der Praxis aber häufig Lücken, fehlerhafte Anforderungen etc.

Zum anderen wird die Arbeit des Verantwortlichen herabgestuft: Es ist ganz klar eine wertende Aussage, keine Zeit zu haben, um dem Kollegen eine Rückmeldung zu geben. Noch schlimmer ist es natürlich, ihm klar zu signalisieren, dass seine Arbeit nicht wichtig ist. Dadurch entsteht Frustration – und mit Sicherheit kein gutes Lastenheft.

Was ist die Lösung?

Den Teammitgliedern muss vonseiten der Führungskräfte im Projekt klar kommuniziert werden, dass sowohl die Arbeit des Verantwortlichen als auch das Lastenheft als Ergebnis sehr hohen Wert für das Projekt haben. Das führt dazu, dass die angesprochenen Experten nun selbst abschätzen müssen, ob Ihre Arbeit wirklich wichtiger ist als das Lastenheft.

Ein weiterer Trick ist, dem Verantwortlichen einen direkten Kanal zu den Führungskräften im Projekt zu geben. Über diesen kann er sich im Zweifel zügig melden, wenn er ein Problem nicht alleine lösen kann.

Zusammenfassung

Diese Stolpersteine zu kennen und zu berücksichtigen, kann dazu führen, dass die Erstellung des Lastenheftes deutlich reibungsloser und erfolgreicher abläuft.

Entscheidend ist, sich nach der Entscheidung für ein Lastenheft die nötige Zeit zu nehmen, um die richtige Person auszuwählen, d.h. also eine Person, die qualifiziert, erfahren und zudem wirklich motiviert ist.

Danach gilt es, sich einen ordentlichen Überblick zu verschaffen – und ihn auch zu behalten. Das Team darf das große Ganze nicht aus den Augen zu verlieren, wenn es sich in die Masse der vorliegenden Dokumente vertieft.

Und schließlich ist es entscheidend, das gesamte Projekt zur Mitarbeit zu bewegen und die Motivation zu fördern. Die Führungskräfte des Projektes müssen den hohen Stellenwert des Lastenheftes klar kommunizieren und dem Verantwortlichen direkte Kommunikationswege freihalten.

Wenn diese Stolpersteine vermieden werden, ist ein Projekt einem wirklich guten Lastenheft und einem erfolgreichen Abschluss ein ganzes Stück näher gekommen!

Stolpersteine bei der Erstellung eines Lastenheftes – Teil I

Bei der Erstellung eines Lastenheftes gibt es immer wieder Hürden, die dazu führen, dass ein Lastenheft nie fertig wird. In diesem zweiteiligen Artikel gehe ich auf die drei typischen Stolpersteine ein, die ich in der Praxis immer wieder vorfinde.

1. Die falsche Person ist verantwortlich

Endlich ist die Entscheidung gefallen: Für das Projekt soll ein Lastenheft erstellt werden. Dann wird geklärt, wer das Lastenheft schreiben soll – und zwar möglichst sofort, denn jetzt muss es plötzlich ganz schnell gehen: Das Lastenheft soll am besten gestern fertig sein und eine dafür verantwortliche Person wird gebraucht – also wird oft voreilig entschieden:

Derjenige, der nicht schnell genug einen Schritt nach hinten gemacht hat, wird ausgewählt. So bekommt nicht derjenige die Aufgabe, der die entsprechende Qualifikation dazu hat, sondern der, der sozusagen zur falschen Zeit am falschen Ort war.

Was ist das Problem daran?

Wenn ich nicht die Qualifikation habe und damit auch nicht die Erfahrung, ist die Wahrscheinlichkeit hoch, dass ich die Aufgabe vor mir herschiebe. Das führt häufig dazu, dass viel zu spät begonnen wird, das Lastenheft zu schreiben.

Irgendwann folgt dann die Erkenntnis, dass immer noch kein Lastenheft vorliegt. Also muss alles noch schneller gehen – und das Lastenheft wird irgendwie zusammengeschrieben. Da Zeit, Lust und Fähigkeit fehlen, ist es in dieser Situation kaum möglich, ein wirklich vernünftiges Lastenheft zu erstellen.

Was ist die Lösung?

Suche in deinem Unternehmen oder Projekt die Person heraus, die sich wirklich mit Begeisterung um ein Lastenheft kümmern wird. Lass dir Zeit bei dieser Suche: Es macht wenig Sinn, den erstbesten anstatt den allerbesten für diese Aufgabe zu finden.

2. Es wird zu kompliziert gestartet

Man will doch ein Lastenheft für ein komplexes System schreiben, also muss man mit dem Naheliegenden beginnen und sämtliche Dokumente zusammensuchen, die man in die Finger kriegen kann.

Dann wird sich durch all diese Dokumente gewühlt, um einen Überblick zu bekommen – nur um anschließend festzustellen, dass man keine Ahnung hat, was man mit dem „Ergebnis“ anfangen soll.

Also sucht man Beispiele und Vorlagen aus anderen Projekten, denn vielleicht findet man dort die richtigen Hinweise, wie ein Lastenheft aussehen soll. Und so vergeht die Zeit …

Was ist das Problem daran?

Bei dieser Vorgehensweise, die ich häufig in Projekten sehe, stürzen sich die Teammitglieder direkt in alle gefundenen Dokumente und versuchen, diese zu analysieren. Je weiter sie sich in die Tiefe bohren, umso mehr verlieren sie den Blick für das große Ganze. So vergeht viel Zeit, während ein wirkliches Ergebnis ausbleibt.

Was ist die Lösung?

Zunächst einmal muss sich das gesamte Projekt den richtigen Überblick verschaffen. Dabei hilft zum Beispiel das „System Footprint“: Mit dieser Visualisierung bekommen alle einen Überblick darüber, was überhaupt in ein Lastenheft hinein soll. Jetzt erst kann man den nächsten Schritt gehen und aus den vorliegenden Dokumenten das heraussuchen, was wirklich notwendig ist.

Den dritten Stolperstein bei der Erstellung eines Lastenheftes – fehlende Rückmeldungen – und meine Lösungsansätze dazu erläutere ich im nächsten Beitrag.

Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil IV

Hier könnt ihr den ersten, den zweiten und den dritten Teil lesen!

Phase V: Die Weiterentwicklung

Für die Erstellung eines Lastenheftes und für das Lastenheft selbst ist diese fünfte Phase – die Weiterentwicklung – eine besondere. Denn der Release von 1.0 bedeutet, dass wir das Lastenheft mit bestem Wissen und Gewissen und auf dem aktuellen Stand der Technik und allem, was wir kennen, erstellt haben.

Release 2.0 – Neues einplanen

Gleichzeitig bedeutet es aber auch: Die Welt dreht sich weiter, wir werden neue Erkenntnisse bekommen, wir werden verstehen, dass und warum Dinge nicht funktionieren, wir werden neue Ideen haben. All das wird kommen. Das heißt, 1.0 ist niemals das eine unveränderliche Lastenheft, das beim Abschluss des Projektes zwangsläufig noch immer genauso vorliegen wird.

In der Regel gibt es eine Weiterentwicklung. Und auch diese kann ich über eine Release-Planung durchaus begleiten. Denn immer wieder kann etwas passieren, das nicht eingeplant war:

Ein Fertigungsstandort wurde plötzlich gewechselt, es ist eine neue Technologie hinzugekommen, die bislang überhaupt nicht geplant war, irgendetwas funktioniert auf einmal doch nicht und muss herausgenommen werden und so weiter.

Das heißt, ich kann in dieser fünften Phase tatsächlich hingehen und sagen: „Wie und auf welchen Wegen wandern wir jetzt zum Release 2.0“?

Mit dem bestehenden Lastenheft und der gesamten Dokumentation kann man sich also weiter zum Release 2.0 iterieren. Das ist eigentlich die Idee dahinter: In vielen kleinen Schritten, in vielen kleinen Schleifen weiterkommen – gegebenenfalls auch noch zu einem 3.0.

Selbst das ist nicht ganz unüblich, allerdings handelt es sich hierbei meist nur noch um Änderungswünsche: 2.0 ist inhaltlich meistens schon relativ stabil, während bei 3.0 eher Änderungen über das Änderungsmanagement abgewickelt werden.

Das agile Vorgehen bei der Erstellung eines Lastenheftes im Überblick

Das waren also die fünf Phasen der Erstellung eines Lastenheftes. Da wir hier relativ stark ins Detail gegangen sind und die Veröffentlichung des ersten Teils schon ein wenig zurückliegt, möchte ich hier kurz alle Phasen zusammenfassen:

1. Phase: Die Nutzen-Klärung

Beim System-Footprint-Workshop werden das System und die Anforderungen definiert und visualisiert. Die Release-Strategien helfen, alle Zusammenhänge zu begreifen, ein gemeinsames Verständnis für das Vorgehen zu entwickeln und eine Roadmap zu erstellen.

2. Phase: Datensammlung

Alle Informationen werden im System-Footprint-Template gesammelt, zusammengestellt und geprüft. So entdecken wir noch bestehende Lücken und füllen sie auf.

3. Phase: Erstellung des Lastenheftes

Hier geht es um die kontinuierliche Erstellung eines Lastenheftes mit einem Requirements-Management-Werkzeug. Release-Stände, zusätzliche Inhalte und Pflege der diversen Attribute fallen in diese Phase.

4. Phase: Reviews & Freigabe

Alle Teammitglieder erhalten alle Daten, Dokumentationen und Teile des Lastenheftes, um 1.0 fertigstellen zu können. Durch die Reviews sind die meisten Inhalte bereits bekannt, sodass es nicht mehr um wirkliche Fehler geht, sondern um zu behebende Auffälligkeiten.

5. Phase: Die Weiterentwicklung

Das Lastenheft kann und wird ständig an die aktuellen Entwicklungen angepasst, 2.0- oder gar 3.0-Releases können die Folge sein.