Kooperative agile Aufwandsschätzung mittels der Planning Poker Methode

Inhaltsverzeichnis

Kurzfassung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation, Problemstellung und Ziel der Arbeit
1.2 Aufbau der Masterarbeit

2 Aufwandschätzungen in der agilen Softwareentwicklung
2.1 Agiles Projektmanagement
2.2 Grundlagen der Aufwandschätzung
2.3 Auswahl einer Schätzmethode im agilen Kontext
2.4 Individuelle und kooperative Expertenschätzungen
2.5 Zusammenfassung

3 Planning Poker Verfahren
3.1 Vorphase: Definition des Backlogs
3.2 Planning Poker Prozessbeschreibung
3.3 Planning Poker Party
3.4 Empirische Prozessüberwachung und Optimierung des Schätzverfahrens
3.5 Effektivität und Ankerheuristik
3.6 Zusammenfassung

4 Weiterentwicklung des Planning Pokers
4.1 Vorsortierung der User Stories. Estimation Board
4.2 Optimierte Konsensbildung durch Intervallschätzungen
4.3 Zusammenfassung

5 Implementierung eines Anwendungsprototyps
5.1 Verteilte agile Entwicklung
5.2 Anforderungen an die Funktionalität
5.3 Auswahl der Entwicklungsplattform
5.4 Iteration Zero. Aufwandschätzung und Iterationsplanung
5.5 Datenmodel des Anwendungsprototyps
5.6 Bedienkonzept des Prototyps
5.7 Struktur und Programmfluss
5.8 Analyse des Zeitaufwands und Zusammenfassung

6 Schlussbetrachtung

Anhang A: Mind-Map Diagramm (Abschnitt 2.2)

Anhang B: Standard-Delphi Methode (Ablauf)

Anhang C: Breitband-Delphi Methode (Ablauf)

Anhang D: Datenmodel des Planning Poker Prototyps

Anhang E: Formular <sitzungen verwalten>

Anhang F: Formular <arbeitsplatz_scrum_master>

Anhang G: Formular <arbeitsplatz_experte>

Anhang H: Objektdiagramm und Sequenzdiagramm

Anhang I: CD-ROM mit Planning Poker Prototyp

Literaturverzeichnis

Versicherung

Kurzfassung

Gegenstand der vorliegenden Masterarbeit ist die Effektivitätsanalyse der Planning Poker Methode für kooperative agile Aufwandschätzungen der Software-Entwicklungsprojekte. Im Rahmen der Arbeit werden Anforderungen an die agile Aufwandsschätzung systematisch formuliert. Auf dieser Basis werden Grundabläufe und Eigenschaften des Planning Poker Verfahrens beschrieben und bewertet. Es werden dabei Erkenntnisse der existierenden empirischen Studien verwendet. Anschließend werden Verbesserungsvorschläge erarbeitet, die sowohl Organisation als auch Inhalt des Schätzprozesses betreffen. Zur Unterstützung des Planning Poker Verfahrens in einer räumlich verteilten agilen Entwicklung wird ein funktionsfähiger Anwendungsprototyp konzipiert und implementiert.

Schlagwörter: Aufwandsschätzung, Planning Poker, Scrum Poker, User Stories, agile Software-Entwicklung, agiles Projektmanagement.

Abbildungsverzeichnis

Abbildung 1: Entwicklung der Änderungskosten im Laufe eines Projekts

Abbildung 2: Iterativer Managementprozess optimiert Projektkosten

Abbildung 3: Veränderungen im Laufe eines Software-Entwicklungsprojekts

Abbildung 4: Kegel der Ungewissheit

Abbildung 5: Aufwandsschätzung als Wahrscheinlichkeitsverteilung

Abbildung 6: Applikation und Ihre Umgebung nach der Function-Point-Analyse

Abbildung 7: Verbreitung der Schätzmethoden

Abbildung 8: Konvergenz der Expertenmeinungen (Delphi)

Abbildung 9: Übersicht der wichtigsten kooperativen Expertenschätzungen

Abbildung 10: Planning Poker Party

Abbildung 11: Tatsächliche Teamproduktivität der ersten Iterationen

Abbildung 12: Schätzgenauigkeit der relativen Aufwandsschätzungen.

Abbildung 13: Suche nach einer Konsenslösung

