AGILES PROJEKTMANAGEMENT

Präsentation zum Thema: "AGILES PROJEKTMANAGEMENT"—  Präsentation transkript:

1 AGILES PROJEKTMANAGEMENT
AGILES PROJEKTMANAGEMENT Einführung, Methoden und Fallbeispiel Zielgruppe: StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER Winf Lehre - VO Übung - UE Do., 4. Mai 2006 VU: /3 im SS 2006

2 Überblick und Gliederung
Agiles Projektmanagement  Definitionen, Aufgaben und Ziele  Grundprinzipen, Manifesto, Artikel Agile Methoden zur Software-Entwicklung  Definitionen, Aufgaben und Ziele  Methoden: Scrum, XP, …  Kombination von Methoden Fallbeispiel (zur Übung) Aktuelle Literatur – eine Auswahl roter Faden Do., 4. Mai 2006 VU: /3 im SS 2006

3 Aufgaben und Ziele (1/2) Ziel des agilen Projektmanagements ist es, die Projektaufgabe(n) in der vorgegebenen Qualität, innerhalb der gesetzten Frist und ohne Überschreitung des Budgets zu bewältigen. Agile Methoden zur Entwicklung von Projekten kennen, kritisch beurteilen und gezielt für eigene Projekte anwenden können. ein Fallbeispiel mit Hilfe agiler Methoden gezielt lösen und Ergebnisse präsentieren können. Do., 4. Mai 2006 VU: /3 im SS 2006

4 Aufgaben und Ziele (2/2) Ziel: Lösung eines Fallbeispiels  mit Hilfe der 3 Einheiten Fallbeispiel: Planung und Realisierung eines „Content Management Systems (CMS)“ für eine Geschäftsbank Webdesigner Projektteam … z.B. CMS Programmierer z.B. … mithilfe des agilen PM Do., 4. Mai 2006 VU: /3 im SS 2006

5 Übersicht: Agiles Projektmanagement (1. Einheit)
Einführung in die Thematik „Wie erfolgreich sind Projekte?“ „Wann ist ein Projekt erfolgreich?“ „Was ist agiles PM?“ Definitionen, Grundprinzipien, … Manifesto für agile Software-Entwicklung Agilität und Ziele für Projekte  Rückschlüsse für Fallbeispiel: CMS Internet-quellen Ziele: Anwendung von agilen Methode(n) für Projektaufgaben und -anforderungen! Do., 4. Mai 2006 VU: /3 im SS 2006

6 Einführung in die Thematik (1/2)
Wirtschaft: „IT-Industrie ist eine dynamische Branche“  laufend Änderungen unterworfen! Beispiel: Internet - Homepage eine Unternehmens  Plattform für Informationen, Übersicht über das Unternehmen, Produkte, Dienstleitungen, …  laufend Änderungen unterworfen! Quelle: Gernert, Ch. (2003): Agiles Projektmanagement - Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 5 Do., 4. Mai 2006 VU: /3 im SS 2006

7 Einführung in die Thematik (2/2)
„Die sehr hohe Innovationsgeschwindigkeit im IT-Bereich erzwingt entsprechend schnelle Produktzyklen!“ „Kunden und Markt sind nicht mehr in der Lage, eigene Anforderungen zu definieren, sondern reagieren nur noch auf die Präsentation neuer technischer Möglichkeiten und Produkte!“ „Die Erstellung von Software ist für sich bereits ein strukturierter Prozess, so dass die Notwendigkeit von systematischem Projektmanagement für Software-Entwicklungsprojekten oftmals nicht erkannt wird!“ Quelle: Projekt Magazin: Das Fachmagazin im Internet für erfolgreiches Projektmanagement Glossar - Agiles Projektmanagement (2005) Do., 4. Mai 2006 VU: /3 im SS 2006

8 Diskussion: Fragen zu Projektmanagement
Wie erfolgreich sind Projekte?  knappe Ressourcen, Zeitdruck, … Wann ist ein Projekt erfolgreich? wenn, … - Budget und Termin eingehalten wurden? - das vorgeschriebene Vorgehensmodell ordnungsgemäß angewendet wurde? - der Auftraggeber mit dem Ergebnis zu frieden ist? „Ich muss lauter Sachen gleichzeitig machen!“ Do., 4. Mai 2006 VU: /3 im SS 2006

9 Internetquelle: Artikelauswahl zu Erfolg und Misserfolg von Projekten
Eine (subjektive) Auswahl an (kurzen) Internet-Artikel (November 2005): „Wann ist ein Projekt erfolgreich?“ (html) contentmanager.de - Autor: Fröhlich, A. (2002) „Softwareprojekte meistern“ (html) Nemetschek Bausoftware GmbH (2005) „Grundlagen erfolgreicher Softwareprojekte“ (pdf) Creasoft AG - Autor: Matt, S. (2002) „Widerständen bei Softwareprojekten erfolgreich begegnen“ (html) perspektive:blau - Autoren: Kraus, G. & Götz, T. (2001) „Können Softwareentwicklungsprojekte erfolgreich sein?“ (pdf) ERNI Consulting AG - Erfahrungsbericht Nr. 10, Juni 2001 „Anleitung zum Unglücklichsein für Projektmanager“ (html) Object International Software GmbH - Autor: Sterkmann, F. (2005) „Ursachen für Misserfolg oder für Erfolg von IT-Projekten“ (pdf) dpunkt - Auszug (Leseprobe), Autor: Zahrnt, Ch. (2005) … Suchanfrage an google.at: „Wie erfolgreich sind Software-Projekte?“ Do., 4. Mai 2006 VU: /3 im SS 2006

