Methoden zur direkten und indirekten Aufwandsschätzung (3)

Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Eine bewährte Methode zur indirekten Aufwandsschätzung ist die Bestimmung des funktionalen Umfangs (anstelle beispielsweise Story Points) und die Verrechnung mit einem Erfahrungswert, welcher Umfang mit einem bestimmten Personalaufwand umgesetzt werden kann (auch häufig als Produktivität oder Effizienz bezeichnet). Die Grundlagen zur Messung des funktionalen Umfangs sind im Industriestandard ISO/IEC 14143 definiert. Sie erfordern eine Präzisierung der User Stories in Anwendungsfälle.

Beispiel eines Anwendungsfalldiagramms

Ein Anwendungsfall steht für ein Verhalten, das ein System nach außen – bezogen auf die definierten Systemgrenzen – anbietet, dessen Ergebnisse also für einen Akteur von außen wahrnehmbar sind. Dabei können Akteure sowohl Anwender als auch andere Systeme oder Maschinen, Hardware oder Software, sein. Die nebenstehende Abbildung zeigt das Anwendungsfalldiagramm einer (stark vereinfachten) Internet Booking Engine für Flüge. Innerhalb der Systemgrenzen (dargestellt als Rechteck mit der Beschriftung „Internet Booking Engine“) sind Anwendungsfälle durch Ellipsen dargestellt. Sie stehen in Beziehung mit Akteuren, im Beispiel ein Reisender und ein Computerreservierungssystem (CRS), was durch Linien zwischen den Akteuren und den Use-Cases dargestellt wird.

Jeder Anwendungsfall steht für Aktionen, aus denen sich die für eine Bestimmung des funktionalen Umfangs relevanten sogenannten Basis-Funktionskomponenten oder Elementarprozesse identifizieren lassen. Der Anwendungsfall „Search Flight“ könnte beispielsweise vereinfacht aus folgenden Elementarprozessen bestehen:

1. Reisender ruft den Flight Search Dialog auf.
2. Reisender gibt das Abflugdatum ein.
3. Reisender gibt die ersten Buchstaben des Reiseziels ein (Name oder Code).
4. System sucht in der Datenbank nach übereinstimmenden Flughäfen und zeigt eine Liste mit Namen und Codes an.
5. Reisender wählt einen Eintrag aus der Liste aus und klickt auf dem Button „Search“.
6. System sendet eine Nachricht vom Typ „Flight Search Request“ mit Datum und Flughafen-Code an das CRS.
7. System empfängt eine Nachricht vom Typ „Flight Search Response“ vom CRS und liest die Felder Abflugzeit, Ankunftszeit, Fluggesellschaft, Flugnummer, Klasse, Preis und Währung aller aufgeführten Flüge aus.
8. System zeigt in einer Tabelle alle Flüge unter Angabe dieser Informationen an.

In Kenntnis dieser Elementarprozesse kann mit jeder funktionsorientierten Messmethode leicht der funktionale Umfang bestimmt und mit Hilfe eines Erfahrungswerts für die Produktivität der zu erwartende Entwicklungsaufwand ermittelt werden. 

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen mit Story Points

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (2)

Indirekte Schätzungen mit Story Points

Eine direkte Schätzung des Entwicklungsaufwands (siehe: Expertenschätzungen) ist von den persönlichen Fähigkeiten des Schätzers abhängig und nicht von der Leistungsfähigkeit des Teams, das für die Entwicklung vorgesehen ist. Im Gegensatz zu einer direkten Schätzung ermitteln indirekte Methoden zunächst die Größe der zu entwickelnden Objekte oder Anforderungen und stellen diese anschließend in Relation zu Erfahrungswerten idealerweise des gleichen Teams aus früheren Sprints. 

