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

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 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

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

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

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

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

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

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

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

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

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

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

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

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

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht Agilität: Scrum Eine zum schnellen Einstieg Sie finden diese und weitere Präsentationen unter (-> Klick): http://www.peterjohannconsulting.de/index.php?menuid=downloads Für (agile) Entwickler und (traditionelle)

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

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

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

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Seminar Softwareentwicklung in der Wissenschaft

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

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

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

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

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

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

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

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

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

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

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

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

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

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

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

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

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

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41913-1 sowie im Buchhandel.

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

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

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

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

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

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

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest?

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest? Scrum Rollen Product Owner (PO) Der PO ist klar definiert Der PO übersetzt Anforderungen in klare Backlog Items Der PO ist ermächtigt, Backlog Items zu priorisieren Der PO verfügt über das Fachwissen,

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

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

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

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

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

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

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

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

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

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

Stop Making Sense. Über Sinn und Unsinn von Schätzungen

Stop Making Sense. Über Sinn und Unsinn von Schätzungen Stop Making Sense Über Sinn und Unsinn von Schätzungen Agenda Agenda Was sind Schätzungen? Agenda Was sind Schätzungen? Geht es auch einfacher? Agenda Was sind Schätzungen? Geht es auch einfacher? Wie

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Leuchtfeuer Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Gliederung Über die Allianz Wie führen wir Scrum ein? Wie haben wir begonnen? Techniken und Praktiken Change-Management

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Susanne Muehlbauer 29. November 2011

Susanne Muehlbauer 29. November 2011 Machen Sie noch Modellierung Anforderungsmanagement oder sind Sie schon READY for SCRUM? Susanne Muehlbauer 29. Wer ist HOOD unser Geschäftsfeld Der Einsatz von Requirements Engineering und kontinuierliche

Mehr

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs IT-Projektmanagement bei basecom Manuel Wortmann, Patrick Rolefs Vorstellrunde Mein Name ist, ich bin Jahre alt und mache meine Ausbildung bei. Übersicht wir sprechen internet Wasserfall - schön linear

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

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

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

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

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

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42524-8 sowie im Buchhandel.

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

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

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

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Silvio Simone, Bison Group Susanne Mühlbauer, HOOD GmbH Scrum Day 2012 Bison Schweiz AG Surentalstrasse 10 CH-6210 Sursee www.bison-group.com HOOD GmbH

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

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

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012 Max Jäger Frankfurt, den 07. Juli 2012 I Inhalt Inhalt Abkürzungen Abbildungen III IV 1 Scrum 1 1.1 Einführung............................. 1 1.2 Überblick über Scrum....................... 1 1.3 Rollen................................

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

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

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

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

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

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

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

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

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr