Wollt ihr bessere Schätzungen? Dann hört auf zu schätzen!
Joel Semeniuk spricht in diesem Video auf InfoQ auf sehr unterhaltsame Weise über die alltäglichen Probleme der Softwareentwicklung: Von Aufwandsschätzungen, die nur geraten sind, von unklaren Anforderungen und unsinnigen Zeitplänen. Leider lässt sich das Video hier nicht direkt einbinden.
Joel beschreibt in seinem Talk eine typische Situation wie folgt:
Der oder die Projektmanager/-in kommt rein und sagt: „Ok, wir haben da dieses Projekt. Es muss in drei Monaten fertig sein und muss dieses und dieses Feature haben. Ihr müsste das jetzt für mich schätzen.“
Entwickler: „Ähm, ok, also auf Basis dieser Informationen ist meine Schätzung… Ich denke wir können das in 5 Monaten schaffen.“
Manager: „Hallo, habt ihr mich nicht verstanden, ihr ignoranten Entwickler? 5 Monate? Ich habe 3 Monate gesagt, weil es zur Messe fertig sein muss.“
Letztendlich wird hier also gar keine Aufwandsschätzung verlangt, sondern die Lösung eines Problems, um ein Ziel zu erreichen. Es gibt den festen Präsentationstermin als Ziel und wahrscheinlich eine Reihe notwendiger Funktionen als Vorgaben. Dieses Problem zu lösen wäre wahrscheinlich in Ordnung. Man muss dafür nur den Funktionsumfang als variabel betrachten.
Joel erzählt von einer Projektmanagerin mit der er zusammen gearbeitet hat, die dieses System verinnerlicht hatte und deswegen sehr erfolgreich war (und dazu noch aussah wie Megan Fox). Das lief dann ungefähr so: Sie kommt rein und sagt: „Hey, ich habe 500.000 Dollar für dieses Projekt und wir müssen im Mai fertig sein“. Und gemeinsam schaut man, was man unter Berücksichtigung dieser gegebenen Einschränkungen für eine bestmögliche Lösung schaffen kann, also wie viel in das Projekt reinpasst. Diese Projekte sind erfolgreich, denn es wird berücksichtigt, dass die Menge an Dingen, die wir in ein Projekt packen, variabel, und nicht fest vorgegeben ist. Und das es unendlich viele Dinge gibt, die nicht vorhersehbar sind und es unendlich schwer ist, den Aufwand von Dingen zu schätzen, die man nicht kennt.
Das ist der Grund, warum agile Methoden in der Softwareentwicklung so erfolgreich sind. In Scrum ist jeder Sprint eine Timebox mit einer festgelegten Deadline. Und für jede Iteration muss der Funktionsumfang neu verhandelt werden. Kommt es zu unvorhersehbaren Problemen, wird eher Funktionalität reduziert und später geliefert, als der Sprint verlängert. So einfach ist das…