Im Fall der Story Point-Methode bewerten Schätzer die Größe von User Stories, jedoch nicht in einer absoluten Maßeinheit sondern relativ zueinander. Beispiel: „Die Auswahl des Zielflughafens und Datums ist eine 1. Die Abfrage verfügbarer Flüge ist im Verhältnis dazu eine 3. Die Buchung eines ausgewählten Flugs ist dann eine 8.“ Die Skala für die zu vergebenden Story Points orientiert sich an der Fibonacci-Folge: 1, 2, 3, 5, 8, 13 und so weiter. Dadurch entfallen kleinteilige Diskussionen und Entscheidungen zwischen den zulässigen Werten werden erleichtert. Gleichzeitig macht die Skala jedoch auch deutlich, dass die Genauigkeit der Bewertung mit zunehmender Größe abnimmt.

Die Berechnung des voraussichtlichen Entwicklungsaufwands auf Basis von Story Points erfordert einen Erfahrungswert, wie viele Story Points das Team unter vergleichbaren Rahmenbedingungen je Inkrement bzw. Sprint umsetzen kann. Dieser Erfahrungswert wird Velocity genannt und nach jedem abgeschlossenen Sprint dadurch aktualisiert, dass die Größe der tatsächlich entwickelten Stories mit der dafür benötigten Zeit ins Verhältnis gesetzt wird.

Eine Aufwandsschätzung durch Story Points hat den Vorteil, dass sie schnell angewendet werden kann und von der aktuellen Leistungsfähigkeit des Teams und nicht einzelner Individuen ausgeht. Durch die permanente Nachkalibrierung der Velocity kann sich diese innerhalb von wenigen Sprints an Veränderungen beispielsweise in der Team-Zusammensetzung oder sonstiger Rahmenbedingungen anpassen.

Ein Nachteil der Methode ist die Detaillierung des Schätzobjekts: eine User Story, die eine Anforderung meist nur umgangssprachlich in einem Satz beschreibt. Unerwartete Komplexität, die erst bei der Umsetzung festgestellt wird, führt dann häufig zu einer Überschreitung des geschätzten Aufwands.

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (1)

Expertenschätzungen

Eine bewährte Methode, um sich dem notwendigen Aufwand zur Umsetzung von Anforderungen bzw. User Stories anzunähern, ist die Expertenschätzung. Ein oder auch mehrere Experten schätzen unabhängig voneinander den Aufwand auf Basis ihrer Erfahrungen mit vergleichbaren Aufgabenstellungen. Da diese Erfahrungen sehr unterschiedlich sein können und sich oft an den eigenen Fähigkeiten orientieren ist eine Mittelwertbildung über mehrere Schätzergebnisse naheliegend. Ein weiteres Problem dieser Methode ist neben der Subjektivität, dass Experten meist Mitglieder eines Entwicklungsteams sind und für die Dauer der Schätzung nicht produktiv zum Entwicklungsprozess beitragen können.

Bei der Delphi-Methode stellt ein Moderator zu Beginn mehreren Experten Details der zu schätzenden User Stories vor, die sie anschließend völlig unabhängig voneinander schätzen. Danach wertet der Moderator die Ergebnisse aus und präsentiert die Abweichungen. Diskussionen sind dabei unerwünscht, um eine Gruppendynamik durch dominante Experten zu vermeiden. Jeder Experte hat die Möglichkeit, seine Schätzung zu überdenken und gegebenenfalls zu verändern. Dieser Prozess wird so lange wiederholt, bis die Abweichungen eine Toleranzschwelle nicht mehr überschreiten. Ein Vorteil der Delphi-Methode liegt in der iterativen Verfeinerung der einzelnen Expertenschätzungen und der damit verbundenen meist höheren Genauigkeit. Ein Nachteil ist die noch größere zeitliche Bindung der Experten.

Alternativen:

• Indirekte Schätzungen mit Story Points
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Agile Prinzipien sind Methoden zur Risikominderung

Viele Risiken kommerzieller Softwareentwicklung können durch agile Prinzipien gemindert werden:

Risiko: Die Anforderungen des Auftraggebers werden nicht ausreichend abgedeckt. Seine Erwartungen beispielsweise an die Gebrauchstauglichkeit des Produkts werden nicht vollständig erfüllt.
Maßnahmen: Das geplante Produkt wird inkrementell entwickelt, das heißt in möglichst kurzen Zyklen, deren Ergebnis jeweils lauffähige Software ist, die vom Auftraggeber hinsichtlich der Erfüllung seiner Erwartungen überprüft werden kann. Der Auftraggeber, insbesondere seine fachlichen und technischen Experten, arbeiten eng und intensiv mit dem Entwicklungsteam zusammen.

Risiko: Ziele und Anforderungen des Auftraggebers verändern sich, bevor die Entwicklung abgeschlossen ist, beispielsweise infolge von Veränderungen des Marktes.
Maßnahmen: Ein Prinzip des Agilen Manifests lautet: "Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden." Agile Softwareentwicklung zeichnet sich grundsätzlich durch die Bereitschaft aus, neue oder geänderte Anforderungen zu berücksichtigen. Jedoch schließt dies nicht eine Einigung zwischen Vertragspartnern bezüglich der kaufmännischen Auswirkungen von Veränderungen auf ein Entwicklungsprojekt aus.

Risiken: Falsche Einschätzung des Entwicklungsfortschritts, Verzögerungen durch Kommunikationsprobleme, Verlust von Know-how durch Personalausfall.
Maßnahmen: Diese Risiken werden in der agilen Entwicklung durch ein hohes Maß an Teamarbeit gemindert. Tägliche kurze Meetings dienen der Diskussion aufgetretener Probleme, der gemeinsamen Einschätzung des Fortschritts und der Verteilung anstehender sowie, falls es sinnvoll erscheint, auch der Umverteilung begonnener Aufgaben. Die Vermeidung starrer Rollen- und Aufgabenzuordnungen macht das Team robust gegenüber dem Ausfall einzelner Mitglieder.

Risiko: Mehraufwand durch zu spät erkannte Qualitätsdefizite.
Maßnahmen: Ein Merkmal agiler Entwicklung sind automatisierte Prozesse zur täglichen Neuerstellung einer lauffähigen Anwendung. Dabei durchläuft der Code in der Regel eine automatisierte Codeanalyse, durch programmierte Komponententests wird die Funktionalität einzelner Komponenten überprüft und, soweit möglich, werden nach der Integration zu einer lauffähigen Anwendung Skripte zur Ausführung von Testfällen aufgerufen.

Risiko: Invalide Planung hinsichtlich des erforderlichen Personalaufwands, um den Entwicklungsauftrag in der notwendigen Zeit erfüllen zu können.
Maßnahmen: Diesem Risiko kann durch die Verwendung von Aufwandsschätzmethoden begegnet werden, deren Genauigkeit sich mit jeder Retrospektive verbessert. Solche Methoden werden in meinem Buch "Aufwandsschätzungen in der agilen Softwareentwicklung" beschrieben.

Wann ist Softwareentwicklung agil?

Die folgenden Eigenschaften kennzeichnen agile Softwareentwicklung:

• Teile des Systems werden zu verschiedenen Zeiten entwickelt und das System jeweils um die fertig gestellten Teile erweitert (inkrementelle Entwicklung).
• Fehlerursachenanalysen und Messungen werden benutzt, um Verbesserungen herbeizuführen (Lernfähigkeit des Teams wie auch der Organisation).
• Alle Beteiligten arbeiten eng und direkt zusammen, beispielsweise durch ein hohes Maß an Teamarbeit oder eine stetige Mitarbeit des Auftraggebers bzw. Produktverantwortlichen.

Diese Eigenschaften sind mit ingenieurmäßigem Vorgehen wie auch mit industrieller Softwareentwicklung völlig vereinbar.