Abbildung 14: Tabellenverknüpfungs-Manager in Microsoft Access

Abbildung 15 Start-Formular des Prototyps

Abbildung 16 Formular <mitarbeiter>

Tabellenverzeichnis

Tabelle 1: Bewertung der Function-Point-Methode

Tabelle 2: Bewertung der Expertenschätzungen

Tabelle 3: INVEST-Eigenschaften einer User Story

Tabelle 4: T-Shirt-Sizing

Tabelle 5: Lösungen des Planning Pokers für die allgemeinen Schätzprobleme

Tabelle 6: Zentrale Tendenz der Schätzung (Fibonacci Skala vs. lineare Skala)

Tabelle 7: T-Shirt-Sizing für das Planning Poker Tool

Tabelle 8 Vorteile und Nachteile der Microsoft Access 2013 Entwicklungsplattform

Tabelle 9: Aufwandsschätzung für die Prototypentwicklung

Tabelle 10: Initiale Iterationsplanung für die Prototypentwicklung

Tabelle 11: Tatsächlicher Verlauf der Prototypentwicklung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

„Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“

Agiles Manifest (1)

1.1 Motivation, Problemstellung und Ziel der Arbeit

Das Thema Aufwandschätzung ist für jedes IT-Unternehmen überlebenswichtig. Die Aufwandschätzung beantwortet zwei grundsätzliche Fragen der Projektplanung:

- Wie umfangreich ist das Projekt?
- Wie kostenintensiv ist das Projekt für das Unternehmen?

Nur auf Basis der Aufwandschätzung ist es möglich rechtzeitig zu erkennen, ob ein Projekt innerhalb der vorgegebenen Frist und im Rahmen des geplanten Budgets zum Ziel gebracht werden kann (2).

Die Aufwandsschätzung gehört zu einer der Hauptaufgaben des Projektmanagements. Im IT-Projektmanagement ist das Problem der zuverlässigen Aufwandsschätzung besonders aktuell, weil der Projekterfolg von sehr vielen technischen und ökonomischen Faktoren abhängt.

Laut einer Studie der Standish Group aus dem Jahr 1994 überschritt jedes zweite Software-Projekt sein Budget um mehr als 100% (3). Eine spätere Studie (4) zeigt, dass bei einem Viertel aller Software-Projekte das vorgegebene Budget um 50% überzogen wird. Als Hauptgründe für die starken Budgetüberziehungen wurden vor allem nicht präzise Vorkalkulationen, Konflikte mit anderen Projekten sowie nicht geplante Erweiterungen des Projektumfangs genannt. Eine weitere Untersuchung der Universität Oxford und des Beratungshauses McKinsey betrachtete etwa 1500 Software-Projekte mit dem durchschnittlichen Umfang in Höhe von 170 Mio. US-Dollar. Diese Studie hat folgende Ergebnisse erzielt (5):

- Software-Projekte sind allgemein hochriskant und das Risiko ist mittels der existierenden Methoden kaum prognostizierbar;
- In mehr als drei Viertel aller Projekte werden die Plan-Kosten um nicht mehr als 27 % überschritten;
- Jedes sechste Projekt kostet durchschnittlich doppelt so viel wie geplant. Die Ursachen dafür sind zu optimistische Projektplanung und mangelhaftes Management.

Wie die vorgestellten Studien feststellen, spielen Effektivität und Weiterentwicklung der Aufwandsschätzung beim Einhalten des Projektkostenplans eine entscheidende Rolle. Die rasche Entwicklung des Software Engineerings (neue Programmiertechniken und Methoden, moderne Entwicklungsumgebungen, neue flexible Konzepte des Projektmanagements) in den letzten 20 Jahren hat die Effektivität des IT-Kostenmanagements deutlich verbessert. Allerdings bleibt das Problem der wesentlichen Budgetüberziehung bei ca. 20-25 % der Software-Projekte immer noch aktuell.

Die existierenden Methoden der Aufwandschätzung haben eine mehrjährige Entwicklungsgeschichte hinter sich. Sie sind meistens in der Lage Komplexität der Projektanforderungen sowie Besonderheiten der technischen Prozesse und Implementierungsmethoden genau zu ermitteln (6). Potenzielle Reserven für die Verbesserung der Aufwandschätzung können in den Bereichen Management (vor allem Organisation der Aufwandsschätzung) und Kommunikationen (innerhalb des Entwicklungsteams und mit dem Kunden) liegen (7).

