Beiträge

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.

Sieben Tipps zur Erstellung von Lastenheften – Teil II

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Hier geht es zu den ersten drei Tipps!

Tipp 4: Keine Referenzen auf Personen!

Auch das habe ich immer wieder erlebt: „Kann man nicht noch einmal auf den Kollegen, der den Input gegeben hat, referieren?“

Nein, kann man nicht!Das macht in einem Lastenheft keinen Sinn, und zwar aus zwei Gründen: Zum einen wird dieser Kollege in einem Jahr wahrscheinlich nicht mehr an der Position oder nicht mehr für die Aufgabe zuständig sein. So ist das Projektgeschäft, Projekte wechseln, Kollegen wechseln.

Zum anderen kann daraus der Fehler entstehen, diese Person indirekt oder sogar direkt als Anforderung zu beschreiben: „Das ist die Person, mit der alles geklärt werden muss.“

Also: Keine Referenzen auf Personen im System-Lastenheft. Das ist ganz, ganz wichtig.

Tipp 5: Kein Excel!

Bitte, bitte, bitte kein Excel. Wenn kein Requirements-Management-Werkzeug vorliegt oder ein Austausch mit dem Kunden nicht anders funktioniert, verwendet Word – aber kein Excel.

Erstens kann Excel keine Bilder einbinden: Wenn ich eine Visualisierung im Lastenheft haben will und Excel nutze, schwebt diese gedanklich quasi über den Tabellen. Das heißt vor allem, dass es keine Zuordnung gibt. Wenn dann – wie schon oft erlebt – Inhalte und Referenzen verrutschen, Zeilen gelöscht oder verschoben werden, steht das Bild plötzlich ganz woanders bzw. vielleicht noch auf der gleichen Position, aber mit ganz anderem Kontext.

Bei Word funktioniert das besser, Word kann mit Bildern umgehen.

Zweitens verführt Excel einen dazu, in dieser Tabellensicht eines Requirements-Management-Werkzeuges zu arbeiten. Das ist zwar super, wenn man Profi ist – aber in der Regel sind die Leute, die so ein Artefakt, so ein Lastenheft schreiben, nicht unbedingt Spezialisten für Requirements-Management-Werkzeug-Anwendungen. Das bedeutet, sie haben enorme Schwierigkeiten, in so einer Excel-Tabelle flüssig zu schreiben. Dabei ist genau das viel wichtiger. Ich kümmere mich um den Rest und mache mit meiner Erfahrung alles entsprechend „sauber“.

Mir ist es egal, ob Deutsch oder Englisch, und mir ist auch egal, wie es formuliert ist, Requirements-Grammatik muss hier nicht eingehalten werden, nichts muss eingehalten werden – Hauptsache, die Inhalte werden flüssig heruntergeschrieben, wie sie den Kollegen in den Kopf kommen, und liegen am Stück vor.

Fangen die Leute aber an, in Excel von einem Tab zum nächsten und von einer Zeile zu anderen zu springen, kann genau dieses „Herunterschreiben“ nicht funktionieren.

Also bitte, bitte kein Excel.

Tipp 6: Keine Lösungen beschreiben!

Mit diesem Punkt verhält es sich so ähnlich wie mit dem bereits beschriebenen Pseudo-Code – und auch dieser Punkt ist extrem wichtig: Wir beschreiben im Lastenheft keine Lösungen.

Was wir schon beschreiben können, ist, welche Dinge übernommen werden müssen, aus welchem Grund auch immer. Das ist kein Problem, aber wie eine zukünftige Lösung, die noch zu entwickeln ist, auszusehen hat, gehört hier nicht hin.

Was ich hineinschreibe, ist der Wunsch, die Vorstellung von dem, was ich hinterher brauche – nicht aber, wie es umzusetzen ist. Denn Lösungsbeschreibungen kommen erst auf der Systemebene, nicht auf der Ebene des Lastenheftes.

Tipp 7: Lastenhefte sind keine Pflichtenhefte!

Vermischt Lastenhefte nicht mit Pflichtenheften. Ein Lastenheft ist ein „Wünsch dir was“ – und bleibt ein „Wünsch dir was“.

Ich habe mittlerweile mit mehreren Kunden aus den verschiedensten Branchen genau diese Diskussion geführt. Die Vermischung kommt häufig daher, dass Firmen bzw. Projekte kein Requirements-Management-Werkzeug nutzen. Das bedeutet, wenn sie Lastenheft und Pflichtenheft als einzelne Dokumente sehen, als einzelne Artefakte, müssten sie im Grunde hingehen und Teile des Lastenhefts kopieren, entsprechend ergänzen, verändern, anpassen, löschen und so weiter. Sie müssten inhaltlich quasi Sinnvolles übernehmen bzw. andere Antworten schreiben.

