So, ich habe ja gerade geschrieben, dass es im Job gerade ein wenig mehr zu tun gibt, als sonst, was wohl auch daran liegt, dass ich neben dem Qualitätsmanagement nun auch die Scrum-Master-Rolle übernommen habe. Und wenn man in einer Rolle aufgeht, dann arbeitet man ja auch gerne mal ein wenig länger. Da wir aber gerade beim Thema sind, handelt der heute Artikel auch von Scrum und dem Schätzen von Stories.

Es ist schon eine Weile her, aber wir haben hier im Blog mal eine Möglichkeit vorgestellt, wie man möglichst gut im Team schätzen kann. Planungspoker war da unser Tipp und ist es auch immer noch. Für mich ist das Pokern die Lösung, die zu den besten Ergebnissen kommt. Nur leider hat es ein Problem: Es dauert ewig. Wenn wir gerade am Anfang eines Projektes auf Planungspoker setzen und sagen wir mal 100 Stories (was eher einem kleineren Projekt entspricht) haben, dann könnt ihr euch ja vorstellen, was es bedeutet bei jeder dieser Stories eine geheime Schätzung abzugeben und danach in Diskussion einen Konsens im Team zu finden. Nach meiner Erfahrung kann man die Teammitglieder nach zwei Stunden eh nicht mehr Schätzen lassen, weil es einfach viel zu langweilig und anstrengend wird.

Wir brauchen eine Lösung, die schnell ist und trotzdem gute Werte liefert. Hier kommt das Team Estimation Game ins Spiel. Erfunden wurde es von Steve Bockman und ist prinzipiell sehr einfach. Man fängt damit an, alle Stories auszudrucken und auf einen Stapel zu legen. Teilnehmer dieses Meetings sind übrigens Team und Product-Owner. Jetzt stellt das Team sich in Reihe und Glied auf und der erste in der Reihe nimmt sich eine STory vom Stapel. Liest sie laut vor und pinnt sie in die Mitte einer Wand (Whiteboard, Pinnwand, …). Der nächste, der an der Reihe ist macht genau das gleiche. Nimmt sich eine Karte, liest sie vor und pinnt sie, falls sie  aufwendiger ist, als die die vorherige über ddiese, wenn sie gleich aufwendig ist neben sie und bei weniger Aufwand unter sie. Ich glaube, die Idee wird jetzt schon klar. Am Ende hat man eine nach Aufwand sortierte Liste der Stories. Jetzt kann man unten anfangen und einen Story-Point vergeben, die nächste Reihe dann 2 und so weiter. Die Fibonacci-Zahlen bieten sich auch hier an.

Damit aber nicht immer nur eine Person den Aufwand schätzt, sondern das Team auch ein Wörtchen mitzureden hat, gibt es noch eine Sonderregel. jeder, der an der Reihe ist, kann statt eine Karte zu nehmen eine bereits geschätzte nehmen und sie umhängen. So können Fehlschätzungen korrigiert werden und die Diskussion, die man in Scrum so liebt wird auch wieder eröffnet. Wenn man will, kann man diese Karte dann markieren, um sich später darüber zu unterhalten.

Ihr könnt euch vorstellen, dass das System um einiges schneller funktioniert, als die herkömmliche Vorgehensweise. Nachteile hat diese Methodik aber leider auch. Es ist nur schwer möglich, wenn die ganzen Stories einmal geschätzt wurden, auf Planungspoker zurückzuwechseln, da man dort andere Referenzen benutzt. Des Weiteren muss man immer wenn man wieder neue Stories im Backlog schätzen will sich die Tafel anschauen und mindestens aus jeder “Reihe” eine Story lesen, um zu wissen, mit welcher man sie vergleichen könnte. Diese Aufwärmphase kostet leider Zeit.

Alles in allem ist das Team Estimation Game aber trotzdem zu empfehlen. Wir haben zumindest in der Vergangenheit gute Ergebnisse damit erzielt.

Die Welt dreht sich weiter

Baut man ein Haus, so ist das Vorgehen klar. Man engagiert einen Architekten, dieser entwirft das Anwesen und es wird im Anschluss von der Baufirma erstellt. In einem solchen Fall würde Wasserfall das Projekt zum Ziel bringen. Es ist verständlich, dass man nach dem Abschluss des Kellers nicht mehr auf die Idee kommen sollte, dass man vielleicht doch einen Indoor-Pool haben möchte.
Bei Internetanwendungen ist dies aber Gang und Gäbe. Sobald ein Feature fertig ist, stürzen sich die Projektmanager und Konzepter darauf und verbessern bzw. erweitern es. Und das ist auch gut so, denn die Welt hat sich in der Zwischenzeit weitergedreht. Neue Ideen sind entstanden und die Konkurrenz ist mittlerweile auch ein Stück weitergekommen. Alles gute Gründe auch weiter zu denken.
Im klassischen Wasserfall sind Änderungen während der Entwicklung nicht geplant. Kostspielige Änderungsanforderungen müssen eingekippt werden und wahrscheinlich muss auch der Auftrag geändert werden, da der Umfang, der am Anfang geplant wurde, nicht mehr aktuell ist.