Tatsächlich gibt es Modelle zur agilen Softwareentwicklung bereits seit Anfang der 90er Jahre. Sie folgen ebenfalls Prozessen und sind aufgrund der meist kurzen Entwicklungszyklen (Sprints) noch stärker auf Messungen beispielsweise von Projektfortschritt, Codequalität, Testabdeckung, usw. und eine schnelle Rückkopplung zu den Entwicklern angewiesen.

Softwareentwicklung mit Methoden der industriellen Produktion

Methoden der industriellen Produktion können eine Antwort sein auf 

• die zunehmende Komplexität von Anforderungen,
• kürzer werdende Entwicklungszeiten und
• steigenden Kostendruck.

Dabei geht es in der Softwareentwicklung weniger um die Serienfertigung eines immer gleichen Produktes als um folgende Aspekte:

• Standardisierung von System- und Anwendungsarchitekturen
• Wiederverwendung von Komponenten
• Automatisierung von Entwicklungs- und Qualitätssicherungsprozessen
• Messbarkeit von Leistung und Ergebnisqualität

Während für die Softwareentwicklung heute zahlreiche Standards, Konzepte zur Wiederverwendung und Werkzeuge zur Automatisierung zur Verfügung stehen und in vielen Unternehmen auch etabliert sind wird das Messen entweder völlig vernachlässigt oder durch Schätzen ersetzt. Dabei sind präzise und regelmäßige Messungen der Produktivität eine wichtige Grundlage dafür, den Aufwand für anstehende Entwicklungsvorhaben schnell und verlässlich zu ermitteln (siehe auch Messung der Produktivität in der Softwareentwicklung).

Die Bedeutung von Prozessen in der kommerziellen Softwareentwicklung

Prozesse geben Verfahrenssicherheit durch festgelegte Arbeitsabläufe und sind Teil der organisatorischen QS. Ich behaupte: Eine kommerzielle Softwareentwicklung kann ohne Prozesse nicht erfolgreich sein.

Dabei folgen auch agile Vorgehensmodelle wie Scrum ihren eigenen Prozessen. Sie basieren auf einer Ablauf- und Terminplanung, die sich gegenüber „schwergewichtigeren“ Vorgehensmodellen durch kürzere Lieferzyklen (Sprints) auszeichnet. Umgekehrt sind die meisten (nicht-agilen) Vorgehensmodelle ebenfalls in der Lage, mit kurzfristigen Änderungen der Projektziele und Anforderungen umzugehen.

Die Welt der Prozessmodelle ist also keinesfalls polarisiert in agiles Vorgehen versus Ableger des klassischen Wasserfallmodells. Vielmehr unterscheiden sich die verschiedenen Vorgehensmodelle nur in der Explizitheit ihrer Prozessdefinitionen, der Flexibilität, mit der Prozesse und Methoden an unterschiedliche Rahmenbedingungen angepasst werden können und der Bedeutung, die der Einhaltung von Prozessen gegenüber menschlichen Interaktionen oder Änderungen zukommt.

Eine größere Bedeutung als die Prozesse selbst hat nach meiner Erfahrung die Festlegung von Quality Gates, durch die eine vorhersagbare Ergebnisqualität im Eingang oder Ausgang eines Prozesses, einer Iteration oder einer Projektphase festgelegt wird. Quality Gates werden durch Prüfungen (Testmethoden oder auch Schwellenwerte für Metriken) und Erfolgskriterien definiert, die ein Testobjekt erfüllen muss, damit das „Gate“ durchschritten werden darf, so dass das Ergebnis verwendet bzw. an den nachfolgenden Entwicklungsschritt übergeben werden kann. Zu Beginn eines Entwicklungszyklus kann so eine Prüfung der Anforderungen auf Konformität mit den verfolgten Zielen, Realisierbarkeit, Vollständigkeit, Konsistenz, usw. vorgeschrieben sein, deren Sinnhaftigkeit keine Frage von leicht- oder schwergewichtigen oder agilen Vorgehensmodellen ist.