Fünf Aufgaben in einer Build-Reihenfolge

Aus der Discovery kommen fünf bewertete Aufgaben. Aus dieser Phase gehen dieselben fünf in einer Reihenfolge hinaus, jede mit einer Position, einem Grund für diese Position, einer Aufwandsschätzung und Betriebskosten.

Der erste Build wird danach ausgewählt, wie schnell er sich beurteilen lässt: Eine Aufgabe, die fertig wird, belegt die Route, während eine Aufgabe mit größerer Ersparnis im März noch halbfertig sein kann. Die übrigen vier ordnen sich nach ihren Abhängigkeiten: Zwei Aufgaben mit demselben Connector werden gemeinsam gebaut, und der Connector wird einmal eingerichtet.

Heraus kommt ein Plan, den jemand stoppen kann. Jede Aufgabe geht einzeln und in den Einsatz, bevor die nächste beginnt, und eine Annahme, die den Kontakt mit der Arbeit nicht übersteht, wird an der zweiten Position korrigiert.

Baukosten und monatliche Betriebskosten auf jeder Zeile

Jede Aufgabe auf dem Plan trägt zwei Zahlen: was sie einmalig im Bau kostet und was sie im Betrieb bei der gemessenen Menge kostet.

Der Aufwand wird geteilt. Die bekannte Arbeit und der Teil, den in diesem System noch niemand gemacht hat, werden getrennt geschätzt, und der unbekannte Teil bekommt eine Time Box mit einer Entscheidung am Ende und einer festgelegten Budgetobergrenze. Das hindert ein einziges fremdes System daran, die ganze Reihenfolge zu verschlucken.

Die Amortisation steht in derselben Einheit wie die Baseline, in Stunden pro Monat, also ist der Vergleich eine Subtraktion. Eine Aufgabe, die ihren Bauaufwand nicht innerhalb eines Jahres hereinholt, steht genau so auf dem Plan, und das ist eine billigere Stelle, das zu merken, als der zweite Monat eines Builds.

Abnahme definiert, Ergebnis gemessen

Die Abnahmekriterien schreibt vor dem Build die Person, die das Ergebnis heute abnimmt. Sie sagen, wie ein richtiges Ergebnis aussieht und was passiert, wenn es falsch ist, und das entscheidet, wann der Build aufhört.

Sobald der Build läuft, wird die Baseline mit derselben Methode noch einmal gelesen, die sie erzeugt hat: Stunden pro Monat auf derselben Aufgabe, von der Person, der sie gehört. Die tatsächliche Ersparnis ist die Differenz zwischen den beiden Messungen, und was diese Zahl über die Schätzung sagt, fließt in die nächste Position.

Nach jedem Build wird die Reihenfolge mit dem neu gelesen, was der letzte gezeigt hat, und die nächste Position startet vom tatsächlichen Stand der Arbeit.

5 Aufgaben
bewertete Kandidaten aus der Discovery
Eine zuerst
ein Build in Arbeit, die anderen vier vorab terminiert
Stunden/Monat
die eine Einheit für Aufwand, Amortisation und Nachmessung

Aus der bewerteten Liste wird ein Build-Plan mit Kosten pro Zeile

Von der bewerteten Liste zur Build-Reihenfolge 3 Schritte
01

Die Planung beginnt mit dem bewerteten Blatt

Die Planungssession beginnt mit dem Artefakt aus der vorigen Phase: fünf ausgewählte Aufgaben, jede mit Stunden pro Monat, einer Eignungssumme von maximal dreißig Punkten, einer führenden Route und einem namentlichen Owner. In den Plan kommt nichts, was nicht schon mit einer Zahl daneben auf diesem Blatt steht.
02

Der erste Build wird nach der Zeit bis zum Urteil gewählt

Der erste Build wird danach ausgewählt, wie schnell er fertig und beurteilt werden kann: eine Aufgabe, deren Owner ein richtiges Ergebnis von einem falschen unterscheidet, deren Systeme heute erreichbar sind und deren Scheitern höchstens einen Nachmittag kostet. Die Ersparnis kommt an zweiter Stelle: Eine Aufgabe, die live geht, belegt die Route genauso wie eine größere.
03

Die übrigen Aufgaben ordnen sich nach ihren Abhängigkeiten

Zwei Aufgaben, die denselben Connector brauchen, kosten zusammen anderthalb Builds, und zwei ohne Berührungspunkte laufen in beliebiger Reihenfolge. Die Sequenz kommt deshalb aus den Abhängigkeiten: Welche Aufgaben teilen sich einen Connector, welche brauchen zuerst die Freigabe einer Berechtigung durch einen Administrator, welche warten auf eine Entscheidung, die jemand außerhalb des Raums trifft. Heraus kommt eine Reihenfolge, in der jede Position ihre Begründung mitträgt.
Was jede Aufgabe kostet, vorher und im Betrieb 3 Schritte
04

Der Aufwand teilt sich in bekannte und unbekannte Arbeit