10 1a.) „Wie erfolgreich sind Projekte?“ – Überblick über Studien und Umfragen (Auswahl) Standish Group Beurteilung on IT-Firmen und Investments CHAOS-Report Fehlschläge von Software-Projekten (pdf) Datamonitor Business Information Center Britisches Marktforschungsinstitut Datamonitor-Studie (März 2002) GULP – Das Portal für IT-Projekte Umfrage: „Woran scheitern IT-Projekte?“ (2002) Bourton Group-Studie Software Engineering Institute Do., 4. Mai 2006 VU: /3 im SS 2006

11 „Ich muss lauter Sachen gleichzeitig machen!“
1b.) „Wie erfolgreich sind Software-Projekte?“ – Studien und Ergebnisse Beispiel: Termineinhaltung [Quelle: Standish Group Survey, 1999] Werte von 1999 29% abgebrochene Projekte 45% über Kosten-/Zeitplan 26% im Zeit- und Kostenplan Werte von 2001 23% abgebrochene Projekte 49% über Kosten-/Zeitplan 28% im Zeit- und Kostenplan „Ich muss lauter Sachen gleichzeitig machen!“ Gründe? Do., 4. Mai 2006 VU: /3 im SS 2006

12 1c.) Erfolgsfaktoren (Standish Group, 2001)
Unterstützung durch die Geschäftsleitung Executive support 18% Einbeziehung der Nutzer Involvement 16% Erfahrene Projektleiter Experienced project manager 14% Eindeutige Geschäftsziele und Verantwortung Clear business objectives 12% Minimierung der Projektgröße Minimized scope 10% Standardisierte Software-Infrastruktur Software infrastructure 8% Stabile grundlegende Anforderungen Firm basic requirements 6% Angemessenes Vorgehensmodell Formal methodology Verlässliche Schätzungen Reliable estimates 5% Kompetente und motivierte Mitarbeiter Other Quelle: Standish Group (Studien von 1994 und 2000) Umfrage des Managements von 365 Unternehmen nach den wesentlichen Erfolgsfaktoren für Software-Projekte Do., 4. Mai 2006 VU: /3 im SS 2006

13 „Perfektionismus oder Vertrauen auf Erfahrung?“
„Welcher Weg führt zum agilen Projektmanagement?“ anhand des Beispiels: Software-Entwicklung Agiles Vorgehen 2000 Objektorientierung Software Engineering Funktionen und Daten 1990 1980 1970 Software-Krise „Perfektionismus oder Vertrauen auf Erfahrung?“ Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

14 „Was ist Agiles Projektmanagement
„Was ist Agiles Projektmanagement?“ (1/3) Definition, Grundprinzip und Methoden Definition: „Agiles Projektmanagement ist ein (branchen- spezifisch für Projekte entwickeltes) Handlungsmodell.“ Grundprinzip: weitgehende Verzicht auf umfangreiche Vorgehensmodelle.  „welche Gefahren sind damit verbunden?“ Methoden: im Baukastenprinzip, die je nach Anforderungen eingesetzt werden. Komponenten: Team - Werkzeug - Prozess  zur Erreichung der Ziele Quelle: Projekt Magazin: Das Fachmagazin im Internet für erfolgreiches Projektmanagement Glossar - Agiles Projektmanagement (2005) Do., 4. Mai 2006 VU: /3 im SS 2006

15 „Was ist Agiles Projektmanagement?“ (2/3) Eigenschaften und Merkmale
agil: (adj.) flink, gewandt, beweglich, rege, felxibel [Latein - agilis] der (Arbeits-) Prozess beinhaltet schnelle (Arbeits-) Methoden Definiert Aufgaben und Ziele für Team(s) und MitarbeiterInnen FußballspielerIn Eigenschaften Diskussionspunkte  Brainstorming: „Welche Voraussetzungen und Eigenschaften müssen TrainerIn bzw. SpielerInnen mitbringen, um ein Fußballspiel zu gewinnen?“ Quelle: Chin, G. (2004): Agile Project Management — How to Succeed in the Face of Changing Project Requirements – Chapter 2: Determining When to Use Agile Project Management (Grundlagen) Do., 4. Mai 2006 VU: /3 im SS 2006

16 „Was ist Agiles Projektmanagement?“ (3/3) Ziele
Ziele des agilen Projektmanagement ist es, die Projektaufgabe(n) in der vorgegebenen Qualität, innerhalb der gesetzten Frist und ohne Überschreitung des Budgets zu bewältigen. Funktionalität / Qualität maximal Ressourcen Zeit optimal minimal Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

