Methode
Motivation für den Einsatz
Unter dem Titel “Knigge für Software-Architekten” haben Peter Hruschka und Gernot Starke bereits im Jahr 2012 einen lesenswerten Artikel über Entscheider geschrieben, der nach meiner Meinung nichts an Aktualität verloren hat. Ich bin überzeugt, dass bei agiler Software-Entwicklung die Transparenz bei Entscheidungen sehr wichtig ist. Mit dem Baustein Decision gibt es die Möglichkeit, eine Entscheidung genau dann zu dokumentieren, wenn sie getroffen wird. Vertreter des Teams formulieren das Problem und betrachten mindestens zwei Lösungsoptionen. Sie bewerten Chancen und Risiken. Sie wägen Stärken und Schwächen gegeneinander ab. Am Ende treffen sie gemeinsam mit dem Produktverantwortlichen eine Entscheidung und begründen sie.
Dokumentierte Entscheidungen müssen bei der Realisierung berücksichtigt werden. Sie sind Vorgaben, die vom Team einzuhalten sind. Natürlich heißt das nicht, dass eine einmal getroffene Entscheidung nie mehr korrigiert wird. Ganz im Gegenteil. Gerade wenn ein Team während der Entwicklung feststellt, dass eine Entscheidung Probleme verursacht, muss diese Entscheidung hinterfragt und über Alternativen nachgedacht werden. Aber eine dokumentierte Entscheidung hat den Vorteil, dass die gewählte Lösung begründet wurde und die schon einmal betrachteten Alternativen bekannt sind. Das ist besonders wichtig, wenn die Personen, die an der ursprünglichen Entscheidung beteiligt waren, gar nicht mehr im Team sind.
Wissensmanagement richtig organisieren.
Zielgerichtet.
Agil.
Iterativ.
Prozesse
Projektmanagement
Der Produktverantwortliche hat mit dem Baustein Decision die Möglichkeit, eine Vorgabe des Auftraggebers, z.B. Qualitätsmerkmale, zu dokumentieren. Gerade bei jenen Entscheidungen eines Auftraggebers, die etwas ausschließen, ist ein Nachweis besonders wichtig.
Prozesse
Anforderungsanalyse
Der Produktverantwortliche hat mit dem Baustein Decision die Möglichkeit, eine Prämisse oder Regel der Anwendungsdomäne zu dokumentieren, die große Auswirkung auf die Realisierung hat.
Prozesse
Produktentwicklung
Der Produktverantwortliche oder Vertreter des Teams haben mit dem Baustein Decision die Möglichkeit, eine abgestimmte Entscheidung für den Einsatz bestimmter
- Werkzeuge
- Programmiersprachen,
- Programmbibliothekn,
- Technologien,
- Plattformen,
- u.s.w.
zu dokumentieren.
Der Baustein Decision verschafft jedem Leser (z.B. Entwickler oder Tester) einen sehr kompakten Überblick über eine Entscheidung, die seine Arbeit an dem Produkt beschränkt.
Seitenvorlagen für alle Bausteine und hilfreiche Makros für die Verwendung in Confluence.
Qualität
Seitenvorlage des Bausteins
Confluence unterstützt mit Seitenvorlagen die Idee der Bausteine optimal. Das folgende Beispiel kann direkt als HTML im Editor der Seitenvorlagen eingefügt werden.
Bitte hier Klicken, um den Quelltext anzuzeigen
<ac:layout> <ac:layout-section ac:type="single"> <ac:layout-cell> <h1>Ausgangslage</h1> <p> <ac:placeholder>Formulierung der Ausgangslage oder ganz allgemein das Problem, für das Lösungen gesucht werden. Was sind die Annahmen und Randbedingungen, welche Einflussfaktoren gibt es.</ac:placeholder> </p> <h1>Lösungen</h1> <p> <ac:placeholder>Beschreibung der Rahmenbedingungen, die für alle Lösungsoptionen gelten.</ac:placeholder> </p> <h2>Lösung A</h2> <p> <ac:placeholder>Beschreibung der Lösung.</ac:placeholder> </p> <table class="relative-table wrapped" style="width: 100.0%;"> <colgroup> <col style="width: 50.0%;"/> <col style="width: 50.0%;"/> </colgroup> <tbody> <tr> <th>Stärken</th> <th>Schwächen</th> </tr> <tr> <td> <ul> <li> <ac:placeholder>Welche Stärken hat die Lösung?</ac:placeholder> </li> </ul> </td> <td> <ul> <li> <ac:placeholder>Welche bekannten Schwächen hat die Lösung?</ac:placeholder> </li> </ul> </td> </tr> <tr> <th>Chancen</th> <th>Risiken</th> </tr> <tr> <td> <ul> <li> <ac:placeholder>Welche Chancen eröffnet die Lösung?</ac:placeholder> </li> </ul> </td> <td> <ul> <li> <ac:placeholder>Welche Risiken beinhaltet die Lösung?</ac:placeholder> </li> </ul> </td> </tr> </tbody> </table> <h2>Lösung B</h2> <p> <ac:placeholder>Beschreibung der Lösung.</ac:placeholder> </p> <table class="relative-table wrapped" style="width: 100.0%;"> <colgroup> <col style="width: 50.0%;"/> <col style="width: 50.0%;"/> </colgroup> <tbody> <tr> <th>Stärken</th> <th>Schwächen</th> </tr> <tr> <td> <ul> <li> <ac:placeholder>Welche Stärken hat die Lösung?</ac:placeholder> </li> </ul> </td> <td> <ul> <li> <ac:placeholder>Welche bekannten Schwächen hat die Lösung?</ac:placeholder> </li> </ul> </td> </tr> <tr> <th>Chancen</th> <th>Risiken</th> </tr> <tr> <td> <ul> <li> <ac:placeholder>Welche Chancen eröffnet die Lösung?</ac:placeholder> </li> </ul> </td> <td> <ul> <li> <ac:placeholder>Welche Risiken beinhaltet die Lösung?</ac:placeholder> </li> </ul> </td> </tr> </tbody> </table> </ac:layout-cell> </ac:layout-section> <ac:layout-section ac:type="single"> <ac:layout-cell> <p> <br/> </p> </ac:layout-cell> </ac:layout-section> <ac:layout-section ac:type="single"> <ac:layout-cell> <h1>Entscheidung</h1> <ac:structured-macro ac:macro-id="6ab46a1c-109c-42ee-acf6-6cec1190a33b" ac:name="details" ac:schema-version="1"> <ac:rich-text-body> <table class="relative-table wrapped" style="width: 100.0%;"> <colgroup> <col style="width: 25.0%;"/> <col style="width: 75.0%;"/> </colgroup> <tbody> <tr> <th>Status</th> <td> <div class="content-wrapper"> <ac:structured-macro ac:macro-id="8a27f6a9-0bb3-466f-b793-5f5e5bba1aa9" ac:name="status" ac:schema-version="1"> <ac:parameter ac:name="colour">Red</ac:parameter> <ac:parameter ac:name="title">offen</ac:parameter> </ac:structured-macro> <ac:structured-macro ac:macro-id="25185b5f-a6aa-4378-afe6-3837325748c2" ac:name="status" ac:schema-version="1"> <ac:parameter ac:name="colour">Yellow</ac:parameter> <ac:parameter ac:name="title">Vorschlag</ac:parameter> </ac:structured-macro> <ac:structured-macro ac:macro-id="3d4836f4-0a53-4524-ace3-5f9703d581f5" ac:name="status" ac:schema-version="1"> <ac:parameter ac:name="colour">Green</ac:parameter> <ac:parameter ac:name="title">entschieden</ac:parameter> </ac:structured-macro> </div> </td> </tr> <tr> <th>Datum</th> <td> <p> <ac:placeholder>Wann wurde der Status entschieden? Verwende das //-Makro zum Einfügen eines Datums.</ac:placeholder> </p> </td> </tr> <tr> <th colspan="1">Beitragende</th> <td colspan="1"> <div class="content-wrapper"> <p> <ac:structured-macro ac:macro-id="a42fb7ed-21ea-4274-ab25-36038b13ac10" ac:name="contributors" ac:schema-version="1"/> </p> </div> </td> </tr> <tr> <th>Entscheidung</th> <td> <p> <ac:placeholder>Welche Lösung wurde gewählt?</ac:placeholder> </p> </td> </tr> </tbody> </table> </ac:rich-text-body> </ac:structured-macro> <h2>Begründung des Produktverantwortlichen</h2> <p> <ac:placeholder>Kurze Zusammenfassung der Begründung für die Wahl der Lösung.</ac:placeholder> </p> <h2>Begründung der Vertreter des Teams</h2> <p> <ac:placeholder>Kurze Zusammenfassung der Begründung für die Wahl der Lösung.</ac:placeholder> </p> </ac:layout-cell> </ac:layout-section> </ac:layout>
Struktur
Eigenschaften des Bausteins
Der Baustein Decision beschreibt ein Problem und mindestens zwei Lösungen für das
Problem.
Er vermittelt eine angemessen genaue Beschreibung als Ausgangslage.
Angemessen bedeutet, dass Entwickler und Tester das Problem verstehen.
Es ist nicht notwendig, jede Lösung in der gleichen Tiefe zu betrachten.
Häufig gibt es von Anfang an eine favorisierte Lösung, die sehr genau beschrieben wird.
Der Seitentitel beginnt immer mit Decision
.
Durch die Seitenvorlage hat jede Seite das Stichwort decision
.
Sie kann aber um weitere Schlagworte ergänzt werden.
Dadurch wird die Seite leichter auffindbar.
Bei der Beurteilung einer Lösung bietet sich die SWOT-Analyse an. Dort stellen Autoren in vier Quadranten folgende Fragen:
- Welche Stärken hat die Lösung?
- Welche Schwächen hat die Lösung?
- Welche Chancen eröffnet die Lösung?
- Welche Risiken beinhaltet die Lösung?
Die Wahl einer Lösung wird immer begründet. Es gibt auch die Situation, dass es keine oder keine akzeptable Lösung gibt. In diesem Fall ist die Begründung besonders wichtig. Zeitpunkt und alle Entscheider werden festgehalten.
Der Baustein Decision hat einen Zustand. Er ist in Arbeit, wenn die Entscheidung noch nicht endgültig getroffen wurde. Er ist fertig, wenn es eine begründete Entscheidung gibt.
Der Baustein Decision hat keinen Bezug zu einem Produktinkrement.
Der Baustein Decision wird in der Sprache der Entwickler geschrieben.