Kostenschätzung in agilen Projekten: Planlos?

Transkript

1 Kostenschätzung in agilen Projekten: Planlos? SAT Sommer 2011 Prof. Dr. Frank Dopatka Stanislas Mauser Hochschule Reutlingen Reutlingen University Fakultät Informatik Studiengang Medien- und Kommunikationsinformatik Agnes-Miegel-Straße Reutlingen Abstract: In der Softwareentwicklung sind die Agile Methoden ein immer aktuelleres und bedeutenderes Thema. Hierbei sind besonders die Aspekte der Kostenschätzung wichtig, welchem jedoch nicht die gebührende Beachtung geschenkt wird. In dieser Arbeit werden die verschiedenen Agilen Techniken zur Aufwands- und Kostenschätzung dargelegt und deren Vor- und Nachteile diskutiert.

2 1 Einleitung In dieser wissenschaftlichen Arbeit geht es um die Kostenschätzung ebenfalls Aufwandschätzung genannt und dessen Probleme in der Softwareentwicklung, mit einem speziellen Fokus auf die Agilen Projekte. Was Agile Projekte sind und wie diese im Unterschied zu den traditionellen Projekten stehen wird im Folgenden erläutert. Die Fragen, die der Autor Michael Hüttermann einleitend in seinem Buch gestellt hat, greifen einige zentrale Aspekte, in Bezug auf die Thematik von Agilen Projekten auf: "Was heißt eigentlich»agil«? Sind wir nicht alle ein wenig agil? Wie würden Sie auf die Frage»Arbeiten Sie agil?«antworten? Ich bin mir recht sicher, dass Ihre Antwort lauten würde»ja, aber sicher, ich arbeite agil«" [Hüt08, S.XV]. Die Bedeutung der Frage scheint einerseits klar, andererseits wiederum nicht. Im Zusammenhang mit der "Agilen (Software-)Entwicklung" wird das Wort "agil" mit flink, flexibel, beweglich übersetzt. Hieraus lässt sich folgende Interpretation der Frage ableiten: "Arbeiten Sie flexibel?". Im Lateinischen hingegen, kann agilis mit tätig, regsam, geschäftig, eifrig übersetzt werden. Dies zeigt eine andere Deutungsweise auf, wenn man sich fern vom Gedanken der Softwareentwicklung bewegt. Aus dieser Sicht betrachtet, ist die folgende Anmerkung "Jeder, der diese Frage gestellt bekommt, wird alles daran setzen, nicht den Eindruck zu erwecken, nicht agil zu sein" [Hüt08, S.XV] berechtigt. "Ich arbeite nicht so flexibel" zu antworten ist vertretbar, aber dem Vorgesetzten zu antworten, dass man teilnahmslos oder in Versunkenheit (vgl. [Hüt08, S.XV]) arbeitet, kann sich negativ auswirken und sollte möglichst vermieden werden. Einleitend wird in dieser Arbeit ein kurzer Überblick über die Problematik der Kostenschätzung in agilen Softwareprojekten gegeben. In Kapitel 2 werden Agile Methoden im Gegensatz zu den traditionellen Methoden vorgestellt. Darauf hin wird die Kostenschätzung der Agilen denen der Traditionellen gegenüber gestellt. Anschließend werden kurz die verschiedenen Verfahren der Kostenkalkulation Agiler Methoden aufgezeigt. Im dritten Kapitel werden die Schwierigkeiten der Kostenschätzung in Agilen Projekten erläutert und anhand von Verfahren belegt. Daraufhin werden die einzelnen Vorteile der Kostenschätzung in Agilen Methoden herausgearbeitet und dargelegt. Das Fazit gibt eine kurze Zusammenfassung dieser Arbeit und einen Ausblick mit Bezug auf die Problematik und persönlicher Stellungnahme. 2

3 2 Agile Methoden und die Kostenschätzung Folgendes Kapitel gibt eine Einführung in die Agilen Methoden. Auf das Agile Manifest 1 mit den Agilen Werten und Praktiken wird in dieser Arbeit nicht weiter eingegangen. Im zweiten Teil dieses Kapitels werden die Verfahren der Agilen und der Traditionellen Methoden zur Kostenschätzung gegenübergestellt. Anschließend werden die Möglichkeiten zur Kostenschätzung Agiler Methoden kurz beschrieben. Diese dienen daraufhin ebenfalls als Diskussionsgrundlage der weiteren Kapitel. Die Agilen Modelle oder auch Leichtgewichtige Modelle genannt wurden mitte der 90er Jahre als "neues Paradigma" gegen die ganzen aufkommenden Probleme der bürokratischen, schwergewichtigen "Traditionellen" Modelle vorgeschlagen (vgl. [BA07, S.265]). Es war zudem ein Vorschlag zur Überwindung einiger Managementprobleme von IT-Projekten, wie beispielsweise die Probleme mit den instabilen Anforderungen des Kunden an das Ergebnis (vgl. [BA07, S.265]). Hier haben Ward Cunningham und Kent Beck mit der Veröffentlichung "Extreme Programming" (englische Erstveröffentlichung 1999) entscheidende Meilensteine für diese neue Bewegung gesetzt. Zwei Jahre später 2001 in Utah schrieb eine Gruppe von 17 Praktikern das neue Leitbild in Worten nieder und veröffentlichten dieses als das "Agile Manifesto" (vgl. [HRS09, S.1]). Es gab bereits weit vor dem 20. Jahrhundert Ansätze zur "Agilen" Entwicklung: spätestens durch die Veröffentlichung Ende 1999 von Kent Beck und seinem Buch "extreme Programming Explained" (vgl. [Bal08, S.654]) und "die darin veröffentlichen Thesen kurz XP genannt kamen einer Revolution gleich. Die Softwareentwicklung wird auf ihr absolutes Minimum reduziert alles, was nicht nötig ist, wird in Frage gestellt" [Bal08, S.654]. Die Popularität der "Agilen" Entwicklung begann rasant zu wachsen. Seit dem Treffen 2001 wurden bis heute eine Vielzahl von Agilen Prozessmodellen, also Prozessmodelle, welche auf Basis dieses Agilen Manifesto niedergeschrieben wurden, vorgestellt. Neben dem wohl bekanntesten Agilen Prozess, dem XP, können ebenfalls Scrum, Crystal als auch FDD zu den heute populärsten Agilen Prozessen gezählt werden. Alistair Cockburn, einer der 17 oben genannten Agilen Vertreter, bezeichnet dies gleichzeitig auch als feierliches Moment: "It has been 10 years since the Manifesto for Agile Software Development was written. It is time to celebrate, reflect, and look forward" [ Zugriff: ]. 1 ( ) 3