17 Übersicht: „Manifesto for Agile Software Development“ (2001)
 öffentliche Erklärung von Zielen und Absichten für die Erstellung von Softwareprodukten Internetquelle: (2001) Beteiligte Personen (in der Klammer die Methode): Kent Beck (XP), Jim Highsmith (ASD), Mike Beedle (Scrum), Ken Schwaber (Scrum), Jeff Sutherland (Scrum), Alistair Cockburn (Crystal), … Agile Alliance ( Do., 4. Mai 2006 VU: /3 im SS 2006

18 Aufgaben und Ziele: Manifesto … (2001)
Aufgaben  Vereinfachung und Verbesserung der Software-Entwicklung Ziele  gezielter (sinnvoller) Einsatz und Kombination von agilen Methoden zur (erfolgreichen) Software-Entwicklung Aufgabe und Ziele agilemanifesto.org „Manifesto for Agile Software Development“ (2001) Do., 4. Mai 2006 VU: /3 im SS 2006

19 „Manifesto for Agile Software Development“ (2001) Übersicht und Ziele (1/2)
Agile Alliance 2001: „Wir entdecken bessere Wege zur Entwicklung von Software, in dem wir Software entwickeln und anderen bei der Entwicklung helfen. Dadurch haben wir gelernt, dass ... We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: … Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

20 „Manifesto for Agile Software Development“ (2001) Übersicht und Ziele (2/2)
„Menschen und Zusammenarbeit“ vor Prozessen und Werkzeugen „We are uncovering better ways of developing software by doing it and helping others do it.“  value „Funktionierende Software“ vor umfassender Dokumentation Individuals and interactions over processes and tools Working software over comprehensive documentation „Zusammenarbeit mit den Kunden“ vor vertraglicher Verhandlung Customer collaboration over contract negotiation „Reaktion auf Veränderung“ vor Einhaltung eines Plans Responding to change over following a plan Quelle: (2001) – Stand: Do., 4. Mai 2006 VU: /3 im SS 2006

21 Agile Prinzipien und Werte zur Software-Entwicklung
Nichts ist Beständiger als der Wandel Es gibt keine 100% fertigen Anforderungen Kurze Entwicklungszyklen – Release und Iterationen Feedback vom Kunden Lernen aus Erfahrung Kontinuierliche und gute Kommunikation und Information als grundlegende Erfolgsbasis Team und Kunde bilden Maßstab für Erfolg Lauffähige Software ist Bezugspunkt für Bewertung des Projektfortschritts Erfahrung und Erfolg vor Regeln und Vorschriften Schlanke Prozesse und Methoden Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

22 Übersicht: Agile Methoden (Auswahl)
Folge von ca. 30-tägigen Sprints, Produkt-Backlog, Sprint-Backlog, Tägliches Meeting. Einfache, aber strenge Regeln, kurze Iterationen, Kontinuierliche Planung, Pair-Programming, ... Mensch steht im Mittelpunkt, Kooperative Zusammenarbeit mit Hauptziel lauffähige Software, Nebenziel: für das nächste Projekt vorbereitet sein. Adaptive Software Development Ziele als Ausgangspunkt, kein Plan Spekulieren, Zusammenarbeiten, Lernen. Scrum XP Crystal ASD … Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

23 Übersicht: Agile Anforderung(en) …
gegenüber … 1. Projektmanager und … 2. Projektteam und … 3. Entwicklungsprozess. Ziel: Rückschlüsse für z.B. Software-Entwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

24 1a)„Was wird vom Projektmanager erwartet?“
Planen Ziele setzen Überwachen Aufgaben des Projektmanagements Informieren Steuern Entscheiden Personal führen Organisieren Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

25 1b) Ein agiles Projekt(team) managen bedeutet …
Projektziele und Projektergebnisse klar zu definieren, deren Umsetzung planen (Projektaktivitäten), die Durchführung der Projektaktivitäten und damit die Zielerreichung überwachen, bei Abweichungen oder Änderungen steuernd eingreifen, Projektprozesse, Teams und Infrastruktur optimal organisieren, Mitarbeiter führen, alle Stakeholder optimal informieren, Entscheidungen vorbereiten und treffen. Es heißt darüber hinaus: Risiken, Qualität und Änderungen aktiv managen Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

26 2) Merkmale eines agilen Projektteams
Motiviertes Team, Vertrauern statt Kontrolle, Angemessenen Vorgehen, Gute Kommunikation, Das Ergebnis zählt, „Best Practices“, Veränderung ist ok, Risikoorientiert. „Wieviel Freiraum?“ „Erlaubt ist alles, was den Erfolg des Projektes fördert und Risikopotenziale senkt!“ Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

27 3) „Was ändert sich im Entwicklungsprozess?“
Anforderungen Anwender formuliert Anforderungen Richtigkeit und Vollständigkeit wird frühzeitig durch Testen lauffähiger Software geprüft Spezifikation weniger formal Implementieren Kurze Entwicklungszyklen Implementieren vor Spezifizieren, dafür regelmäßiges Refactoring Design / Architektur Testen als Designansatz (Test-First) Regelmäßiges Refactoring Vorschriften verlieren Angemessenheit vor Architektur wächst Test Basis für Feedback und Lernen Akzeptanztest: effiziente Form der Anforderungsformulierung Unit-Tests: beste Form der Dokumentation von Sourcecode Sicherheitsnetz für Refactoring und Einbau neuer Feature Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

28 4) Rückschlüsse: Anforderung(en) an agile Software-Entwicklung
„Nein, keineswegs! Rückbesinnung auf das Wesentlich!“ „Hilfe, geben wie wieder alles auf?“ Agile Projekte – „Was ist anders?“ Beispiel:  Methoden auswählen, anwenden, umsetzen, kombinieren, anpassen, ..  reflektieren, aus Fehlern lernen Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

29 Übersicht: Agile Projekte – Was ist anders?
Agilität und Ziele Grundsätze der Planung für agile Projekte Was verändert sich in der Dokumentation? Was verändert sich im Projektcontrolling? Was verändert sich im Team? Verantwortungsverteilung verändert sich Erfolgsfaktor Mensch Jeder braucht ein anderes Maß an Freiheit Ohne Wissen und Disziplin funktioniert es nicht Menschen formen Prozesse Agilität benötigt Freiraum Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

30 1. Agilität und Ziele für Projekt(e)
Agile Projektmanager achten auf Freiräume  Eigenverantwortlichkeit und Motivation setzen eine klare Ziel- orientierung voraus auf Ergebnisorientierung  um Ergebnisse vereinbaren zu können, müssen Ziele und Richtung bekannt sein auf Angemessenheit  ohne eine inhaltliche Zielsetzung lassen sich Alternativen nicht bewerten Agiles Projektmanagement benötigt klare, eindeutige und verbindliche Ziele! Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