Barry W. Boehm, einer der bekanntesten Forscher im Bereich IT-Kostenmanagement, hat bereits im Jahr 1981 festgestellt:„Poor management can increase software costs more rapidly than any other factor“(8).

Chuck Tonies hat im Jahr 1979 ein 3-Faktoren-Model der Effektivität einer IT-Organisation vorgeschlagen (7):

Formel 1

mit den folgenden Parametern (Organisationskompetenzen):

– Effektivität;
– Technische Kompetenz einer IT-Organisation;
– Kommunikative Kompetenz einer IT-Organisation;
– Management- Kompetenz einer IT-Organisation.

Die Organisationskompetenzen werden als Werte in einem Intervall von 0 („sehr schlecht“) bis 1 („sehr gut“) geschätzt. Wenn eine der Organisationskompetenzen mit 0 bewertet wird, wird die gesamte Organisationseffektivität trotz aller anderen Kompetenzen gleich 0 sein. Unter anderem betont Chuck Tonies mit diesem Model die Bedeutung der nicht technischen Kompetenzen eines IT-Unternehmens.

Dr. Randall W. Jensen stellt in seiner Arbeit (7) fest, dass die traditionellen Methoden der Aufwandschätzung sich hauptsächlich auf die technischen Aspekte der Softwareentwicklung fokussieren. Die wirtschaftlichen und sozialen Aspekte (Organisation, Motivation, Kommunikationen, Koordination, Teamarbeit) werden oft überhaupt nicht berücksichtigt. Somit bleibt die herkömmliche Aufwandschätzung eindimensional und zwar projektorientiert. Die moderne Aufwandsschätzung sollte nach Dr. Randall W. Jensen mehrdimensional, d.h. projekt-, organisations- und teamorientiert sein. Somit entspricht die Aufwandschätzung als Instrument des IT-Managements dem allgemeinen Trend. Dieser Trend ist im Rahmen des klassischen Managements als Entwicklung von der Theorie X zu der Theorie Y bekannt. Die beiden benannten Theorien sind die von Douglas McGregor formulierten entgegengesetzten Konzepte des Managements.

Laut der Theorie X sind Struktur und Prozesse einer Organisation fest definiert. Die Mitarbeiter sollen sich an die Struktur und Prozesse anpassen. Somit ist der Kommunikationsaufwand innerhalb einer Organisation durch die Standardisierung der Prozesse minimiert. Der Informationsfluss ist sehr zentralisiert und deshalb leicht verletzbar. Dieser funktioniert nur in Richtung entlang der Hierarchie nach unten akzeptierbar schnell. Die Änderungen in einer solchen Organisation werden ebenfalls von den oberen Hierarchieebenen nach unten durchgeführt. Da die Organisationsstruktur häufig viele Hierarchieebenen hat, dauert der Änderungsprozess in der Regel relativ lang. Dadurch ist die Organisation auch für Änderungen der Umgebung und Risiken sehr empfindlich.

Aus der Sicht der Theorie Y soll eine Organisation dynamisch und flexibel sein. Die Prozesse und Struktur werden von den Mitarbeitern an die aktuellen Anforderungen angepasst. Dies wird dadurch erreicht, dass der Informationsfluss und das Management verteilt organisiert sind. Die Anforderungen an die Mitarbeiter sind allerding sehr hoch: Sie sollen kreativ, kompetent, initiativ und kommunikationsfähig sein. Sind die beschriebenen Fähigkeiten nicht vorhanden, scheitern daran die komplexen dezentralisierten Organisationsprozesse.

Es ist wichtig zu erwähnen, dass die Theorie X für das Management der relativ einfachen und stabilen Prozesse sehr effektiv und effizient funktioniert. Die komplexeren und anfänglich nicht klar definierten Prozesse (wie z.B. große riskante IT-Entwicklungsprojekte) werden nach den flexiblen Prinzipien der Theorie Y besser gesteuert.

