Nehmen Sie an, Sie werden beauftragt, ein völlig neues Software-Produkt zu entwickeln. Sie bekommen die Chance, eine individuelle Lösung mit einer agilen Projektorganisation auf der “grünen Wiese” zu entwerfen. Ich möchte Sie an meiner Vision teilhaben lassen, in der dieses Projekt mit der Methode CARDS+ erfolgreich startet.

01-Vision-Produktidee

Ausgangssituation

Oft wird ein Projekt auf der “grünen Wiese” gestartet, um ein schlecht oder gar nicht dokumentiertes Bestandsystem (englisch: legacy system) zu ersetzen. Es kann nicht mehr gewartet werden, weil der letzte Programmierer, der sich im Code auskannte, nicht mehr verfügbar ist (Pension, Tod, keine Lust). Oder der Hersteller von Hardware oder Software existiert nicht mehr oder bietet das Produkt zukünftig nicht mehr an. Diese Situation entsteht auch bei einer Individuallösung, die mehr schlecht als recht gewartet wird. Die Projektmitarbeiter sind kaum mehr motiviert. Das Budget für die Wartung ist beschränkt. Die Kosten für die Wartung steigen kontinuierlich. Die Gründe sind fehlende Innovationen, immer mehr technische Schulden, Wissensverlust durch Fluktuation oder wachsende Lizenz- oder Betriebskosten. Es kann aber ganz einfach eine neue bahnbrechende Idee sein!

Projektinitialisierung

Das Projekt hat klare Ziele, macht aber (noch) keine Vorgaben für die technische Umsetzung. Für das neue System formuliert der Auftraggeber neben der prinzipiellen Projektidee ein paar weitere Randbedingungen:

  1. Das System muss “zukunftssicher” sein.
  2. Das System muss “agil” entwickelt werden.
  3. Die Projektorganisation ist nur in Deutschland, dort aber auf mehrere Standorte verteilt.
  4. Das System muss “vollständig” dokumentiert sein.

Was bedeutet “zukunftssicher”? Meiner Meinung nach kann das nur bedeuten, dass wir versuchen, die derzeit am besten geeignete technische Lösung für die fachlichen Problemstellungen einzusetzen. Niemand kann in die Zukunft blicken und behaupten, dass wir jetzt die beste Lösung kennen und keine bessere kommen wird. Darum müssen wir sicherstellen, dass wir einzelne Entscheidungen im Rahmen der technischen Lösung mit so geringem Aufwand wie möglich korrigieren können.

Die Entscheidung, agil zu entwickeln, kann verschiedene Beweggründe haben. Oft wird agile Entwicklung damit verwechselt, dass wir so “billiger” entwickeln können (→dilbert.com). Ob wir durch agile Entwicklung schneller Ergebnisse produzieren können, hängt maßgeblich von der Qualität der Anforderungen und von der Effizienz und Genauigkeit bei der Vermittlung des Produktwissens ab – und hier spielt die Produktdokumentation eine große Rolle. Direkte, persönliche Kommunikation im Team ist sehr effektiv. Aber welches Wissen bei den Projektmitarbeitern ankommt, und wie die Kollegen das Wissen für ihren Bedarf sichern ist völlig unterschiedlich. Eine dokumentiertes Produktwissen hingegen ist immer verfügbar. Es ist ein Ergebnis des ganzen Teams. Jeder im Team trägt seinen Teil zum Ganzen bei. Argumente für agile Entwicklung gelten auch für agiles Dokumentieren. Agil eine Produktdokumentation zu schreiben bedeutet, dass wir alle Informationsquellen im Projekt berücksichtigen, also auch Code, Spezifikationen, Konfigurationen, Testfälle.

Besonders im Zusammenhang mit verteilter Fertigung ist eine Produktdokumentation mit hoher Qualität ein ganz wichtiger Faktor für den Erfolg des Projektes. Die Einschränkung auf Deutschland spielt hierbei eine eher untergeordnete Rolle. Es ist ein Vorteil bei dem Ziel, eine gemeinsame Sprache im Projekt zu etablieren. Dabei geht es um eindeutige Begriffe, die von allen Mitarbeitern in allen Bereichen gesprochen wird. Das Glossar ist der Teil der Produktdokumentation, der für die Erreichung des Ziels unbedingt notwendig ist.

Projektdurchführung

Ganz spannend ist es, die Projektorganisation davon zu überzeugen, dass eine Produktdokumentation bereits beim Start des Projektes begonnen wird. Oft höre ich, dass die Leute gerade mit anderen, wichtigeren Dingen beschäftigt sind. Also wird der Aufbau der Produktdokumentation verschoben. Dabei vergeben wir aber eine große Chance.

Die Produktdokumentation hilft uns, bereits am Beginn des Projektes eine gemeinsame Sprache zu etablieren. Durch die Erstellung und laufende Pflege des Glossars und die Erstellung eines Fachklassenmodells mit den wichtigsten Klassen legen wir verbindliche Begriffe im Projekt fest. Auch die Struktur des Systems kann bereits beim Projektstart analysiert werden. Es ist zielführend und auf jeden Fall machbar, bereits beim Start des Projektes alle Topics zu kennen und ihnen einen aussagekräftigen Namen zu geben. Dadurch erhalten wir bereits sehr früh einen ersten Eindruck von der Komplexität des System. Und wir wissen, welche Geschäftsprozesse vom System berührt werden. Dadurch wissen wir auch sehr früh, wer unsere Stakeholder sind – und zwar alle, nicht nur die Auftraggeber.

Es ist kein Widerspruch mit einer agilen Methode, beim Projektstart einen fachlichen Strukturrahmen oder eine fachliche Architektur zu definieren. Agil bedeutet aber in diesem Zusammenhang, dass nur das dokumentiert wird, was auch besprochen wird. Es ist illusorisch, bereits jetzt alle Epics zu kennen. Ein Fachklassenmodell, dass bereits alle Unterklassen und Typen bis zur Ebene der Attribute und Operationen beschreibt, ist zu diesem Zeitpunkt falsch.

Gleiches gilt für die Architekturdefinition. Gerade jetzt werden viele wichtige technische Entscheidungen getroffen. Gerade jetzt ist es besonders wichtig, diese Entscheidungen auch als Decisions zu dokumentieren. Jetzt sind alle betrachteten Lösungsalternativen und die Argumente für oder gegen eine Middleware, ein Framework oder ein technisches Konzept noch bekannt. Später können uns diese Decisions helfen, trotz Problemen an Entscheidung festzuhalten oder sie aufgrund nicht behebbare Mängel zu korrigieren.

Fazit

Wenden wir bereits beim Projektstart die Methode CARDS+ an, dann geben wir uns von Anfang an das Versprechen, eine vollständige Produktdokumentation mit hoher Qualität zu erstellen.

  • Wir trainieren von Anfang an die konsequente Arbeit mit einem Wiki.
  • Wir leben eine Projektkultur, in der Feedback gewünscht und gefördert wird.
  • Wir haben ein Ziel: Eine vollständige Produktdokumentation.
  • Wir tragen gemeinsam Verantwortung für die Qualität.

Mit der Produktdokumentation können wir unseren Auftraggebern den Fortschritt neben dem lauffähigen Produktinkrement (englisch: potentially shippable increment) auch in einer Form präsentieren, die er lesen kann: Als Baseline der Produktdokumentation.