Kann man verlässlich schätzen, wie lange ein Team braucht, Anforderungen in einsetzbare Software zu übersetzen? Kann man das für einen Horizont von wenigen Wochen? Kann man das für Monate oder Jahre?
Diese Frage führt immer wieder zu hitzigen Diskussionen. Eine der am besten besuchten Sessions auf der letztjährigen DevCon drehte sich auch um diese Frage. Das Interesse an einer Antwort, ja geradezu an einer Erlösung von diesem Thema ist groß.
Ich habe dazu auch meine Meinung und bin stolzes Mitglied der XING-Gruppe "Stop Software Estimation Now!" :-)
Aber wenn ein Thema so lange und so fortschrittslos diskutiert wird, frage ich mich auch: Gibt es hinter der Frage nicht ein grundsätzlicheres Problem? Sitzen wir vielleicht einem Missverständnis auf?
Vielleicht rennen wir ja kollektiv gegen eine Wand - und sehen nicht, dass nur ein paar Schritte weiter eine Tür ist.
Solch eine Tür meine ich nun entdeckt zu haben. Ich glaube, die Diskussion zum Thema Schätzen kommt aus einem ganz simplen Grund nicht voran: Wir messen einfach nicht den Erfolg des Schätzens. Keine Partei weiß so richtig, ob Schätzen wirklich erfolgreich ist.
Der Weg aus dem Problem mit dem Schätzen besteht aus meiner Sicht daher aus zwei Schritten:
1. Festlegen, wann eine Schätzung erfolgreich ist; wir brauchen Kriterien.
2. Messen, ob eine Schätzung nach den aufgestellten Kriterien erfolgreich war.
Klingt einfach, oder? Und man fragt sich, ob das nicht immer schon so gehandhabt wurde. Ich glaube, nein. Mit dem Schätzen ist man schnell bei der Hand. Aber weder werden Schätzungsqualitätskriterien bilateral (!) festgelegt, noch wird geprüft, wie die Schätzqualität am Ende war.
Bilateral Schätzungsqualitätskriterien festlegen
Beim Schätzen sind mindestens zwei Parteien beteiligt: der Kunde und das Entwicklungsteam. Der eine hat das Geld und die Zeit, die anderen sollen sagen, was sie im Rahmen dieser Budgets leisten können. Das Team muss also abschätzen, wie viel Geld und Zeit es für einen Scope braucht oder ob es einen Scope innerhalb eines gewissen Budgets realisieren kann.
Wenn nun Geld, Zeit und Scope zu einem Vertrag zwischen diesen Parteien gehören, dann natürlich auch die Schätzung. Deshalb müssen sich beide einig darüber sein, wann eine Schätzung gut war. Sonst ist es schlecht mit der Schätzerfolgskontrolle für beide Seiten. Und ohne Erfolgskontrolle kein Lernen, um es das nächste Mal genauso zu machen, weil es gut war, oder es besser zu machen, weil es nicht gut war.
Hier sehe ich das erste Defizit: Üblicherweise werden Schätzungsqualitätskriterien nicht explizit festgelegt und schon gar nicht bilateral. Es gibt einfach keine Diskussion darüber. Die Schätzung besteht aus zwei Zahlen (“Wir brauchen M Monate und G Euro für den gegebenen Scope.”), die irgendwer irgendwie im Blick behält. Wenn M und G zur Neige gehen, schaut man, wie viel vom Scope noch übrig ist. Dann stellt man fest, dass M und G nicht reichen werden und die Nachverhandlungen beginnen.
So tut man das halt. Darüber wird vorher nicht gesprochen. Das nehmen beide Seite als normal hin – und ärgern sich doch. Oder zumindest eine Seite ärgert sich. Die andere mag es nicht kratzen, weil sie eine Horde von Anwälten für solche Nachverhandlungen beschäftigt.
Dazu kann man nun sagen: “So ist halt die Welt.” Doch das will ich nicht akzeptieren, solange diese Parteien auf der anderen Seite klagen, “alles” sei so teuer. Denn Aufwand für Nachverhandlungen aufgrund schlechter Schätzung ist unnütz, falls schlechte Schätzungen die Norm sein sollten. Es wäre dann auf die Dauer billiger das Schätzen zu verbessern. Dafür braucht man jedoch Qualitätskriterien. Die müssen bilateral und explizit definiert sein, weil sie zum Vertrag gehören. Und die müssen dann auch am Ende überprüft werden.
Explizite Schätzungsqualitätskriterien
Müssen denn die Softwarevertragsparteien aber länglich über Schätzungsqualitätskriterien sprechen? Sind die nicht offensichtlich?
Nein. Das ist ja das Problem. Darüber bestehen unterschiedliche Meinungen, über die nicht gesprochen wird.
Offensichtlich sind natürlich die Schätzwerte selbst, z.B. geschätzte Zeit und geschätztes Geld. Die werden mit dem Soll an Scope verglichen und man erfährt, ob das geschätze Budget ausgereicht hat oder nicht.
Zu diesen offensichtlichen Schätzwerten sollten dann allerdings noch mindestens drei weitere Kriterien treten:
Hinnehmbare Budgetabweichung: Es sollte ausdrücklich darüber gesprochen werden, welche Abweichung von den Schätzwerten noch als Erfolg verbucht werden darf. Sind 5% Abweichung ok oder 10% oder gar 20%? Schätzungen sind eben Schätzungen. Dass ein Team punktgenau landet, ist nicht zu erwarten. Also sollte man sich darüber unterhalten, wie groß der Landeplatz ist.
Hier sind sogar zwei Seiten zu unterscheiden: Am Anfang stehen ein Termin und ein Geldbetrag in Bezug auf einen Scope. Der Kunde ist zufrieden, wenn aus seiner Sicht beides innerhalb einer zu definierenden Abweichung eingehalten wird.
Das Team hat zur Erreichung dieser Fixpunkte aber auch noch einen Aufwand geschätzt, der durch den Geldbetrag gedeckt werden soll. Selbst wenn der Kunde also zufrieden ist, kann es sein, dass das Projekt aus Teamsicht floppt. Falls es den Aufwand erhöhen musste, um den Scope zum Termin zu liefern, ohne mehr Geld zu bekommen, ist die Schätzung auch schlecht gewesen – ohne, dass der Kunde davon etwas merken muss.
Hinnehmbarer Qualitätsverlust: Inzwischen wissen wir ja, dass es eben nicht nur um Geld, Zeit und Scope geht, sondern immer auch um Qualität. Der Kunde stellt funktionale und nicht-funktionale Anforderungen (Scope), die ein Entwicklungsteam mit unterschiedlicher interner Codequalität umsetzen kann. Inwiefern der Scope innerhalb des geschätzt nötigen Budgets umgesetzt wird, beobachtet der Kunde natürlich genau. Fällt der Erfüllungsgrad unter eine bestimmte Marke, übt der Kunde Druck aus. Darunter leidet gewöhnlich die interne Codequalität. Das sollte so nicht sein, ist aber so. Deshalb ist es wichtig, sich darüber Gedanken zu machen, ein wie großer Verlust an dieser Qualität noch als Erfolg beim Schätzen verbucht werden darf. Denn beim Schätzen besteht ja der Anspruch, dass die interne Qualität konstant über die geschätzte Dauer gehalten wird. (Dass man die interne Qualität dann auch noch messen können muss, um eine Abweichung vom Soll feststellen zu können, steht auf einem anderen Blatt.)
Hinnehmbarer Zufriedenheitsverlust: Der Kunde ist zufrieden, wenn er seinen Scope innerhalb des geschätzten Budgets bekommt. Wie ein Team das schafft, ist ihm in der Regel ziemlich egal. Überstunden, Wochenendarbeit, Urlaubssperre, Zuckerbrot, Peitsche… das schert ihn nicht. Schade – aber wohl nicht zu ändern.
Ein Team sollte für sich allerdings in dieser Hinsicht einen Anspruch definieren. Ist eine Schätzung erfolgreich, wenn zwar der Scope zum geschätzten Termin abgeliefert wird – aber die Stimmung auf Null ist? An dieser Stelle geht es mir nicht um eine Abweichung beim Aufwand, ohne dass der Kunde das zu spüren bekommt. Dafür gilt es, eine hinnehmbare Budgetabweichung zu definieren (s.o.).
Ich glaube, genauso wichtig wie die Beobachtung der Ressourcen Zeit und Geld, ist die der Motivation, der Stimmung, der Zufriedenheit, der Kompetenz (s. dazu z.B.Jeff Sutherland, “Happyness Metric – The Wave of the Future”). Alle Teammitglieder sind wertvolle Ressourcen – warum sollte man sie sonst bezahlen? Also sollte man nicht leichtfertig mit ihnen umgehen. Sie können ihren Wert nur voll einbringen, wenn sie “wie geschmiert funktionieren”.
Eigentlich mag ich diesen Ressourcen-Jargon nicht, aber an dieser Stelle scheint er mir nützlich, um den Kontakt zu anderen Schätzungsqualitätskriterien zu halten.
“Wie geschmiert funktionieren” die Teammitglieder nur, wenn sie das Gefühl haben, dass ihre persönlichen Bedürfnisse erfüllt werden. Sie haben einen Anspruch daran, wie ihr Arbeitsumfeld zur Befriedigung ihrer Bedürfnisse beitragen soll. Dazu zählt z.B. “regelmäßiges Gehalt für das Bedürfnis ‘Certainty’” oder “nette Kollegen für das Bedürfnis ‘Connection’” oder “Zeit fürs Lernen für das Bedürfnis ‘Growth’” (Bedürfnisbezeichnungen nach Tony Robbins “Why we do what we do”).
Dass nicht immer alle Bedürfnisse voll erfüllt werden können, weiß jeder. Man ist deshalb damit zufrieden, wenn sie recht verlässlich innerhalb eines gewissen Bereichs erfüllt werden. Geschieht das allerdings nicht… dann geht die Stimmung in den Keller. Unaufmerksamkeit schleicht sich ein, die Fehler nehmen zu, Demotivation zieht ihre Kreise, Dienst nach Vorschrift bekümmert den Kunden, Krankmeldungen nehmen zu, Fluktuation entsteht usw.
Das sind Entwicklungen, die nicht nur persönlich bedauerlich für die Teammitglieder sind, sondern Unternehmen Geld kosten. Diese Kosten sind allerdings meist unsichtbar für das Projekt. Wenn Teammitglieder aus Frust über das Projekt kündigen, das unter hohem Druck steht, weil ein Termin zu halten ist, dann wird die Einarbeitung eines neuen Teammitglieds nicht dem Projekt zugeschlagen – obwohl das Projekt sie verursacht.
Deshalb scheint es mir nützlich, die Zufriedenheit der Teammitglieder als Kriterium heranzuziehen. Dieser Messwert kann innerhalb des Teams erhoben werden, auch wenn niedrige Zufriedenheit außerhalb des Teams zu Kosten führt.
Ein Projekt kann also mit dem gewünschten Scope zum geschätzten Termin mit dem geschätzen Aufwand und mit hinnehmbarer Qualität abgeschlossen werden – und doch war die Schätzung insgesamt nicht erfolgreich, wenn nämlich trotz der Einhaltung dieser Kriterien die Zufriedenheit aus dem definierten Rahmen gefallen sein sollte. Das kann z.B. passieren, wenn die Einhaltung der anderen Kriterien dazu führt, dass Stress entsteht, der messbar unzufrieden macht. Das ist dann ein Raubbau an der “Ressource Entwickler”.
Fazit
Ob Schätzungen funktionieren oder nicht… Ich habe da zwar meine Meinung, doch ich empfehle ihnen heute nur: Messen Sie doch einfach mal. Aber richtig.
Setzen Sie sich im Team oder noch besser mit dem Kunden zusammen und definieren Sie die Erfolgskriterien für Schätzungen. Bleiben Sie allerdings nicht bei Geld und Zeit stehen. Weiten Sie Ihren Blick und definieren Sie auch Ihren Anspruch an die innere Qualität und Ihre persönliche Zufriedenheit.
Dann messen Sie vorher, während und nachher. Und dann vergleichen Sie die Messwerte mit Ihren vorher definierten Ansprüchen.
Wenn die Messungen innerhalb der Toleranzgrenzen sind, dann funktioniert das Schätzen. Glückwunsch.
Aber wenn sie wiederholt außerhalb der Toleranzgrenzen liegen… tja, dann funktioniert das Schätzen eben nicht. Soviel Einsicht sollten Sie dann haben und Ihre Praxis ändern.
PS: Dass die Diskussion über das Schätzen so hitzig verlaufen, liegt also daran, dass da unterschiedliche Wertesystem aufeinanderprallen. Die Kriterien, wann Schätzungen erfolgreich sind, differieren. Deshalb lohnt es, einen Schritt zurückzutreten und erst einmal zu schauen, was denn diese Kriterien überhaupt sind.
