Programmierkonzepte: der Bauplan hängt am Feature

Die meisten Rückfragen beim Programmieren sind keine technischen. Es sind Fragen wie „Für wen ist das eigentlich?“, „Was passiert mit den alten Daten?“ oder „Gehört der Export auch dazu?“. Wer sie erst beim Bauen stellt, wartet auf Antworten oder rät. Das Programmierkonzept ist der Ort, an dem diese Fragen vorher beantwortet werden: fünfzehn Abschnitte von Ziel und Zielgruppe über Anforderungen und Datenmodell bis zu Zeitplan, Risiken und dem, was ausdrücklich nicht dazugehört.

Nur an Feature und Story

Ein Konzept hängt an einem Feature oder einer User Story, sonst nirgends. Ein Epic ist zu grob, um darin ein Datenmodell zu beschreiben, eine einzelne Aufgabe zu fein für Zielgruppe und Zeitplan. Sonderaufgaben und Requests stehen ohnehin außerhalb der Planung. Je Vorgang gibt es genau ein Konzept. Wird es gelöscht, darf ein neues entstehen.

Geöffnet wird es über den Knopf „Konzept öffnen“ auf der Vorgangskarte, und es bekommt eine eigene Seite. Links die Erfassung, rechts eine eigene Kommentarspalte. Der Kopf mit Status, Gesamtaufwand und Version bleibt beim Scrollen stehen, denn bei fünfzehn Abschnitten verliert man sonst schnell, wo man ist.

Ein Konzept an einem Feature: oben der feste Kopf, links die Abschnitte, rechts die Kommentare.

Positionen statt Fließtext

Die Anforderungen sind keine Aufzählung im Text, sondern Positionen mit Name, Beschreibung, Priorität und Stunden. Am Feature darf eine Position Unterpositionen haben: Die Position wird später eine Story, die Unterposition eine Aufgabe. Der Aufwand rechnet sich dabei nach oben, eine Position mit Kindern ist die Summe ihrer Kinder.

Dabei steckt eine Entscheidung im Speichern. Bei Fragebögen und Checklisten ersetzt GODAV beim Speichern einfach die ganze Liste. Hier wäre das falsch gewesen. Jede Position behält über alle Speicherungen hinweg ihre eigene Kennung, und GODAV gleicht ab: Was eine Kennung hat, wird geändert, was keine hat, wird angelegt, was fehlt, wird entfernt. Nur so kann das Protokoll sagen „Anforderung X geändert“, und nur so kann später eine Story auf die Position verweisen, aus der sie entstanden ist.

Version, Protokoll und, nachgereicht, Fassungen

Jede Speicherung zählt die Version hoch. Version 1 entsteht beim ersten Speichern und nicht beim Anlegen, denn ein frisch angelegtes, leeres Konzept wäre sonst eine Fassung, die niemand geschrieben hat. Am Vorgang steht im Protokoll nur, dass am Konzept gearbeitet wurde. Wer wissen will, was genau, öffnet das Protokoll des Konzepts.

Ursprünglich hatte ich bewusst auf gespeicherte Fassungen verzichtet, das Protokoll sollte reichen. Das war ein Irrtum. Wird eine Anforderung entfernt, hielt das Protokoll nur ihren Namen fest. Ihre Beschreibung, ihre Testzeilen und ihre Unterpositionen waren weg. Inzwischen habe ich das nachgeholt: Jede Speicherung legt den vollständigen Inhalt als Fassung ab. Im Reiter „Log“ lässt sich jede Fassung nachlesen und mit der vorigen vergleichen. Zurücksetzen auf eine alte Fassung gibt es bewusst nicht: Wer einen früheren Text wieder will, übernimmt ihn von Hand und weiß dann auch, was er übernimmt.

Zwei Kommentarkreise und ein violetter Status

Kommentare am Konzept nutzen dieselbe Technik wie die am Vorgang, mit Antworten, Erwähnungen und Posteingang. Sie bleiben aber getrennt. Ein Beitrag zum Datenmodell gehört nicht zwischen die Fragen zur Aufgabe. Und sie sind immer intern: Ein Anfragender sieht in seinem Portal Vorgänge, keine Baupläne.

Der Status hat drei feste Werte: „In Bearbeitung“ in Blau, „Überarbeitung erforderlich“ in Gelb und „Freigegeben“ in Violett. Grün wäre naheliegend gewesen, ist in GODAV aber für Erledigtes reserviert. Ein freigegebenes Konzept ist nicht das Ende der Arbeit, sondern ihr Anfang. Auf dem Aufgabenboard trägt jede Karte das Konzeptsymbol in der Farbe ihres Standes, und man kann danach filtern.

Vier Haken, jeder mit der Zahl dessen, was daraus entstehen würde.

Außerdem

• Die Freigabe bleibt gesperrt, solange Pflichtabschnitte fehlen oder ein Risiko ohne Kategorie, Wahrscheinlichkeit oder Auswirkung dasteht. Ein halb bewertetes Risiko im Register wäre schlimmer als gar keines.
• Wer ablehnt, muss begründen. Die Begründung steht als Kommentar am Konzept, und das nächste Speichern setzt es wieder auf „In Bearbeitung“.
• Mitwirkende lassen sich eintragen. Sie bekommen dadurch keine eigenen Rechte, die Eintragung sagt nur, wer mitschreibt.
• Ob es Konzepte gibt, schaltet jeder Prozess für sich. Abschalten betrifft nur neue, bestehende bleiben lesbar und speicherbar.

Das Konzept ist der erste Baustein in GODAV, der vor der Arbeit steht statt neben ihr. Ich bin gespannt, wie viele Rückfragen es in der Praxis wirklich spart.