Sinn und Unsinn von Schätzungen – Teil 1

In der Software-Entwicklung sind wir es seit ewigen Zeiten gewohnt, die Größe von Vorhaben abzuschätzen. Selbst in vielen agilen Vorgehensweisen wird kaum hinterfragt, welchen Nutzen wir aus den Schätzungen ziehen und ob es nicht Mittel und Wege gibt, den Aufwand für Schätzungen zu reduzieren oder gar komplett darauf zu verzichten.

In einer 3-teiligen Artikelserie soll dieser Frage ein wenig Aufmerksamkeit gewidmet und Denkanstöße für einen bewussteren Umgang mit Schätzungen gegeben werden. Der erste Teil beschäftigt sich mit unserer grundsätzlichen Motivation für Schätzungen. Teil zwei beleuchtet ein paar prinzipielle Wege, sich dem Thema Schätzungen differenzierter und effizienter zu nähern. Der abschließende Teil zeigt dann anhand eines Beispiels, wie ein solcher Umgang und Übergang in der Praxis aussehen kann.

Die Software-Entwicklung hat in den vergangenen Jahrzehnten einige Veränderungen durchgemacht. Seien es neue Programmier-Paradigmen, Behandlung von Tests, Plattformen für die programmiert wird oder Vorgehensweisen für die Zusammenarbeit in Teams und Projekten. Eines hat sich aber über die gesamte Zeit erhalten – wir schätzen Aufgaben ab.

Zugegeben, das Vorgehen bei Schätzungen hat sich in der langen Zeit auch gewandelt und neue Möglichkeiten hervorgebracht. Schlagworte wie Expertenschätzungen, Delphi-Methode, Team-Schätzungen, Function Point Analyse oder Komplexitätsschätzung stellen nur einen kleinen Ausschnitt der verfügbaren Bandbreite dar. Im Kern hat sich aber eine Aussage gehalten – wir schätzen Aufgaben ab.

Aber warum tun wir das? Schätzungen werden für diverse Zwecke verwendet:

  • Wir erstellen aus den Ergebnissen Release- und Meilensteinpläne (oder etwas ähnliches)
  • Wir versuchen, daraus eine Personalplanung abzuleiten (Ressourcenplanung ist mir da doch etwas zu technisch)
  • Wir verfolgen anhand einmal geschätzter Werte der Fortschritt unseres Projektes oder Vorhabens
  • Wir erstellen aufgrund der Schätzungen Angebote oder Budgetpläne
  • Speziell in agilen Vorgehen benutzen wir den Vorgang des Schätzens zur Stärkung der Kommunikation und Verbreitung von Wissen über Projektinhalte und Technik

Und alle diese Zwecke haben natürlich auch entsprechende Zielgruppen. Manager, Auftraggeber und Controller lieben Zahlen und erhalten diese aus den Projekten basierend auf den Schätzungen. Wie umfangreich ist das Projekt? Wo stehen wir im Projekt? Sind wir noch im Budgetplan? Über Reports versuchen Projektleiter diese und andere Fragen zu beantworten und sind damit natürlich auch eine Zielgruppe. Die Messlatte wird dabei stets durch die Schätzungen gelegt (gut, manchmal zählt auch einzig der Termin. Das ist aber eine andere Geschichte). Letztlich schätzen wir aber auch für uns, für unser Team und unsere Kollegen. Was passt noch in den nächsten Sprint? Wie hoch ist unsere Velocity? Und manchmal leider auch wer ist unser Super-(Hero/Loser)-Programmierer?

Die Zahlen an sich stellen aber noch keinen Wert dar. So wie jede gute Metrik für sich genommen nur eine Zahl ist und erst in einen Kontext eingebettet einen Sinn ergibt, verhält es sich auch mit Schätzungen.

  • Wir verwenden sie, um mehr Sicherheit und/oder Kontrolle zu erlangen. Aus den nackten Zahlen erstellen wir einen Plan, dessen Einhaltung verfolgt werden kann.
  • Schätzungen befördern die Kommunikation innerhalb des Projektteams, indem Gespräche über die Aufgaben gefördert werden.
  • Wir schaffen eine (zumindest gefühlte) Vergleichbarkeit. Wer schlägt die Schätzungen und wer nicht? Wie entwickelt sich unsere Entwicklungsgeschwindigkeit?
  • Sie erlauben uns Schuldzuweisungen und Rechtfertigungen. „Mein Team konnte gar nicht rechtzeitig liefern, weil das andere Team seine Schätzungen überzogen hat“.

Betrachten wir diese Aspekte einmal mit etwas Abstand, stellen sich schnell ein paar Fragen. Können wir den Informationsbedarf der unterschiedlichen Zielgruppen auch anders befriedigen? Muss für einen Plan tatsächlich immer geschätzt werden? Muss immer alles geschätzt werden oder sollten wir diese Tätigkeit auf bestimmte Aufgaben oder Abstraktionsebenen beschränken?

Mit Antworten auf diese und weitere Fragen soll sich der zweite Teil beschäftigen. Zudem wollen wir einmal beleuchten, welche grundsätzlichen Ansätze und Alternativen wir für die Schätzung sehen.

 

Dieser Beitrag wurde unter Agile Blog abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.