Festpreisprojekte mit agiler Softwareentwicklung nach Scrum

INHALTSVERZEICHNIS

1. Einleitung
1.1. Untersuchungsgegenstand der Hausarbeit
1.2. Thematische Abgrenzung

2. Kritische Erfolgsfaktoren im Projektmanagement

3. Charakteristik von Festpreisprojekten

4. Der Ansatz von Scrum
4.1. Scrum im Kurzüberblick
4.2. Das Agile Manifest
4.3. Die Rollen in Scrum
4.3.1. Product-Owner
4.3.2. Scrum-Master
4.3.3. Team

5. Planung von Softwareprojekten nach Scrum
5.1. Die Bedeutung der Produktvision
5.2. Der Anforderungsworkshops
5.3. Das Product-Backlog
5.4. Die Schätzklausuren
5.5. Ermittlung der Projektgesamtkosten und -dauer

6. Durchführung von Softwareprojekten nach Scrum
6.1. Die Sprintplanung
6.2. Das Planning
6.3. Der Sprint
6.4. Die Review
6.5. Die inkrementelle Softwareauslieferung
6.6. Die Abnahme durch den Kunden

7. Weitere Controllingwerkzeuge in Scrum
7.1. Retrospektive
7.2. Pflege des Product-Backlogs
7.3. Burndown-Chart
7.4. Impediment Backlog
7.5. Velocity

8. Zusammenfassung

Literaturverzeichnis

ABBILDUNGSVERZEICHNIS

Abbildung 1 - Wasserfallmodell (Ullmann, 2002)

Abbildung 2 - Scrum-Bierdeckel (it-agile GmbH)

Abbildung 3 - Scrum-Rollen (Holisticon AG)

1.Einleitung

1.1. Untersuchungsgegenstand der Hausarbeit

„This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions. 44% were challenged which are late, over budget, and/or with less than the required features and functions. 24% failed which are cancelled prior to completion or delivered and never used.“

(Johnson 2009)

Auch wenn in der heutigen Praxis die Herkunft und Validität der Zahlen der Standish Group von zahlreichen IT-Projektmanagern ernsthaft angezweifelt wird, so ist die signifikante Anzahl der gescheiterten IT-Projekte nicht weg zu diskutieren. In den vergangenen Jahren haben die Bedeutung und der Einsatz von agilen Techniken in der Softwareentwicklung deutlich zugenommen. Ziel der neuen Projektmanagementansätze ist die Überwindung wesentlicher Nachteile der klassischen Methoden und damit die Minimierung der Projektrisiken. Einer der wesentlichsten Nachteile ist die meist unzureichende Definition der einzelnen Leistungsanforderungen an die neue Software in der Angebotsphase. Sie wird häufig in der Praxis auf Grund von Zeit- und Kostendruck nicht ausreichend im Detail vollzogen. Und selbst wenn vor Produktionsbeginn ein abgestimmtes Lasten- und Pflichtenheft vorliegt, dann könnte das Produkt die wirklichen Bedürfnisse des Kunden in den seltensten Fällen abdecken, da der Kunde häufig seine Anforderungen erst im Laufe der Produktions- und Abnahmephase detailliert.

Eine der bedeutendsten agilen Methoden ist Scrum. Nach Scrum wird das auszuliefernde Produkt vor Produktionsbeginn nicht in seiner Gesamtheit konzipiert, sondern in seine Einzelfunktionen zerlegt. In den kurzen Arbeitszyklen, in denen die Einzelanforderungen funktionsfähig hergestellt werden, können Probleme frühzeitig aufgedeckt und mit entsprechenden Lösungsoptionen zeitnah gesteuert werden. Mit jedem Arbeitszyklus werden die erzielten Ergebnisse auf ihre ursprüngliche Anforderung und ihren definierten Mehrwert hin überprüft und neue Anforderungen abgeleitet und definiert.

