1 / 87

AGILES PROJEKTMANAGEMENT

AGILES PROJEKTMANAGEMENT. Einführung, Methoden und Fallbeispiel Zielgruppe: StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER. Winf. Lehre - VO. Übung - UE. Überblick und Gliederung.

tamah
Télécharger la présentation

AGILES PROJEKTMANAGEMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AGILES PROJEKTMANAGEMENT Einführung, Methoden und FallbeispielZielgruppe:StudentInnen der Wirtschaftsinformatik Vortragender: Andreas WÖBER Winf Lehre - VO Übung - UE VU: 050127/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 VU: 050127/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. VU: 050127/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 VU: 050127/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! VU: 050127/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 VU: 050127/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 ProjektmanagementGlossar - Agiles Projektmanagement (2005) VU: 050127/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!“ VU: 050127/3 im SS 2006

  9. Internetquelle: Artikelauswahlzu 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?“ VU: 050127/3 im SS 2006

  10. 1a.) „Wie erfolgreich sind Projekte?“ – Überblick über Studien und Umfragen (Auswahl) • Standish GroupBeurteilung 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-ProjekteUmfrage: „Woran scheitern IT-Projekte?“ (2002) • Bourton Group-Studie • Software Engineering Institute VU: 050127/3 im SS 2006

  11. 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? VU: 050127/3 im SS 2006

  12. 1c.) Erfolgsfaktoren (Standish Group, 2001) Quelle: Standish Group (Studien von 1994 und 2000) Umfrage des Managements von 365 Unternehmen nach den wesentlichen Erfolgsfaktoren für Software-Projekte VU: 050127/3 im SS 2006

  13. „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 VU: 050127/3 im SS 2006

  14. „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 ProjektmanagementGlossar - Agiles Projektmanagement (2005) VU: 050127/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 Zielefü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) VU: 050127/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 VU: 050127/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: http://agilemanifesto.org/ (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 (http://www.agilealliance.com/) VU: 050127/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) VU: 050127/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 VU: 050127/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 interactionsover processes and tools Working softwareover comprehensive documentation „Zusammenarbeit mit den Kunden“ vor vertraglicher Verhandlung Customer collaboration over contract negotiation „Reaktion auf Veränderung“ vor Einhaltung eines Plans Responding to changeover following a plan Quelle: http://agilemanifesto.org/ (2001) – Stand: 17.10.2005 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/3 im SS 2006

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

  38. 7b. Ohne Wissen und Disziplin funktioniert es nicht • Wissen • 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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/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 VU: 050127/3 im SS 2006

  43. Wiederholung: Einzelarbeit Kontrollfragen zur Wiederholung (1/2) • Handout (Multiple Choice Test, 5/2006) • Homepage zur Lehrveranstaltung: SS 2006Projektmanagment (Bakk.), 050.127 (VU)URL: http://www.pri.univie.ac.at/courses/inf-pm/ss06/index.php • Agiles Projektmanagement VU: 050127/3 im SS 2006

  44. II. AGILE METHODEN Projektmanagement zur (erfolgreichen) Softwareentwicklung Zielgruppe:StudentInnen der WirtschaftsinformatikVortragender: Andreas WÖBER Winf Lehre - VO Übung - UE VU: 050127/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 DevelopmentHistory: The Agile Manifesto VU: 050127/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 VU: 050127/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 VU: 050127/3 im SS 2006

  48. Scrum: „Was ist ein Scrum?“ (2/2) „Scrum is an agile, lightweight processthat can be used to manage and controlsoftware and product developmentusing 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: http://www.controlchaos.com/ (Mo., 17.10.2005) VU: 050127/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) VU: 050127/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? VU: 050127/3 im SS 2006

More Related