Jede Aufgabe wird geteilt: in den Teil, der bekannte Arbeit ist, und in den Teil, den in diesem System noch niemand gemacht hat. Eine Graph-Berechtigung und ein Postfachzugriff sind bekannt, ein Wrapper um ein System, das es nur in dieser Firma gibt, liegt in der unbekannten Hälfte. Beide Teile bekommen Tage zugeordnet, und der unbekannte Teil bekommt eine Time Box mit einem Entscheidungspunkt am Ende und einer festgelegten Budgetobergrenze.
05

Amortisation in derselben Einheit wie die Baseline

Beide Seiten stehen in Stunden pro Monat: die gemessene Baseline, der Zielwert nach dem Build und die Differenz. Eine Aufgabe, die ihren Bauaufwand innerhalb eines Jahres hereinholt, verdient einen Platz in der Reihenfolge; eine, die das nicht schafft, steht genau so auf dem Plan.
06

Baukosten und Betriebskosten pro Aufgabe

Jede Aufgabe trägt deshalb zwei Zahlen: was sie einmalig im Bau kostet und was sie pro Monat im Betrieb kostet, bei der gemessenen Menge. Die Modellnutzung wird pro Lauf geschätzt und mit den Läufen pro Monat multipliziert, Hosting ist eine fixe Zeile, und beides steht auf dem Plan, bevor irgendetwas freigegeben wird.
Wie es tatsächlich live geht 2 Schritte
07

Jede Aufgabe geht live, bevor die nächste beginnt

Jede Aufgabe in der Reihenfolge ist so geschnitten, dass sie allein live geht und in den Einsatz kommt; die nächste startet erst, wenn die vorige läuft. Das kauft das Recht, sich billig zu irren: Eine Annahme, die den ersten Build nicht übersteht, wird im zweiten korrigiert.
08

Die Abnahmekriterien stehen vorab fest

Die Abnahmekriterien schreibt vor dem Build, wer das Ergebnis heute abnimmt, und sie sagen, wie ein richtiges Ergebnis aussieht und was passiert, wenn es falsch ist. Dieser Satz ist der ganze Handover-Test: Er entscheidet, wann der Build aufhört, und an ihm wird die Nachmessung gelesen.
Was jeder Build einbringt 2 Schritte
09

Die Baseline wird nach dem Live-Gang neu gelesen

Sobald der Build läuft, wird die Baseline mit derselben Methode noch einmal gelesen, die sie erzeugt hat: Stunden pro Monat auf derselben wiederkehrenden Aufgabe, erfasst von der Person, der sie gehört. Die Differenz ist die tatsächliche Ersparnis. Was sie über die Schätzung sagt, fließt in die nächste Position der Reihenfolge.
10

Die Reihenfolge wird nach jedem Build neu gelesen

Nach jedem Live-Gang wird die Reihenfolge mit dem gelesen, was der letzte Build gezeigt hat: welche Systeme sich wie erwartet verhalten haben, welcher Schritt länger gedauert hat als geschätzt, was die Abnahmekriterien über die Aufgabe verraten haben. Der nächste Build startet aus einer Position, die den tatsächlichen Stand der Arbeit abbildet.

Häufige Fragen

Worin unterscheidet sich das von der Discovery-Phase davor?
Die Discovery liefert Fakten, diese Phase liefert eine Entscheidung. Die Systemanalyse und eine einzige Session mit dem Büro zählen die wiederkehrenden Aufgaben, messen die Stunden pro Monat, bewerten jede Aufgabe gegen sechs Kriterien und weisen ihr eine führende Route zu. Diese Phase nimmt das bewertete Blatt und klärt, was als Nächstes kommt: welche Aufgabe im September gebaut wird und welche bis November wartet, und was jede im Betrieb kosten wird.
Wie lange dauert die Planung selbst?
Sie wird in Tagen gemessen. Die Arbeit liegt im Schätzen: jede Aufgabe in bekannte und in unbekannte Arbeit teilen, prüfen, ob die Systeme aus ihrer Route tatsächlich erreichbar sind, und die Abnahmekriterien von den Menschen schreiben lassen, die die Ergebnisse heute abnehmen. Heraus kommt ein Plandokument.
Was, wenn sich der Plan als falsch herausstellt, sobald der erste Build startet?
Genau deshalb geht jede Aufgabe einzeln live. Eine Annahme, die den ersten Build nicht übersteht, wird an der zweiten Position korrigiert, und die Reihenfolge wird nach jedem Build neu gelesen. Die Baseline und die Abnahmekriterien bleiben fest, denn beide wurden festgehalten, bevor irgendetwas gebaut wurde, und an ihnen wird die Nachmessung gelesen.
Ist das dieselbe Planung wie für ein Softwareprojekt?
Nein, und das ist Absicht. Ein Engineering-Plan legt einen Dateibaum fest, einen verantwortlichen Track pro Pfad und jedes gemeinsame Interface wortgleich, damit mehrere Build-Tracks gleichzeitig an einer Codebase arbeiten. Dieser Plan ordnet Büroaufgaben gegen die Systeme, die eine Firma schon betreibt, in Stunden pro Monat und Betriebskosten pro Monat. Wenn die Arbeit ein Build auf Ihrer eigenen Codebase ist, gilt die Seite Fact Gathering und Planning auf dem Engineering-Zweig.