31 2. Grundsätze der Planung für agile Projekte
Wichtigste Bezugspunkte für Planung sind Anforderungsmodell und Systemarchitektur, Planung erfolgt stufenweise (Produkt, Release, Iterationen), Details zur richtigen Zeit, Planung orientiert sich strikt an prüfbaren Ergebnissen Prinzipien des Timeboxing werden konsequent angewandt, Schnelles, konsequentes Feedback wird gezielt zur Verbesserung von Planungsprozess und Planungsqualität genutzt, Adaptive Planung (kontinuierlicher Prozesse). Realisierung im Kleinen – Denken im Ganzen Planung ist flexibler, aber aufwendiger, Offen sein für Änderungen statt festhalten an starren Vorgaben! Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

32 3. Was verändert sich in der Dokumentation?
Dokumentation im Entwicklungsprozess Ziel ändert sich: Unterstützung der Kommunikation ist wichtiger als Wissenstransfer, daher weniger und nicht zwingend vollständige Dokumentation. Weniger Dokumentation möglich durch schnelle Realisierung, sofortige Ableitung von Testfällen und unmittelbare Einbeziehung des Kunden. Daher Dokumente nicht mehr als Instrument zur Verfolgung des Projektfortschritts geeignet. Zurückfahren von Dokumentation erfordert Zunahme der direkten Kommunikation  Wissenstransfer sichern. Doku Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

33 4. Was verändert sich im Projektcontrolling?
Kurze überschaubare Etappen ermöglichen schnelle Reaktion Fortschrittskontrolle basiert aus Inspektion von lauffähiger Software In der Mitte der Iteration  Interview Am Ende der Iteration  Reflektions-Workshop Aktive Manager sind gefordert Regelmäßiges aktives Nachfragen Entscheidungen dort treffen, wo Wissen vorhanden ist Manager  Team Partizipative und kollaborative Entscheidungsprozesse Mangel an Entscheidungsfreudigkeit  eines der größten Risiken in Projekten Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

34 5. Was verändert sich im Team?
Agile Prozesse brauchen Teams mit gleichwertigem Wissen Vom Spezialwissen zum Allgemeinwissen Spezialisten mehr Generalisten Kopfmonopole vermeiden Big Picture sollte jeder verinnerlicht haben Leistung und nicht Rollen führen zu Anerkennung Teamsprecher vs. Teamleiter: Kontaktperson koordiniert wer an einem bestimmten Meeting teilnimmt „Führungsaufgaben müssen jederzeit im Projekt übernommen werden, jede Minute, von jedem im Team“ [Kent Beck 2001] Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

35 6. Verantwortungsverteilung verändert sich
Jeder ist für seine Aufgabe gesamtverantwortlich Jeder trägt Verantwortung für das gesamte System Jeder trägt Verantwortung für Prozesse im Projekt  Beispiel: Collective Ownership Fazit: Jeder steuert mit  dies bedeutet in der Regel für alle im Projekt Umdenken und Lernen Nicht jeder nimmt die übertragende Verantwortung an Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

36 7. Erfolgsfaktor Mensch Die größten Probleme bei unserer Arbeit sind keine technologischen Probleme, sondern soziologische Probleme. Software- und Systementwicklung ist ein kreativer Prozess, bei dem Menschen (unter Ausnutzung professioneller Hilfsmittel) Lösungen für vorhandene Probleme suchen. „Meine Idee ist besser als Deine!“ „Was gefällt ihm jetzt wieder nicht!“ Inputs Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

37 7a. Jeder braucht ein anderes Maß an Freiheit
Unerfahrene Projektbeteiligte Benötigen Unterstützung durch Erfahrene Benötigen klare Vorgaben & Regeln Erfahrenen Projektbeteiligte Benötigen weniger Vorgaben, aber eindeutige, verbindliche Rahmenbedingungen Möglichkeit des individuellen Spielraums bieten Eingearbeitete Projektbeteiligte Benötigen Unterstützung in Teilbereichen Nutzen Vorgaben als Orientierung „Achten Sie bei der Auswahl Ihres Vorgehens auf alle Facetten Ihrer Mitarbeiter!“ Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

38 7b. Ohne Wissen und Disziplin funktioniert es nicht
Werte und Prinzipien müssen allen bekannt sein gute Kenntnis der Organisation & der eigenen Rolle Denken im Ganzen Agiles Management erfordert Charakter Ehrlichkeit, Vertrauen, Mut, Konsequenz Agiles Management erfordert Erfahrung Disziplin Denken Sie an Sport oder Musik – ohne Disziplin und Übung kein Erfolg Erst wenn die Grundregeln beherrscht werden, entsteht Raum für Flexibilität, Kreativität und Innovation Auswählen, Kombinieren, Anpassen, Umsetzen, Zurückschauen, Reflektieren und Lernen Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

39 7c. Menschen formen Prozesse
Wissen und Disziplin Kommunikation Das Team Unternehmens-Kultur Augenmaß Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung Do., 4. Mai 2006 VU: /3 im SS 2006

40 1) „Was macht agile Projekte erfolgreich?“ (1/2)
schätzen ein motiviertes Team höher ein als perfekt ausgeklügelte Regeln; legen mehr Wert auf gute Kommunikation im Team als auf ein formalisiertes Berichtswesen; achten darauf, dass ein erreichtes Ergebnis mehr zählt als die sture Abarbeitung einer vorgeschriebenen Aufgabe; akzeptieren kontinuierliche Änderungen im Projekt und halten nicht an Planvorgaben starr fest; Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 2 Do., 4. Mai 2006 VU: /3 im SS 2006