Mehr Flexibilität ist auch eine aktuelle Tendenz des modernen IT-Projektmanagements. Das populäre agile Management-Konzept (extreme Programmierung, Scrum) kann als Einsatz der Theorie Y auf einer niedrigeren Abstraktionsebene interpretiert werden. In diesem Sinne sind die agilen Methoden eine natürliche dialektische Weiterentwicklung des traditionellen Wasserfall-Entwicklungsmodels mit seinen fest definierten Prozessphasen, die sehr an die Theorie X erinnern. Als Zwischenschritt dieser Entwicklung kann das Spiralmodell von Barry W. Boehm betrachtet werden, das einerseits das Wasserfall-Model modernisiert und andererseits auch Elemente der agilen Methoden (iterative Prozesse, das Prototyping) beinhaltet.

Die Anforderungen an mehr Agilität werden immer häufiger durch die Praxis der IT-Entwicklung gestellt. Neue technische Paradigmen, Methoden und Werkzeuge des Software Engineerings systematisieren und beschleunigen den Entwicklungsprozess, fordern allerdings gleichzeitig von den Entwicklern und Managern neue Fähigkeiten und Qualifikationen. IT-Aufgaben werden technisch gesehen immer komplexer und vielseitiger. Diese Aufgaben können oft nur durch die enge Kooperation und ständige Kommunikationen zwischen den Experten unterschiedlicher Fachgebiete erledigt werden. Somit werden Effektivität der Kommunikationen und Kooperationskompetenz des Personals zu den Hauptfaktoren, die Projektkosten und Projekterfolg bestimmen.

Die oben beschriebene Tendenz wird von einer Reihe von aktuellen wirtschaftlichen Trends der IT-Branche verstärkt (9):

1) Steigender Konkurrenzdruck;
2) Offshoring und Outsourcing;
3) Spezialisierung und Kooperation;
4) Diversifikation und Fusionierung.

Effiziente Kooperationen und Kommunikationen minimieren Unternehmensrisiken und Kosten. Wie sollen die Aufwandschätzungsmethoden geändert werden, um den Anforderungen der agilen Konzeption zu entsprechen? Diese Frage hat die vorliegende Masterarbeit motiviert.

In der letzten Zeit hat sich die Methode namens Planning Poker (oder auch Scrum Poker) als in der Praxis oft verwendetes, einfaches Verfahren für die agile Aufwandsschätzung in den frühen Projektphasen etabliert (9). Die Analyse der Effektivität und Effizienz des Planning Pokers stellt das Ziel dieser Masterarbeit dar.

Im Laufe der Arbeit werden folgende Kernfragen erläutert:

1) Was sind die Aufgaben und Effektivitätskriterien der agilen Aufwandsschätzung?
2) Wie soll die agile Aufwandschätzung organisiert werden?
3) Gibt es empirische Nachweise über die Effektivität der Planning Poker Methode?
4) Wie kann das Planning Poker Verfahren die agilen Anforderungen erfüllen?
5) Wie kann das Plannig Poker verbessert werden?

Im abschließenden praktischen Teil der Arbeit werden die Konzeption und die Implementierung eines Planning Poker Anwendungsprototyps vorgestellt.

1.2 Aufbau der Masterarbeit

In Kapitel 2 werden Grundlagen des agilen Entwicklungsmodells und allgemeine Konzepte der Aufwandsschatzung erläutert. Ferner werden agile Effektivitätskriterien bzgl. der Aufwandsschätzung formuliert. Somit wird die Basis für eine kritische Betrachtung der Planning Poker Methode aufgebaut.

Kapitel 3 beginnt mit der Prozessbeschreibung des Planning Poker Verfahrens. Danach werden agile Aspekte des Planing Pokers genauer analysiert. Abschließend wird auf das Thema Effizienz der Planing Poker Methode eingegangen.

In Kapitel 4 werden mögliche methodische Verbesserungen des Planning Pokers beschrieben.

Kapitel 5 befasst sich mit Konzipierung, Planung und Realisierung eines Anwendungsprototyps, der Workflows des Planning Pokers unterstützt. Dabei werden einige Elemente der agilen Planung verwendet.

Die im Laufe der Masterarbeit erzielten Ergebnisse werden in Kapitel 6 zusammengefasst.

2 Aufwandschätzungen in der agilen Softwareentwicklung

„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“

Agiles Manifest (1)

2.1 Agiles Projektmanagement

