Software schätzen ist grausam

Software schätzen ist grausam. Im agilen Umfeld ist es zudem umstritten weil es keinen funktionalen Mehrwert für den Kunden hat. Dennoch: Der Kunde möchte gerne am Anfang des Projekts eine „Hausnummer“ haben. Bei der neusta software development habe ich mit meinen Kollegen ein Verfahren entwickelt, welches agile mit nicht agilen Techniken kombiniert.

Software schätzen: Zunächst agil …

Wir beginnen normalerweise damit die Stories auf Karten zu schreiben um dann ein Team Estimation Game zu spielen. Dabei werden die einzelnen Stories zunächst ins Verhältnis gesetzt. Es werden keine Aufwände/Storypoints geschätzt sondern das Ergebnis ist wie viel Aufwand eine Story im Verhältnis zu der anderen hat.

Software schätzen ist Grausam - Team Estimation Game

Der zweite Schritt ist dann Gruppen von gleichartigen Aufwänden zu finden. Aufwände, die nicht zu zugeordnet werden können, werden hinten auf die 40 gelegt. Sie sind nicht Teil der Schätzung. Mit Storypoints kann ich nun grob den Abstand der einzelnen Gruppen bewerten und komme zu einem Ergebnis in Points.

Software schätzen ist Grausam - Team Estimation Game Chunks

Damit ist der erste Schritt der Schätzung beendet.

Software schätzen: Dann Erfahrung …

Die Frage ist nun: Wie viel Aufwand ist denn nun ein 2er Punkt, wieviel ein 5er Punkt etc. Dazu nehmen wir aus jeder Gruppe ein paar Stories heraus und schätzen sie mit dem PERT-Verfahren. Wir schätzen reinen Entwicklungsaufwand also:

  • Entwerfen
  • Tests schreiben
  • Codieren
  • Refactoring
  • Dokumentation
  • Internes Code Review
  • … was immer in der DoD steht

Nun wissen wir, wie viel Entwicklungsaufwand in den bekannten Stories steckt.

Software schätzen ist Grausam - Team Estimation Game - Aufwand

Software schätzen: Zum Schluss klassisch …

Aus anderen Projekten haben wir Metriken entwickelt heraus zu bekommen, wie hoch der Entwicklungsaufwand in Bezug zu anderen Aufwänden ist.

Software schätzen ist Grausam - Team Estimation Game - Gesamtaufwand

Wichtig ist zu wissen: Ein Softwareprojekt ist wie ein Garten. Bereits nach dem ersten Sprint entstehen Wartungsaufwände, die berücksichtigt werden müssen.

Und zum schluss …

Sagen Sie ich bin böse: Meine Erfahrung ist, dass Entwicklerinnen und Entwickler meistens viel zu optimistisch schätzen, trotz PERT. Ich verdoppele meistens den Entwicklungsaufwand, lasse aber die anderen aus dem ursprünglich errechneten Werten bestehen. Im obigen Projekt würde ich also 1050 BT kommunizieren.

Wer jetzt sagt: Das ist doch kein solides Verfahren dem entgegne ich:

  1. Eine Schätzung ist eine Schätzung ist eine Schätzung.
  2. Meine Methode ist genau so gut oder schlecht wie jede andere wissenschaftliche Methode.
  3. Meine Methode ist sehr zeit effektiv (wir brauchen im Schnitt weniger als einen Tag auch für große Projekte).

Das Problem sind immer noch die Manager, die oft aus politischen Gründen eine Schätzung verringern. Und: In einem agilen Projekt ändern sich die Anforderungen sowieso im Laufe der Zeit. Wir haben hier also nur einen Anhaltspunkt ob das Projekt eher 100.000 €, 200.000 €, 300.000€, 500.000 € … kostet. Auch hier gilt Fibunacci.

 

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Ein Gedanke zu „Software schätzen ist grausam

Schreibe einen Kommentar

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