Handlungen und Vorgehensweisen

Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil II

Hier könnt ihr den ersten Teil lesen!

Phasen II & III: Datensammlung und Erstellung des Lastenheftes

In der zweiten Phase geht es darum, Informationen zu sammeln, zu sichten und alles bereitzustellen. Bei B. Braun haben wir das am zweiten Workshop-Tag gemacht, das kann sich aber auch über ein paar Tage oder eine Woche hinziehen.

Fakten, Fakten, Fakten

Diese Daten können alte Lastenheftdokumentationen sein, alte Spezifikationen, Marketingunterlagen, One-Pager, etc. All das sollte über einen FTP-Server bereitgestellt werden, sodass es mir immer vorliegt.

Darauf basierend setze ich die ganzen Informationen in das System-Footprint-Template (eine Art Word-Struktur). Dies tue ich auf Basis der Visualisierungen aus dem Workshop, sie stellen sozusagen die einzelnen Teilüberschriften dar und stellen die wesentlichen Aspekte heraus.

Vereinfacht gesagt übertrage ich das alles ins Lastenheft. Danach arbeite ich das Ganze auf, prüfe die Requirements, die Grammatik und so weiter. Dann folgt die Klärung der Lücken.

Diese werden typischerweise unterschätzt. Häufig höre ich von den Projektleitern bei den Workshops, dass das Lastenheft schon weitestgehend vollständig ist. Doch beim Footprint-Workshop folgt dann der große Aha-Effekt.

Genau das funktioniert in den Footprint-Workshops unglaublich gut: Was fehlt, was ist noch nicht besprochen, nicht visualisiert, nicht dokumentiert. Diese Lücken schließe ich dann durch das Triggern der inhaltlich zuständigen Leute.

In der Regel stecke ich nicht im Detail in dem technischen System, sodass ich die Zuarbeit der jeweiligen Spezialisten benötige. Sie können aber alles so zusammenschreiben, wie sie möchten und wie es für sie am einfachsten ist. Ich übernehmen den Feinschliff.

Das Lastenheft

Und damit kommen wir zur dritten Phase: Das tatsächliche, kontinuierliche Erstellen des Lastenheftes. Dafür nutze ich die Release-Stände und die Inhalte, die von der Entwicklung kommen, und kümmere mich um die Pflege der verschiedenen Attribute.

Wenn wir über Engineering-Requirements-Management reden, meine ich nicht nur die Requirement-Statements, also die Aussagen, sondern auch weitere Attribute für die klare Definition. Zudem kümmere ich mich um die Peer-Reviews.

Als Requirements-Management-Werkzeug nutze ich Polarion und fülle all das dort ein, inkl. Release-Stände. Das können auch Zwischen-Stände sein, also z.B. 0.3-3, diese schicke ich dann wieder zurück zum Projekt, damit die Leute vor Ort sich darum kümmern können, die Peer-Reviews durchzuführen.

Polarion – es gibt aber auch andere Tools – bietet die „Word-Round-Trip“-Funktion an, das heißt die andere Seite muss nicht zwingend ein ALM-Tool haben. Sie kann in Word korrigieren und sobald ich das wieder in Polarion integriere, kümmert das Tool sich selbstständig um das Einpflegen.

Die Erstellung eines Lastenheftes ist also der dritte Schritt, die dritte Phase. Das zieht sich im Grunde genommen so lange, bis 0.8 erreicht ist.

Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil I

Phase I: Nutzen-Klärung

Wir können bei der Erstellung eines Lastenheftes fünf Phasen festlegen. Die erste Phase ist die Nutzen-Klärung. Das muss ganz typischerweise am Anfang und live mit dem Projekt in einem System-Footprint-Workshop geklärt werden.

System-Footprint-Workshops

Im Fall von B. Braun bin ich für zwei Tage und für zwei Aufgaben vor Ort gewesen. Die erste war der System-Footprint-Workshop, bei dem wir visualisiert haben, was überhaupt das System ist und was die Anforderungen an dieses sind.

Parallel habe ich hier – und auch in anderen Projekten – den Project-Footprint mit aufgebracht. Denn relativ häufig kommen Projektanforderungen in den System-Footprint-Workshops hoch, obwohl sie nicht in eine Systemspezifikation gehören.

Sie sind jedoch für einen Projektmanager besonders wichtig und müssen daher dokumentiert werden, damit er sie nutzen kann. Dennoch: Sie gehören nicht in ein Lastenheft.

Am zweiten Tag sind wir bereits die Ergebnisse der ersten Dokumentation durchgegangen. Gleichzeitig haben wir die Release-Strategie erstellt, um eine gemeinsame Vorstellung davon zu schaffen, WIE die Erstellung aussehen wird.

Die Release-Strategie

Die Release-Strategie ist aus drei Gründen unglaublich wichtig.

1. Sie sorgt für ein gemeinsames Verständnis und damit gleichzeitig für eine Roadmap: Allein dadurch, dass wir das Ganze diskutieren, wird klar, wie alles zusammenhängt und wie wir das auffädeln, wer was macht und wer sich um was kümmert.

2. Wir definieren den Zweck der Zwischenreleases: Welchen Zweck hat 0.3? Welchen Zweck hat 0.5, 0.7, 0.8 und 1.0? Das sind die typischen Zwischenreleases, die ich nutze.

Release 0.3 ist in der Regel erst einmal die Erstellung und das Befüllen des Footprint-Workshops mit den vorliegenden Dokumenten. Ich fahre das im 0.3-Release zusammen, denn so werden ganz viele Lücken sichtbar. Diese sind in 0.5 mit Inhalten zu füllen, sodass quasi ein erstes grobes Lastenheft entsteht.

Das Ganze geht ab 0.5 dann in die Peer-Reviews und basierend auf diesen folgt 0.7. Hier gibt es manchmal noch kleinere Anpassungen und Änderungen und oft ergeben sich noch neue Fragen. Darauf basierend wiederum erschaffen wir den 0.8-Release.

0.8 ist quasi der Stand, der an die großen Peer-Reviews geht und auf dessen Basis wir das finale Review machen, um dann 1.0, also quasi das offizielle Release zu machen.

3. Die Release-Strategie ist die Visualisierung für das Top-Management. So können sie sehen, von welchem Zeitraum und von welcher Dauer wir reden, wann was gemacht wird und welchen Zweck das Ganze hat. Deswegen ist auch dieser Workshop vor Ort so wichtig.

Das Kanban-Board

Zudem bauen wir ein gemeinsames Kanban-Board auf. Ich arbeite in der Regel remote und auch die Spezialisten, welche mir inhaltlich zuarbeiten, sind meist in aller Welt verstreut, sodass wir eine gemeinsame Arbeitsplattform benötigen.

Wir haben im Fall von B. Braun Trello genutzt und waren sehr zufrieden, im Grunde aber kann es jede andere Form sein – wichtig ist nur, dass wir es aktualisieren können und dass jeder sehen kann, was noch wo zu tun ist.

Außerdem können wir uns so gegenseitig triggern, wenn noch etwas fehlt, und schließlich sehen, was wir geschafft haben – unter anderem nämlich, den Nutzen und die Strategie bei der Erstellung des Lastenheftes zu klären.

Hier geht es zum zweiten Teil.

Wann und warum ein Lastenheft

In diesem Beitrag möchte ich auf folgende, ganz grundsätzliche Frage eingehen: Warum eigentlich Lastenhefte? Wenn wir mal einen Gedankenschwung über Sinn und Zweck des gesamten Themas machen, so finden wir zwei grundlegende Ausgangslagen für Lastenhefte. Ich möchte diese ein wenig beleuchten.

Unabhängig davon, welchen Business Case Du in Deinem Unternehmen tatsächlich vorliegen hast, es gibt immer diese eine Konstellation: Jemand möchte etwas entwickelt wissen und jemand anderes – ein Spezialist bzw. die richtige Abteilung – entwickelt dieses Etwas.

Die erste typische Ausprägung für ein Lastenheft liegt vor, wenn ein Geschäftskunde sagt: „Ich will für mein Gesamtsystem ein Teilsystem entwickelt haben. Dafür hole ich mir einen externen Spezialisten, der das entwickeln und produzieren kann.“

Diese Situation finden wir typischerweise in der Automobilentwicklung oder bei der Luft- und Raumfahrt, d.h. in Branchen, die mit großen, komplexen Systemen arbeiten. Hier werden die Lastenhefte von den Herstellern erstellt, um den Zulieferern alle nötigen Informationen und Inhalte für die Erstellung und spätere Umsetzung ihrer Angebote vorzulegen.

Die zweite typische Ausprägung bzw. Situation ist die ohne direkten Kunden: Du lieferst in diesem Fall in den Markt hinein, ohne dass es konkrete technische Zielpersonen gibt, wie z.B. in der klassischen Consumer-Elektronik oder bei bestimmten Spezialprodukten.

