Agile und klassische Aufwandsschätzungen in der Softwareentwicklung

In unserem Entwicklungsprozess schätzen wir den Aufwand für ein Projekt oder eine Story (dazu später mehr), nachdem es fertig spezifiziert wurde.

Warum schätzen wir?

Zu diesem Zeitpunkt steht meistens schon fest, dass die Anpassung umgesetzt werden soll. In mindestens 90% der Fälle handelt es sich um selbstbestimmte Weiterentwicklungen, das heißt, sie werden von keinem Kunden gezahlt. Hier stellt sich natürlich die Frage, warum wir überhaupt schätzen.

Neben den Kosten gibt es weitere wichtige Gründe für eine Schätzung. In unserem Fall wollen wir folgende Fragen beantworten:

• Muss das Projekt weiter aufgeteilt werden?
• Wann starten wir die Umsetzung?
• Wer setzt das Projekt um?
• Wann kann es fertig sein?

Wir stellen also durch die Schätzung eine Vergleichbarkeit her. Im ersten Schritt entscheidet das Produktmanagement zum Beispiel, wann das Projekt zur Umsetzung an die Entwicklungsabteilung gegeben wird. Im zweiten Schritt legen wir in der Entwicklung fest, wer es umsetzt oder umsetzen kann.

Klassische Aufwandsschätzungen

Wie schätzt man nun ein solches Projekt oder eine Story?

In der klassischen Softwareentwicklung wurde für ein Projekt ein Lastenheft erstellt, in dem alles festgehalten wurde, was das entsprechende Softwaretool an Funktionalität bieten sollte.

Das Lastenheft wurde von Entwicklern analysiert, und jedem Implementierungsschritt wurde eine Anzahl an Stunden oder Tagen zugeordnet.

Das Vorgehen hat allerdings auch einen Nachteil. Neben der Tatsache, dass es den angestaubten Charme von Softwareentwicklung aus den 1970ern versprüht, muss man relativ viel Aufwand in eine solche Schätzung stecken. Man beginnt bereits mit der Planung der Implementierung, um den Aufwand für die einzelnen Schritte schätzen zu können.

Das Ergebnis ist dann eine Stundenzahl. Allerdings hat jeder Entwickler eine andere Arbeitsgeschwindigkeit, sodass die Stundenschätzung nur auf den Entwickler bezogen werden kann, der sie erstellt hat. Setzt das Projekt später ein Entwickler um, der sich im entsprechenden Code noch nicht vollständig auskennt, erhalten wir eine große Abweichung nach oben.

Hinzu kommt, dass Menschen nur sehr schwer absolute Werte schätzen können. Je höher oder größer der Wert ist, desto schwerer tun wir uns.

Agile Schätzungen

In der agilen Softwareentwicklung unterteilt man Projekte immer zuerst in möglichst kleine Bestandteile, meist Stories genannt.

Projekt vs. Story

Je kleiner eine solche Story ist, desto einfacher kann ein Aufwand geschätzt werden – und desto stabiler ist die Umsetzung. Ist eine einzelne Story zu groß oder schwer abschätzbar, muss sie weiter unterteilt werden.

Wir schätzen nicht wie in der klassischen Methode von oben nach unten (top-down), sondern bottom-up. Wir nehmen uns erst möglichst kleine Bestandteile und schätzen diese, bevor wir uns mit dem kompletten vollständigen Projekt beschäftigen.

Vergleichende Schätzungen

Menschen können zwar nur schwer absolute Werte schätzen, dafür aber sehr gute Vergleiche erstellen. Wenn mir drei Projekte beschrieben werden, kann ich nur schwer direkt eine geschätzte Anzahl an Stunden nennen, die ich so auch einhalten würde. Ich kann aber sehr wahrscheinlich problemlos die Projekte nach den Aufwandsgrößen sortieren.

Ein klassisches Beispiel ist die Schätzung von Einwohnerzahlen verschiedener Städte. Die wirklichen Werte können die meisten Menschen nicht schätzen, nach Einwohnerzahlen sortieren kann aber zum Beispiel fast jeder.

Komplexitätsschätzungen

Jetzt haben wir noch immer das Problem, dass wir eine Stundenanzahl ermitteln wollen, aber ohne bekannten umsetzenden Entwickler keine Stundenanzahl nennen können. An dieser Stelle können wir einfach eine andere Größe schätzen – die Komplexität des Projektes.

Die abgeschätzte Komplexität kann in einen Stundenwert genau dann umgerechnet werden, wenn feststeht, wer das Projekt umsetzt. Die Entscheidung darüber, wer das Projekt übernimmt, ist deutlich einfacher. Einen Entwickler mit wenig Erfahrung oder einen Auszubildenden zum Beispiel lasse ich kein Projekt mit sehr hoher Komplexität umsetzen.

Auch hier ergibt sich wieder ein Problem. Vergleichend zu schätzen und dann sogar noch vergleichend die Komplexität zu schätzen setzt Erfahrung voraus. Was aber, wenn ich unerfahrene Entwickler ebenfalls mit schätzen lassen möchte?

Function-Point-Analyse

Ein Beispiel für ein vorgegebenes Verfahren zur Abschätzung der Komplexität einer Softwareanpassung ist die Function-Point-Analyse.

Das Verfahren wurde Ende der 70er-Jahre von Allan J. Albrecht für IBM entwickelt. Über die Jahre wurde das Verfahren weiter entwickelt und mittlerweile als ISO-Standard festgehalten (ISO-Norm ISO/IEC 14143).

In diesem Verfahren bewertet man aus Anwendersicht folgende Punkte:

• Eingabe
• Ausgabe
• Abfrage
• Interne Datenbestände
• Externe Datenbestände

Ich zähle also, wie viele Eingabemasken, Ausgabemasken, Abfragen und Datengruppen vorliegen, bestimme jeweils die Anzahl der Felder und bilde so Summen über die Funktionspunkte. Je höher der Wert am Ende ist, desto höher ist die Komplexität der Anpassung.

An dieser Stelle könnte der berechtigte Einwand kommen, dass ich vorhin noch die klassischen Schätzungen als angestaubt bezeichnet habe und jetzt eine Methode aus den 70ern vorstelle. Tatsächlich ist das Thema aber auch in der agilen Softwareentwicklung noch immer aktuell.

Häufig werden Komplexitäten abgeschätzt und auch hier zerlege ich ein großes Projekt aus Anwendersicht in seine Bestandteile – nicht aus Entwickler- oder Implementierungssicht.

Planning Poker / T-Shirt-Methode

In agilen Teams sollen häufig alle Teammitglieder an Schätzungen beteiligt werden, zusätzlich möchte man vergleichende, schnelle Schätzungen.

Eine Methode sind sogenannte Planning Poker. Alle Teilnehmer erhalten ein Kartenset mit immer stärker steigenden Werten. Eine Story wird vorgestellt und alle Teilnehmer spielen eine Karte aus. Wird ein Konsens oder eine Mehrheit gefunden, wird die Schätzung angenommen – wenn nicht, wird diskutiert und weiter gespielt.

Um den Versuch, auf Stundenwerte zu kommen, zu unterbinden gibt es beispielsweise die T-Shirt-Methode, in der in Größen XS, S, M, L, XL geschätzt wird.

Schätzungen bei onOffice

Wir vermischen die Schätzung von Stunden und Komplexität. Wir geben eine Schätzskala vor (5, 10, 20, 50, 100, 200) und ordnen jeder Größe eine exakte Stundenzahl zu. Natürlich ist uns klar, dass ein 100h-Projekt kein Azubi im ersten Ausbildungsjahr umsetzen kann, da es zu komplex ist.

Über unser Tracking-System wissen wir außerdem, dass die tatsächlichen Umsetzungs- und Testzeiten von den Schätzgrößen abweichen.

An die Function-Point-Analyse angelehnt geben wir bestimmte Kriterien vor, nach denen eine Anpassung bewertet und in eine Kategorie einsortiert wird:

• Was muss gemacht werden?
  • GUI?
  • Logik?
  • Datenbank?
• Erweiterung oder Neubau?
  • »nur« Erweiterung bestehender Logik?
  • neue Logik / neue Struktur?
• Mögliche Hürden?
  • Neue Technologie
  • Externe Abhängigkeit (API, anderes Team, …)

Je mehr Punkte ich mit ja beantworte, desto höher ist meine Projekteinschätzung auf der oben genannten Skala. Zur Beantwortung der oben genannten Fragen reicht diese Einschätzung vollkommen, alles weitere liefert uns die Statistik.

Ein Beispiel aus der Praxis

Wir sollten kürzlich eine Anpassung unserer Feldfilter durchführen, die Eingabefelder nach bestimmten Kriterien (Gruppen, bestimmte Werte) ausblenden können. Im Projekt sollten die Art des Energieausweises und der mögliche Wert, nach dem gefiltert werden kann, in die Liste aufgenommen werden.

Die Schätzung aus dem Bauch heraus lag bei 20h.

• Es werden keine neuen Technologien verwendet.
• Die GUI muss an zwei Stellen erweitert werden (Administration und Frontend) um eine dynamische Liste zu konfigurieren und die Konfiguration zu berücksichtigen (= Werte auszufiltern).
• Es wird eine neue Logik implementiert, die in Abhängigkeit von ausgewählten Werten andere Werte ein- oder ausblendet.
• Die Datenbank muss erweitert werden. Beliebige Felder können über die neue Konfiguration ausgeblendet werden. Man hat also mindestens eine neue m:n Tabelle sowie die Datentabelle für die Filterkonfiguration.

Wenn man pro Bereich für Planung, Testing, kleine Refactorings von bestehendem Code und Umsetzung von durchschnittlich 10 Stunden ansetzt, überschreitet man deutlich die 20h und landet somit in der 50h-Projektklasse.

Die Umsetzung hat gezeigt, dass dieser Aufwandsblock realistisch gewesen wäre.