Agile Modelle, die seit Ende der 1990er Jahre im Software Engineering aktiv diskutiert und umgesetzt werden, haben das Ziel, Qualität, Transparenz und Steuerbarkeit der Software-Entwicklung zu verbessern (10). Zu einer der bekanntesten agilen Methoden zählt die Scrum Methode, die die Software Engineering Disziplinen Projekt-Management und Requirements-Management besonders konsequent und vollständig unterstützt (11). Im Rahmen dieser Masterarbeit werden zentrale Prinzipien des agilen Managements auf Basis des Scrum-Verfahrens zusammengefasst. Diese Prinzipien sind für die meisten agilen Methoden relevant.

Bei Scrum wird angenommen, dass Software Projektanforderungen und deren Umsetzung so umfangreich und kompliziert sind, dass eine komplette detaillierte Projektplanung im Vorfeld grundsätzlich nicht möglich ist. Nur durch die Selbstorganisation und permanente Kommunikationen innerhalb eines Projektteams ist das effektive Projektmanagement realisierbar.

Zentrale Ideen des agilen Verfahrens sind in einem konzeptuellen Dokument namens Agiles Manifest (1) wie folgt formuliert:

1) Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge;
2) Funktionierende Software ist wichtiger als umfassende Dokumentation;
3) Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung;
4) Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans;

Die Verfasser haben explizit betont, dass die unterstrichenen Werte für die IT-Entwicklung ebenfalls bedeutend sind.

Das agile IT-Management basiert auf der systematischen Verwendung der folgenden Techniken (3):

1) Desaggregation des gesamten Projektablaufs auf kleine Iterationen (Sprints nach der Scrum-Terminologie). Jeder Sprint wird separat geplant, implementiert, getestet und durch den Kunden abgenommen. Die Vorgehensweise ist evolutionär: Zwei aufeinander folgende Sprints (Sprint-Intervall beträgt in der Regel 2 bis 4 Wochen) unterscheiden sich relativ gering. Am Ende jeder Iteration wird ein funktionsfähiges Teilprodukt ausgeliefert;
2) Die Projektplanung (Planning Game genannt) erfolgt auf zwei Ebenen: Grobe Produkt- bzw. Release-Planung und feine korrigierende Iterationsplanung. Die Anforderungen werden vom Kunden (Product Owner) in Form sogenannter User Stories definiert und mit Prioritäten versehen. Die User Stories werden in einem Dokument namens Product Backlog (für eine Produkt-Planung) bzw. Sprint Backlog (für eine Iterationsplanung) zusammengefasst. Ferner wird eine Aufwandschätzung der User Stories durchgeführt. Anhand der Aufwandschätzung wird entschieden, welche User Stories in Rahmen welcher Iteration zu realisieren sind;
3) Für jede User Story wird ein Test-Prozess definiert. Erst dann kann mit der Realisierung angefangen werden. Der Kunde definiert fachliche Test-Fälle, mit denen die Funktionalität überprüft werden kann. Technische Test-Fälle werden von den Entwicklern definiert und durchgeführt. Alle Änderungen der Funktionalität oder der technischen Umsetzung erfordern das neue Testen;
4) Der Kunde steht im Mittelpunkt des Prozesses. Er ist permanent in alle Management-Prozesse involviert und sorgt sich genauso wie das ganze Projektteam um den Projekterfolg;
5) Der agile Implementierungsprozess funktioniert ebenfalls evolutionär. Es wird immer die einfachste Lösung zum Implementieren ausgewählt, damit das gewünschte Ergebnis am schnellsten erreicht wird. Danach wird die Qualität der Lösung mittels der modernen Programmiermethoden (Refactoring) permanent verbessert. Der Programmcode ist durch die Verwendung der fest definierten Programmierrichtlinien für jeden Entwickler im Team selbsterklärend. Damit kann auf die aufwändige Erstellung und Pflege der Projektdokumentation verzichtet werden.

Die agile Software-Entwicklung ist ein flexibles leichtgewichtiges Konzept, das auf intensive Kommunikationen und kollektives verteiltes Wissen Akzente setzt. Am effektivsten funktioniert das Konzept, wenn ein Entwicklungsteam aus maximal 7-10 Personen besteht, ansonsten wird der Kommunikationsaufwand deutlich steigen (12) (10).