4 2.1 Agile Methoden und die Unterschiede zu Traditionellen Methoden Dieser Abschnitt erläutert, was Agile Methoden sind und was diese ausmachen. Zudem wird beleuchtet, was keine Agilen Methoden sind und worin der Unterschied bzw. die Abgrenzung zu den Traditionellen Methoden liegt. Agil sein bedeutet im Allgemeinen, dass jemand körperlich oder geistig wendig oder flink ist [WB11, S.7]. Genau so kann man ebenfalls die Agile Softwareentwicklung beschreiben. Ein hoher Wert wird darauf gelegt "schnell und flexibel" auf die Kundenanforderungen und Wünsche zu reagieren. Dabei wird gezielt ein minderer Wert auf die detaillierte Planung zu Beginn des Projektes gelegt. Es kann bestätigt werden, dies ist einer der Hauptunterschiede zu den Traditionellen Methoden, dass "der Kunde [ ] häufig zu Beginn noch gar nicht die genauen Anforderungen an das zu entwickelnde Produkt [kennt]. Erst im Laufe der Zeit formt sich mit den ersten Zwischenlösungen auch sein Bild, wie er die Anforderungen genau umgesetzt haben möchte" [Hüt08, S.13]. Gerade deshalb ist eine penible Planung bis ins letzte Detail und erst recht zu Beginn eines jeden Projektes doch im Grunde nur Augenwischerei [BH10, S.94ff], alles zu wissen (vgl. [HRS09, S.8]). Könnte man ein Projekt zu Beginn bereits bis ins letzte Detail planen, so gäbe es dieses bereits (vgl. [Hüt08, S.89], [OW08, S.75f]). Der Vergleich von R. Fairley (2009) bietet einen guten Ansatz für eine Gegenüberstellung. Sollen zwei Paradigmen gegenübergestellt werden, so kann gesagt werden, dass die plangetriebenen, schwergewichtigen und strikt Traditionellen Modelle eine Anleitung bilden, wie Software erstellt werden muss. "Es definiert die Rollen sämtlicher am Prozess beteiligter Personen, also wer wann welche Verantwortung hat, was macht und welche Artefakte erstellt, die eine genaue Form haben müssen" [Hüt08, S.23]. Eine Alternative ist eine Agile Vorgehensweise: die Team-Mitglieder starten mit einem grundlegenden Konzept und nähern sich in einer iterativen Weise in kleinen, aber in sich abgeschossenen Stücken, dem Endprodukt (vgl. [RF09, S.8], [Hüt08, S.23]). In Agilen Methoden wird ein geringerer Wert auf eine detaillierte Planung (vgl. [HRS09, S.94]), funktionierende Software und nicht ausführliche Dokumentation (vgl. [OW08, S.15]), etc. gelegt. Jedoch werden genau solche Prinzipien der Agilen Methoden häufig und gerne von Teams und Projektleiter, aber auch vom Kunden, falsch interpretiert. Hierzu eine passende Geschichte aus dem wahren Leben der Autoren P. Baron und M. Hüttermann (2010): "Wir waren schon vor 30 Jahren agil", sagte mal ein vermeintlich gut informierter Entwicklungsleiter. Damit war gemeint, dass sie auch damals schon nicht dokumentierte, endlose Kopfabhängigkeiten hatten, keinerlei automatisierte Tests, kein nennenswertes Design außer "mal schnell eine Datenbanktabelle auf Papier zusammenschreiben", keinerlei Wissen über die Schnittstellen, da man von der Hand in den Mund gelebt hat. Agil. Suizidal. Klingt ähnlich, oder? [BH10, S.9]. Wie in dieser Geschichte erzählt wird, sind Beispiele wie wir arbeiten agil eine gute Ausrede, wenn mal der Plan nicht mehr stimmt und alles sozusagen aus dem Ruder 4

5 läuft. Oder wenn die ganze Planung von Beginn an, nie realistisch war, und nur Augenwischerei betrieben wird (vgl. [BH10, Kap. 9.2]), also ein schöner, detaillierter Plan präsentiert wird, jedoch im Hintergrund mit allen Mitteln auf Zeit gespielt wird um unbedingt die gewünschten Ergebnisse zu erzwingen. Diese Beispiele sind jedoch keinesfalls agil, denn "Agile Entwicklung bedeutet dabei, nicht chaotisch, sondern diszipliniert vorzugehen [ ]" [Hüt08, S.XV]. Bei Agilen Methoden heißt es auch keinesfalls, komplett auf die Dokumentation zu verzichten. Es obliegt dem Risikomanagement, wie viel dokumentiert werden muss und auf wie viel verzichtet werden kann. Hierfür sind entscheidende Faktoren u.a. die Wirtschaftlichkeit, die Wiederverwendung oder auch die gesetzlichen und vertraglichen Gründe. Um den Vergleich von Agilen Methoden und Traditionellen Methoden auf eine andere Art und Weise zu verdeutlichen, wird im Folgenden eine abstrakte Gegenüberstellung der Traditionellen Methoden (Symphonie Orchester) zu den Agilen Methoden (Jazz Gruppe) gezeigt: Abbildung 1: Agilität eine Musikalische Analogie [BA07, Figure1] 2.2 Vergleich der Kostenschätzung in Agilen zu Traditionellen Methoden Wenn Projektleiter in die Zukunft blicken könnten, wäre es sicher, dass die Kosten, Risiken und Probleme gleich im Vorhinein bekannt wären und sie demnach den Ablauf der Entwicklung maximieren könnten. Somit könnte die lästige Planung, und aufwändige Aufwands- und Kostenschätzung erspart bleiben. Implizit ist verständlich, dass der Rest dieser Arbeit somit unbrauchbar wäre. 5

6 Da jedoch diese Fähigkeiten nur in TV-Serien und Spielfilmen existieren, bleibt nur die Möglichkeit, durch Aufwandsschätzung und Risikomanagement die Unsicherheit, die die Zukunft mit sich bringt in den Griff zu bekommen (vgl. [LL10, S.114]). Kostenschätzung, Kostenplanung Die Kostenschätzung bzw. Kostenplanung ist ein wesentlicher Bestandteil einer jeden Softwareentwicklung. Die wichtigste Frage, die hier gestellt wird lautet: "Wie hoch wird der Aufwand sein?". Die folgenden zentralen Fragen, welche eng miteinander verbunden sind, da diese u.a. durch den Aufwand errechnet werden können, sind jedoch nicht gleichbedeutend. - Wie lange wird die Entwicklung dauern? - Wie viele Personen werden benötigt? Zur Berechnung der Gesamtkosten eines Projekts spielen folgende drei Parameter eine bedeutende Rolle: a. Arbeits- bzw. Personalkosten b. Hard- und Softwarekosten inklusive Wartung (Benötigte Server, Computer Hardware, Testumgebungen, Entwicklungsumgebungen oder auch die Softwareteile, für den Faktor "make or buy") c. Sonstige Kosten (einmalige) (Bsp.: Reisekosten, Verpflegungskosten, Kommunikationskosten, etc.) Bei der Berechnung dieser Kosten, machen die Personalkosten den größten Anteil (vgl. [LL10, S.115ff], [Som07, S.660]). Aufwands- oder Kostenschätzverfahren zielen darauf ab, möglichst frühzeitig Antworten auf diese Fragen zu liefern. Die Resultate werden benötigt für die: - Kalkulation und Angebotserstellung, - Personalplanung und mittelfristige Disposition, - Vorbereitung einer Entscheidung»make or buy«, - Nachkalkulation [LL10, S.116]. Ansätze zur Aufwandsschätzung Grundsätzlich kann man die Schätzmethoden auf zwei Obermengen aufteilen: die algorithmische Schätzung [LL10, S.117] und die empirische Methode [BO06, S.84]. 1. Algorithmische Schätzung "Kosten werden aus Größen berechnet, die frühzeitig bekannt sind oder leichter und genauer als der Aufwand geschätzt werden können" [LL10, S.117]. Beispiele hierfür sind die Function Point- oder COCOMO II Methode. 6

7 2. Empirische Methoden Empirische Methoden sind beispielsweise die Expertenschätzung, das Analogieverfahren oder auch das Prozentsatzverfahren. Es handelt sich um Schätzungen auf Basis der Erfahrungen von Fachleuten und/oder früherer, vergleichbarer Projekte (vgl. [LL10, S.117], [BO06, S.84]). Abbildung 2: Klassifizierung bekannter Schätzmethoden [BO06, Abb.1] Abbildung 2 zeigt ein paar der vielen verschiedenen Schätzmethoden auf, wobei die wohl bekanntesten, die oben genannten sind. Was an dieser Auflistung auffällt, ist, dass der Fokus auf die Schätzmethoden der Traditionellen Methode gelegt wurde. Der Einsatz von algorithmischen Methoden ist bei den traditionellen Methoden stark verbreitet. Da Agile Vorgehensmodelle höchstens Vorschläge zur Aufwandsschätzung verwenden, wäre es rein theoretisch möglich auch hier algorithmische Methoden einzusetzen. Jedoch basieren diese komplexen Formeln auf historischen Daten, d.h. Daten aus vergleichbaren bzw. vergangenen Projekten (vgl. [BA07, S.273]). Da jedoch Agile Maßnahmen nicht dem plangetriebenen, strikt vorgeschriebenen Ansatz folgen so wie die Traditionellen Methoden es tun sind Agile Methoden so stark individuell, dass hier historische Daten nicht sehr aussagekräftig und verlässlich sind. Im Sinne des Agilen Vorgehens, wird ja bewusst auf so komplexe und hoch mathematische Verfahren verzichtet. Agile Methoden legen einen sehr hohen Wert darauf, dass jedermann die Techniken zur Aufwandsschätzung ohne sich erst einmal einzulesen oder einzulernen einsetzen und sofort anwenden kann. 7

8 2.3 Agile Aufwandsschätzung In diesem Abschnitt sollen die gängigsten Verfahren zur Aufwandsschätzung und Planung Agiler Projekte, mit deren Techniken und der dazugehörigen Einheiten kurz vorgestellt und diskutiert werden. Es wird versucht, Antworten auf folgende Fragen zu finden: - Was für Verfahren/Methoden gibt es? - Unterschiede in Theorie und Praxis? (s. [BO06, Kapitel 3.1]) - Welche sind besonders gut? Wie bereits im vorherigen Abschnitt angesprochen, kann man grundsätzlich mit Agilen Methoden jede beliebige Methode also auch die algorithmischen Schätzmethoden anpassen (vgl. [BA07, S.273]). Gängig ist es jedoch, die Ansätze zur Verwendung von Produkt-Backlog, Story Cards, Story Points, Velocity, etc. zu verwenden Die Schätzung Dass es "die eine Schätzung" nicht gibt, ist genau so klar, wie, dass es "das eine Vorgehensmodell" nicht gibt. Ebenso so wenig gibt es "das Auto" oder "das Betriebssystem", etc. Egal in welchem Bereich oder welcher Branche man sich bewegt, steht man immer vor dem Dilemma, die Qual der Wahl zu haben. Software-Projektleiter haben das Problem, dass sie bei jedem Projekt erneut mit einer enormen Unsicherheit zu kämpfen haben, denn jedes Projekt ist ein Unikat (vgl. [Hüt08, S.89]). So kann die seit Jahren bewährte Schätzmethode X für das aktuelle Projekt doch nicht geeignet sein, wie es der Fall bei einem anderen Projekt sein kann. Die Herausforderung hier an den Agilen Projektmanager ist, dass er stets abwägen muss, welches Vorgehen und welcher Einsatz der Methoden oder auch im agilen Sinne: der "best practs" für das aktuelle Projekt optimal sind. Für den agilen Projektmanager sind alle Methoden und Werkzeuge nur Hilfsmittel, um das Projektziel möglichst einfach, schlank und direkt in einer funktionierenden Teamarbeit zu erreichen [BO06, S.85]. Auch wenn die eine oder andere Agile Methode dem Anschein nach aussieht, als würde diese strikte Vorgaben machen, sind diese eher als Vorschläge und Richtungsweisungen zu interpretieren und können aber beliebig kombiniert werden. Ein Beispiel hierzu: Allgemein wird die Kombination von Scrum und XP oft genutzt (vgl. [Hüt08, S.28ff]). Im Projektmanagement stecken hinter den agilen Grundprinzipien viele klassische Erfolgsfaktoren [Sel04]. Hier hilft kein Schwarzweiß- Denken. Selbst im eher klassischen oder nicht-agilen Umfeld großer Projekte auf der Basis von Festpreisverträgen, können agile Managementprinzipien wichtige Erfolgsfaktoren darstellen [Cau05] [BO06, S.86]. Es gibt eine Vielzahl verschiedener Agiler Methoden. Jede von Ihnen bieten Techniken und Methoden zur Aufwandsschätzung. In diesen Techniken gibt es untereinander oft Überschneidungen. Im Rahmen dieser Arbeit werden diese Techniken zur Aufwandsund Kostenschätzung jedoch als solche ohne speziellen Bezug zu einer einzelnen Agilen 8