Der Kunde ist in den gesamten Entwicklungsprozess intensiv einbezogen und kann das Produkt nach seinen Bedürfnissen stetig mitgestalten. So wächst das Produkt im Laufe des Entwicklungsprozesses inkrementell bis zur Abbildung des tatsächlich gewünschten Leistungsumfanges. Nach Scrum können aber die Gesamtherstellungskosten zum Projektbeginn nur schwer beziffert werden. Dennoch erwarten die Kunden in der Regel nicht nur die Lieferung der zugesicherten Leistungsmerkmale, sondern auch die Einhaltung des abgestimmten Budgets sowie Verlass auf einen verbindlichen Liefertermin.

Die Hausarbeit hat das Ziel, unter Berücksichtigung genereller IT-Projekt-Risiken in Ansätzen die Frage nach der Kompatibilität von Festpreisprojekten und Scrum in der Softwareentwicklung zu beantworten. Skizziert wird dafür ein möglicher Ablauf eines Scrumprojektes, dem ein Festpreisangebot zu Grunde liegt. Ermöglicht Scrum, richtig eingesetzt, unter Nutzung aller zur Verfügung gestellten Werkzeuge die Abgabe von validen Festpreisangeboten mit definierten Leistungsmerkmalen und der Nennung eines verbindlichen Liefertermins vor Produktionsbeginn?

1.2. Thematische Abgrenzung

Im Rahmen der Hausarbeit werden ausschließlich die Angebots-, Planungs-, Realisierungs- und Abnahmephase von Softwareprojekten berücksichtigt, wobei ein Softwareprojekt im weiteren Kontext als Festpreisprojekt verstanden wird, dessen Ziel die Entwicklung definierter Individualsoftware für einen Kunden ist. Vor bzw. nach gelagerte Projektphasen wie z. B. die Projektakquise, die Vertragsverhandlungen oder auch die Projektnachkalkulation haben keine wesentlichen Einflüsse auf den eigentlichen Untersuchungsgegenstand der Hausarbeit und werden nicht betrachtet.

Auf Besonderheiten von öffentlichen Ausschreibungsprojekten wird nicht eingegangen.

Es ist nicht Ziel der Hausarbeit, Scrum als Methode der agilen Softwareentwicklung vollumfänglich vorzustellen und zu bewerten, sondern auf Besonderheiten und Risiken in Verbindung mit Festpreisangeboten einzugehen.

2. Kritische Erfolgsfaktoren im Projektmanagement

Die Wahl eines geeigneten Projektmanagementansatzes allein ist kein Garant für den Erfolg von IT-Projekten, liefert er doch lediglich hilfreiche Instrumente zur Durchführung des Projektes. Das Wissen um die kritischen Erfolgsfaktoren im Projektmanagement in Verbindung mit zielorientierten Strategie- und Lösungsansätzen ist eine wesentliche Grundsäule für die erfolgreiche Durchführung von Softwareprojekten. „Kritische Erfolgsfaktoren (KEF) definieren die wichtigsten Elemente oder Handlungen, um Kontrolle über oder innerhalb eines bestimmten Prozesses zu erzielen. Sie sind in der Regel management-orientierte Vorgaben und identifizieren die wichtigsten strategischen, technischen, organisatorischen oder prozeduralen Aufgaben.“ (Wallmüller 2004: 87)

Die «Management Guidelines des COBIT-Framework» identifizierten und publizieren acht wesentliche Erfolgsfaktoren im IT-Projektmanagement, mit denen sich nahezu alle Softwareunternehmen in der Praxis immer wieder konfrontiert sehen. (vgl. Wallmüller 2004: 87-89) Das Management sollte sich diesen Erfolgsfaktoren immer wieder bewusst sein und sein Projektmanagement und die Unternehmensstrategie zielgerichtet darauf ausrichten.

KEF 1: Erfahrene und geschickte Projektleiter sind verfügbar. Oftmals werden aus Ressourcenmangel Mitarbeiter für die Position des Projektleiters eingesetzt, die das notwendige Anforderungsprofil nicht oder nur ansatzweise erfüllen. Der Projekterfolg hängt aber im Wesentlichen von den Hard- und Softskills des Projektleiters ab. Ebenso werden erfahrene Projektleiter häufig zeitgleich für mehrere Projekte eingesetzt. Durch die anhaltende Überlastung steigt die Risikoquote für Fehlentscheidungen. (vgl. Wallmüller 2004: 87-89)