Zu den wesentlichen Vorteilen der Agilität gehört die Minimierung der Kosten, welche mit Anforderungsänderungen verbunden sind. Abbildung 1 zeigt eine typische Entwicklung der Änderungskosten in der traditionellen und agilen Software-Entwicklung (das Wasserfall-Model und das Scrum-Model).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Entwicklung der Änderungskosten im Laufe eines Projekts^[1]

Die Änderungskosten in der traditionellen Software-Entwicklung wachsen exponentiell von einer Projektphase zur nächsten, da die Anforderungsänderungen wesentliche Korrekturen in allen bereits beendeten Projektphasen verursachen können. Die agilen Anforderungen werden iterativ und in kleineren Teilen formuliert und umgesetzt. Die einzelnen Teile (User Stories) sollen möglichst unabhängig voneinander definiert werden (auf dieses Thema wird in Kapitel 3 näher eingegangen). Daher ist im idealen Fall lediglich eine Iteration des agilen Projekts von den Änderungen betroffen. Die Entwicklung der Änderungskosten wird deswegen deutlich flacher sein.

Eine weitere Stärke des agilen Projektmanagements ist die rechtzeitige Erkennung der überflüssigen Anforderungen. Da die User Stories in kleinen Iterationen umgesetzt werden, kann es theoretisch passieren, dass der zu erwartende Mehrwert bereits vor den letzten eingeplanten Iterationen erreicht wird. Der iterative Prozess wird dann vom Product Owner operativ (effektive Kommunikation vorausgesetzt) erfolgreich abgeschlossen. Damit wird das Ziel mit den minimierten Kosten erreicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Iterativer Managementprozess optimiert Projektkosten^[2]

Abbildung 2 illustriert den oben beschriebenen Fall: Wenn die User Stories 1 und 2 im Rahmen des ersten Sprints durchgeführt werden, wird das Entwicklungsziel bereits im Punkt A erreicht. Somit wird der zweite Sprint mit der User Story 3 überhaupt nicht nötig sein. Bei der traditionellen Entwicklung wird das Ziel nur im Punkt B mit den höheren Kosten erreicht, da das komplette Paket mit allen User Stories nach der Anforderungsanalyse in die Projektphase Realisierung übergeben wird.

Eine weitere positive Eigenschaft des agilen Managements ist die empirische Prozessüberwachung (12). Die nach dem Abschluss jedes einzelnen Sprints neu gewonnenen Erkenntnisse können für die Korrektur des gesamten Entwicklungsprozesses verwendet werden. Alle agilen Managementprozeduren (und unter anderem auch die Aufwandsschätzung) verbessern sich permanent mit jeder einzelnen Iteration durch die gesammelte Projekterfahrung.

Es ist wichtig an dieser Stelle zu erwähnen, dass Wirksamkeit und Effektivität der agilen Methoden nur durch die praktische Umsetzung nachweisbar sind. Zum heutigen Zeitpunkt sind sich die Analysten im Bereich IT-Management noch nicht einig, ob das agile Management bereits jetzt als etabliert gelten kann. Es sollte noch ungefähr 5 bis 10 Jahre dauern, bis die praktische Effektivität der agilen Methoden allseits anerkannt wird (11). Eins ist allerdings bereits heute klar: Sowohl technische (vor allem Unit-Testen, Refactoring, Entwurfsmuster) als auch wirtschaftliche Elemente (empirische Prozessüberwachung, Einsatz der User Stories im Anforderungsmanagement) des agilen Paradigmas finden in der Theorie und Praxis der Software-Entwicklung immer häufiger Verwendung.

2.2 Grundlagen der Aufwandschätzung

In der Praxis wird die Aufwandschätzung oft mit den anderen Aufgaben des Projektmanagements (Budgetierung, Erstellung der Angebotskalkulation, Planung) verwechselt bzw. vermischt. Im Gegensatz zu den anderen o.g. Aufgaben betrachtet die Aufwandschätzung nur das Schätzobjekt (ein Software-Entwicklungsprojekt) unabhängig vom vorgegebenen Budget bzw. vom vordefinierten Abgabetermin.

Ein grobes Basis-Modell der Aufwandschätzung lässt sich mit den folgenden Formeln ausdrücken (vgl. (2)):

Formel 2

Die Aufgaben der Aufwandsschätzung sind den Projektumfang und die Teamproduktivität möglichst korrekt zu berechnen. Existierende Schätzmethoden unterscheiden sich grundsätzlich nach Art und Weise, wie sie diese zwei Parameter ermitteln.

Die Teamproduktivität ist ein komplexer qualitativer Faktor, der sowohl technische (Entwicklungsumgebung, technische Infrastruktur, technisches Know-how) als auch betriebswirtschaftliche Komponenten (Kommunikationen und Management in einer Organisation) beinhaltet. In der Regel lässt sich die Produktivität eines Entwicklungsteams kurzfristig nicht deutlich erhöhen, auch wenn neue Experten ins Projekt involviert werden können (12). Daher ist es denkbar, dass die Leistungen im vollen Umfang zu einem gewünschten Termin nicht lieferbar sind. Die Aufgabe. den Projektumfang und die Projektdauer in Einklang zu bringen, wird von der Projektplanung übernommen. Gegebenenfalls können dabei einige Funktionalitäten (Projektmenge) bzw. Qualitätsanforderungen nach Absprache mit dem Auftraggeber gestrichen werden. Das beschriebene Dilemma wird in der Fachliteratur als Teufelsquadrat von Harry Sneed bezeichnet (2).

Das Ziel der Angebotskalkulation ist die Begründung des Projektpreises. Beim Preiskalkulieren werden nicht nur die geschätzten Projektkosten, sondern auch andere kaufmännische Faktoren (Marktsituation, Konkurrenz, Strategie, Kunde) berücksichtigt. Werden die Projektkosten überschätzt, kann das zu einem zu hoch kalkulierten Angebotspreis und sogar zum Verlust der Beauftragung führen. Die Kostenunterschätzung kann nicht selten finanzielle Verluste zur Folge haben.

Spricht man über die Budgetierung, ist damit die Limitierung der in einem Projekt bzw. in einem Teilprojekt verfügbaren wirtschaftlichen Ressourcen gemeint. Dabei können sich die verfügbaren Ressourcen von den ermittelten benötigten Ressourcen (oder anders ausgedrückt vom geschätzten Aufwand) wesentlich unterscheiden.

Steve McConnell hat eine effektive Aufwandschätzung wie folgt definiert: „Eine gute Aufwandschätzung ist eine Schätzung, die einen Blick auf das Projekt ermöglicht , der klar genug dafür ist, dass die Projektleitung gute Entscheidungen zur Steuerung des Projekts fällen kann, um so die Ziele des Projekts zu erreichen“ (6). Die Aufwandschätzung ist also dann effektiv, wenn sie alle zum Zeitpunkt der Schätzung relevanten Projektfaktoren und Risiken berücksichtigen kann.

Um die Qualität der durchgeführten Aufwandschätzung zu bewerten, ist es sinnvoll, die ermittelten Schätzwerte mit dem tatsächlich erzielten Ergebnis zu vergleichen. Zu diesem Zweck ist die Berechnung der relativen Fehlergröße (engl. magnitude of relative error oder MRE) hilfreich^[3]:

Formel 3

Abbildung 3 zeigt, dass die Abweichung gegenüber dem Ist-Aufwand (MRE) nicht immer als Effektivitätskriterium des Schätzverfahrens dienen kann: Das Projektergebnis kann von mehreren zum Zeitpunkt der Schätzung nicht vorhersehbaren Faktoren abhängig sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Veränderungen im Laufe eines Software-Entwicklungsprojekts^[4]

Im Beispiel sind der Schätzaufwand und der tatsächliche Aufwand absolut identisch (X Bearbeiter-Tage). Allerdings wurde der tatsächliche Projektaufwand von drei bei der Aufwandschätzung nicht erwarteten Ereignissen beeinflusst:

1) Anfangs ist einer der Projektexperten krankheitsbedingt ausgefallen. Das hat den Projektaufwand erhöht;
2) Es wurden bessere Konditionen mit einem Lieferanten vereinbart. In diesem Falle handelt es sich um eine gezielte Projektsteuerung, die den Projektaufwand minimiert;
3) Danach wurden einige wesentliche Anforderungen vom Kunden gestrichen. Dies führte logischerweise zur Aufwandsminderung.

Jede existierende Schätzmethode realisiert mindestens eine der folgenden grundlegenden Techniken:

[...]

---

^[1] vgl. (25) (10).

^[2] vgl. (10).

^[3] vgl. (15).

^[4] vgl. (6).