Commite jeden tag, oder wirf es weg – Lebe Agilität jeden Tag

5 Kommentare

Eines der größeren Proleme in agilen Softwareentwicklungsteams ist der Aufwand. Natürlich, denn Aufwand ist Geld, und da wir alle gerne Geld haben, wollen wir auch möglichst wenig Aufwand. In Planungsmeetings wird aber oft vereinfachend mit Aufwand umgegangen „oh das ist eine Woche Aufwand“. Wie kann denn aber diese eine Woche umgesetzt werden, wenn man es nicht schafft die Aufgaben für die 5 Tage zu definieren?

Zur Lösung des Problems schlage ich eine radikale Strategie vor: Werft am Ende eines Tages alles unfertige weg!

Wie kann das nun hilfreich sein? Nun, ich glaube daran daß jede Aufgabe innerhalb eines Tages erledigt werden kann. Agile Prozesse sorgen zwar dafür, daß Aufgaben klein sind, aber keiner beschränkt eine Aufgabe auf maximal einen Tag. Da das Wegwerfen von geleisteter Arbeit an einem Tag schmerzlich ist, führt dieser Ansatz dazu am Ende des Tages etwas fertig zu haben. Die Gründe dafür warum eine Aufgabe länger als einen Tag dauern kann sind im wesentlichen:

Die Aufgabe ist viel zu groß

Wie offensichtlich, und dennoch widersprüchlich zu meiner Aussage. Aber wenn man mal genauer hinsieht geht es doch im Wesentlichen nur darum die Granularität von Aufgaben richtig zu gestalten. Wenn eine Aufgabe zu groß ist, sollte man das bisher Erledigte wegwerfen und die Aufgabe zerlegen. Die Arbeit ist nicht verschwendet, gewann man doch viel Wissen über die Aufgabe und die Gründe warum sie länger als einen Tag dauert. Es gibt immer eine Teilaufgabe die sich an einem Tag erledigen lässt!

Der Fortschritt an der Aufgabe wird durch Andere verhindert

Nehmt eine andere Aufgabe und wartet nicht einfach ab. Das Hindernis wird frühestens am nächsten Tag diskutiert und ist auch frühestens am folgenden Tag erledigt. Bis dahin könnten mindestens 2 weitere Aufgaben erledigt sein. Außerdem lässt sich selbst bei blockierten Aufgaben immer noch eine Teilaufgabe finden die man noch bis zum Ende des Tages erledigt haben kann.

Eine total einfache Aufgabe dauert viel zu lang

Kann eigentlich nicht sein, ist aber häufig so. Dies ist auch das häufigste Anzeichen dafür, daß man sich verrennt. Es ist besser einfach das Angefangene wegzuwerfen und am nächsten Tag mit einer besseren Lösung zu beginnen. Ich weiß daß jetzt viele denken mögen: „oh jeh, die Kosten“, aber ich weiß auch daß mir viele Entwickler zustimmen, denn nach dem Wegwerfen von Code entstehen fast immer bessere und aber auch in Summe günstigere Lösungen.

Ist das nun alles einfach nur Zeitverschwendung? NEIN. Es geht darum zu lernen! Es ist wichtig handhabbare Aufgaben zu erstellen. Realistische Aufwandsschätzungen sind nur möglich wenn die Aufgabe kleiner als ein Tag ist. Natürlich sind das dann mehr Aufgaben, aber sie sind genauer und somit das Endresultat der Schätzung, aber auch der Arbeit selbst, bessser. Eine anfänglich höhere Rate von „Verschwendung“ reduziert sich schnell, da niemand Arbeit wegwerfen will. Das Bewusstsein für die Aufgaben und ihren Wert steigt. Am Ende lässt sich diese „oh eine Woche“ Aufgabe in 3 Tagesaufgaben zerlegen.

Es gibt sogar noch weitere Aspekte an dieser Philosophie. Durch das häufigere commiten von Code oder dem Wegwerfen von unfertigem Code am Ende des Tages findet echte „continous integration“ statt. Jeden Morgen können Entwickler auf einem konsitenten vollständigen und funktionierendem Stand arbeiten. Codemerges werden einfacher und Konflikte selten. Auch wird Duplikation reduziert, da ein Entwickler nicht mehr das machen muss was ein anderer tags zuvor tat. Neben den technischen Vorteilen kann man am Ende des Tages den Kopf einfach frei machen und sich entspannen, ohne Sorge zu haben daß etwas noch nicht fertig ist und man sich am nächsten Tag noch an alles erinnern muss.

Warum nicht?