9 Methode behandelt. Es soll also nur die Aufwandsschätzung und dessen Prozess in seiner Gesamtheit betrachtet werden. Unter diesem Aspekt ist es daher sinnvoll auf folgende Punkte näher einzugehen: 1.) Anforderungen 2.) Planen: Projekt, Releases, Iterationen, Sprints... 3.) Messen, Verfolgen und Bewerten Anforderungen Anforderungen bzw. Requirements beschreiben eine oder auch mehrere Eigenschaften oder Verhaltensweisen an die zu erstellende Software, welche stets erfüllt sein sollen (vgl. [OW08, S.416], [WB11, S.38]). "Unter der Summe aller Anforderungen verstehen wir alle [ ] Aspekte des Einsatzkontextes, die vom zukünftigen System abgedeckt werden sollen [WB11, S.38]. Die Anforderungen werden vom Anwender in Form von sog. "User Stories", in einer "nicht-technischen Sprache" auf die "Story Cards" geschrieben. Eine Story ist dabei eine textuelle Beschreibung einer Anforderung, wobei der Fokus stets auf dem funktionalen Teil liegen soll (vgl. [BA07, S.268], [WB11, S.39]). Dabei wird ein hoher Wert darauf gelegt, dass die Beschreibung einer User Story dennoch so präzise ist, dass die Entwickler später den Aufwand schätzen können. Um den Umfang der Anforderungen schätzen zu können, muss das übergeordnete Ziel bekannt sein, damit dann anhand dieses geschätzten Aufwandes und der vom Kunden zugeordneten Prioritäten, eine erste Iterationsplanung durchgeführt werden kann (vgl. [WB11, S.38f]). Zur Visualisierung dient das folgende Beispiel: eine handgeschriebene Story Card (Abbildung 3) und ein einfaches Beispiel für eine Story (Abbildung 4): Abbildung 3: Story Card aus einem Projekt [WB11, Abb.5-1] 9

10 Abbildung 4: Beispiel einer Story (Story 142) [WB11, S.40] Wie in Abbildung 4 zu sehen ist, sind die Stories zu beginn noch sehr grob strukturiert und ohne Details. Damit soll vermieden werden, dass zu Beginn des Releases und auf Basis der unsicheren Produkt-Vision, umfassende Spezifikationen erstellt werden. Nur wenn es zu Beginn des Releases für die Schätzung wichtig ist, wird eine Story genauer beschrieben. Erst später, wenn die Stories für eine Iteration geplant sind, also wirklich umgesetzt werden, werden diese in mehrere Technische Tasks transformiert. Dazu treten die Entwickler dann mit dem Kunden in Kontakt um alle Details zur Umsetzung zu klären (vgl. [WB11, S.39-41], [Hüt08, S.83]) Planen: Projekt Releases, Iterationen, Sprints... Die Grundlage agiler Planung bildet das Backlog (vgl. [BC09]). Es enthält Planungselemente in der Regel in Form von User-Storys" [JC11, S.22]. Angelehnt an Scrum, existieren zwei Arten des Backlogs. Das Product Backlog ist das wichtigste Dokument, es enthält alle Anforderungen, die im Projekt umgesetzt werden sollen. Zusätzlich werden auch alle Aufgaben im Product Backlog abgelegt, welche erledigt werden müssen (vgl. [LL10, S.230]). Somit kann das Product Backlog als ein "Themenspeicher (Feature-Speicher) für das Release" [Hüt08, S.88] gesehen werden. Alle Anforderungen des Product Backlogs werden vom Kunden (bzw. nach Scrum Definition dem "Product Owner", also dem "Produktverantwortlichen") verwaltet, erstellt und priorisiert. Die Schätzung der Anforderungen, welche ebenfalls für eine präzisere Priorisierung für den Kunden wichtig ist, wird durch das Team in sog. Planungssitzungen durchgeführt (vgl. [BA07, S.269f]). Abbildung 5: Product Backlog 3 (vgl. [BA07, S.270])

11 Für die genauere Planung der einzelnen Iterationen werden dann auf Basis des Product Backlogs, die einzelnen Sprint Backlogs erstellt. Der Begriff Sprint kommt von Scrum und bezeichnet in den meisten Fällen, eine feste Iterationslänge von 30 Arbeitstagen. Demnach werden alle Anforderungen, die in der nächsten Iteration umgesetzt werden sollen, in ein Sprint Backlog übernommen (vgl. [LL10, S.230]). Abbildung 6: Der Product Owner erstellt das Sprint Backlog [WB11, Abb.23-2] Wie in Abbildung 6 gezeigt, ist das Sprint eine Auswahl aus dem Product Backlog, welche in Folge des sog. Sprint-Planning-Meeting ("Sprint-Planung") getroffen wird. Für das Sprint-Planning-Meeting wird generell ein ganzer Tag eingeplant welcher wiederum in zwei Teile gegliedert ist. Im ersten Teil stellt der Product Owner, aus der ggf. großen Menge von Anforderungen aus dem Product Backlog eine reduzierte Teilmenge an Anforderungen dem gesamten Team vor (vgl. [WB11, S.162f]). Ziel dieser Auswahl soll es sein, eine angemessene und mit dem Team abgestimmte Menge von Anforderungen, für das nächste Sprint zu bestimmen. Der Product Owner trifft dabei zwar die inhaltliche Auswahl, ist bei der Menge aber auf die Zusammenarbeit mit dem Entwicklungsteam angewiesen, das den Aufwand für die ausgewählten Anforderungen abschätzt (vgl. [WB11, S.162f]). Darauf dies aufbauend, kann der Product Owner dann die Anforderungen priorisieren, bzw. wenn sie bereits eine Priorität haben, diese ggf. anpassen. Im Zuge dieser Vorstellung und anschließenden Diskussion, sollen die Parallelen und Abhängigkeiten einzelner Anforderungen identifiziert werden. So kann der Product Owner diese zusätzlich in das neue Sprint aufnehmen oder aufgrund von Abhängigkeiten einzelner Anforderungen mit einer geringeren Priorität austauschen. Alle Anforderungen die im nächsten Sprint umgesetzt werden, müssen möglichst detailliert beschrieben und in ihrem Aufwand geschätzt sein. Zudem liegt es in den 11

12 Aufgaben des Projektmanagers (bzw. in Scrum-Sicht des "ScrumMasters") das Sprint Backlog täglich zu aktualisieren, d.h. die umgesetzten Anforderungen müssen als erledigt markiert werden, der Aufwand dafür dokumentiert und eventuelle Restaufwände und neue Aktivitäten und deren Aufwand eingetragen werden (vgl. [LL10, S.230f]). Dieser erste Teil kann unter bestimmten Umständen auch auf ein bis zwei Tage ausgedehnt werden. Z.B. im Zuge der Initialen Product Backlog Planung, oder auch wenn ein großes System geplant wird. Bei großen Systemen wird dann zusätzlich ein Release-Plan entworfen. Dieser legt die Schritte fest, in denen das System realisiert (und wenn möglich auch umgesetzt) werden soll. Der Release-Plan basiert auf der Grundlage der Initialen Version des Product Backlogs und legt fest, wie viele Sprints durchzuführen sind um das Produkt zu erstellen, und welche zentralen Anforderungen in den einzelnen Sprints umgesetzt werden. Nach jedem Sprint muss dieser Release-Plan dann auf Basis der neuen Erfahrungen geändert und um die neu hinzugekommenen Anforderungen aktualisiert werden (vgl. [LL10, S.231]). Im zweiten Teil steht es dem Product Owner frei, als "Zuschauer" noch anwesend zu sein, jedoch muss er dies nicht. Für Fragen sollte er dennoch zur Verfügung stehen (vgl. [Sch10, S.137f]). In diesem zweiten Teil muss das Team "herauszufinden, wie es das ausgewählte Product Backlog in ein Inkrement potenziell auslieferbarer Produktfunktionalität umwandelt" [Sch10, S.138]. "Das Ergebnis des zweiten Segments des Sprint Planning Meetings ist eine Liste, die als Sprint Backlog bezeichnet wird, und Aufgaben, Aufgabenschätzungen und Zuweisungen enthält, auf deren Basis das Team mit der Entwicklung der Funktionalität beginnt. Die Aufgabenliste muss [hierbei noch] nicht zwangsläufig komplett sein, [ ] muss [aber] ausführlich genug sein, um die gemeinsame Verpflichtung das Commitment aller Team-Mitglieder widerzuspiegeln und diese durch den ersten Teil des Sprints zu tragen, in dessen Verlauf das Team weitere Aufgaben für das Sprint Backlog plant" [Sch10, S.138]. Am Ende eines Sprints wird dem Product Owner das Sprint-Ergebnis im sog. "Sprint- Review" präsentiert. Das Ergebnis eines solchen Reviews hat unter anderem zur Folge, dass neue Anforderungen hinzu kommen oder geändert werden müssen. Nicht erledigte Anforderungen müssen zurück ins Product Backlog. Das Review soll dem Team auch als Reflexion zur Verbesserung der Arbeit, des Prozesses, der Aufwandsschätzung und der Velocity dienen (Vgl. [WB11, S.163]). 12

13 Abbildung 7 veranschaulicht diesen Prozess noch einmal visuell: Abbildung 7: Elemente des Scrum-Prozesses [LL10, Abb.10-18] Messen, Verfolgen und Bewerten Wie in Abschnitt bereits beschrieben, läuft der Prozess zur Aufwandsschätzung als ein wichtiger Teil des Sprint-Planning-Meetings ab. Zur Schätzung wird ein sog. "Planungsspiel" [Hüt08, S.87f] eingesetzt, und bezüglich Extreme Programming "Planning Game" [BA07, S.268f] und in der Begriffswelt von Scrum als "Planning Poker" [Coh06, S.56ff] bezeichnet. In Literatur und Aufsätzen wird Planning Poker am häufigsten als Begriff für diese Technik verwendet. In den meisten Fällen sogar unabhängig davon, ob es ein Bezug zu Scrum gibt oder nicht. Diese Technik ist keine grundsätzliche Neuerfindung und auch keine unbekannte Größe hinsichtlich der Traditionellen Methoden. Um ca gab es bereits die "Delphi- Methode", welche der Definition nach [OW08, S.276f] dem "Planning Poker" grundsätzlich sehr verwandt ist, was auch bei diversen anderen Autoren zu lesen ist. By the way, the planning poker game [...] is a variation of the Wideband-Delphi estimation technique [Kre09, S.46]. Das Planning Poker Am "Planning Poker" nimmt das gesamte Entwickler Team vom Programmierer bis zum Tester teil. Im Normalfall sind dies weniger als zehn Personen. Sollte jedoch diese Zahl überschritten werden, ist es sinnvoll, mehrere Gruppen zu bilden, welche dann separat ihre Schätzungen abgeben können. Der Product Owner nimmt zwar am Planning Poker teil, darf sich jedoch an der Schätzung nicht beteiligen (vgl. [Coh06, S.56]). 13

14 "Es gibt spezielle Schätzpokerkarten, prinzipiell ist aber jeder handelsübliche Pokerkartensatz dafür geeignet" [WB11, S.27]. Grundsätzlich kann hier jedoch zwischen zwei verschiedenen Wertebereichen gewählt werden. Die erste Möglichkeit besteht aus Zahlen von 1 bis 10. Hier können die handelsüblichen Poker-Karten-Sets verwendet werden, wobei das Ass als 1 deklariert wird. Zusätzlich einigt man sich noch auf eine "Diskussionskarte", beispielsweise die Dame (vgl. [Coh06, S.56], [WB11, S.27f]). Die zweite Möglichkeit richtet sich nach dem Wertebereich der Fibonacci-Folge, also: 1, 3, 5, 8, 13, etc. (vgl. [Coh06, S.56], [WB11, S.28]). "Viele erhältliche Schätzpokerkarten-Sets sehen auch nur diesen Wertebereich vor. Er hat sich deshalb bewährt, weil er dem Team eine Diskussion um kleinere Abweichungen erspart" [WB11, S.28]. Durch die Verwendung der Fibonacci-Zahlen muss das Team sich nicht mehr zwischen den geringen Differenzen von 1 oder 2, 6 oder 7, etc., entscheiden. Hier liegen die Werte ausreichend auseinander. (vgl. [WB11, S.28]). Abbildung 8: Planning Poker deck [Cohe10, Figure6.3] Jede "User Story" oder jedes zu schätzende Element, wird vom Moderator vorgestellt. Im Normalfall ist dies der Product Owner, kann aber auch ein Analyst sein. Grundsätzlich kann diese Rolle jeder einnehmen, da ihr keine spezielle Personengruppe zugeordnet ist. Anschließend schätzt jedes Teammitglied für sich selbst den Aufwand, in dem er die passende Karte verdeckt vor sich hinlegt. Haben sich alle entschieden, werden alle Schätzungen aufgedeckt. Liegen die Schätzungen zu weit auseinander, kann einerseits über den Aufwand diskutiert, da ggf. nicht alle Entwickler gut mit dem Bereich vertraut sind, und deshalb den benötigten Aufwand falsch interpretiert haben. Anschließend müssen alle erneut eine Schätzung abgeben. Eine Alternative hierzu wäre, dass sich das Team einigt, den Mittelwert zu nehmen. Haben beispielsweise drei Entwickler einen Aufwand von drei und zwei einen Aufwand von acht und einer einen Aufwand von zwei geschätzt, könnte man sich auf fünf einigen (vgl. [Coh06, S.56ff]). 14

15 Story Points und die relativen Wertebereiche Bei Agilen Methoden werden die Aufwände üblicherweise in "Story Points" geschätzt. Story Points sollen relative Werte darstellen und somit den Entwicklern das Schätzen erleichtern (vgl. [Coh06, S.36]). Später können diese relativen Werte in Personen-Tage, in Stunden oder in eine konkrete Geldeinheit umgerechnet werden. Zu Beginn der ersten Schätzung sollte jedoch definiert werden, was einem Story Point entspricht. In der Praxis hat es sich bewehrt, beim Schätzen eine oder mehrere Referenzaufgaben festzulegen. Diese Aufgaben sollen dem kleinstmöglichen Wert von einem Story Point entsprechen, denn eine Schätzung mit einem festgelegten Wert fällt leichter, als eine freie Schätzung (vgl. [WB11, S.28-29]). Welche Größen diesen relativen Werten letztlich zugewiesen werden, kann sehr unterschiedlich sein. So definiert jedes Projekt-Team oder Autor etwas anderes, das letztendlich das Beste für die Umrechnung ist. So assoziiert Wake [Wak00] einem Story Point mit einer ganzen Woche, Shore [Sho07] hingegen schlägt vor, dass ein Story Point einem "Ideal Day" (ein komplett störungsfreier Arbeitstag) entspricht, Bossi [Bos03] wiederum definiert ein Story Point als eine Arbeitsstunde, etc. (vgl. [BA07, S.268]). Schlussendlich spielt es keine Rolle, was bzw. wie viel Stunden, Tage oder Wochen einem Story Point entsprechen. Wichtig ist nur, dass am Ende eine User Story mit zwei Story Points doppelt so aufwändig ist, wie eine mit nur einem Story Points (vgl. [Coh06, S.36]). Velocity Mike Cohn (2006) definiert in "Agile estimating and planning" die Velocity als: Velocity is a measure of a team s rate of progress per iteration. At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story" [Coh06, S.40]. Velocity ist der Messwert eines Teams, bezogen auf "[...] wie viele Story Points es in einer Iteration abarbeiten kann" [Hüt08, S.85]. Der Wert der Velocity ist ein einfaches aber bedeutendes Mittel für die gesamte Iterations- und Projektplanung hinsichtlich Zeit, Umfang und Kosten. Da die Velocity auf ein spezielles Team bezogen ist, wird es auch als "Team-Velocity" bezeichnet. "Generell [gibt es] drei Möglichkeiten, die Velocity zu bestimmen" [Hüt08, S.85]. Die erste, und fast immer umsetzbare Möglichkeit, besteht darin, den Mittelwert der Summe aller abgearbeiteter Story Points der ersten zwei bis drei Iterationen zu berechnen. Als zweite Möglichkeit bietet sich an, die Erfahrung früherer Projekte mit dem gleichen Team zu vergleichen. "[...] [B]ildlich gesprochen, das Wetter von gestern als Grundlage für die Vorhersage des Wetters von morgen" [Hüt08, S.85]. Da die Team-Velocity jedoch ein sehr allgemeiner- und keineswegs konstanter Wert ist, kann diese Möglichkeit nur bei einer exakt gleichen Teamzusammensetzung und mit vergleichbaren Projektbedingungen eingesetzt werden. Bei starken Abweichungen bezüglich der Anforderungen oder technischen Bedingungen, sollte dieser Wert bezogen auf die 15

16 Erfahrungen lediglich als erster Anhaltspunkt genommen werden (vgl. [Hüt08, S.85]). Mit den Werten aus den ersten Iterationen muss dieser Velocity-Wert dann angepasst werden (vgl. [Hüt08, S.85]). Die dritte und letzte Möglichkeit besteht darin, einen Velocity-Wert vorherzusagen. Wenn es keine Vergleichswerte gibt und "[...] die Gelegenheit, erste Iterationen durchzuführen" [Hüt08, S.86] nicht gegeben ist, so muss die Velocity vorhergesagt werden. Jedoch ist diese Option die letzte, die gewählt werden sollte, "[...] da sie mit vielen Unsicherheiten verbunden ist" [Hüt08, S.86]. Zudem ist es hierbei sehr bedeutsam, den geschätzten Wert durch die Daten der laufenden Iterationen, für eine kontinuierliche Anpassung der Velocity zu verwenden. 16

