S. 1
HERMES AgilWege agiler Projektführung
S. 2
HERMES 5 heute
Traditionelles PM mit „Agiler Ergänzung“
Entscheidung Variante
Entscheidung Agil
S. 3
Leitfaden Agiles HERMES 5
Mitarbeit:
Andreas Hamberger (MitgliedThemengruppe)
Boris Bäsler (QS Scrum)
Daniel Kobi (Autor)
Frank H. Ritz (Autor)
Hans Dijkgraaf (QS HERMES 5)
Hans-Jürg Kleine (Autor)
Matthias Roth (Autor / LeiterThemengruppe)
Peter Lang (Autor / Lektor)
S. 4
Einbettung der User Group eco-HERMES
eco-HERMES
ISB / USIC / OSICproduziert
TÜV Süd(SAQ)
beau
ftra
gt
eCH
Zusammenarbeit
Personen
zertifiziert
AnwendersindMitglied
sind re
presen
tiert du
rch
standardisiert
Markt
Added Value
„Praxis-Sicht“
sind Mitglied
S. 5
Grundlage für Leitfaden Agiles HERMES 5
+SAFe®
Leitfaden
S. 6
Traditionelles PM vs. Agiles PM
TPM: was Manuals
APM: wie Best Practices
Best Practices Orientierung am Geschäftswert Adaption an Veränderung Rollierende Planung Timebox Feature Breakdown Selbstorganisation Trandsparenz und Rückkopplung
Leitfaden
S. 7
Agilität Blueprint
PMI-ACP®
Tools and techniques
Value driven, Storys …
Estimation, Planning ...
Knowledge and Skills
Performance, Enabler, ...
Self (Orga., Motivation) ...
Verschiedene methodische Ansätze:
• Scrum
• DSDM
• Crystal
• XP
• Lean
• Agile Modeling
• Scrum & Kanban = Scrumban
• SAFe ...
S. 8
Ansatz der TG Agiles HERMES
Entscheidung Agil, mglw. nach Variante Neue Technologie / Architektur
Leitfaden
S. 9
Variante: Projekt Simpel
Alle durch die Storys im BL betroffenen Dokumentations-Aspekte in KRE realisieren Backlogs pflegen: anpassen, priorisieren, ... Sprint – Organisation: Statistik: Burndown, Velocity, …; Demo, Review; Retrospective Impediment Backlog Konkretes Ergebnis (Shippable) zum Sprintende Betriebshandbuch Migrationsverfahren
Letzter Sprint: alle offenen Aspekte realisierter Storys finalisieren Projektschlussbeurteilung
Leitfaden
S. 10
Leitfaden
Demo
Demo, Plan. 1
wie
Was geschieht zusätzlich in jedem Sprint
S. 11
Leitfaden
Sprint Planung 1 und 2
S. 12
Variante: Neue Technologie / Architektur
Klare Vision, Einigkeit über Ziele, Anforderungen sind bekannt Infrastruktur: unbekannt / ist neu Risiken: Technologie, Skalierbarkeit 2. Freigabe: in Sprints Erfahrung sammeln (PoC) mit
Nichtfunktionalen Anforderungen Systemarchitektur
Leitfaden
2. Freigabe: PoC, Architektur
S. 13
Streams
1 Product Backlog n parallele Sprints mit S-BL Start Konzept mit einem initialen Stream BL - Zerlegung nach technologischer /
fachlicher Diversifizierung
Leitfaden
S. 14
Variante: N Entwickler-Teams
Mehrere Anwendergruppen, typisch f. grosse Projekte Verschiedene / Unklare Vision / Zielvorstellungen = Risiken 2. Freigabe: Erstellung gemeinsamer Infrastruktur und Vision Analog: Variante N Entwickler Teams und Zerlegung in Streams
2. Freigabe: gemeinsame Anforderungen, Parallelität
S. 15
Releases
Sprints ≠ Releases → Wird jedes Sprintergebnis ausgerollt? Durchläuft das Sprint-Ergebnis eine Staging-Umgebung (nicht-Agil) Für wen wird ausgerollt? PO, Stakeholder, Schulung oder Produktiv Releases: Produktiv setzen, für PO, Stakeholder, Schulung: Testumgebung
S. 16
Ergebnisse und Rollen am Beispiel der Variante “Simpel”
je Scenario / Variante aus Hermes 5 entnommen Ergebnisse Rollen
Nicht-Agile Ergebnisse sindgrün hinterlegt
Legende V – Verantwortlich
PL – Projektleiter ISDSV - Arch – Architekt PO – Product Owner SM – Scrum Master ET - Entwicklungsteam
S. 17
Konflikt: Agilität durch Flexibilisierung des Inhalts nach Business Valuebei Festpreisprojekten
Prinzip: Business Value stattFunktionalität
Business Value statt Zeit, Kosten, Inhalt →warum: Anforderungen, Integration,
Interaktionsfähigkeit ist erst durch Nutzungvollständig bekannt und verstanden
Unsicherheiten sind immer enthalten undzwangsläufig
Konsequenz
Magisches Sechseck erfahren einschätzen Ausschreibung für Business Value
(Backlog: Vision, Epics, Stories) gestalten kein Time & Material indikativer Festpreisrahmen (Optinenmodell) Rahmenwerk: Inkrementell / Iterativ Teile des
Werks vergeben (Optionen)
Organisation auf Agitität ausrichten
Magisches Sechseck: Anpassung von Anforderungen und Lösungen →inkrementelle Lieferung von Ergebnissen in Iterationen // Ergebnis: Höhere Zufriedenheit → aktuellere Lösungen (beste Software fürs Budget) Besseren Geschäftswert → intensive Interaktion mit dem Geschäft Bessere Qualität → frühere Qualitätssicherung mit dem Nutzer Vermeidung (Reduktion Umfang) unnötiger / aufwendiger Implementierungen
→ stetige Priorisierung des Nutzers
S. 18
Magisches Sechseck
Kombination von Management Dreieck (Traditionell,
Planungsgetrieben) 4 HERMES Dimensionen Agilem Dreieck(Werte- /
Geschäftsgetrieben auds Prozess)
durch Erweiterung von 2, 3weiteren Dimensionen Business Value Zufriedenheit Qualität (hat Agilität intrinsisch
zusammen mit Risiko)
Erfassen, Messen, Zeigen !
intrinsic:
Q/R
S. 19
Worst case: WTO - Ausschreibung
Worst case: Projektnatur: WTO-Ausschreibung Evaluation erforderlich: Risiken - unzureichende Funktionale Anforderungen Evaluation erforderlich: Nichtfunktionale Anforderungen unzureichend sicher
Erfordernis: Ausschreibung flexibel halten, auf „Business Value“ orientieren Inkrementell Iterativ freigeben: Evaluation, dann Umsetzung Ausschreibung sucht einen Lösungspartner Ausschreibung enthält Business Value und dessen inkrementelle / iterative
Verfeinerungswünsche
Neuen Change Freigeben
S. 20
Beispiel einer alternativen Story- / Sprint-Planungsmethodik MoSCoW
Agile Sprint Planungs Methodik, kommt ausden agiles Ansätzen des DSDM Konsortiums(Brit.); unterstützt KANO-Modell. Prio./SprintPlanung aus DSDM Ansatz entnehmen: Must Storys (essentiell) Should Storys (erfreulich) Could Storys (nebensächlich) Won‘t Storys (später oder gar nicht)
Bereits in den Phasen vor der PhaseKRE an Prinzip der Abarbeitung des Backlog Sprint- und Taskplanung Priorisierung Team-Performance
je Sprint denken
Effizienz und Effektivitätder agilen Methodikeinbringen. Scrum, aber nicht nur
Scrum Emotionale Intelligenz
hinzunehmen Sevant Leadership
Must or
Should, Could
or Won‘t
S. 21
Fragen Links
Links
User Group eco-HERMEShttp://www.eco-hermes.ch
Agiles Manifesthttp://www.agilemanifesto.org
Scrumhttp://scrum.orghttp://www.scrumguides.org/doc
s/scrumguide/v1/scrum-guide-us.pdf
Agilität, PMI-ACP®
http://www.pmi.org/certification/agile-management-acp.aspx
Unsere eMail: [email protected]
S. 22
Backup
S. 23
Verschiedene Anwendergruppen
Anforderungen verschiedener (neuer) Anwendergruppen sind nicht harmoniesiert Konsolidierte Sicht muss erarbeitet werden Architektur und Technologie sind jedoch bekannt und gesetzt Inkrementell Iterativ in wenigen kurzen Sprints diese Ziele erarbeiten bis ein Initiales
Backlog existiert (nicht Velocity relevant) PO gibt den Start für Initiales Backlog als gültig an.
Reguläres Projektvorgehen beginnt (Beginn der Messung von Velocity und anderen Kennzahlen)
S. 24
Entscheid Agile Entwicklung mit Scrum
S. 25
Product Backlog, Increment
S. 26
Sprint durchführen
S. 27
Product backlog führen
S. 28
Ergebnisse (Auschnitt Agil)
S. 29
Projekt führen
S. 30
Projekt steuern