41 2) „Was macht agile Projekte erfolgreich?“ (2/2)
wenden für die Verbesserung des Vertrauens im Team mehr Zeit auf als für Kontrollverfahren; schätzen die Erfahrungen aus vorigen Projekten wertvoller ein als die Aussagen in Prozessmodellen oder Lehrbüchern (inklusive diesem Smile☺); geben angemessenen Vorgehensweisen den Vorzug gegenüber extremem Handeln; managen aktiv die Risiken Ihres Projekts statt Krisen zu bewältigen. Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 2 Do., 4. Mai 2006 VU: /3 im SS 2006

42 3) Checkliste für (erfolgreiche) agile Projekte
für ein erfolgreiches Projekt ist ein motiviertes Team wichtiger als perfektes Management; ist selbstständiges Denken und Handeln entscheidender als ein bis ins Detail vorgegebenes Prozessmodell; ist eine funktionierende Kommunikation im Team und mit dem Kunden bedeutsamer als ein formalisiertes Berichtswesen; sind kontinuierliche Anpassungen an veränderte Situationen wichtiger als das Festhalten an Planvorgaben; sind wenige, für jeden verständliche und überschaubare Regeln hilfreicher als umfangreiche, ellenlange Vorgehensvorschriften; ist das Wissen um die Sache eine wesentliche Voraussetzung. Quelle: Gernert, Ch. (2003): Agiles Projektmanagement - Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 24 Do., 4. Mai 2006 VU: /3 im SS 2006

43 Wiederholung: Einzelarbeit
Kontrollfragen zur Wiederholung (1/2) Handout (Multiple Choice Test, 5/2006) Homepage zur Lehrveranstaltung: SS Projektmanagment (Bakk.), (VU) URL: Agiles Projektmanagement Do., 4. Mai 2006 VU: /3 im SS 2006

44 II. AGILE METHODEN Projektmanagement zur (erfolgreichen) Softwareentwicklung Zielgruppe: StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER Winf Lehre - VO Übung - UE Do., 4. Mai 2006 VU: /3 im SS 2006

45 Übersicht: Agile Methoden zur Software-Entwicklung
Scrum XP (eXtreme Programming) RUP (Rational Unified Process), DSDM (Dynamic Systems Development Method) Crystal Methodolgies, FDD (Feature-Driven Development) Lean Development, Pragmatic Programming TDD (Test-driven development) Adaptive Software Development Welche Methode(n) soll ich wählen? Quelle: Highsmith, J. (2001): Manifesto for Agile Software Development History: The Agile Manifesto Do., 4. Mai 2006 VU: /3 im SS 2006

46 Scrum: Übersicht Einleitung „Was ist ein Scrum?“ Definitionen
Ziele von Scrum Der Scrum Prozess Beteiligte Personen Product Owner Scrum Master Scrum Team Scrum Funktionen Literaturquellen Do., 4. Mai 2006 VU: /3 im SS 2006

47 Scrum: „Was ist ein Scrum?“ (1/2)
Begriff aus dem Rugby-Spiels Ein Scrum ist die Besprechung des Teams (bestehend aus acht Spielern) auf dem Spielfeld, bevor ein Durchbruch durch die gegnerischen Linien versucht wird. Ziel: Ball über die Torlinie zu bringen Merkmale: keine zuvor eingeübten Spielzüge oder Anweisungen des Trainers Spieler entscheiden spontan und individuell Do., 4. Mai 2006 VU: /3 im SS 2006

48 Scrum: „Was ist ein Scrum?“ (2/2)
„Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices.“ „Wrapping existing engineering practices, including eXtreme Programming (XP) and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation.“ „Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.“ Quelle: Schwaber, K. (2005): „What ist Scrum?“ unter der URL: (Mo., ) Do., 4. Mai 2006 VU: /3 im SS 2006

49 Scrum: „Die Philosophie“ – Vergleich
Rugbyspiel(erInnen) TrainerIn, Coach Fußballspiel(erInnen) „Scrum-Prozess“ „Scrum-Prozess“ Spielzüge, etc. Sprint „parallelen“ Aufgabe(n) und Ziel(e) Aufgabe(n) und Ziel(e) Do., 4. Mai 2006 VU: /3 im SS 2006

50 Scrum: Bestandteile eines Scrums (Begriffe)
Product Backlog Product Owner Daily Scrum Sprint Backlog Sprint Planning Meeting Scrum Team Was habe ich seit gestern erledigt? Was hat mich dabei behindert? Was habe ich mir bis morgen vorgenommen? Do., 4. Mai 2006 VU: /3 im SS 2006

51 Scrum: Vorgehensweise (1/2)
 Agiler Prozess zur Software-Entwicklung Wie? mit Hilfe eines Scrums werden die Projekte in Serien von 30-tägigen Zyklen, den so genannten Sprints, bearbeitet. Wofür? für Projekte, bei denen sich die Anforderungen schnell ändern (können) oder dazukommen, Ziele: „Iterativen Umsetzen von Anforderungen nach bestimmten Prioritäten, wobei laufend kontrolliert und adaptiert werden muss.“ Do., 4. Mai 2006 VU: /3 im SS 2006

52 Scrum: Vorgehensweise (2/2)
Quelle: Mountain Goat Software, abgefragt am Do., 4. Mai 2006 VU: /3 im SS 2006

53 Scrum: Der Entwicklungsprozess (1/2)
Pre-Game (Vorbereitungen) Architecture Develop Backlog list High-level design Address open questions in Backlog list Mid-Game: Development (Spiel) Post-Game (Nachbearbeitung) Closure of questions Do., 4. Mai 2006 VU: /3 im SS 2006

54 Scrum: Aufgaben und Eigenschaften des Teams
Aufbauorganisation: self-directed, self-organizing teams no external addition of work to an underway iteration Ablauforganisation: daily stand-up meeting with special questions Zeitplan: usually 30-calendar day iterations demo to external stake holders at each iteration end each iteration: client-driven adaptive planning Do., 4. Mai 2006 VU: /3 im SS 2006

55 Scrum: Werte (Values) „Commitment“ (Engagement, Verpflichtung, Bindung) Definde goal for an iteration „Focus“ (sein Hauptaugenmerk richten auf …) „Product Backlog“ „Openness“ (Offenheit) „Respect“ (zu achten, respektieren, Beziehung) „Courage“ (Mut, Herz) Quelle: Schwaber, K. & Beedle, M. (2002): Agile Software Development wirth Scrum – Scrum values, Prentice-Hall Ziele: gemeinsam an seiner Sache arbeiten, miteinander anstatt gegeneinander (sich damit identifizieren können)! Do., 4. Mai 2006 VU: /3 im SS 2006

56 Scrum: „Common Mistakes and Misunderstandings“ (1/2)
Error: Not a self-directed team; managers or Scrum Master direct or organize the team Error: No daily update of the Sprint Backlog by members or daily tracker Error: New work added to iteration or individual Error: Product Owner isn't involved or doesn't decide Error: No Sprint Review Do., 4. Mai 2006 VU: /3 im SS 2006

57 Scrum: „Common Mistakes and Misunderstandings“ (2/2)
Error: Many masters Error: Documentation is bad Error: Design or diagramming is bad Full team (including customers and management) not briefed in Scrum and its values Error: Scrum Meeting too long or unfocused Error: Iteration doesn't end in an integrated and tested partial product Do., 4. Mai 2006 VU: /3 im SS 2006

58 Scrum: Background Do., 4. Mai 2006 VU: 050127/3 im SS 2006
Schwaber, K / Beedle, M. (2002): Agile Software Development with SCRUM, Figure 28-1: A System Representation of Scrum, Prentice Hall Do., 4. Mai 2006 VU: /3 im SS 2006

59 XP: „eXtreme Programming“ Übersicht über Methode
Kent Beck  4 Grundwerte Kommunikation (Communication) Pair programming, task estimation, iration planning Einfachheit (Simplicity) Rückmeldung (Feedback) Testing, customer stories, small irations/frequent deliversies, pair programming/cinstant code reviews Mut (Courage) (Respekt) Wolf, H. / Roock, St. / Lippert, M. (2005): eXtreme Programming, 2. Auflage, dpunkt.verlag Do., 4. Mai 2006 VU: /3 im SS 2006

60 Einfachheit (Simplicity) Kommunikation (Communication)
XP: Werte XP beruht auf die folgenden vier Werten: Einfachheit (Simplicity) Mut (Courage) Kommunikation (Communication) Feedback Wolf, H. / Roock, St. / Lippert, M. (2005): eXtreme Programming, 2. Auflage, dpunkt.verlag Do., 4. Mai 2006 VU: /3 im SS 2006

61 XP-Techniken (1/3)  Pair Programming (Programmieren in Paaren)
Do., 4. Mai 2006 VU: /3 im SS 2006

62 XP-Techniken (2/3) 13 XP-Techniken, auf denen die Grundwerte aufbauen
Planning Game (Planungsspiel), User Storys Kleine Release, kurze Releasezyklen System-Metapher Einfachstes Design Testen Refactoring (Kontinuierliche Verbesserung) Pair Programming (Programmieren in Paaren) Do., 4. Mai 2006 VU: /3 im SS 2006

63 XP-Prinzipien (3/3) Fortlaufende Integration (Continuous Integration)
Gemeinsamer Codebesitz und Verantwortlichkeit Kunde im Projekt involviert 40-Stunden-Woche Offene Arbeitsumgebung Einfache Richtlinien Voraussetzungen: Kommunikation, Teamgeist Grenzbereiche Fazit: kleine Projekte Do., 4. Mai 2006 VU: /3 im SS 2006

64 XP: Softwarewerkzeug (Open Source)
XPlanner  URL: AgilePlace XPWeb  Weitere SCM (Source Control Management) BUILD TEST BUGTRACKING Do., 4. Mai 2006 VU: /3 im SS 2006

65 Beispiel: Kombination von Methoden (aus der Praxis)
XBreed: Scrum und XP (eXtreme Programming) Komination von management-orientierten Scrum mit dem technisch-orientierten XP  Mike Beedle, URL: UPXS: UP, XP und Scrum UP für die Phasen vor und nach der Software-Entwicklung (z.B. Logistik, Vertrieb) XP als Sammlung von ingenieurmäßigen Disziplinen für hochqualitative Softwareentwicklung Scrum als Management-Rahmen für die Entwicklung  Roman Pichler, Siemens AG (auf der OOP 2005 in München Abkürzung: Objekt-orientiertes Programmieren) Do., 4. Mai 2006 VU: /3 im SS 2006

66 Beispiel: Scrum und „eXtreme Programming (XP)“ Raumausstattung für tägliches Scrum-Meeting
Quelle: Larman, C. (2003): Agile and Iterative Development: A Manager´s Guide, Addison Wesley Chapter 11: Practice Tips – Environment, Figure 11.12: sample room elements Do., 4. Mai 2006 VU: /3 im SS 2006

67 Beispiel: Scrum und „eXtreme Programming (XP)“ Raumausstattung für tägliches Arbeiten (Entwicklung)
Quelle: Larman, C. (2003): Agile and Iterative Development: A Manager´s Guide, Addison Wesley Chapter 11: Practice Tips – Environment, Figure 11.10: agile project common room with walls exposed Do., 4. Mai 2006 VU: /3 im SS 2006

68 Wiederholung: Einzelarbeit
Kontrollfragen zur Wiederholung (2/2) Handout (Multiple Choice Test, 2. Seite, 05/2006) Homepage zur Lehrveranstaltung: SS Projektmanagment (Bakk.), (VU) URL: Agiles Projektmanagement Do., 4. Mai 2006 VU: /3 im SS 2006

69 Weitere Methoden: Crystal Methodologies
Kein Prozess, eher ein Framework Alistair Cockburn befragte Anfang der 1990er-Jahren  Teammitglieder erfolgreicher Projekte „Welche Methoden, welche Techniken?“ Ergebnis: unterschiedliche Projekte benötigen unterschiedliche Prozesse Lösung: Klassifizierung von Projekten  Matrix mit verschiedenen Kriterien Erkenntnis: Je geringer die Größe des Teams ist, umso weniger Dokumente müssen verwendet werden Je kritischer das Softwareprojekt, desto formaler müssen die Dokumente sein Quelle: Cockburn, A. (2002): Agile Software Development, Boston (MA), Addison Wesley Do., 4. Mai 2006 VU: /3 im SS 2006

70 FDD: Feature Driven Development
Gründer: Jeff DeLuca, Peter Coad Mitte der 1990er-Jahre  erfolgreich bei der Verwendung in sehr großen Projekten Nach einer kurzen Initialisierungsphase werden iterativ ausgewählte Anforderungen geplant und umgesetzt. stark kundenorientierte Methode mit kleinen Teilresultaten, Einschränkungen durch die Bedingung, dass ein Feature in maximal zwei Wochen entwickelt werden sollte, Lösung: Aufteilung der Feature bis die Vorgabe erfüllt werde kann. Quelle: Palmer, S & Felsing, J. (2002): A Practical Guide to Feature Driven Development, London, Prentice Hall Do., 4. Mai 2006 VU: /3 im SS 2006