17 3 Probleme & Vorteile der Kostenschätzung von Agilen Projekten Dieses Kapitel stellt die Probleme, die bei der Kostenschätzung in Agilen Projekten entstehen dar. 3.1 Keine Standards zum Schätzen Im Zusammenhang mit Agilen Schätztechniken, ist es interessant zu beleuchten, warum diese keinem Standard nachgehen. Zudem ist es von Interesse, welche Auswirkung dies hat und wie stark sich der Schätzprozess der Agilen zu den Traditionellen Prozessmethoden unterscheidet. Die Aufwandsschätzung in den Agilen Methoden stellt den größten Nachteil dar. Eine nach L. Buglione und A. Abran (2007) allgemeine Beobachtung ist, das jede Methode und jedes Team nach seiner eigenen Definition geht. Ein standardisiertes Verfahren beruht auf einem definierten Prozess mit geprüften und einheitlichen Eingangsparametern (vgl. [BA07, S.273]). Egal ob nun Planning Poker, Planning Game, Analogie Schätzung, o.ä. Techniken gemeint sind, alle sind sog. Expertenschätzungen, welche als weniger aufwändig, aber dafür nicht standardisiert gelten. Sie haben keine einheitlichen oder festen Messeinheiten und liefern generell keine handfesten Ergebnisse, sondern nur Annahmen. Zudem sind die Ergebnisse nur auf ein Team bzw. Experten bezogen und somit nur eingeschränkt vergleichbar (vgl. [BA07, S.273]). Ein weiterer Negativfaktor, der damit zusammenhängt, ist die Velocity. Der Wert der Velocity (vgl. Kapitel 2.3.4) beschreibt die Arbeitsgeschwindigkeit, also das Story Points/Iterations Verhältnis des Teams. Der Velocity-Wert ist jedoch nur ein sehr grober Richtwert. Dies lässt sich daran erkennen, dass schon die Sprint-Velocity [ ] bei gut eingespielten Teams um ± 20 % [schwankt] [JC11, S.25]. Diese Schwäche durch den Velocity-Faktor wird häufig stark unterschätzt. Der Wert kann variieren wenn beispielsweise eine Agile Methode mit mehreren Teams, vielleicht sogar an mehreren Standorten eingesetzt wird, und die Teamzusammensetzung verändert ist, sei es wegen einer internen Rotation, oder auch weil ein Mitarbeiter ganz den Bereich wechselt. Ungeachtet aus welchem Grund die Teamzusammensetzung sich verändert bzw. auch wenn diese bestehen bleibt, wird meist nicht daran gedacht, das Management hinsichtlich der Team-Velocity zu aktualisieren (vgl. [PP11, S.61f]) Wieso dennoch Agile Projekte? Obgleich der ganzen Kritiken und Nachteile, können Agile Projekte mit ihren Schätztechniken, aufgrund der flexiblen und transparenten Handhabung und der relativ einfachen Umsetzung überzeugen (vgl. [BO06, S.87]). In Agilen Projekten wird nicht zuerst ein Evaluierungsprojekt durchgeführt, genau so wenig wie in Ausnahmefällen mit dem Prototypen begonnen wird. Das Problem der 17

18 Fehlinterpretation von Anforderungen wird vermieden durch die aktive Einbindung des Kunden in den Entwicklungsprozess. Zudem fließen die neuen Erkenntnisse der ersten Iterationen in die Verbesserung der initialen Schätzung ein (vgl. [JC11, S.22]). Es reicht also nicht aus, sich aus diversen Büchern ein paar schön kompliziert aussehende Formeln zu kopieren [ ] [JC11, S.22]. Agile Projekte passen die initiale Schätzung kontinuierlich an. So ist zum Beispiel in Scrum der ScrumMaster (vgl. Projektmanager) für eine kontinuierliche Pflege der Aufwandsschätzung als auch für den Projektstatus verantwortlich Ein Blick auf die andere Seite An dieser Stelle ist zu klären, ob in der Praxis Agile Projekte die Expertenschätzung einsetzen und traditionelle Projekte hierfür lieber auf die genaueren algorithmischen Verfahren setzen, oder ob dies nur ein veraltet Vorurteil ist. Zur Beantwortung dieser Frage gibt es einige empirische Studien [BO06, S.86]. Aus einer Übersicht von vier empirischen Studien (vgl. [MJ03] zit. n. [BO06, Kapitel 3.1]) welche sich mit Grundgesamtheiten von 89, 114, 209 bzw. 369 betrachteten Projekten beschäftigten, geht hervor: "Alle Studien bestätigen die Expertenschätzung als die am weitesten verbreitete Schätzmethode" [BO06, S.86]. Auf dieser Daten-Basis kann man auf folgende Verteilung schließen (vgl. [BO06, Kapitel 3.1]): Expertenschätzung: 70% 80% algorithmische Verfahren: 10% 20% andere Verfahren: 10% 20% Bezüglich der "rein-agilen" Projekte dominiert laut Untersuchungen (vgl. [Con05] z.n. [BO06, Kapitel 3.1]) auch hier die Expertenschätzung, gefolgt von der Function Point Methode. Allerdings scheinen diese, aufgrund des geringen Datenumfangs nicht sehr repräsentativ zu sein (vgl. [BO06, Kapitel 3.1]). "Fast umgekehrt proportional scheint die Verbreitung der verschiedenen Schätzmethoden in Publikationen zu sein. Jørgensen findet in seiner statistischen Erhebung in allen relevanten IT-Zeitschriften in [MJ04] nur ca. 17% publizierte Papiere über die Expertenschätzung. Die überwiegende Mehrheit widmet sich den algorithmischen Verfahren. Hier scheinen Theorie und unternehmerische Praxis überhaupt nicht zu korrespondieren" [BO06, S.87]. 3.2 Schwierigkeiten der Kostenschätzung bezüglich der Feinspezifikation Auch wenn die Feinspezifikation nur indirekt eine Rolle für die Kostenschätzung spielt, hat diese letztendlich doch eine große Auswirkung. "[...] software development is often complex, and requirements are, especially in the beginning of a project, unknown or ambiguous" [Kre09, S.15]. 18

19 Unabhängig ob ein Agiles oder ein Traditionelles Vorgehen gewählt wird, liegt das Kernproblem bei der Produkt-Vision. Der Kunde weiß zu Beginn des Projektes nur grob, was er letztendlich realisiert haben möchte. Erst im Laufe der Entwicklung bekommen Kunde und Entwickler ein immer deutlicheres und einheitlicheres Bild, des zu entwickelnden Systems (vgl. [Hüt08, S.13]). Der entscheidende Unterschied zwischen dem Agilen und dem Traditionellen Projektvorgehen liegt darin, wie mit dieser Unsicherheit umgegangen wird. Am Extrembeispiel des Wasserfallmodells, wird dies aufgezeigt: Dieses "[ ] Modell geht davon aus, dass die Anforderungen zu Beginn alle klar sind und sich im Laufe der Zeit kaum noch ändern [ ]" [Hüt08, S.24]. Durch eine umfangreiche Planung zu Beginn des Projektes und fest vorgeschriebene und voneinander getrennten Entwicklungsphasen, wird versucht die Unsicherheit und die Kosten zu minimieren (vgl. [Hüt08, S.24f]). Es entsteht verhältnismäßig viel Dokumentation, da zwischen dem Entstehungszeitpunkt von Information (z.b. Identifikation einer Anforderung) und dem Zeitpunkt ihrer Nutzung (z.b. Entwurf, wie die Anforderung umgesetzt werden kann) ein Zeitraum liegt, der das Kurzzeitgedächtnis der Entwickler überfordert. Außerdem sind häufig verschiedene Personen damit betraut, d.h., es wird "Stille Post" gespielt [OW08, S.46]. Aufgrund dieser Unsicherheit, strickten Planung und vor allem bei Großprojekten mit langen Entwicklungsphasen, ist es in konventionellen Projekten durchaus üblich, dass Entwickler Funktionalität»auf Vorrat«realisieren [Hüt08, S.15]. Man erhofft sich dadurch, falsche oder fehlende Anforderungen bereits in der Planung berücksichtigt zu haben. Bei den V-Modellen oder Wasserfallmodellen müssen bei einer Änderung die ganzen Testschritte und Spezifikationsschritte neu durchlaufen werden, was wiederum die Auslieferung verzögert. Durch solch große Zeitspannen und hinzukommenden Verzögerungen kann es speziell bei Geschäftssystemen dazu kommen, dass das Unternehmen bei einer zu langen Entwicklungszeit der Software diese dann nicht mehr benötigt (vgl. [Som07, S.426]). Deshalb liest man von den verschiedensten Autoren, dass dieser Entwicklungsansatz auch wenn dieser seit Jahren verwendet wird bei weitem nicht optimal ist. Nach der eigenen Projekterfahrung des Autors G. Cohen (2010, S.7ff) ist es unbedeutend, wie genau der Produkt-Manager alles plant, denn nach 9-18 Monaten kann sich vieles geändert haben. Dies geben ebenfalls die Autoren I. Rehman, S. Ullah, A. Rauf, A. Shahid (2010) wieder: When a large and complex system is going to develop it is not possible to gather all the requirements before launching the project. Thus changes will be made in the requirements during the later phases of the development process which is not supported by the traditional models [RU10, S.2]. "Anstatt nun die Augen zu verdrehen und darüber zu schimpfen, [...] wird beim iterativen Vorgehen akzeptiert, dass die Klarheit über das herzustellende Produkt nicht mit einem Mal plötzlich entsteht, sondern schrittweise zustande kommt, und dass das Ziel keine konstante Größe ist, sondern sich mit der Zeit verändern kann" [OW08, S.3]. 19

20 Agile Vorgehensweisen verzichten bewusst auf eine vollständige Spezifikation zu Beginn des Projektes. Was aus der Perspektive traditioneller Projekte als ungewöhnlich oder gar als Risiko gesehen wird, verstehen die agilen Vorgehensweisen als Chance (vgl. [DR11, S.30], [Kre09, S.15]). "Kann so etwas gut gehen? Die Erfahrung zeigt: Es kann" [DR11, S.30]. "Bei konventionellen Projekten unterliegt man dem Trugschluss, komplexe Sachverhalte ausschließlich in Papierform dokumentieren zu müssen. Es werden ganze Schränke mit Spezifikationen gefüllt" [Hüt08, S.22]. Doch "schützt auch eine umfassende Spezifikation nicht vor Überraschungen" [DR11, S.30]. Es ist eine Illusion, die sich auch nur allzu oft in der Praxis als solches herausgestellt hat, zu glauben, komplexe Softwaresysteme zu Beginn oder auch nach einer ersten Analyse bereits vollständig spezifizieren zu können (vgl. [DR11, S.30]). A. Rüping (2011) ist hierbei nicht die Ausnahme bei der Behauptung, "viele insbesondere große Projekte haben mit einer langen Spezifikationsphase begonnen und sind letztlich doch bei etwas ganz anderem angekommen, als ursprünglich geplant war" [DR11, S.30]. "Letztlich ist es ehrlicher, ein Projekt mit einer überzeugenden Perspektive, aber einer unvollständigen Spezifikation zu beginnen, als sich der Illusion hinzugeben, sämtliche Anforderungen von vornherein formulieren zu können" [DR11, S.30]. Auch wenn es weniger starre Modell wie dem Spiralmodell gibt, so (vgl. [Hüt08, S.24]) "bleibt der Prozess dennoch schwergewichtig und prozess- und dokumentenzentriert" [Hüt08, S.24]. Selbst wenn das V-Modell bzw. V-Modell XT, durch die Trennung von der Entwicklung fachlicher Funktionalitäten und das Testen in zwei Zweige aufgeteilt, einen großen Vorteil bietet, so werden dennoch entscheidende Eigenschaften Agiler Prozessmodelle vermisst (vgl. [Hüt08, S.24]). Anstatt hohe Aufwände in die anfängliche Planung und Kostenschätzung zu stecken, ist "Planung [...] bei XP eine fortlaufende Aktivität, keine Phase [...] [Hüt08, S.32], die wenn nötig bis zum Abschluss des Projektes kontinuierlich gepflegt wird. Genau so ist in Scrum der ScrumMaster für eine kontinuierliche Verbesserung der initialen Schätzung als auch Verfolgung des Projektfortschritts verantwortlich. 3.3 Das Detail liegt in der Iteration! Wie im vorherigen Abschnitt dargestellt, setzen Agile Vorgehensweisen gezielt einen geringeren Wert auf die Gesamtplanung. Zwar wird bei größeren Projekten ein Iterations-Plan für das gesamte Projekt ausgearbeitet, jedoch ist dieser nicht ansatzweise mit einer Gesamtplanung eines traditionellen Modells vergleichbar. Ein weiterer Grund, weshalb man sich doch für das Agile Projekt entscheidet, kann durch den Vorteil der Kosten und Qualität des Projekts belegt werden. Agile Vorgehen harmonisieren den Aufwand und somit die Kosten, die in die Software fließen (s. Abbildung 9) [Hüt08, S.25]. Dies zeigt sich darin, dass bewusst zu Beginn 20