1 Shipping Software Raiffeisen Bausparkasse V-ARC, 21.12.2011 Gerhard H. Leonhartsberger It s all about shipping software! Seite 2
2 How fast do you ship quality software? Seite 3 Software Entwicklung bei Raibau Ziel ist Software zu liefern (einzusetzen) - Alle Beiträge zur Zielerreichung sind gut. - Alle Beiträge, die kaum oder nicht zur Zielerreichung führen sind schlecht. Software Entwicklungsprozess muss beitragen - die Vorhersagbarkeit zu erhöhen - ein definiertes Qualitätsniveau zu halten Stetige Weiterentwicklung - Bewusste Gestaltung, Anpassung, Veränderung Seite 4
3 Teams 4 interdisziplinäre Scrum Teams mit Product Owner und Scrum Master 4 Software Produkte für die Abwicklung des Bauspargeschäfts für unterschiedliche Vertriebspartner Software Produkt Management Team - Planung, Organisation und Steuerung der Software Produkte - Internes, Externes Marketing - Stellen Product Owner für Scrum Teams - Lean Academy Seite 5 Software Product Management Product Management Team Fachbereich 4 Fachbereich 1 Fachbereich 3 Fachbereich 2 Seite 6
4 Raibau Boards BMC Business Management Committee PMC Project Management Committee AMC Architecture Management Committee Seite 7 Team Member Recognition In Scrum: - Alle Team Mitglieder sind gleich! Bei Raibau: - Werte-Skala basiert auf der Fähigkeit qualitativ-hochwertige Software zu liefern Werte-Skala 1. If you ship quality software, you may speak! 2. Did you ever ship anything? 3. You never shipped anything! Seite 8
5 Agile Analyse Seite 9 Agile Analyse Oder anders - Wie komme ich zu einem initialen, priorisierten Product Backlog? Praktiken bei Raibau - Early Incremental Planning - Personas - User Stories, Story Points und Planning Poker - User Story Writing Workshops - Paper Prototypen und Story Boards - Usability Workshops - Cross functional Teams Seite 10
6 Early Incremental Planning Big Picture of a Release: Project Plan 1 2 3 4 Release Topic ( Anforderung ) Funktionalität Thema Aspekt + 5 Seite 11 Early Incremental Planning Product Management Team Fachbereich 4 Fachbereich 1 Fachbereich 3 Fachbereich 2 Seite 12
Early Incremental Planning Product Management Team Product Owner Sprint 1 Sprint 2 Project Plan Product Owner Sprint 1 Project Plan Project Plan Product Owner Sprint 1 Sprint 2 Seite 13 Plan Item Workflow Evaluierung Kunde und PO treffen eine Vorauswahl und erstellen eine ANF Idee im Jira. PO bekommt eine ANF zugewiesen. Die Analyse beginnt. Die Analyse ist abgeschlossen. Kann dem Steuerungsboard vorgelegt werden. I d e e PO NEW ANALYZING EVALUATED Zustandsergebnis: ACCEPTED Ergebnis ist eine kompakte Beschreibung eines Themas/Idee mit folgende Aspekten: Motivation Lösungsansatz Big Picture Risiken Arbeitsgebiete für Umsetzung Business Case Bildet die Entscheidungsgrundlage für das Business/IT Board!! Seite 14 7
Plan Item Workflow Umsetzung PO bekommt eine ANF zugewiesen. Die Umsetzung nach Scrum beginnt. PO begleitet die Umsetzung, bereitet die monatlichen Themen vor. Die Umsetzung ist abgeschlossen. PO und FB kann mit Abnahme beginnen. Akzeptanz- Phase. APPROVED IN PROGRESS SCOPE COMPLETE DELIVERED Zustandsergebnis: ACCEPTED Zustandsergebnis: ACCEPTED INCOMPLETE Genehmigung durch das REJECTED Business/IT Seuererungsboard. Sowohl das Ergebnis aus der Analysephase als auch die Entscheidung des Business/IT Seuererungsboard kann negativ sein. EVALUATED APPROVED Zustandsergebnis: REJECTED Seite 15 Early Incremental Planning Erarbeiten Projektpläne für Software Release - In Form von priorisierten Product Backlogs - Eintrag im Product Backlog ist ein Plan Item ( Anforderung ) - Plan Item kann eine Funktionalität, Thema oder Aspekt sein, der realisiert wird. - Business Value jeder Plan Items wird berechnet. - Bug Fixing, Testfälle, Dokumentation, Beispiele, Performance Optimierungen, Usability Verbesserungen, etc sind nicht in den Projektplänen aufgelistet, außer es werden erhöhte Aufwände erwartet. - Definieren Anzahl und Länge der Sprints Release Trains - Release Train definierte Meilensteine einer Simultan-Release mehrer Software Produkte. - Meilenstein Termine, End Gaming, Abnahme - Koordination Project Plans werden monatlich aktualisiert. - Fortschritt zu zeigen - Veränderungen frühzeitig sichtbar zu machen - Die finale Version der Projektpläne entsteht zum Release Zeitpunkt. Tools - Jira Seite 16 8
9 Personas Personas sind virtuelle Personen Helfen bei UI-Entscheidungen einen passenden Lösungsansatz zu finden. Aus verschiedenen empirischen Studien hat sich gezeigt, dass es ausreicht zwei gegensätzliche Charaktere zu definieren, um die Adäquatheit von Benutzer-Konzepten zu überprüfen. Seite 17 User Stories, Story Points und Planning Poker Es gibt nur User Stories keine Tech Stories Story Points werden im Planning Poker bei Sprint Planung geschätzt Seite 18
10 User Story Writing Workshops Ziel - Anforderungen zu einem Thema zu erarbeiten Es nehmen nur jene Personen teil, die zum Thema beitragen können ohne Rücksicht auf Hierarchie - Anwender, Entwickler, Architekten, Abteilungsleiter, etc. Team Work Rooms mit Multi User Editor - Jeder Teilnehmer hat Laptop mit Multi User Editor Ablauf - Product Owner stellt Thema und Personas vor. - Gemeinsames Schreiben der User Stories jeder schreibt das Wichtigste aus seiner Sicht zum Thema - Anschließend bewerten, gruppieren, priorisieren und Vorbereitung für Planning Poker mit Team Sind zu User Stories weitere Informationen für die Umsetzung notwendig, so werden diese gesammelt (in Form von UIs, Aufzählungen, etc.) Beispiel: Welche Daten hat ein Bausparvertrag - Time-boxed Seite 19 User Story Writing Workshops Seite 20
11 Paper Prototypen und Story Boards Ziel - Visualisierung Benutzerinteraktionen - Early Feedback Zutaten - Kreativität - Papier - Bleistift - Klebstoff Seite 21 Usability Workshops Ziel - Frühzeitige Überprüfung der Nutzbarkeit Wie - Mit Paper Prototypen (Workshop wird gefilmt) - Mit Software Prototypen Wer - Anwenderkreis der Personas - Team, Product Owner, Scrum Master Seite 22
12 Cross Functional Teams Komponenten/Produkt übergreifende Funktionalitäten werden durch eigenes Team bearbeitet bis Product Owner grünes Licht gibt. - Dynamische Teams - Existieren nur bis Thema gelöst Seite 23 Backup
13 Agile Software Entwicklung Empirisches Management zur Steuerung komplexer Systeme - (vlg. Fredmund Malik & Stafford Beer Management-Kybernetik ) - Software-Entwicklung = komplexes System Anforderungen Technologie Menschen Empirisches Management durch empirische Prozesskontrolle Sichtbarkeit und Transparenz aller Aspekte bei der Software- Entwicklung, die das Ergebnis beeinflussen Häufiges und wiederholtes Beobachten des Verlaufs und der Ergebnisse der Prozesse Anpassungen werden bis zu einem bestimmten Limit akzeptiert Seite 25 Fokus on Change Wie schnell kann ein Manöver durchgeführt werden? - Was muss ich alles ändern, um eine Kurs-Korrektur vorzunehmen? - Welche Einstellungen brauchen Mitarbeiter dafür? Änderungen so einfach wie möglich machen! - Reduzierung der Tools - Reduzierung der Analyse-Dokumente - Fokussierung auf Whiteboard und Pinwand - Erhöhung der Kommunikation Seite 26