71 ASD: Adaptive Software Development
Jim Highsmith  Rapid Application Development (RAD) Seit 1992 wurde ASD in über 100 Projekten erfolgreich verwendet Regeln für die Zusammenarbeit zwischen Team, Kunden und Organisation dar Softwareprojekt wird als komplexes System gesehen Anforderungen: Team muss flexibler sein, aufgrund weniger Regeln ASD-Lebenszyklus:  Ende jeder Iteration: neue Version Anfang: Initialisierungsphase Zyklen von Adaptive „Cycle Plannings“, „Concurrent Feature Developments“ und „Quality Reviews“ werden durchgeführt Team liefert alle 4 Wochen viele Features wie möglich (aufgrund einer Prioritätenliste Do., 4. Mai 2006 VU: /3 im SS 2006

72 MSF: Microsoft Solutions Framework
Merkmal: Framework  Rahmen Bestandteile Teammodell (6 Rollen sind Development-, Test-, Logistic-, User-, Costumer- und Program Manager  Communication) MSF Prozessmodell Prinzip der lebendigen Dokumente Application-Architekturmodell Proaktives Risikomanagement Flexibilität Vorgehensmodell bietet ein Vorgehensmodell zur Bewältigung von Projekten Kleine Projekte  Gleichberechtigung der 6 Hauprollen Do., 4. Mai 2006 VU: /3 im SS 2006

73 Zusammenfassung: Agile Methoden (1/2)
Agile Methoden unterscheiden sich untereinander ganz erheblich in Umfang und Detaillisierungstiefe. Scrum, ASD und Crystal Methodologies  Meta-Prozesse  Prozesse als Rahmenbedingungen Verzicht auf detaillierte Vorgaben in der täglichen Arbeit XP und FDD sind dazu konkrete, detaillierte Verfahren für Software-Entwicklung Quelle: OCG Journal - Ausgabe 5/2004, Agile Software Entwicklung auf der Seite 6 Do., 4. Mai 2006 VU: /3 im SS 2006

74 Zusammenfassung: Agile Methoden (2/2)
Agile Softwareentwicklungsmethoden sind nicht neu Verwenden Strategien und Methoden von anderen Methoden  Kombination Vorteile: Schlankheit der Prozesse, Übersichtlichkeit und der Möglichkeit die Kundenwünsche umzusetzen. Nachteile: Kollision des stark iterativen Vorgehens, kompetenter Ansprechpartner auf Kundenseite (Fachwissen und Entscheidungsbefugnisse), konkrete Anforderungsdefinition Nicht jedes Projekt eignet sich für die Anwendung agiler Methoden Quelle: OCG Journal - Ausgabe 5/2004, Agile Software Entwicklung auf der Seite 6 Do., 4. Mai 2006 VU: /3 im SS 2006

75 Aufgabenstellungen: Gruppenarbeit
Überprüfen Sie zunächst die Anwendbarkeit der beiden agilen Methoden: Scrum und XP auf Ihr eigenes Projekt!  Gehen Sie dabei auf die jeweiligen Grundbegriffe, Werte, Prinzipien, … ein!  Vor- und Nachteile der beiden Methoden im Praxiseinsatz „Welche weitere(n) agile Methode(n) können bei Ihrem Projekt sinnvoll miteinander kombiniert werden?“ „Wo sehen Sie Schwierigkeiten bei der Anwendbarkeit agiler Methoden gegenüber Vorgehensmodelle (RUP, V-Modell, …)?“ Do., 4. Mai 2006 VU: /3 im SS 2006

76 III. FALLBEISPIEL Projektmanagement zur (erfolgreichen) Softwareentwicklung Zielgruppe: StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER Winf Lehre - VO Übung - UE Do., 4. Mai 2006 VU: /3 im SS 2006

77 Aufgaben für Projektmanager und –team gezielt anwenden können.
Übersicht: Fallbeispiel zur Software-Entwicklung (Aufgaben und Ziele zur 3. Einheit) Erstellung eines „Content Management Systems“ (CMS) für eine Geschäftsbank  Ressourcen unter Contentmanager.de, Agiles Projektmanagement und Methoden für Planung, Umsetzung, … anwenden, Aufgaben für Projektmanager und –team gezielt anwenden können. Do., 4. Mai 2006 VU: /3 im SS 2006

78 CMS: Erstellung eines Content Management Systems für eine Geschäftsbank
Was ist ein CMS? „Softwaresystem für das Administrieren von Web-inhalten mit Unterstützung des Erstellungsprozesses basierend auf der Trennung von Inhalten und Struktur.“ CMS Input Output Inhalte, Vorgaben, Struktur, … Do., 4. Mai 2006 VU: /3 im SS 2006

79 CMS: Planung (und Erstellung)
Aufgabenstellung(en) für Planung von … Webdesign, Datenbanken, Programmierung, Multimedia, …  mithilfe des Agilen Projektmanagements und Methoden Geschäftsbank Do., 4. Mai 2006 VU: /3 im SS 2006

80 CMS: Aufgabe(n) und Ziel(e) für Fallbeispiel
Aufgaben: Planung mithilfe der agilen Methoden (Gruppenarbeit)  Aufbau- und Ablauforganisation des Projekts XP (eXtreme Programming), DSDM, EVO, Crystal Clear, MSF (Microsoft Solutions Framework), … Ziele: Ausarbeitung des Fallbeispiels und Präsentation der Gruppenarbeit (inkl. aufgetretene Schwierigkeiten, … ) Scrum Do., 4. Mai 2006 VU: /3 im SS 2006

81 IV. LITERATUR Projektmanagement zur (erfolgreichen) Softwareentwicklung Zielgruppe: StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER Winf Lehre - VO Übung - UE Do., 4. Mai 2006 VU: /3 im SS 2006

82 Übersicht: Literaturquellen – eine Auswahl (zur 1. bis 3. Einheit)
Agiles Projektmanagement Agile Methoden Fallbeispiel: CMS Do., 4. Mai 2006 VU: /3 im SS 2006

83 1. Agiles Projektmanagement
[Gern2003] Gernert, Ch.: Agiles Projektmanagement – Risikogesteuerte Softwareentwicklung, ISBN: , Hanser Fachbuch Verlag. [Hrus2003] Hruschka, P. & Rupp, Chr. & Starke, G. (2003): Agility kompakt, ISBN: , Spektrum Akademischer Verlag. [Stro2003] Strohmeier, H. (2003): Architektur erfolgreicher Projekte - Objekte und agile Strukturen statt Aktivitäten und Phasen, ISBN: , Hanser Fachbuch Verlag. [Gras2004] Grasl, O. & Rohr, J. & Grasl, T. (2004): Prozessorientiertes Projektmanagement, ISBN: , Hanser Fachbuch Verlag. Do., 4. Mai 2006 VU: /3 im SS 2006

84 2. Agile Methoden Schwaber, K. & Beedle, M. (2002): Agile Software Development with SCRUM, ISBN: , 1st Edition, Upper Saddle River, New York, Prentice-Hall. Schwaber, K. (2004): Agile Project Management with Scrum, ISBN: x, Redmond, Washington, Microsoft Press. [Cock2004] Cockburn, A. (2004): Crystal Clear – A Human-Powered Methodology for Small Teams, ISBN: , Addison-Wesley Professional. [Popp2003] Poppendieck, M. & Poppendieck, T. (2003): Lean Software Development – An Agile Toolkit, ISBN: , Addison-Wesley Professional. Do., 4. Mai 2006 VU: /3 im SS 2006

85 Internetquellen: Addons für MS Project 2003
Add-On für Microsoft Project 2003 (Std. oder Prof.)  “Scrum Solution Starter” 1. URL: (Abfrage am ) 2. URL: (Abfrage am ) Do., 4. Mai 2006 VU: /3 im SS 2006

86 3. Fallbeispiel: CMS – Content Management System
Nix, M. (2005): Web Content Management, CMS verstehen und auswählen, ISBN: , 1. Auflage, Software & Support Schröer, M. (2004): Web Content Management mit PHP und MySQL, ISBN: X, 1. Auflage, Galileo Press Friedrichs, M / Portwich, G. / Thoss (2005): CMS in der Praxis, ISBN: , 1. Auflage, Hanser Verlag Meyer, R. (2005): Praxiswissen TYPO3, ISBN: X, 1. Auflage, OReilly Verlag Hauser, T / Wenz Ch. (2005): Mambo und Joomla!, ISBN: , 1. Auflage, Hanser Fachbuchverlag Do., 4. Mai 2006 VU: /3 im SS 2006

87 Internetquellen Kommerzielle Software IBM.com Software – DB2 Content Management Open-Source Software (Auswahl) Joomla.de – Joomla! 1.0.x Mamboserver.com – Mambo 4.5.x opensourceCMS.com typo3.com - TYPO3 Unterlagen Contentmanager.de oder Contentmanager.net – Das Content Management Portal … Do., 4. Mai 2006 VU: /3 im SS 2006