Für die Darstellung der Lösung verwende ich gedanklich ein ausreichend komplexes Projektumfeld. Das Projekt hat die Aufgabe, ein Software-Produkt agil zu entwickeln. Der Auftraggeber und die Stakeholder sind in dieser agilen Methode integriert. Sie haben Ziele festgelegt, die nicht nur die Realisierung eines Software-Produktes, sondern auch die Bereitstellung einer Produktdokumentation umfasst, bestehend aus einer Systembeschreibung, einer Architekturdefinition und Benutzer– und Betriebshandbuch.

10 Was ist die Lösung

In diesem Artikel beschränke ich mich auf die Rolle der agilen Methode CARDS+ für Wissensmanagement in einem Software-Projekt. Die Methode

  • gibt ein Wissensmodell mit klar definierten Strukturen vor,
  • legt Regeln fest, die es dem Team ermöglichen, die geforderte Qualität sicherzustellen,
  • formuliert Praktiken, durch die wir wichtige Informationen von weniger wichtigen unterscheiden können und
  • fordert Werkzeuge, die es uns erlauben, schnell und effektiv einmal erarbeitetes Wissen zu sichern.

Bereitstellung von Wissen

In der agilen Methode Scrum ist die Verwendung von User-Stories und Epics für die Bereitstellung von Wissen bereits fest verankert.

Eine User-Story kann Wissen zwar sehr effizient vermitteln, aber das Wissen wird nicht in einer nachhaltigen Form gespeichert.

User-Stories sind für die Realisierung der Software unabdinglich. Aber User-Stories sind häufig aufeinander aufbauend, sie beschreiben quasi den Weg der Entwickler in den Sprints. Es fehlt die konsolidierte Form der User-Story, die es uns später noch erlaubt, die Umsetzung nachzuvollziehen. Die Beschreibung in einer User-Story “verdirbt” recht schnell.

Der Einsatz geeigneter Werkzeuge für die Abbildung von Product- und Sprint-Backlog stehen nicht zur Diskussion. Wir nutzen aber User-Stories nur in Kombination mit unserer Systembeschreibung. Und wir treffen die bewusste Entscheidung, dass alle weiteren Informationen, die wir in der User-Story erfassen, nur den agilen Prozess der Entwicklung im Sprint unterstützen. Eine User-Story ist demzufolge Teil der Projektdokumentation, also kein Wissen, das wir im Wiki erhalten müssen. Natürlich steht es den Entwicklern frei, nützliche Informationen aus der User-Story als Code-Kommentar zu verwenden.

Analyse von Anforderungen

In der klassischen Anforderungsanalyse werden Usecases immer noch sehr gerne verwendet. Mit der Verwendung von Usecases unternehmen wir den Versuch, das Wissen sehr strukturiert und umfassend bis ins letzte Detail zu beschreiben.

Ein Usecase ist agil nur sehr schwer umsetzbar. Ein Usecase ist in den meisten Fällen einfach zu groß, um ihn in einem Sprint umzusetzen.

Die aktuelle Weiterentwicklung mit dem Titel “Usecase 2.0” ist eine wesentliche Verbesserung. Die Grundidee der Aufteilung eines Usecase in basic und alternative usecase flows und usecase slices findet sich daher in abgewandelter Form auch in dieser Lösung wieder. Ich denke, dass sich eine Systembeschreibung mit Usecase 2.0 und CARDS+ nicht wesentlich unterscheiden. Meine persönliche Übersetzung der Begriffe sieht so aus:

  • Topic = “Big Picture”, Akteure
  • Epic = “Big Story”, Usecase
  • Case = “User Story”, Usecase Slice für Basic oder Alternative Flows

Ich finde, dass die Begriffe der Methode CARDS+ sehr klar sind. Den Begriff “Case” haben wir bewusst gewählt, weil wir in den vielen Diskussionen während der Einführung der Methode festgestellt haben, das der Begriff “Usecase” sehr unterschiedlich belegt ist und sich daher nicht als eindeutiger Begriff eignet.

Agile Methode

Beim Entwurf der Methode CARDS+ haben wir versucht, die Vorteile der agilen Methode mit den bewährten Ansätzen aus der klassischen Anforderungsanalyse so optimal wie möglich zu verbinden, um eine nachhaltige und vollständige Systembeschreibung zu erstellen, zu pflegen und langfristig für unseren Auftraggeber zu erhalten. Unser Ziel im Software-Projekt ist es, den Aufwand für diese Aufgabe so gering wie möglich zu halten. Und dabei soll uns die Methode unterstützen.

Im Zusammenhang mit Wissensmanagement brauchen wir klare Strukturen, um Wissen zu erhalten. Wissen wird nicht vollständig auf einmal vermittelt, sondern wird in einem Prozess erarbeitet, der Zeit braucht. Die Strukturen stellen sicher, dass man Wissen in der Form konserviert, in der wir sie von den Wissensträgern erhalten. Die Bausteine des Wiki sind so definiert, dass sie immer ein Ergebnis eines Schrittes sind und von den Wissensträgern geprüft werden.

Zur Beurteilung, ob ein Artefakt fertig für den nächsten Schritt ist, verwenden wir die in agilen Methoden bereits bekannte “Definition of Ready”.

Die Abfolge der Schritte bezeichnen wir als Produktionskette. Die Schritte der Produktionskette führen dazu, dass wir unser Product-Backlog ausreichend mit User-Stories von hoher Qualität füllen. Eine User-Story nutzen wir, um dem Team zusätzlich zur Systembeschreibung alle notwendigen Informationen zur Umsetzung zu geben.

Am Ende des Releases können wir unsere User-Stories ohne Wissensverlust “entsorgen”.

Ich möchte die Produktionskette als eine Art Kochrezept formulieren. Ein gutes Kochrezept enthält Angaben über die Anzahl oder Menge der benötigten Zutaten (=Bausteine) für ein Gericht (=Systembeschreibung) sowie Anweisungen über Art und Reihenfolge ihrer Verwendung und Zubereitung (=Produktionskette).

Grundrezept

CARDS+ Produktionskette
CARDS+ ist eine agile Methode mit dem Ziel, am Ende eines Produktinkrementes zusammen mit dem Software-Produkt eine vollständige und fehlerfreie Produktdokumentation bereitzustellen. Das Bild verwendet bewusst die Bildsprache von Scrum. Es geht hier aber nicht um Scrum, sondern um eine agile Methode zum Erstellen und Pflegen einer Produktdokumentation. In der Produktionskette von CARDS+ sehen wir, dass fünf Schritte  Priorisierung, Refinement, Planning, Realisierung und Review sich sehr schön mit einer auf Scrum basierten agilen Entwicklung synchronisieren lassen. Wir ergänzen die Produktionskette noch um drei Schritte für die agile Anforderungsanalyse: Bewertung, Validierung und Analyse einer Anforderung.

Die Produktionskette in der Methode CARDS+ besteht aus insgesamt acht Schritten:

  1. Bewertung des Bedarfes. Was brauchen meine Nutzer eigentlich wirklich?
  2. Validierung der Anforderung. Was genau sind die wichtigsten Anforderungen?
  3. Analyse der Anforderung, Erweiterung des Product-Backlog.
  4. Pflege und Priorisierung des Product-Backlog.
  5. Refinement der Analyseergebnisse.
  6. Sprint-Planning und Kick-Off.
  7. Realisierung im Sprint.
  8. Review der Sprint-Ergebnisse.

Zutaten

Jedes Rezept basiert auf Zutaten. Ein gutes Ergebnis erhalten wir nur bei Zutaten mit großer Qualität. Qualität ist ein wichtiges Ziel der Methode CARDS+. Die notwendigen Zutaten sind:

Fazit

Der große Vorteil dieser Produktionskette ist unter anderem auch die Tatsache, dass wir am Ende jedes Schrittes abbrechen können, ohne bis zu diesem Zeitpunkt gesammeltes Wissen zu verlieren. Ein weiterer Vorteil ist, dass mit Sicherheit am Beginn eines Schrittes die Inhalte im Wiki vorliegen, die wir brauchen, in der Qualität, die wir fordern.

Dieses Vorgehen fordert ein hohes Maß an Disziplin und die Bereitschaft zu trainieren, um sich zu verbessern – frei nach dem Motto “Nutze deine Stärken, trainiere deine Schwächen”.

Wir müssen uns die schon lange von Entwicklern im Zusammenhang mit Programmierung verwendeten Praktiken auch für das Dokumentieren zu eigen machen. Die professionelle Erstellung und Pflege technischer Dokumentationen unterscheidet sich nach meiner persönlichen Einschätzung nur wenig bis gar nicht von professioneller Programmierung.