Agile Methoden im Projekt- und Produktmanagement, in der Anforderungsanalyse und bei Realisierung, Test, Einführung und Betrieb sind große Herausforderungen für jede Projektorganisation. Häufig sind die Entscheider in diesen Projekten Personen, die nicht überzeugt sind von Agilität, ein eigenes Verständnis davon haben (z.B. agil mit chaotisch verwechseln) oder ganz einfach nichts oder zu wenig darüber wissen. Dadurch entstehen ganz spezielle Prozesse, ein projektspezifischer Mix aus Vorgehensmodellen. Akzeptieren wir die Tatsache, dass für etablierte Management-Prozesse Lastenheft, Pflichtenheft und vor allem Expertenschätzungen notwendig sind, dann ergibt sich mit der Verwendung von CARDS+ die Chance, diese Inhalte gewinnbringend und qualitätsfördernd für die Realisierung zu erhalten.

15 Die große Chance

Motivation

Agilität schafft Vorteile für alle Prozesse. Hier herrscht mittlerweile große Einigkeit. Scrum ist eine Methode, die eine praktikable Lösung für agile Produktentwicklung anbietet, für andere Prozesse aber keine Aussagen trifft. Es reicht auch nicht, rein formal alle Rollen von Scrum zu besetzen. Ein Projektleiter ist nicht automatisch geeignet als Scrum-Master oder Product-Owner. Kein Team wird von Anfang an vollkommen selbst organisiert sein. Selbst die “großen” agilen Vorgehensmodelle wie Safe, Nexus oder Less decken nicht jeden Prozess in der gleichen Qualität ab. Und viele Erweiterungen dieser Vorgehensmodelle zielen darauf ab, den Kontrollverlust im Management auszugleichen. Auftraggeber und Manager wünschen sich Sicherheit durch bekannte Strukturen wie Lastenheft, Pflichtenheft, Meilensteine und Schätzungen. Strukturen, die ihnen in den phasenorientierten Vorgehensmodellen immer zur Verfügung gestellt wurden. Auftraggeber brauchen häufig solche “schwergewichtige” Dokumente für interne Freigabeprozesse zur Bereitstellung der Finanzmittel für das Projekt. Die rechtlichen Rahmenbedingungen für agile Projekte orientieren sich immer noch an der Frage, welche Ansprüche der Auftraggeber hat, wenn der Auftragnehmer seine “Pflicht” nicht erfüllt, also Termine nicht einhält oder den ursprünglich geplanten Umfang nicht liefert, unabhängig von zwischenzeitlichen Erkenntnissen. Was aber irgendwie schräg ist, weil wir durch Agilität eigentlich das richtige Produkt zum richtigen Zeitpunkt liefern wollen, weil wir Veränderungen zu unserem Vorteil nutzen können. Mit CARDS+ eröffnen wir uns die große Chance, eine inkrementell erstellte Produktdokumentation durch selektiven Export in die Form altbekannter Strukturen wie Lastenheft, Pflichtenheft oder Schnittstellenbeschreibung zu transformieren.

