Entwickler mögen keine Zeitpläne. Sie versuchen, wenn möglich, ohne auszukommen. "Es wird fertig sein, wenn wir damit fertig sind!", sagen sie, in der Hoffnung, den Boss mit dieser geistreichen Bemerkung zum Grinsen zu bringen, und dass in der dann ausbrechenden Heiterkeit der Zeitplan in Vergessenheit gerät.
Die meisten Zeitpläne sind nur halbherzige Versuche. Sie werden auf irgendeinem gemeinsamen Laufwerk abgelegt und ... vergessen. Wenn solche Teams ihr Produkt ausliefern, kommt der Kauz, der all die Akten in seinem Büro sammelt, und bringt den alten Ausdruck mit zur Abschlussbesprechung; jeder darf mal lachen, "Guck dir das an! Wir hatten 2 Wochen geplant ... fürs Neuprogrammieren in Ruby!"
Zum Schreien komisch ... wenn man noch im Wettbewerb ist.
Natürlich willst du deine Zeit so investieren, dass du den größten Knaller für dein Geld kriegst. Aber du kriegst nicht raus, wieviel Geld dich dein Knaller kostet, wenn du nicht vorher ermittelt hast, wie lange du dafür brauchst. Wenn du dich zwischen der "animierten Büroklammer" oder "mehr finanztechnischen Funktionen" zu entscheiden hast, dann musst du ganz dringend wissen, wieviel Zeit dich das jeweils kostet.
Warum machen Entwickler keine Zeitpläne? Zwei Gründe. Erstens nervt es. Und zweitens: Keiner glaubt, dass ein Zeitplan realistisch ist. Warum soll man sich damit abplagen, wenn der Zeitplan sowieso nicht richtig wird.
Das letzte Jahr über haben wir bei Fog Creek ein System entwickelt, das so einfach ist, dass sogar die Entwickler klaglos mitmachen, die sonst immer meckern. Und soweit ich das sagen kann, produziert es extrem zuverlässige Zeitpläne. Wir nennen es "Beleggestützte Zeitplanung" (engl.: Evidence-Based Scheduling - EBS). Man sammelt Belege, vor allem alte Stundennachweise, die in die Zeitpläne mit einfließen. Das Ergebnis ist nicht nur ein Fertigstellungsdatum; du erhältst eine Zuversichts-Verteilungs-Kurve, die die Eintrittswahrscheinlichkeit für jedes mögliche Fertigstellungsdatum zeigt. Sie sieht so aus:
Je steiler die Kurve, desto sicherer kannst du dich fühlen, dass das Datum der Wirklichkeit entspricht.
Und so wird es gemacht:
Einem Zeitplan, der in Tagen oder Wochen rechnet, sehe ich schon an, dass er nicht funktioniert. Du musst den Plan in kleine Einheiten aufbrechen, die in Stunden gemessen werden können; maximal 16!
Das zwingt dich dazu, wirklich darüber nachzudenken, was zu tun ist. Schreibe eine Routine murx(), entwickle ein So-und-so-Dialogfenster, durchsuche die Dingens-Datei! Einzelne Entwicklungsaufgaben sind einfach abzuschätzen, weil du schon Routinen geschrieben, Dialogfenster entwickelt und Dateien durchsucht hast.
Wenn du schluderst, indem du Drei-Wochen-Brocken auswählst ("Realisiere den Ajax-Photo-Editor!"), dann hast du nicht darüber nachgedacht, was zu tun ist. Detailliert! Schritt für Schritt! Und wenn du das nicht getan hast, kannst du auch nicht wissen, wie lange es dauern wird.
Eine Obergrenze von 16 Stunden zwingt dich, für das blöde Teil einen Entwurf zu machen. Wenn du lässig mit einer drei Wochen schweren Funktion hantierst, dann - tut mir leid, das sagen zu müssen - bist du zum Scheitern verurteilt. Du hast niemals genug über die nötigen Schritte nachgedacht, und mit Sicherheit einiges vergessen.
Es ist schwer, im Einzelnen richtig zu schätzen. Wie berücksichtigt man Unterbrechungen, unvorhergesehene Fehler, Status-Sitzungen und den halbjährlichen Tag Tribut an Windows, wenn mal wieder auf dem Entwicklungsserver alles neu installiert werden muss? Selbst ohne dieses ganze Zeug - wie willst du mir sagen können, wie lange das Implementieren einer bestimmten Routine dauert?
Das kannst du gar nicht.
Also, halte dich an Stundenzettel. Schreib' auf, wie lange du für jede Aufgabe gebraucht hast. Dann kannst du im nachhinein ermitteln, wieviel Zeit das im Vergleich zur Schätzung war. Sammle also für jeden Entwickler Daten wie die folgenden:
Jedes Kästchen steht für eine abgeschlossene Aufgabe, inclusive Schätzung und tatsächlich gebrauchter Zeit. Geschätzte Zeit geteilt durch tatsächliche Zeit ergibt die relative Geschwindigkeit: wie schnell, im Verhältnis zur Schätzung, die Aufgabe erledigt wurde. Im Laufe der Zeit sammelst du eine Historie von relativen Geschwindigkeiten.
Wenn Schätzer Erfahrung sammeln, verbessern sie ihre Fähigkeit zu schätzen. Also weg mit relativen Geschwindigkeiten älter als, sagen wir mal, sechs Monate.
Für einen neuen Schätzer im Team, also ohne erfasste Daten, nimmst du das Schlimmste an: gib ihm eine Pseudo-Historie mit weit gestreuten relativen Geschwindigkeiten, zumindest solange, bis er ein halbes Dutzend echter Aufgaben erledigt hat.
Anstatt die geschätzten Zeiten einfach zu addieren, um ein Endedatum zu erhalten - das klingt richtig, führt jedoch zu einem grundfalschen Ergebnis -, verwendest du die Monte-Carlo-Methode, um viele verschiedene Zukunftsszenarien zu erzeugen. Mit der Monte-Carlo-Methode kann man hunderte möglicher Szenarien erzeugen, so dass eine Kurve entsteht mit einer Wahrscheinlichkeit für jedes beliebige Fertigstellungsdatum.
Für die Berechnung jeder mögliche Zukunft einer beliebigen Entwicklerin dividierst du die geschätzte Zeit der verschiedenen Aufgaben durch eine zufällig ausgewählte relative Geschwindigkeit aus den im 2. Schritt gesammelten historischen Daten dieser Entwicklerin. Hier folgt das Beispiel einer möglichen Zukunft:
| Aufgabe: | A | B | C | D | E | |
| Geschätzte Zeit: | 4 | 8 | 2 | 8 | 16 | |
|
Zufällig ausgewählte Relative Geschwindigkeit: |
0,6 | 0,5 | 0,6 | 0,6 | 0,5 | Summe: |
| GZ/RG: | 6,7 | 16 | 3,3 | 13,3 | 32 | 71,3 |
Das machst du 100 mal, jede Summe hat eine Wahrscheinlichkeit von 1%; nun kannst du für jedes mögliche Lieferdatum die Wahrscheinlichkeit ablesen.
Pass' auf, was passiert:
Nach jeder Runde der Monte-Carlo-Simulation musst du die Stunden in Kalenderdaten übersetzen. Das heißt, für jeden Entwickler müssen berücksichtigt werden: Arbeitszeiten, Urlaub, Feiertage, usw. Und dann gilt für jede Runde das Fertigstellungsdatum des "letzten" Entwicklers, weil ja dann erst das Team als ganzes fertig ist. Diese Berechnungen erfordern Sorgfalt und Mühe, aber, glücklicherweise, sind Computer darin besonders gut.
Was ist mit den Zeit, in der dich der Chef mit langatmigen Geschichten über seine Angelerlebnisse quält? Oder die Vertriebssitzung, an der du ohne einsehbaren Grund teilnehmen musstest? Was ist mit den Kaffeepausen, was mit dem halben Tag, an dem du dem Neuen geholfen hast, seine Entwicklungsumgebung zum Laufen zu bringen?
Als Brett und ich diese Technik bei Fog Creek entwickelten, hatten wir ziemliche Sorgen wegen dem ganzen Kram, der ja richtig Zeit kostet, den man aber nicht vorhersagen kann. Manchmal macht er zusammen mehr aus als die ganze Programmiererei. Soll ich den auch schätzen und die Zeiten festhalten?
Jaaa, kannst du machen, wenn du willst. Und die Beleggestützte Zeitplanung wird damit funktionieren.
Aber du musst nicht!
Es zeigt sich nämlich, dass EBS (Evidence Based Scheduling) so gut funktioniert, dass du nichts weiter tun musst, als für die gerade unterbrochene Aufgabe die Uhr weiter laufen zu lassen. Egal wie verwirrend das klingen mag, aber EBS produziert damit die besten Ergebnisse.
Lass' mich das an einem kurzen Beispiel zeigen. Um es möglichst einfach zu halten, stelle ich mir einen ziemlich gut berechenbaren Programmierer John vor, dessen gesamte Aufgabe nur daraus besteht, diese einzeiligen set- und get-Funktionen zu schreiben, die in minderwertigen Programmiersprachen gebraucht werden. Den lieben langen Tag schreibt er nichts als:
private int breite;
public int getBreite() { return breite; };
public void setBreite(int inBreite) { breite = inBreite; };
Ich weiß, ich weiß ... Das Beispiel ist ausgesprochen dumm. Aber so einen kennst du bestimmt auch.
Egal. Jeder Getter oder Setter kostet ihn 2 Stunden. Seine Aufwandsschätzungen sehen so aus:
{2; 2; 2; 2; 2; 2; 2; 2; 2; 2; 2; ... }
Der arme Kerl hat außerdem einen Boss, der ihn immer mal wieder für zwei Stunden mit einer Story vom Hechtangeln unterbricht. Natürlich könnte John auf seinem Stundenzettel eine Kategorie "Quälende Gespräche über Hechte" aufführen, doch das wäre taktisch ungeschickt. Stattdessen lässt John die Uhr weiterlaufen, so dass seine tatsächlichen Aufwandszeiten so aussehen:
{2; 2; 2; 2; 4; 2; 2; 2; 2; 4; 2; ... }
Und die relativen Geschwindigkeiten sind dann folgende:
{1; 1; 1; 1; 0,5; 1; 1; 1; 1; 0,5; 1; ... }
Und was passiert nun in der Monte-Carlo-Simulation? Die Wahrscheinlichkeit, dass eine der Schätzuungen durch 0,5 dividiert wird, ist genauso hoch wie die Wahrscheinlichkeit, dass Johns Boss ihn bei einer bestimmten Aufgabe unterbricht. So produziert EBS einen korrekten Zeitplan!
Es ist sogar so, dass EBS sehr wahrscheinlich diese Störungen akkurater anzeigt, als selbst der zeiterfassungsbesessenste Entwickler es könnte. Genau deshalb ist es ja so gut! Ich erkläre das folgendermaßen: Wenn Entwickler gestört werden, gibt es zwei Möglichkeiten. Sie können sich entweder
In beiden Fällen liefert EBS das gleiche, exakt richtige Resultat, egal um welchen Typ passiv-aggressiver Persöhnlichkeit es sich bei dem Entwickler handelt.
Ist EBS erst einmal eingerichtet, kannst du deine Projekte aktiv beeinflussen, so dass sie pünktlich fertig werden. Wenn du beispielsweise die verschiedenen Anforderungen nach Prioritäten sortiert hast, ist leicht zu erkennen, wie sich das Streichen niedrig priorisierter Aufgaben auf den Zeitplan auswirkt.
Genauso kannst du dir die möglichen Fertig-Zeitpunkte jedes Entwicklers anschauen:
Manche Entwickler (wie in diesem Beispiel Milton) können zum Problem werden, weil ihre ermittelten Endezeitpunkte zu ungenau sind; sie müssen lernen, genauer zu schätzen. Für andere Entwickler (wie Jane) ergeben sich ziemlich verlässliche Endezeitpunkte, die einfach nur zu spät kommen; ihnen muss man ein paar Aufgaben abnehmen. Bei anderen Entwicklern (bei mir, jawohl) ist gar nichts kritisch; denen kann man ihren Frieden lassen.
Mal angenommen, du hast zu Beginn alles bis ins Detail geplant, dann funktioniert EBS prima. Aber um ehrlich zu sein: wahrscheinlich kommen noch ein paar ungeplante Funktionen hinzu. Du hast neue Einfälle, eure Vertriebsleute verkaufen ein Programmmerkmal, das es nicht gibt, und einer der Geschäftsführer kommt mit der coolen Idee, eure GPS-Anwendung für Golfkärrelchen um eine Funktion "Belastungs-EKG der Golfer" zu bereichern. All das führt zu Verzögerungen, die beim Erstellen des Zeitplans nicht absehbar waren.
Idealerweise hast du dafür Zeitpuffer. In der Tat solltest du für alles Folgende zeitliche Puffer einbauen:
Wenn jetzt neue Wünsche auftauchen, kannst du ein Stück vom entsprechenden Puffer abschneiden und für die neue Aufgabe benutzen.
Was passiert, wenn du immer weiter neue Aufgaben dranhängst, nachdem der Puffer schon aufgebraucht ist. Nun, das Fertigstellungsdatum, das dir EBS liefert, läuft dann aus dem Ruder. Du solltest jeden Abend eine Momentaufnahme der Zuversichts-Verteilungs-Kurve machen und sie über die Laufzeit hinweg beobachten:
Hier zeigt die X-Achse, wann gerechnet wurde, die Y-Achse das Fertigstellungsdatum. Wir sehen hier drei Kurven: die obere zeigt die Zeitpunkte mit einer Eintrittswahrscheinlichkeit von 95%, die mittlere die mit 50% und die untere die mit 5%. Je näher die Kurven beieinander liegen, umso kleiner ist das mögliche Zeitfenster.
Da wo der Endezeitpunkt immer später wird (ansteigende Kurven), da gibts Probleme. Dort, wo pro Tag mehr als ein Tag Verspätung angezeigt wird, dort generierst du schneller Arbeit, als du sie erledigst: so wirst du nie fertig! Man kann auch sehen, wie die Zuversichtsverteilung immer enger wird (die Kurven nähern einander); so sollte es sein, wenn man ein Datum wirklich wahrmachen will.
Hier noch einiges mehr, was ich über die Jahre über Zeitpläne gelernt habe.
A. Nur der Programmierer, der auch die Arbeit tun, kann den Zeitplan erstellen. Jede Organisation, bei der das Management die Zeitpläne macht, ist zum Scheitern verurteilt. Nur die betroffenen Programmierer wissen um die nötigen Arbeitsschritte zur Erledigung einer bestimmten Aufgabe.
B. Korrigiere Fehler, sobald sie auftreten, und addiere den Zeitaufwand zur ursprünglichen Aufgabe. Fehlersuche kannst du nicht im voraus abschätzen, weil du nie weißt, welche Arten von Fehlern auf dich warten. Werden Fehler in neuem Kode entdeckt, gehört der Zeitaufwand fürs Beheben zur ursprünglichen, fehlerhaft umgesetzten Aufgabe. Dadurch wird EBS Zeiten für fehlerbereinigten Kode voraussagen, nicht nur für einen nur lauffähigen.
C. Lass nicht zu, dass Manager die Programmierer zu kürzeren Schätzungen drängen. Viele unerfahrene Softwaremanager glauben, ihre Programmierer mit "straffen" (das heißt, unrealistisch engen) Zeitplänen "motivieren" zu können. Das ist phantasie-, um nicht zu sagen hirnlos. Wenn ich dem Zeitplan hinterherhinke, werde ich depressiv und antriebslos. Wenn ich vor dem Plan liege, freue ich mich und bin produktiv. Ein Zeitplan eignet sich nicht für Psycho-Spielchen.
Warum probieren Manager sowas?
Zu Beginn des Projekts treffen sich die technischen Manager mit den Vertriebsleuten und kommen zurück mit einer Liste von Aufgabe, von denen sie glauben, dass sie in drei Monaten zu erledigen sind; in Wahrheit würde es 12 Monate dauern. Ohne über die einzelnen Schritte nachgedacht zu haben, wird es immer so aussehen, als ob eine Zeit T ausreichen würde, während es tatsächlich eher 4T kostet. Wenn du nun einen "echten" Zeitplan erstellst, mit allen Einzelschritten, und dann die Zeiten addierst, wird du erkennen, um wieviel länger das braucht. Die Vertriebsleute wären also unglücklich.
Damit's schneller geht, suchen unfähige Manager nach Möglichkeiten, an mehr Personal zu kommen. Das ist ziemlich unrealistisch. Vielleicht kannst du ein paar Leute mehr anstellen, doch die müssen erst mal Fahrt aufnehmen; wahrscheinlich arbeiten sie mehrere Monate nur zu 50% effizient, und wahrscheinlich bremsen sie die anderen aus, von denen sie betreut werden müssen.
Möglicherweise schaffst du es zeitweise, 10% mehr Kode rauszukitzeln, zum Preis eines 100%igen Burn-out innerhalb eines Jahres. Kein großer Fortschritt, eher was in der Qualität von "Saatgut aufessen". Außerdem verdoppelt sich die Zeit für die Fehlersuche, wenn Leute überarbeitet sind ... und das verspätete Projekt verspätet sich weiter. Tolles Karma!
Niemals aber wirst du 4T statt T genehmigt bekommen, und wenn du doch meinst, dass das geht, sag mir, wie die Aktie deiner Firma heißt, damit ich sie runterstufen kann.
D. Ein Zeitplan ist wie eine Schachtel mit Holzklötzen. Du hast zwei Möglichkeiten, wenn die Klötze nicht reinpassen: Nimm eine größere Schachtel, oder lass' ein paar Klötze draußen. Wenn du in 6 Monaten ausliefern willst, aber schon 12 Monate verplant hast, musst du entweder den Termin schieben oder ein paar Funktionen rauswerfen. Du kannst die Klötze nicht schrumpfen lassen, und wenn du so tust, als ob, beraubst du dich selbst einer Chance, in die Zukunft zu gucken, weil du dich selbst belügst.
Apropos... ein großer Pluspunkt realistischer Zeitplanung ist die Tatsache, dass du gezwungen wirst, Funktionen rauszuschmeißen. Warum ist das gut?
Nimm an, du hast zwei Funktionen im Sinn. Eine ist nützlich und macht dein Produkt richtig gut. Die andere ist ganz simpel und die Programmierer drängeln schon zum Kodieren ("Schau her! Und ... bing!"), doch sie dient keinem sinnvollen Zweck.
Ohne Zeitplanung werden die Programmierer die simplen/spaßigen Funktionen zuerst machen. Dann läuft die Zeit davon und du hast nur noch die Möglichkeit, wegen der wichtigen Funktionen den Termin nach hinten zu schieben,
Mit Zeitplanung merkst du schon, bevor die Arbeit begonnen hat, dass etwas raus muss. Also wirfst du die simple/spaßige Funktion raus. Indem du dich zwingst, Funktionen zum Verwerfen auszuwählen, generierst du im Endeffekt ein robusteres, besseres Produkt mit einem höheren Anteil von guten Funktionen, das außerdem noch früher fertig wird.
Lang ist's her, da arbeitete ich mit an Excel 5, unsere erste Liste mit Funktionen war riesig und wäre weit über den Zeitrahmen hinausgegangen. "Ööha", dachten wir, "das sind ja alles wichtige Funktionen! Wie können wir ohne einen Makro-Assistenten überhaupt überleben?"
Wie sich bald herausstellte, hatten wir keine Wahl; für den Zeitplan kürzten wir, - so meinten wir - "bis zur Schmerzgrenze". Alle waren wir unglücklich über diese Einschnitte. Um uns besser zu fühlen, sagten wir, "Wir schmeißen die Sachen nicht raus, wir verschieben sie nur auf Excel 6".
Kurz bevor Excel 5 fertig war, begann ich mit meinem Kollegen Eric Michelman mit dem Konzept für Excel 6. Wir gingen die Liste der "Excel 6-Funktionen" durch, die vom Excel 5-Zeitplan verstoßen worden waren. Nun ratet mal! Es war die schäbigste Liste minderwertiger Funktionen, die du dir vorstellen kannst. Nicht eine davon war es wert, getan zu werden. Ich glaube, nicht eine einzige wurde jemals realisiert.
Der Prozeß des Ausmerzens von Funktionen, war das beste was wir hatten tun können. Hätten wir es nicht getan, Excel 5 hätte doppelt so lange gedauert und hätte 50% unnützen Müll enthalten, der auch noch, wegen Rückwärts-Kompatibilität, für alle Zeiten hätte unterstützt werden müssen.
Beleggestützte Zeitplanung zu benutzen, ist einfach: es kostet dich ein, zwei Tage zu Beginn jeder Iteration zum Erzeugen detaillierter Schätzungen, und es kostet dich ein paar Sekunden am Tag, um festzuhalten, wann immer du eine neue Aufgabe im Zeitplan angehst. Der Nutzen ist riesig: ein realistischer Zeitplan!
Realistische Zeitpläne sind der Schlüssel zum Erstellen guter Software. Sie zwingen dich, die besten Funktionen zu realisieren, und erlauben die richtigen Entscheidungen darüber, was getan werden muss. Das macht dein Produkt besser, deinen Chef glücklich, erfreut die Kundschaft, und - jetzt kommt das Beste! - entlässt dich um pünktlich um Fünf in den verdienten Feierabend.
Beleggestützte Zeitplanung ist Bestandteil von FogBugz 6.0.