Hier sind es Produktmanagement und Marketing, die Deine eigentlichen Kunden abbilden. In diesen Fällen arbeitet man nicht mit dem technischen Spezialisten oder dem Projektleiter von beispielsweise VW, wie es bei der ersten Ausprägung der Fall ist. Stattdessen sind es hier eher Produktmanager oder Marketing-Leute, die mit Dir sprechen und Dir eigentlich das Lastenheft übergeben sollten.

Warum? Sie dokumentieren damit ihre Wünsche, das Lastenheft ist ihr „Wünsch Dir was“ – das zusätzlich auch die Beschreibung ihrer Probleme beinhaltet. Das Entscheidende aber für jede Ausprägung, jeden Kunden und jedes Lastenheft: Lastenhefte sind nicht für Lösungen da.

Wenn wir das Thema kurz ein wenig größer aufziehen und fragen, wo Lastenhefte hineingehören, so sehen wir wieder die unterschiedlichen Ebenen, die ich bereits in einigen Podcast-Episoden diskutiert habe: Es sind diese hierarchisch übereinandergelegten Bereiche, von denen der oberste die Kundenebene darstellt.

Und genau auf dieser Ebene existiert das Lastenheft mit der reinen Wunsch- und Problembeschreibung, oft in Kombination mit ergänzenden Grundlagen wie Normen oder referenzierten Standard-Branchenvorgaben etc.

Die nächste Ebene darunter ist die Systemebene mit zwei Artefakten bzw. zwei Teilspezifikationen: Die Systems-Requirements- und die Systems-Architecture-Specification.

Ersteres ist die Antwort auf das Lastenheft, während letzteres quasi die Lösungsbeschreibung darstellt. Dies findet also auf einer anderen Ebene statt als das Lastenheft, welches sozusagen als Dokumentation der Wünsche erstellt wird.

Ein Entwicklungsprojekt antwortet auf diese Wunschliste mit einem Pflichtenheft – auch wenn ich diesen Begriff nicht gerne verwende: Er fasst beide Artefakte aus der Systemebene zusammen, obwohl der Systems-Requirements-Teil aus problembeschreibender Sicht eigentlich schon die Antwort darstellt.

Also: Das Lastenheft gehört als „Wünsch Dir was“ auf die oberste, auf die Kundenebene! Und dort ist es DAS entscheidende Dokument, DAS Artefakt, das ausschlaggebend für ein erfolgreiches Projekt ist.

Meine Erfahrungen aus jahrelangem Trouble-Shooter-Leben zeigen das immer wieder: Projekte, die extreme Schwierigkeiten hatten und sehr stark gestrauchelt sind, hatten immerhin ein mangelhaftes Lastenheft, an dem sie sich mehr schlecht als recht entlanghangeln konnten.

Die Projekte allerdings, die grandios und komplett an die Mauer gefahren wurden, hatten überhaupt kein Lastenheft. Daher denkt daran: Warum Lastenhefte? Weil sie absolut essentiell für erfolgreiche Projekte sind!

Systemfunktionen identifizieren

Die Funktionen eines Systems sind entscheidend für die Erzeugung eines Nutzens für den Kunden. Dabei ist egal, ob die Funktion über Software, Hardware oder Konstruktion umgesetzt wird. Deshalb ist es wichtig, die Systemfunktionen zu identifizieren. Weiterlesen

Lastenhefte analysieren

Lastenhefte analysieren – ein wichtiges Puzzlestück in der Entwicklung, um zu verstehen, was der Kunde sich wünscht. Denn Lastenhefte beschreiben das „Wünsch-dir-was“ eines Kunden.

Weiterlesen

5 Schritte zur erfolgreichen Systemabgrenzung im Lastenheft

Eine erfolgreiche Systemabgrenzung hilft im Lastenheft zu entscheiden, wo drinnen und wo draußen ist.

Ein System existiert niemals alleine, sondern interagiert immer mit anderen Systemen oder Menschen. Die Grenzen zeigen uns, was im System drinnen und draußen ist. Gleichzeitig ermöglicht uns die Systemgrenze auch, die Schnittstellen des Systems zu identifizieren und festzulegen, was über die Systemgrenzen hinweg ausgetauscht wird. Schnittstellen sind der entscheidende Faktor in einem System. Weiterlesen

Sieben Möglichkeiten um Requirements zu finden

Um Requirements an ein System zu finden müssen wir eine Übersicht erlangen. Das bedeutet, sich die Zeit zu nehmen, um alle relevanten Quellen zu sammeln und sich einen Überblick zu verschaffen. Weiterlesen