80-Prozent-Syndrom

Projekte haben viele Teilaufgaben. So viele Teilaufgaben, dass es eine gute Idee erscheint, zu parallelisieren. Dies ist auch bedingt richtig. Wenn man viele Teammitglieder hat, dann kann man es probieren. Die Bedeutung für das Projekt ist leider häufig sehr ähnlich. Von den 20 gleichzeitig angegangenen Aufgaben sind 15 offen, aber zu 80 Prozent fertig. Leider kann man erst wirklich was damit anfangen, wenn es 100 Prozent sind.

Misslungene Schätzungen

Sich das fachliche Feinkonzept zu Gemüte zu ziehen und danach eine präzise Schätzung abzugeben hat noch nie geklappt. Trotzdem passiert es immer wieder, dass ein Projektmanager oder ein einzelner Entwickler diese Aufgabe zugeschustert bekommt, dass dies im Normalfall bis zu 500 Prozent danebenliegen kann, ist empirisch belegt. Bei besonders hartnäckigen Projektleitern, kann es auch vorkommen, dass diese Schätzung bereits in einem frühen Projektstadium in Stein gemeißelt wird und die TV-Werbung für den Launch sozusagen schon auf den Tag genau gebucht wird. Eine Anpassung des Zeitplans ist somit nicht mehr möglich.

Priorisieren

Fragt man den Auftraggeber, welches Feature besonders wichtig für den Erfolg des Projektes ist, dann ist die Antwort oft die gleiche. Alle. Viele. Für das Priorisieren ist dies recht kontraproduktiv. Das Team muss entscheiden was zuerst angegangen wird. Wenn dann aber dann an einem bestimmten Meilenstein das falsche fertig ist, wird es den Entwicklern vorgeworfen.

Projektabschluss-Hektik

Das Gute an klassischen Projekten ist, dass auch sie irgendwann mal ein Ende finden. Nur leider ist das Ende meist mit Überstunden, Druck und Stress verbunden. Alles was man bis kurz vor dem Abschluss noch nicht implementiert bekommen hat, muss jetzt in kürzester Zeit nachgeholt werden.  Meist wird in einer solchen Phase auch auf Qualität keinen großen Wert mehr gelegt. Erfahrungsgemäß sind Unit Tests das erste was gestrichen wird, wenn ein Projekt  unter Stress zu Ende geführt wird.

In Scrum schätzt man keine Personenstunden, wenn man ein Feature implementiert, sondern Story Points. Das sind abstrakte Werte, die die Komplexität eines Tasks (für die Scrummies Story) darstellen. Klingt erstmal super. Keine Stunden, dass heißt am Ende kann dir keiner an den Karren fahren, weil es länger gedauert hat. Wunderbar. Um in das Schätzen reinzukommen, einigt man sich im Team auf einen Tasks, den man gut abschätzen kann und nimmt ihn als Referenz. Danach sagt man das ein anderer Task ähnlich komplex ist oder ein anderer doppelt.

Wenn ich das eine Weile so mache, dann weiß ich, wie viele Story Points in einer gewissen Zeiteinheit schaffe (Sprint) und kann damit die Teamgeschwindigkeit (Velocity) berechnen. Wenn alle meine zukünftigen Aufgaben durchgeschätzt sind, kann ich sogar sagen, wann mein Projekt zu Ende ist, auch wenn man keine Aufwände geschätzt hat.

Klingt jetzt alles ein wenig “abgefahren”, aber es funktioniert und nach einer Weile wird das Team auch wirklich sehr ähnliche Schätzungen abgeben. Bis jetzt also nur Sonne.

Jetzt gibt es ein häufiges Problem, wenn man sich in einem Schätzmeeting befindet. Man hat einen Task, der ist aufwendig, aber nicht komplex. Was sagt uns das über die Story Points? Eigentlich sollten sie sehr niedrig angesetzt werden. Das ist aber doof, denn wenn ich nur solche Tasks in meinem Sprint hätte, dann würde meine Teamgeschwindigkeit in diesem Sprint ja unheimlich niedrig sein, denn viel Komplexität habe ich nicht gemeistert. Also kann das mit der Komplexität nicht so ganz korrekt sein, wenn man sich das ganze im Zusammenspiel anschaut.