Das führt dazu, dass viele darin doppelte Arbeit sehen bzw. das ganze Organisieren und Verwalten eben nicht entsprechend funktioniert. Wir können aber, solange kein Requirements-Management-Werkzeug da ist, keine Traceability – so nennt sich das fachlich – herstellen. Das heißt, ich kann nicht aus einem Lastenheft eine Anforderung in ein Pflichtenheft ableiten.

Um das zu umgehen, neigen viele Firmen dazu, Lasten- und Pflichtenheft in ein Dokument zu schreiben. Ob diese Teile in zwei verschiedenen Farben dargestellt werden oder das eine Heft quasi mithilfe der Struktur des Dokuments dargestellt wird: Ganz ehrlich – das ist Bullshit.

Lasst das bleiben! Und wenn Ihr doch diesen Weg gehen wollt: Ich gehe da nicht mit. Es führt – auch aus Erfahrungen aus dem Trouble-Shooting – definitiv ins absolute Chaos.

Sieben Tipps zur Erstellung von Lastenheften – Teil I

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Tipp 1: Realistische und strikte Zeitplanung und -einhaltung!

Ihr müsst Eure (und meine) Zeit sinnvoll einplanen – und dranbleiben. Bei meinen Erstgesprächen für die Erstellung eines Lastenheftes mit den Entwicklungsleitern kommt sehr schnell die Frage: „Wie viel Zeit werden wir brauchen?“

Zunächst sind der Footprint-Workshop und der Aufbau der Release-Strategie ganz wichtig – auf diesen beiden Grundlagen basiert schließlich der gesamte Rest. Zeitlich sind sie allerdings nicht so wahnsinnig aufwändig: Diese beiden Punkte sind relativ einfach in ein bis zwei Tagen abzuarbeiten.

Dann geht es um das Erarbeiten der Inhalte (also der Teile 0.3, 0.5, 0.7, 0.8, 0.9, 1.0) – und hier müssen wir zwischen dem Aufwand und der Dauer unterscheiden. Der Aufwand auf Seiten des Projektes entsteht, weil noch fehlende Teile beschrieben werden und viele Inhalte zum Review müssen.

Der Aufwand auf meiner Seite ist ein etwas anderer: Ich kümmere mich mit meinem Erfahrungsschatz und meinem Wissen – quasi mit der Hand auf dem Ganzen – um die Erstellung und das „Hübsch-Machen“. Beim B.-Braun-Projekt beispielsweise belief sich mein Aufwand auf 18 Tage.

Man könnte meinen, dies klinge relativ locker – doch Vorsicht: Aufwand ist nicht Dauer! Denn gleichzeitig bedeutet diese Vorgehensweise auch: Wenn irgendjemand im Projekt etwas sucht oder erarbeitet, ist das eine Phase, in der ich zunächst auf weiteren Input warte. Entscheidend für die Organisation ist hierbei, dass ich je nach Projektphase ca. zwei Tage pro Woche für solche 18-Tage-Projekte einplane.

Somit bedeutet dieser Aufwand also eine Dauer von vier Monaten – und das ist nicht unüblich. Bei der Berechnung kommt es auch auf die Größe und die Komplexität des Systems an: Bei überschaubaren Subkomponenten und einem übersichtlichen Entwicklungsteam war das schnellste Lastenheft in ca. drei Wochen erstellt, das aufwändigste dauerte hingegen acht Monate: Hier handelte es sich um ein hochkomplexes, hochintegratives System von Systemen.

Mein Fazit: Unterschätzt die Dauer nicht, auch wenn der Aufwand nicht allzu hoch sein mag.

Plant also die Zeit ein – und vor allem: Bleibt dran! Das ist ein ganz großer Punkt. Immer wieder erstelle ich für Projekte Lastenhefte und merke, dass die Aktivitäten peu à peu weniger werden oder gar im Sande verlaufen.

Hierbei ist der Projektleiter ganz entscheidend, denn ich kann die Motivation des Teams nicht steuern, das kann nur er: Wenn der Projektleiter sich dahinterklemmt, dranbleibt und das Ganze wirklich planmäßig abschließen WILL, dann schaffen wir es auch.

Tipp 2: Weniger ist mehr!

Ich bekomme bei den Vorbereitungen immer wieder zu hören, dass man am liebsten alles und jeden noch in das Lastenheft hineinschreiben möchte. Meine Antwort: „Nein.“