ktip In Confluence reicht die Standardfunktion leider nicht für einen professionellen Export aus dem Wiki. Die Erweiterung (Add-onScroll-Office schafft hier Abhilfe.

Mit diesen gesicherten Zwischenständen (englisch baseline) können wir “klassische” Prozesse bedienen. Die Empfänger der Dokumente erkennen keinen Unterschied. Inhalt und Form sind quasi identisch. Der Vorteil für den Ersteller der Dokumente ist das inkrementelle Schreiben mit den Bausteinen von CARDS+, die Prüfbarkeit der Inhalte und die Verwendung eines Wiki. Bereits jetzt entsteht das Glossar und die gemeinsame Sprache. In phasenorientierten Prozessen wurden diese Dokumente nach Abschluss der Phase ganz oft zur Seite gelegt (Archiv, Rundablage) und durch neue, genauere Dokumente ersetzt:

  • Ein Lastenheft wird durch das Pflichtenheft ersetzt.
  • Ein Pflichtenheft wird durch ein oder mehrere Fachkonzepte konkretisiert.
  • Expertenschätzungen werden immer wieder neu gemacht.
  • Schnittstellenbeschreibungen sind für jede Schnittstelle individuell gestaltet.

Mit CARDS+ bleiben die Inhalte im Wiki erhalten und werden laufend verbessert, neue Erkenntnisse und Feedback aller Projektmitarbeiter fließen ein. Wissen aus den Anfängen des Projektes steht dadurch den Entwicklern auch später noch zur Verfügung.

Lastenheft

Das Lastenheft wird vom Auftraggeber eines Projektes formuliert. Es präzisiert und ergänzt den Auftrag und definiert die Rahmenbedingungen eines Projektes. Es beschreibt die Anforderungen des Auftraggebers an ein zukünftiges Produkt.

ktip Im Beitrag “Was? Pflichtenheft und Lastenheft sind nicht dasselbe?” geht der Autor auf die Unterschiede zwischen Lasten- und Pflichtenheft ein.

Die Form des Lastenheftes wird immer projektspezifisch gestaltet. Das ist eine große Chance. Wenden wir die Methode CARDS+ bereits vor dem Projektstart an, dann werden die Anforderungen an das zukünftige Produkt bereits in der bekannten Struktur mit den Bausteinen Topic und Epic erfasst. Gleich zu Beginn wird der Grundstein für das Glossar und die gemeinsame Sprache im Projekt gelegt. Beim Baustein Topic ist der Auftraggeber auch ganz klar Experte. Er kennt seine Ziele, weiß, für welche Aufgabenbereiche das gewünschte Produkt gebraucht wird. Der Baustein Epic ist sehr gut geeignet, die Motivation und grobe Idee der Fachabteilung des Auftraggebers für eine Anforderung zu erfassen, wie sie in Lastenheften üblicherweise formuliert wird.

Stellen wir uns einen Auftraggeber vor, der ein Lastenheft inkrementell erstellen will. Dieser Auftraggeber könnte auf die Idee kommen, sein Lastenheft einem potentiellen Auftragnehmer in einem Workshop vorzustellen. Der Auftragnehmer wird vermutlich Fragen stellen, wenn eine Anforderung nicht klar ist. Dieses direkte Feedback kann der Auftraggeber sofort zur Verbesserung des Lastenheftes verwenden. Gibt es mehr als einen interessierten Auftragnehmer, kann der Workshop wiederholt werden. Ganz nebenbei kann ein Auftraggeber mit dieser Maßnahme von Anfang an agile Werte praktizieren. Er erlebt, wie ein Produkt (hier das Lastenheft) inkrementell entsteht. Wie jedes andere komplexe Dokument wird auch ein Lastenheft mehrfach gelesen, kommentiert und verbessert. Auch hier kann das Wiki eine echte Verbesserung sein. Die Aufteilung in Bausteine ist eine Erleichterung für jeden Leser. Das wird jeder bestätigen, der schon einmal ein viele hundert Seiten dickes Dokument lesen und prüfen musste. Auch die Möglichkeit, Seite für Seite zu lesen und gemeinschaftlich zu kommentieren ist ein unschätzbarer Vorteil. Der Autor muss sich nicht durch zig Kopien seines Dokumentes wühlen, um jeden Kommentar einzeln zu beurteilen und Änderungen im Hauptdokument zu machen. Leicht geht so wertvolles Feedback verloren.

Pflichtenheft

Ein Auftragnehmer erstellt auf Grundlage eines Lastenheft sein Pflichtenheft. Es beschreibt, wie und womit er das gewünschte Produkt umsetzen will. In Kombination mit einem Angebot stellt es die vertragliche Grundlage der zu erfüllenden Leistungen dar. Mit dem Einsatz von CARDS+ ist die Erstellung des Pflichtenheftes der nächste logische Schritt nach dem Abschluss des Lastenheftes.

ktip In Confluence reicht die Standardfunktion leider nicht für eine saubere Trennung von Lasten- und Pflichtenheft in einem Bereich. Die Erweiterung (Add-onScroll-Versions schafft hier Abhilfe.

Der Auftragnehmer hat durch das Lastenheft einen mehr oder weniger klaren Auftrag. Nutzt der Auftraggeber die Chance, das Lastenheft im Wiki mit dem Auftragnehmer in einem Workshop durchzugehen, Begriffe im Glossar zu definieren und Fragen zu klären (wie in einem Refinement in Scrum), können bereits jetzt Missverständnisse ausgeräumt werden. Ein Auftraggeber kann das Lastenheft sogar als Wiki bereitstellen.

ktip Confluence kann mittlerweile von vielen Service-Anbieter praktisch auf Knopfdruck bereitgestellt werden. Ein Lastenheft als Wiki kann daher sehr einfach und kostengünstig für jeden potentiellen Auftragnehmer für begrenzte Zeit bereitgestellt werden.

Der Auftragnehmer ergänzt das Lastenheft um die Bausteine Case und Layout. Der Baustein Case konkretisiert jedes Epic aus dem Lastenheft. Die Lösung wird jetzt angedeutet, wenn es möglich ist oder ganz offen gelassen. Ein Layout vervollständigt das Pflichtenheft um den Entwurf für die Benutzeroberflächen. Das Pflichtenheft enthält das komplette Lastenheft. Kann oder will ein Auftragnehmer ein Epic nicht realisieren, kann er dies direkt als Abgrenzung dokumentieren. Der Auftragnehmer legt sich in dieser Phase auf den Architekturstil fest, mit dem er glaubt, das Produkt realisieren zu können. Treiber sind die angedeuteten Lösungen in jedem Case. Der Architekturstil ergibt sich dabei aus einer Reihe von technischen Entscheidungen, die der Auftragnehmer mit dem Baustein Decision dokumentiert.

Schnittstellenbeschreibung

Schnittstellenbeschreibung sind in einem komplexen Umfeld mit vielen Schnittstellenpartnern aus verschiedenen Organisationseinheiten eines Unternehmens “alternativlos”. Wir dürfen trotzdem die Frage stellen, wie umfangreich so ein Dokument sein muss. Die besondere Herausforderung ist hier häufig das aufeinander treffen von Projekten mit unterschiedlicher Projektkultur. Oft treffen agile Projekte auf phasenorientierte Projekte. Die Nutzung und Bedeutung der Schnittstellenbeschreibung für eine Schnittstelle unterscheidet sich dann sehr. Im einem agilen Projekt will man offen gegenüber Änderungen auch an Schnittstellen sein, in einem phasenorientierten Projekt muss Struktur und Umfang einer Schnittstelle ganz genau definiert sein, Änderungen sind nur mit großem Widerstand durchführbar.

In diesem Spannungsfeld können wir mit CARDS+ trotzdem inkrementell dokumentieren. Eine Schnittstellenbeschreibung besteht aus einem Rahmendokument, dass  im Wiki für jede Schnittstelle erstellt und gepflegt wird. Das Rahmendokument enthält Abschnitte wie Steckbrief oder Kontext der Schnittstelle, eine Übersicht der Operationen und Vereinbarung zu nicht-funktionalen Aspekten. Das Versprechen an den nicht-agilen Schnittstellenpartner ist die hohe Qualität der Schnittstellenbeschreibung. Ein weiterer Vorteil ist die Verknüpfung der Spezifikation der Schnittstelle mit den Bausteinen Epic und Case aus der Systembeschreibung. Auch technische Beschreibungen in den Bausteinen Service (die Schnittstellenendpunkte), Entity und Event (z.B. als Nachrichtenmodell der Schnittstelle) machen Informationen des agilen Projektes ganz transparent für den Schnittstellenpartner verfügbar. Informationen sind Immer aktuell, sie werden ja während der Entwicklung validiert und aktualisiert. Mit anderen Worten teilen wir mit einer Schnittstellenbeschreibung unser aktuelles Wissen aus dem Projekt mit dem Schnittstellenpartner.

Expertenschätzung

Schätzen ist ein kontrovers diskutiertes Thema in agilen Projekten. In der agilen Entwicklung mit Scrum schätzen wir die Komplexität einer Aufgabe bei der Umsetzung einer User-Story. Natürlich gehen wir davon aus, dass das cross-funktionale Team die Aufgabe verstanden hat, dass wir das komplexe Problem so abgegrenzt haben, dass es vielleicht sogar eine offensichtliche Lösung gibt. Zumindest aber ist die Aufgabe kompliziert, aber wir haben einen konkreten Plan, der auf mehr oder weniger Erfahrung basiert.

Sobald aber die Frage nach einer Schätzung zum Produkt für eine langfristige Planung gestellt wird, gibt es erste Widerstände. Die Diskussion dazu würden den Rahmen des Artikels sprengen. Gehen wir einfach jetzt davon aus, dass eine langfristige Schätzung einfach notwendig ist, um die Finanzierungszusage für die Produktinkremente im nächsten Jahr zu erhalten. Agil hin oder her, wir brauchen eine Zahl, an die wir selbst glauben. Viel wichtiger ist aber, dass wir klar zeigen, was wir in der Schätzung berücksichtigt haben und was nicht. Finden wir später Lücken oder müssen wir eine Einschätzung korrigieren, sollten wir in der Lage sein, die Schätzung anzupassen, um den Unterschied gegenüber der ursprünglichen Schätzung zu zeigen.

Eine strukturierte Systembeschreibung, wie wir sie mit CARDS+ erstellen, ist eine Basis für die Schätzmethode mit dem Namen Use Case Points. Wir nutzen den Baustein Case für die Schätzung. Ein Case erfüllt alle Bedingungen der Schätzmethode. Es ist völlig ausreichend, wenn der Case nur das fachliche Problem beschreibt und die Lösung nur angedeutet wurde oder sogar völlig offen ist. Wir wollen ja schätzen. Die Erstellung eines Case ist für uns kein Zusatzaufwand, er gehört zum Backlog-Management.

  • Use Case Points nutzt den Baustein Case als Eingangsgröße (“Use Case”) der Methode. In der Schätzmethode wird somit jeder Case in seiner Komplexität eingeschätzt und bildet so die Grundlage für die Schätzung.
  • CARDS+ stellt die Nachvollziehbarkeit der Schätzung durch die Pflege der Bausteine Epic und Case sicher.

Im Verlauf der Entwicklung verbessern wir jeden Case, fügen eine konkrete Lösung hinzu. Wenn wir wollen, können wir auch die Schätzung laufend verbessern. Mit der Kombination der Methoden CARDS+ und Use Case Points können wir inkrementell schätzen. Damit erarbeiten wir uns eine Möglichkeit, die Auswirkung von Veränderungen transparent zu machen, auch für nicht ganz so agile Projektorganisationen.

Fazit

Meiner Meinung ist das Thema Wissen in agilen Projekten zu wenig beachtet. Wissen muss erarbeitet, gesammelt, bereitgestellt und verteilt werden. Niemand will Kopfmonopole und Wissensinseln, aber Kommunikation alleine kann sie in ausreichend komplexen Projekten nicht verhindern. Eine angemessene Produktdokumentation kann die Lücke schließen, ein inkrementelles Vorgehen wie bei CARDS+ die Erstellung in hoher Qualität ermöglichen. Auch der Bedarf von Organisationen großer Unternehmen an “klassischer” Dokumentation führt in agilen Projekten zu unerwarteten und ungeliebten Zusatzarbeiten. Solche extra Dokumentation kann aus einer gut strukturierten Produktdokumentation jederzeit und schnell erzeugt werden. Die Methode CARDS+ ist ein möglicher Weg zu einer hochwertigen, strukturierten Produktdokumentation.