KEF 2: Ein akzeptierter und standardisierter Projektmanagementprozess ist vorhanden. Der Projektmanagementprozess definiert den Overhead zur Initiierung, Planung, Organisation, Steuerung, Überwachung und Koordination eines Projektes. Trotz des Bewusstseins der Notwendigkeit eines definierten, im Unternehmen kommunizierten und vor allem gelebten Projektmanagementprozesses neigen viele Projektleiter und das Management zum Initiieren von Ausnahmeprozessen in besonders stressigen Projektphasen, aus der Annahme heraus, kostbare Projektzeit zu sparen. Die Mehrkosten auf Grund der fehlenden Einhaltung definierter Kommunikations- und Ablaufprozesse sind in der Regel um ein vielfaches höher als die kurzfristige Einsparung von Prozesszeiten. (vgl. Wallmüller 2004: 87-89)

KEF 3: Die Geschäftsleitung unterstützt die Projekte, und Auftraggeber wie Projektmitarbeiter kooperieren in der Definition, Implementierung und der Führung der Projekte. Ein großes Risiko liegt in dem Versuch der identischen Prozessabbildung innerhalb der neuen Softwarelösung. Oftmals geht ein fundiertes Prozessreengineering dem Anforderungsworkshop nicht voraus. Schlecht organisierte Prozesse werden als Basis für die Definition des Leistungsumfangs herangezogen. Die neu erstellte Softwarelösung wird somit den bestehenden Ablaufprozess nicht optimieren können. Die Unzufriedenheit des Kunden ist vorprogrammiert. (vgl. Wallmüller 2004: 87-89)

KEF 4: Ein Grundverständnis über die Fähigkeiten und Grenzen im Projektmanagement ist vorhanden. Entwicklungs- und Systemtestzeiten werden vom Management oftmals auf Grund mangelnder Erfahrung unterschätzt und bestehende Restriktionen in der Softwareentwicklung nicht wahrgenommen. So ist es nicht selten, dass dem Kunden gegenüber unrealistische Liefertermine und Leistungsmerkmale kommuniziert werden. Das Projekt kommt zwangsläufig in Zeitdruck, welcher meist durch die Reduzierung von Testdurchlaufzeiten oder dem Wegfall von zugesicherten Eigenschaften kompensiert werden soll. (vgl. Wallmüller 2004: 87-89)

KEF 5: Eine unternehmensweite Projektrisiko-Beurteilungsmethode ist definiert und durchgesetzt. Trotz der Häufigkeit des Scheiterns von IT- Projekten verfügen die meisten Unternehmen über keinen Projekt­Risikomanagementansatz. Auftretende Probleme und Prozessstörungen werden immer wieder neu analysiert und Lösungsansätze individuell erarbeitet. Wertvolle Projektzeit geht verloren und gegensteuernde Maßnahmen werden zu spät eingesetzt. (vgl. Wallmüller 2004: 87-89)

KEF 6: Jedes Projekt verfügt über einen Detailplan der Projekttätigkeiten, Aufwandsschätzungen, Mitarbeiter-Anforderungsprofile, Pendenzlisten und Qualitätspläne. Der Erfolg eines ziel ori enti erten Projektcontrollings ist im Wesentlichen abhängig von der Transparenz der notwendigen Informationen rund um den Entwicklungsprozess. Projektpläne werden oft schon kurz nach Beginn der Realisierungsphase nicht mehr fortlaufend aktualisiert, Pendenzlisten fehlen meist ganz. Die interne Projektrevision ist ohne aktuelle Daten und Informationen nicht zielorientiert durchführbar. Als Konsequenz wird das so genannte „aus dem Ruder laufen“ der Projekte erst wesentlich später bemerkt, als der eigentliche Eintritt. (vgl. Wallmüller 2004: 87-89)

KEF 7: Der Übergang von der Entwicklung in den Livebetrieb ist hinsichtlich des Ablaufs definiert. Häufig werden nach einer umfangreichen Betatestphase die Softwareprodukte in den Livebetrieb überführt ohne zu gewährleisten, das die direkt betroffenen und angrenzenden Bereiche ausreichend strukturiert, informiert und geschult wurden. Die Einführungsphase wird in zahlreichen Fällen als chaotisch wahrgenommen, welches oftmals auch von den anwendenden Mitarbeitern auf die Leistungsmerkmale der Software projiziert wird. Ein noch so gutes Produkt kann auf Grund einer misslungenen Einführungsphase bereits gescheitert sein. (vgl. Wallmüller 2004: 87-89)

KEF 8: Die Systementwicklungsmethode ist definiert und in der Praxis angewandt. Gerade in stressigen Projektphasen werden Projektteams oftmals durch weitere Ressourcen unterstütz. Die Konventionen für die Programmierung in einem Projekt sind zwar oft definiert und dokumentiert, werden allerdings im Laufe der Projektphase selten kontrolliert und neu kommuniziert. Je mehr Systementwickler an einem Projekt mitarbeiten, umso größer ist die Gefahr der Nutzung von unterschiedlichen Systementwicklungsmethoden, welche zu Inkompatibilitäten zwischen den einzelnen Modulen führen können. Auch entsteht oft der so genannte Spaghetticode, welcher zeit- und kostenaufwändig zu einem späteren Zeitpunkt einem Refactoring unterzogen werden muss. (vgl. Wallmüller 2004: 87-89)

3. Charakteristik von Festpreisprojekten

Besteht die Anforderung, dem Kunden schon vor Entwicklungsbeginn die konkreten Projektaufwände in einem verbindlichen Angebot zu übermitteln, spricht man in der Praxis von so genannten Festpreisprojekten. Neben den abrechenbaren Aufwänden sind in der Regel der Liefertermin und die zu liefernden Leistungsbestandteile ebenfalls fest. Das verbindliche Angebot soll dem Kunden so eine Entscheidungsfindung ermöglichen, den Auftrag zu erteilen oder nicht. In den seltensten Fällen beauftragt ein Kunde die Implementierung einer Software, dessen Gesamtkosten und Leistungsmerkmale er nicht kennt.

Die Mehrzahl der IT-Unternehmen setzt bei der Durchführung von Festpreisprojekte auf das Wasserfallmodell, ein sequenzielles Verfahren, welches die Entwicklung auf Basis aufeinander folgender Phasen vollzieht. (vgl. Kurbel et al.) Dennoch ist die Abgabe eines verbindlichen Angebotes in der Praxis risikobehaftet. Trotz der häufig verwendeten Zuschlagsfaktoren werden zahlreiche IT-Projekte weder in Time noch in Budget durchgeführt.

Um vor Produktionsbeginn die konkreten Projektaufwände und den Fertigstellungstermin beziffern zu können, muss ein Festpreisprojekt bereits in der Angebotsphase detailliert analysiert und geplant werden. Basis für die Analysen bildet in der Regel das Lastenheft, welches anschließend in ein Pflichtenheft überführt wird. In dem Lastenheft beschreibt der Kunde verbal, welche konkreten Anforderungen er an die zu implementierende Softwarelösung stellt. Die Erfahrung der vergangenen Jahrzehnte zeigt, dass selbst der Kunde im Vorfeld seine Bedürfnisse an die Software vollumfänglich nur schwer definieren kann. Häufig ist das Lastenheft nur ein grober Abriss dessen, was der Kunde wirklich möchte. Auch wenn bei der Überführung der Kundenanforderungen in das Pflichtenheft undefinierte Anforderungen offensichtlich und so in die Analyse noch mit einbezogen werden, deckt auch ein Pflichtenheft nicht die detaillierte Beschreibung jedes einzelnen Leistungsmerkmals ab. Eine Abgrenzung der Leistungsbestandteile in dem verbindlichen Angebot kann in der Regel nicht erfolgen, da sich die Projektmanager und Entwickler über die Lücken in der Analyse meist nicht bewusst sind.

[...]