26. Aug 2013

Andreas Fröwis

3 Min.

Aufwandsschätzung in der agilen Softwareentwicklung

Im aufregenden Leben eines Software­entwicklers wird ständig geschätzt. Zum Beispiel, wie lange er brauchen wird, um etwas zu programmieren. Oder wie viel etwas für den Kunden kosten wird. Falsche Schätzungen sind ein sehr häufiger Grund für das Scheitern von Softwareprojekten – deshalb ist es wichtig, etwas über Schätzung zu wissen.

Ein wichtiger Punkt: Schätzungen sind immer ungenau. Aber durch Übung kann man immer besser im Schätzen werden.

In der Vergangenheit kam man zu folgenden Erkenntnissen:

  • Personen, die die Aufgabe durchführen, sollten immer bei der Schätzung miteinbezogen werden
  • Mehr Erfahrung bedeutet präzisere Schätzungen
  • Dokumentation der Schätzungen hilft, im Schätzen besser zu werden
  • Je genauer die Informationen, desto besser die Schätzungen
  • Projekte möglichst weit zu zerlegen kann beim Schätzen hilfreich sein

Agiles Schätzen vs. klassische Aufwandsschätzung

Grundsätzlich unterscheidet sich das agile Schätzen von der klassischen Aufwandsschätzung in einem zentralen Punkt: Es wird kein Aufwand, sondern eine Komplexität geschätzt. Das hat den Hintergrund, dass es für Menschen einfacher ist, abstrakte Größen (beispielsweise eine Schwierigkeit oder Komplexität) zu vergleichen als eine absolute Größe – die Umsetzungsdauer.

Noch besser schätzbar ist ein Projekt, nachdem es in Teile zerlegt worden ist. Diese Teile werden “Storys” genannt. Diese Zerteilung in Storys hat den Vorteil, dass kleinere Storys viel schneller und leichter zu schätzen sind als große Projektteile. Für die Messung der Komplexität eines Projektes werden “Story Points” als Einheit verwendet. Üblicherweise verwendet man 0 bis 100 Storypoints, um eine Story zu schätzen, wobei 100 Storypoints die maximale Komplexität bedeutet.

Faustregeln für das agile Schätzen:
Nicht alleine, sondern im Team schätzen. Jeder Experte sieht andere Risiken – so ist das Schätzen auch ein Erfahrungsaustausch zwischen den Mitarbeitern. Nicht zu viel Zeit in die Schätzung investieren. Die dadurch gewonnene Genauigkeit ist die Zeit (beziehungsweise das Geld) nicht wert. Es hilft, beim Schätzen Relationen zu anderen Projekten oder Schätzungen herzustellen.

SCRUM

SCRUM (oder ähnliche agile Frameworks) eignen sich perfekt für Schätzungen mit Story Points. Nach einigen Sprints (in Scrum dauert ein Sprint üblicherweise 2 Wochen) weiß das Team ungefähr, wie viele Storypoints es in einem Sprint bewältigen kann. Somit können zukünftige Sprints einfacher geplant werden.

Fazit

Auch wenn Schätzungen immer ungenau sind: Oft sind Schätzungen die Grundlage, um zukünftige Kosten oder Mitarbeiterstunden zu prognostizieren. Deshalb macht es Sinn, sich ein wenig genauer mit Aufwandschätzung zu beschäftigen oder Schätzungsmethoden (beispielsweise Planning Poker) zu benutzen.

Scrumboard bei Fusonic