Story Points müssen also doch so etwas wie den Aufwand wiederspiegeln. Ich war so frei und habe mal in der Xing-Gruppe zum Thema Scrum meine Fragegestellt und leider waren die meisten Antworten esoterisch oder einfach nicht hilfreich. Leider. Bis jetzt habe ich noch keinen wirklich guten Artikel gefunden, der alle meine “Fragen” beantwortet hat, aber ich bin weiter dran. Wer schon mal eine weitere Meinung lesen will, dem empfehle ich Mike Cohn’s Blog. Er hat ein nettes Beispiel angebracht.

“Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery–snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points–each is expected to take the same amount of time. “

Da ich weiß, dass viele von euch agil arbeiten, hoffe ich auf eine Diskussion, wie ihr Story Points schätzt. Gerne auch im Xing-Forum.

Falsch ist das ja alles nicht, was ich erklärt habe, es ist ein wichtiger Bestandteil des Konzepts, dass man nach jedem Commit, also möglichst oft und automatisch durchtestet und sein System baut. Wichtig dabei st aber auch, dass man möglichst oft comittet. In den meisten Fällen ist es ja so, dass man erst seine Änderungen in den Trunk eincheckt, wenn das Feature fertig ist und vollständig implementiert ist. CI geht da einen anderen Weg, nicht wenn das vollständige Feature fertig ist, sondern wenn etwas funktionsfähig fertig ist, wird comittet.

Die Idee dahinter ist, dass man viel einfacher kleine Inkremente in das Gesamtsystem mergen kann, als das große Ganze am Ende. Konflikte mit anderen Änderungen (von den lieben Kollegen) findet man so zeitnah und kann auch von dem Code, den die anderen produzieren profitieren. Ob das System in der Art für einen funktioniert, hängt auch immer davon ab, wie sehr man bereit ist Testabdeckung für seinen Code und seine Funktionalitäten hochzuschrauben. Denn wenn die Abdeckung hoch ist, so weiß man jeder Zeit, ob der Code, den man gerade produziert hat etwas am bereits bestehenden System ändert. Wenn nicht, kann es auch nicht schaden, den Code mit in die Versionskontrolle zu packen.

Continuous Integration ist ein sehr großes Thema, auch wenn es eigentlich nur auf zwei Grundsätzen beruht. Ich werde versuchen in der nächsten Zeit noch mal etwas über einzelne Implementationen zu schreiben, dann will ich auf Feature-Toggles eingehen und etwas für Continuous Deployment verfassen. Wenn euch etwas fehlt, dann schreibt es in den Kommentaren. Ich kümmere mich dann darum.

Damit ich euch (und wahrscheinlich am meisten mich) nicht gleich überfordere hier eine Kleinigkeit, die mir in den letzten Wochen aufgefallen ist. Das Team, in dem ich arbeite produziert Tools, mit denen die übrigen Entwickler arbeiten können. Und es ist unglaublich wie wichtig dabei die Dokumentation ist. Ok, das war klar, aber was mir nicht ganz so klar war, ist, dass Doku auch gut aussehen muss, damit man sie gerne liest. Struktur ist dabei ja obligatorisch. Wir hatten beim aktuellen Projekt mit einer Standard-Wiki-Struktur angefangen. Also plattgekloppt. Kann man machen, sollte man aber nicht. Versucht man so eine lesefreundliche Version zu bauen, hat man oft die A-Karte gezogen. Strukturen gehen verloren.

Zum Glück hat unser Wiki (Confluence) einen besonderen Dokumentations-Modus, mit dem alles schon viel leichter von der Hand geht. Was mir danach aber sehr wichtig war, was die Anpassung des CSS. Man ist es einfach nicht gewohnt auf den großen 22-Zoll-Monitoren von Links nach Rechts zu lesen. Da bekommt man ja ‘nen Drehwurm oder besser ‘nen Schwenkwurm. Also Breite anpassen, Zeilenabstände (line-height) vergrößern und auf einmal flutscht es. Die Entwickler haben die Änderungen sehr dankbar angenommen. Ich schau mal, ob ich noch eine Vorher-Nachher-Grafik erstellen kann, damit ihr wisst, was ich meine.

Also macht euch nächstes mal einfach ein paar Gedanken darüber, ob das was ihr schreibt nicht nur inhaltlich korrekt ist, sondern auch eine Form hat, mit der man arbeiten möchte. Ach ja, die Symfony2-Struktur und -Optik finde ich sehr gelungen, da haben wir uns dann auch ein wenig dran orientiert.

Was ich ganz vergessen hab: Frohes neues Jahr euch allen.

PS: Das phm|network ist grad kaputt, aber wir kümmern uns baldmöglichst drum.