Das häufigst genannate Gegenargument ist daß es bei vielen komplexen schwierigen Aufgaben einfach nicht möglich ist sie in Tagesaufgaben zu zerlegen. Dies kann aber nicht wahr sein, denn es muss einen Anfangspunkt geben, und nach 4 Stunden arbeit muss man weiter sein. Schon nach 10 Minuten hat man etwas gemacht. Etwas, was man als Einzelaufgabe hätte aufschreiben können. Eine nicht zerlegbare 2Wochenaufgabe muss sich immer in 10 Tagesaufgaben zerlegen lassen. Es geht darum, daß nicht der Entwickler vor der 2 Wochenaufgabe sitzt und sich fragt „Wo fang ich nur an?  Wie soll ich das machen?“, sondern daß alle involvierten Personen sich daran beteiligen können. Und es gibt die ersten Ergebnisse schon am nächsten Tag. Und da Tagesaufgaben tendenziell einfacher sind können auch unerfahrenen Teammitglieder besser einbezogen werden.

Dieser Artikel wurde an 4 Tagen geschrieben. Am ersten verfasst, am zweiten rezensiert, am dritten übersetzt und am vierten veröffentlicht. So war am Ende jeden Tages etwas fertig.

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Jens Schauder

    Hi Fabian,
    der Aussage es sollte jeden Tag committet werden pflichte ich bei. Wenn man den ganzen Tag entwickelt, sollten kommen in meiner Erfahrung so ca 10 commits dabei heraus.

    Die harte Forderung (wenn sie denn so hart ist) angefangene Arbeit am Ende des Tages wegzu werfen halte ich für nicht sinnvoll (wie die meisten harten Regeln) Wenn eine Aufgabe 60 Minuten dauert, aber ich nur noch 30Minuten Zeit habe, fange ich sie dennoch an, und mache sie am nächsten Tag fertig.

    Jens

  • Fabian Lange

    Hallo Jens,
    Ja.. und nein 🙂 Natürlich ist das keine realistische Forderung, sondern eher als mahnendes Beispiel zu sehen. Ausgehend von einer Situation wo man es nicht schafft Aufgabeneinheiten für einen Tag zu finden.

    Aber auch bei Deinen 30 Minuten kann man fragen: Gibt es nicht etwas was abgeschlossen realisierbar ist? Oder mag man dann nicht einfach eher nach Hause gehen können?
    Eine Teilidee ist es ja den Kopf freizumachen und sich ebend nicht noch was merken zu müssen (wir merken uns eh schon zu viel [bei mir ist ne Komplettlösung von Monkey Island im Kopf die ich nicht weg bekomme 🙂 ])

    Und zuletzt: Es ist deshalb so radikal formuliert damit es im Gedächtnis bleibt

  • Friedel

    Als Idee und Ideal taugt diese Forderung denke ich schon. Aber birgt das nicht die Gefahr, dass man groessere Aenderungen unnoetig zerteilt? Die Antwort lautet, dass es vom Entwicklungsprozess abhaengt. Ein Commit beinhaltet in meinem Umfeld, eine lauffaehige Software zu haben, die mit keinem anderen Modul in Konflikt steht. Wenn also Interfaces veraendert werden, muss die zum naechsten Commit auf beiden Seiten vollzogen sein. Daher kommt es vor, dass man manchmal mehrere Wochen seinen Code in die Integration geben kann. – Das ist aber wie gesagt eine Prozesshuerde, die den Commit verhindert – nicht jedoch, dass man versuchen sollte, eine Teilaufgabe am Abend fertig zu haben.
    Daher stimme ich dir trotzdem voll und ganz – alleine deswegen, damit man sich am naechsten morgen nicht ueberlegen muss, wo man gestern aufgehoert hat.

    • Andreas Ebbert-Karroum

      Wenn man bedenkt, dass es mittlerweile auch die „Strömung“ von nano-commits gibt, denke ich dass die Forderung wenigstens einmal am Tag zu commiten nicht übertrieben ist. Nano-commits finden in der Testgetriebenen Entwicklung entwicklung bei jedem „grünen Balken“ statt, also immer, wenn alle Tests funktionieren. Dadurch werden eventuelle synchronisations/merge-Aufwände und Risiken weiter reduziert. Ich denke auch eine Interface-Änderung kann man, wenn man darüber nachdenkt, in kleinere Schritte zerteilen, die jeder für sich schon Wert generieren und Risiko minimieren.

  • Thomas Jaspers

    9. September 2009 von Thomas Jaspers

    Da hat Fabian ja ein sehr interessantes Thema aufgegriffen und ich kann auch durchaus die Bedenken verstehen, zumal man im Projektstress evtl. nicht immer sofort sieht, wie umfangreiche Änderungen gut gesplitted werden können.

    Aber gerade bei Interface-Änderungen denke ich es bietet sich oft an diese in drei Schritten einzuführen:

    1. Neues IF parallel zum bestehenden IF anbieten.
    2. Client(s) updaten auf das neue IF.
    3. Das alte IF entfernen.

    Klingt erstmal aufwendig, aber ich bin überzeugt es ist insgesamt weniger Aufwand, da deutlich weniger Absprachen nötig sind und weniger Synchronisationsaufwand betrieben werden muss. Auch ist die Gefahr eines am Ende doch „gebrochenen Builds“ deutlich geringer :-).

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.