Der große Trick, die große Kunst ist, zu streichen. So lange zu kürzen, bis wir merken: Wenn wir diesen Teil jetzt löschen – diesen Satz, dieses Kapitel, dieses Unterkapitel –, verändern wir den Inhalt entscheidend. Für uns Ingenieure ist es ganz normal, zu viel zu dokumentieren, zu viel hineinzuschreiben – allerdings führt das nicht zu einem Mehrwert im Verständnis, ganz im Gegenteil: Meist führt es nur zu Unklarheiten.

Hier helfen mir die Inhalte der Phasen 1.5 bis 1.8, also die Peer-Reviews, die ich parallel mache und in denen ich ebenso die Frage stelle: „Muss das da rein? Kann man das nicht komprimieren, fokussieren, rausschmeißen?“.

Dieses „weniger ist mehr“ ist ganz wichtig, wenn schließlich Punkt 1.0 in der Welt ist und darauf basierend vielleicht andere, neue Kollegen mit der Umsetzung konfrontiert werden.

Tipp 3: Kein Pseudo-Code!

Pseudo-Code kommt primär im Embedded-Software-Umfeld vor – und gehört dort auch hin. Ich hingegen schreibe keinen Pseudo-Code, denn dies ist eine Lösungsbeschreibung, auf der basierend vor allem Softwareentwickler Quellcodes umsetzen sollen.

Ich mache aber in einem Lastenheft für ein komplexes technisches System auf der obersten Ebene keine Lösungsbeschreibung, die irgendwo ganz unten und viel später eine Embedded-Software im Design umzusetzen hat.

Wenn ich ein Verhalten beschreiben muss, kann ich das wunderbar mit anderen Mitteln machen, aber eben nicht mit Pseudo-Code. Das Gleiche gilt als Bild übrigens auch für die Elektronik und für die Konstruktion.

 

Hier geht es zu den nächsten vier der sieben Tipps

Episoden

SF008: Fünf Mythen rund ums Lastenheft

11.08.2015 16 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Seit über 10 Jahren beschäftige ich mich als Systemingenieur mit Lastenheften und mir sind einige Mythen über den Weg gelaufen, mit denen ich aufräume.

Denn diese Mythen halten sich hartnäckig und sind oftmals mit ein Grund, warum Projekte in Schwierigkeiten kommen. In der Episode wirst du erfahren, warum Lastenheft oft inhaltlich falsch sind und was du dagegen tun kannst.

Die fünf Mythen rund ums Lastenheft:

  • Mythos #1: Es ist effektiv das Lastenheft und das Pflichtenheft in ein Dokument zu packen
  • Mythos #2: Wir machen Scrum und brauchen kein Lastenheft
  • Mythos #3: Ein Lastenheft kann nicht mehr verändert werden
  • Mythos #4: Projektanforderungen gehören ins Lastenheft
  • Mythos #5: Ein Lastenheft zu erstellen braucht Monate

SF007: Fünf Tipps zum Requirements Management mit Word und Excel

28.07.2015 38 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Mittelständische Firmen nutzen Word oder Excel, weil Requirements Management Tools sind zu teuer oder zu kompliziert sind. Das kann schnell schief gehen.

Ich gehe in dieser Episode auf viele Hörerfragen zum Requirements Engineering und Management mit Word und Excel ein. In der Episode wirst du erfahren, wie Spezifikationen mit Word gehand habt werden können und warum Excel der Tod für dein Requiremens Management ist.

Inhalt der Episode:

  • Die aktuelle Situation in mittelständischen Unternehmen
  • Meine fünf Tipps zum Requirements Management mit Word und Excel
    • Welche Spezifikationen brauche ich?
    • Wie organisiere ich die Spezifikationen?
    • Wer ist für die Spezifikationen verantwortlich?
    • Was könnt Ihr gewinnen, wenn Ihr auf ein Requirements Management Tool geht?
    • Was sind die Herausforderungen mit einem Requirements Management Tool?

SF006: Geheimwaffe Reviews

14.07.2015 18 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Aus meiner Erfahrung ist diese Methode eine mächtige Waffe, um Projekte zum Erfolg zu führen.

Fehler, die im Reviews auffallen, können häufig bedeutend kostengünstiger behoben werden, als wenn diese erst während der Testdurchführung gefunden werden. Untersuchungen haben gezeigt, dass mit Reviews 85% der Fehler bei einem Aufwand von 25% gefunden werden können. In der Episode wirst du erfahren, warum Reviews so wirkungsvoll sind, welche Arten von Reviews es gibt, wie du Reviews durchführen kannst und was für Tipps und Tricks es aus meiner Praxiserfahrung gibt.

Inhalt der Episode

  1. Einleitung und Begrüßung
  2. Warum sind Reviews so wirkungsvoll?
  3. Wie kannst du Reviews gezielt einsetzen?
  4. Welche Arten von Reviews gibt es?