Jetzt geht's los – agile Projekte starten

1.265 Aufrufe

Veröffentlicht am

Auch für agile Projekte gilt: Die Basis eines guten Projekts ist der Projektstart. Hier werden die Weichen gestellt und hier wird die Voraussetzung für den weiteren Projekterfolg geschaffen. Fehler, die zu Beginn gemacht werden, sind im späteren Projektverlauf nur noch schwer zu korrigieren. Aus diesem Grund ist die Beherrschung des agilen Starts sowie deren unterschiedlicher Aktivitäten von zentraler Bedeutung. Die Session sensibilisiert für die verschiedenen Aspekte und Risiken des agilen Projektstarts anhand praktischer Beispiele.

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.265
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
27
Aktionen
Geteilt
0
Downloads
13
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Jetzt geht's los – agile Projekte starten

  1. 1. Frank Düsterbeck Jetzt geht's los: agile Projekte starten
  2. 2. Fundament für Projektverlauf Festlegung Gesamtausrichtung Vorgehensweisen, Prozesse Technisch, fachlich Grundlage für Projekterfolg Grundlage für weitere Projekte Fehler die hier schon gemacht werden sind nur sehr sehr sehr schwer wieder behebbar! Sehr schwer!
  3. 3. Probleme Aufgaben Themen Herausforderungen Risiken
  4. 4. Neuer Kunde Zusammenarbeit noch nicht eingespielt Sprachgebrauch / fachliche Domäne Politische Rahmenbedingungen unbekannt
  5. 5. Stakeholder Fachpersonal nicht eingebunden Persönliche Interessen Politische Interessen
  6. 6. Ziele Ungenau Unrealistisch Nicht messbar
  7. 7. Anforderungen Nicht alle bekannt Technisch, fachlich Welcher technische Rahmen? Alle späteren Änderungen teuer Offenheit gegenüber Änderungen ist höher priorisiert als Planverfolgung
  8. 8. Planung Budget Zeit Menschen Ressourcen
  9. 9. Und nun?
  10. 10. Beherrschung des Projektstarts durch Strukturierung / Transparenz Bewusstmachung, Verdeutlichung und Nennung der Schlüsselthemen Erkennung von Schlüsselanforderungen Verbesserung der planerischen Basis Sensibilisierung bzgl. Tätigkeiten und Risiken Durch eine vernünftige Strukturierung!
  11. 11. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  12. 12. Vision Ziel des Projektes Erstellung eines Produktes Ergebnis des Produktes Welche Veränderung soll erzielt werden? Nutzen des Produktes Welche Verbesserung soll aus Ergebnis resultieren? Zielgruppe Wer soll mit dem Produkt arbeiten? Business Case Vision
  13. 13. Eindeutig, konsistent verständlich beschrieben Mess- und Prüfbar Zielklassen (Beispiel) Zeitlich Finanziell Leistung Sozial Akzeptiert von allen Stakeholdern Unabhängig von der Lösung Vision Vision - Ziele
  14. 14. Vorgaben Rahmenbedingungen Abhängigkeiten und Risiken Erste notwendige Anforderungen „Agenda des Lastenheftes“ inkl. Abgrenzung Priorität KostenTermine Leistung Vision Vision - Inhalt Kriterien für das Projektende
  15. 15. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  16. 16. Projektanalyse
  17. 17. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  18. 18. „Geben Sie uns mal 'nen groben Daumen“ Führt zur Beauftragung Siehe Planung Preisindikation
  19. 19. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  20. 20. Definierte Unterstützung unterschiedlicher Projektaktivitäten Projektmanagement, Qualitätsmanagement, Risikomanagement, Anforderungsmanagement Hilfestellung, Festlegung Vorgehensweisen, Aktivitäten Projekthandbuch, Teststrategie / Testkonzept, Handlungsanleitungen, Arbeitshilfen Vorgabendefinition Organisation
  21. 21. Vorgabendefinition Wie sieht mein Entwicklungsprozess aus?
  22. 22. Vorgabendefinition Macht Scrum denn immer Sinn?
  23. 23. Team Besetzung Organisation
  24. 24. Organisation Organisation Sind alle Arbeitsmittel und Räume vorhanden?
  25. 25. Scrum Gemeinsamer Sprachraum zwischen Team und Stakeholdern DoR (Definition of Ready) Wann ist ein Product Backlog Item bereit zur Umsetzung? Transparent, verstanden, kleinteilig DoD (Definition of Done) Wann ist ein Product Backlog Item Umgesetzt? Programmiert, akzeptanzgetestet, dokumentiert Sprintlänge, Sprintstart, Planning & Review Vorgabendefinition
  26. 26. Test Vorgabendefinition Anforderungen Entwurf Programmierung Test Noch Water Scrum:
  27. 27. Team muss gemeinsam das Ziel erreichen Stages suggerieren unterschiedliche Verantwortungen Nicht immer durchlaufen alle Tasks alle Stages Wo ist die Abgrenzung einer Stage? Wie sieht mein Scrum Board aus? Soll ich den trotzdem Test als zusätzliche Stage einbauen? Vorgabendefinition
  28. 28. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  29. 29. Extern Vermittlung der Vision durch Auftraggeber Kennenlernen Bildung einer gemeinsamen Basis eines gemeinsamen Verständnisses Teilnehmer: Interessensvertreter Auftraggeber, Product Owner, Auftragnehmer inkl. Eskalationsebenen, ggf. Scrum Team (Scrum Master, Entwickler) Kick-Offs
  30. 30. Kick-Off: Intern Vermittlung der Vision an Projektteam Definition zus. Organisations- und Kommunikationsstrukturen Teilnehmer: Product Owner, alle Projektbeteiligten des Auftragnehmers ! Vermittlung allein reicht nicht  Verbindlichkeit, Identifikation ist notwendig.  Würdet Ihr in das Produkt investieren? NEIN! Warum nicht? Kick-Offs
  31. 31. Strukturierung (Beispielweg) Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  32. 32. Produktplan Was? Product Backlog Releaseplan Wann? Zeitliche Wünsche, Priorität Ressourcenplan Wie? Welche Mitarbeiter, Ressourcen Planung
  33. 33. Produktplaung Was bekommt der Kunde? Tätigkeit oder Funktionalität? Funktionalität! Product Backlog Items Geordnet (Reihenfolge) User Stories, Fixes, usw. Planung Produkt- planung
  34. 34. Produktplanung User Story Hat nicht den Anspruch Anforderungen umfassend zu dokumentieren Wichtigkeit, Kosten, Nutzen, Risiken, Abhängigkeiten Erfüllt 3Cs und INVEST Hat eine Bewertung bzgl. ihrer Struktur Benutzerverwaltung Als Admin möchte ich Benutzer verwalten um Zugriffe zu sichern Planung
  35. 35. Produktplanung User Story Card Aussagefähiger, beschreibender Satz Conversation User Story ist Einladung zur Kommunikation Zwischen Stakeholdern, Product Owner, Scrum Team Anreichern (z.B. im Refinement) durch Use Case, UML-Grafik, Text, Aktivitätsdiagramme UI-Entwürfe, Prozess-Diagramme, Interfacebeschreibungen Planung Benutzerverwaltung Als Admin möchte ich Benutzer verwalten um Zugriffe zu sichern
  36. 36. Produktplanung User Story Confirmation Akzeptanzkriterien Grundlage für DoR Zur Qualitätssicherung Abnahme der Story Definition der DoD Herstellung der Messbarkeit Planung Benutzerverwaltung Als Admin möchte ich Benutzer verwalten um Zugriffe zu sichern
  37. 37. Produktplanung Story Points Bewertung der Struktur Größe Story ist starr Velocity Menge an Points, die ein Team pro Zeiteinheit schafft Abgewandelte Fibonacci-Reihe Je größer die Story, desto größer die Unsicherheit ½, 1, 2, 3, 5, 8, 13, 20, 40,  Basis ist Referenzstory (relative Schätzung) z.B. 5 ≡ Stammdatendialog mit mehreren Zuordnungen Planung Story Point Unsicherheit
  38. 38. Produktplanung Bewertung Team Estimation Game Ziel: Schnelle Schätzung großer Mengen Backlog Items Planung Produktplanung
  39. 39. Release- und Ressourcenplanung Value is created with every Sprint The product increment at the end of a Sprint is potentially usable Planung Und wie geht dann die Release- und Ressourcenplanung? Warum dann überhaupt ein Release? Weil ein Release auch immer eine Klammer für Prototypen, Installation, Migration, Schulung, Change Management, usw. ist
  40. 40. Releaseplanung Reihenfolge Planung What’s the next most important thing the system doesn’t do? Dan North
  41. 41. Basis Produkt Backlog Items Preisindikation aller Items, Bewertung über Referenzstory und Faktoren Genauere Planung nach z.B. 5 Sprints über Messung der Velocity Release- und Ressourcenplanung Planung Entscheide lieber ungefähr richtig, als genau falsch
  42. 42. Release- und Ressourcenplanung Welches Angebot ist genauer? Welches kostet mehr? Lastenheft Plichtenheft Umsetzung Product Backlog Refinement Umsetzung CR CR Umsetzung Klassisch Agil Planung Preisindikation Preisindikation Angebot
  43. 43. Refinement Wie sieht mein Product Backlog aus? Planung
  44. 44. Jetzt geht‘s los Planung Vision ProjektanalyseVorgabendefinition Kick-Offs Preisindikation Organisation
  45. 45. Sprint 0? Ken Schwaber: “Sprint 0 has become a phrase misused to describe the planning that occurs prior to the first sprint” Sprint ist “timeboxed” und nicht länger als 1 Monat Also: Projekt startet mit Sprint 1
  46. 46. Framework Rahmen / Gerüst / Vorgabe / Standard / Kern der Anwendung Muss nicht abgeschlossen sein für Umsetzung fachlicher Anwendungsteile Wächst mit Projektfortschritt wird weiterentwickelt, modifiziert, refaktoriert Ziele Standardisierung, Erweiter- und Wiederverwendbarkeit !KISS !Clean Code Developer WPF WF ASP .NET EF MVC … Framework
  47. 47. Refactoring Ziele Konsolidierte Anpassung des Systems Vorbedingung Erkennung der Notwendigkeit Kontinuierlich und / oder dedizierte Sprints Definition der Inhalte einer Refaktorierungsphase Kunden frühzeitig einbinden
  48. 48. Kein Korsett / Dogma sondern Hilfe und Unterstützung Einfachheit Strukturierung Transparenz Sensibilisierung Beherrschung
  49. 49. FRANK DÜSTERBECK FRANK.DUESTERBECK@HEC.DE

×