Kostenschätzung in agilen Projekten: Planlos?

Größe: px
Ab Seite anzeigen:

Download "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" [http://10yearsagile.org/, 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]) 3 10

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

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

Mehr

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm Übersicht Kurze Situationsübersicht Diskussion Prozesse Challenges in der SW-Entwicklung Wie geht Scrum

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Verlages gestattet. Agiles Projektmanagement Scrum, Use

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

07. November, Zürich-Oerlikon

07. November, Zürich-Oerlikon 07. November, Zürich-Oerlikon Individuelles Vorgehensmodell mit dem TFS als Schlüssel zum Erfolg Arpagaus Patrick Bereichsleiter AKROS AG Stricker Mark Software Architekt AKROS AG Agenda Einleitung AKROS

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Markus Schramm compeople AG Frankfurt

Markus Schramm compeople AG Frankfurt Markus Schramm compeople AG Frankfurt Scrum kurz vorgestellt Bedeutung für agile Teams Kompetenzen und Zuständigkeiten Zusammenhang mit Softskills Transition Markus Schramm compeople AG 2 Individuen und

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Planst Du noch oder lebst Du schon (agil)?

Planst Du noch oder lebst Du schon (agil)? Planst Du noch oder lebst Du schon (agil)? IIBA Chapter Summit Salzburg, 11.10.2013 Anton Müller cscakademie.com Copyright CSC Deutschland Akademie GmbH Worum geht es? Gestaltung von Veränderungen in Unternehmen!

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003 Agile Software Entwicklung mit Raffael Schweitzer 18. November 2003 Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche Erfolgsfaktoren Fazit Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche

Mehr

Lastenheft. Beschreibung des Unternehmens. Ziele der Software-Einführung. Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer

Lastenheft. Beschreibung des Unternehmens. Ziele der Software-Einführung. Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer Lastenheft Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer Softwareentwicklungsfirma Beschreibung des Unternehmens Allgemeine Daten Name des Unternehmens Softwarentwicklungs

Mehr

Agiles Projektmanagement nur eine Illusion?

Agiles Projektmanagement nur eine Illusion? Fachgruppe IT-Projektmanagement, Stuttgart, 11.4.2014 Dirk Jahnke, Managing Consultant Agenda These: Sprint 1: > Motivation > Versuch einer Definition Agiles Projektmanagement Sprint 2: > Vergleich mit

Mehr

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Aufwandsschätzung in Scrum

Aufwandsschätzung in Scrum Aufwandsschätzung in Scrum 1 Planning Poker und Varianten 2 HINWEIS Aus lizenzrechtlichen Gründen sind in dem Handout die meisten Bilder und Grafiken entfernt worden. Ich bitte um Verständnis. 3 1. Scrum

Mehr

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung?

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Marlis Friedl Christina Wirth Comet Computer GmbH tekom-jahrestagung 2010 5. November, UA 17 Überblick Die agile Software-Entwicklung

Mehr

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand: Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben.

Mehr

Planung in agilen Projekten

Planung in agilen Projekten Planung in agilen Projekten Angelika Drach DeutscheScrum 2012 improuv GmbH Agile Leadership. h7p://improuv.com Über mich Lange Jahre Erfahrung in der Bauplanung Planung und Agiles Vorgehen sind ein Widerspruch?

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

Agile Softwareentwicklung Scrum vs. Kanban

Agile Softwareentwicklung Scrum vs. Kanban Agile Softwareentwicklung Scrum vs. Kanban Betül AtIiay, Ganna Shulika, Merve Yarat Universität Salzburg 29. Jänner 2016 Atliay, Shulika, Yarat (Univ. Salzburg) Agile Softwareentwicklung. Scrum vs. Kanban

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006 Überleben mit Scrum Andrea Schulz Hintergrund Projektmanager, Scrummaster, SW-Entwickler Siemens Healthcare Webbasierte Software Produkte (Releases als Projekte) Teilweise Medizinprodukt Scrum seit 2006

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

SCRUM. Agile Softwareentwicklung mit Scrum Semesterprojekt: Zug um Zug

SCRUM. Agile Softwareentwicklung mit Scrum Semesterprojekt: Zug um Zug SCRUM Agile Softwareentwicklung mit Scrum Semesterprojekt: Zug um Zug Rollen Product Owner (WIR): Definition von Produkt-Features (User Stories) Priorisieren der Features für die nächsten Sprints Scrum

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Höchst elastisch Scrum und das Wasserfallmodell

Höchst elastisch Scrum und das Wasserfallmodell Höchst elastisch Scrum und das Wasserfallmodell Kraus Wolfgang www.sourceconomy.com 1 Abstract Das Projekt bietet zwar alle Voraussetzungen für ein agiles Vorgehen, doch der Auftraggeber und das Kunden-Management

Mehr

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung?

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? @LeanAgileScrum #LASZH LAS Conference 2012 Sponsoren Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? Marcus Winteroll 16:15 Auditorium Organisationsteam Patrick Baumgartner (Swiftmind GmbH)

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Ergebnisse der Umfrage zum V-Modell XT bei VMEA 2009

Ergebnisse der Umfrage zum V-Modell XT bei VMEA 2009 Ergebnisse der Umfrage zum V-Modell XT bei VMEA 2009 Dr. Karl Kollischan, Arbeitsgruppe Projektmanagement WEIT e.v. April 2010 Bei der VMEA am 17. November 2009 in München hat der ANSSTAND e.v. zusammen

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

Mehr

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Teamaufstellung - Zwischen Dream und Nightmare

Teamaufstellung - Zwischen Dream und Nightmare Teamaufstellung - Zwischen Dream und Nightmare Vom Versuch aus einem Referat ein Scrum-Team zu machen Michael Schäfer Unterföhring, September 2011 Inhalt 1 2 3 4 5 6 Warum Scrum? So haben wir begonnen

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende

Mehr

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014 ^^ Meetings in SCRUM Leitfaden Stand: 10.11.2014 Sitz der Gesellschaften: Cassini Consulting GmbH Bennigsen-Platz 1 40474 Düsseldorf Tel: 0211 / 65 85 4133 Fax: 0211 / 65 85 4134 Sitz der Gesellschaft:

Mehr

White-Paper zur Studie Lean-IT

White-Paper zur Studie Lean-IT White-Paper zur Studie Lean-IT Riesiges Verbesserungspotential in der Durchführung von IT-Projekten In Zusammenarbeit der Universität Hohenheim mit mm1 Consulting & Management Königstraße 10c D-70173 Stuttgart

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Scrum in der Praxis (eine mögliche Umsetzung)

Scrum in der Praxis (eine mögliche Umsetzung) Scrum in der Praxis (eine mögliche Umsetzung) ALM Talk, 26. Oktober 2011 Stefan Stettler Ausgangslage Viele Projektbeteiligte Verkauf, Entwickler, PM, Designer, Ergonomen Unterschiedliche Sichten und Vorstellungen,

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Projektmanagement Vorlesung 12/ 13

Projektmanagement Vorlesung 12/ 13 Folie 1 Projektmanagement Vorlesung 12/ 13 Prof. Adrian Müller, PMP FH Kaiserslautern phone: +49 6332 914-329 http://www.fh-kl.de/~amueller Folie 2 Inhalte Agile Modelle Manifesto Übersicht XP Prinzipien

Mehr

SCRUM - Trend oder Alternative zum traditionellen Projektmanagement

SCRUM - Trend oder Alternative zum traditionellen Projektmanagement SCRUM - Trend oder Alternative zum traditionellen Projektmanagement www.pmcc-consulting.com Manfred Brandstätter, MBA 12.07.2012 Agenda > 01 - Traditionelles Projekt Management > 02 - Probleme + Erkenntnisse

Mehr

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

Mehr

Agiles Requirements Engineering mit Scrum. Rainer Fetscher Neuss, 16. November 2010

Agiles Requirements Engineering mit Scrum. Rainer Fetscher Neuss, 16. November 2010 Agiles Requirements Engineering mit Scrum Rainer Fetscher Neuss, 16. November 2010 1 Inhalt A. Vorstellung Creditreform B. Grundprinzipien in SCRUM C. IST-Stand D. Ausgangssituation E. Der Weg F. Fazit

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Thomas Löchte Geschäftsführer Informationsfabrik GmbH Wir produzieren INFORMATION. Konzeption und Architektur Implementierung [ETL,

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

Anforderungen und Auswahlkriterien für Projektmanagement-Software Anforderungen und Auswahlkriterien für Projektmanagement-Software Anika Gobert 1,Patrick Keil 2,Veronika Langlotz 1 1 Projektmanagement Payment Giesecke &Devrient GmbH Prinzregentenstr. 159, Postfach 800729,

Mehr

Dr. Wolfgang Göbl Raiffeisen Solution

Dr. Wolfgang Göbl Raiffeisen Solution Die Bedeutung schriftlicher Dokumentation im Agilen Requirements Management Dr. Wolfgang Göbl Raiffeisen Solution Requirements Management im Wasserfall Requirements Management fokussiert auf die Erstellung

Mehr

Agiles Projektmanagement SCRUM

Agiles Projektmanagement SCRUM Agiles Projektmanagement SCRUM www.pmcc-consulting.com club pm, 17.10.2013 Manfred Brandstätter, MBA Agenda 1 2 3 4 5 6 Traditionelles Projekt Management Probleme & Erkenntnisse Agiles Projektmanagement

Mehr

Agile Estimation. Mit Agilem Schätzen in die Zukunft blicken. Benjamin Seidler. XP Days Germany 2014 16. Oktober 2014, Hamburg

Agile Estimation. Mit Agilem Schätzen in die Zukunft blicken. Benjamin Seidler. XP Days Germany 2014 16. Oktober 2014, Hamburg Agile Estimation Mit Agilem Schätzen in die Zukunft blicken. XP Days Germany 2014 16. Oktober 2014, Hamburg Benjamin Seidler [Bildwuelle: https://www.flickr.com/photos/wecand/3461082232/] Mit Agilem Schätzen

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

Mehr

Agile Software-Entwicklung: Vom Hype zum Daily Business

Agile Software-Entwicklung: Vom Hype zum Daily Business Agile Software-Entwicklung: Vom Hype zum Daily Business Prof. Dr. Sven Overhage Lehrstuhl für Wirtschaftsinformatik, insb. Industrielle Informationssysteme Otto-Friedrich-Universität Bamberg sven.overhage@uni-bamberg.de

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr