Dr. Michael ProMind. Definition of Done AGILES REQUIREMENTS ENGINEERING IN EINEM VERTEILTEN SOFTWAREPROJEKT ABER NICHT SO

Größe: px

Ab Seite anzeigen:

Download "Dr. Michael Amann @ ProMind. Definition of Done AGILES REQUIREMENTS ENGINEERING IN EINEM VERTEILTEN SOFTWAREPROJEKT ABER NICHT SO"

Andrea Acker
vor 8 Jahren
Abrufe

1 Dr. Michael ProMind Agiler Praktiker: Agilist seit 2007, mehrere Jahre Erfahrung als Master, Product Owner, Product Marketing Owner und Projekt Manager Coach: Agile Softwareentwicklung auch für große und verteilte Projekte, Prozessmanagement und Prozessautomatisierung, Qualitätsmanagement Tool-Coach: Unterstützung bei Auswahl, Programmierung, Anpassung und Weiterentwicklung von Continuous Delivery - im Einklang mit dem Prozess Lehrbeauftragter: Universität Klagenfurt, FH Steyr, FH Graz Campus 02 TITEL DATUM AGILES REQUIREMENTS ENGINEERING IN EINEM VERTEILTEN SOFTWAREPROJEKT NAME DR. MICHAEL AMANN 1 Entwickler: Java, JavaEE, Webtechnologien, Testautomatisierung, Modellgetriebene Entwicklung Trainer: Certified Agile Tester, Geshäftsprozessmanagement, Mobile App Development, Quality Management, Continuous Integration, TDD, BDD 2 Definition of Done Welches Projekt? Wie läuft RE in einem so großen Kontext? Was benötigen die Teams, um effizient zu sein? ABER NICHT SO MAN MUSS 3 4 STELLEN SIE SICH VOR... BEGLEITEN SIE MICH AUF EINE KLEINE REISE IN EIN REALES PROJEKT 5 SIE SIND SOFTWAREHERSTELLER MIT IHRER SOFTWARE WERDEN 6

2 TAUSENDE NEUE & GEBRAUCHTE AUTOS VERKAUFT WARTUNGEN UND REPARATUREN DURCHGEFÜHRT FAHRZEUGE VERKAUFEN REPARATUREN DURCHFÜHREN Dr. Michael Amann

3 SIE MÜSSEN EINE ENTSCHEIDUNG TREFFEN NEUENTWICKLUNG VS. WEITERENTWICKLUNG Quelle: 13 AGILITÄT - VIELE KÖNNEN ES NICHT MEHR HÖREN WEIL SIE WISSEN, DASS ES EINFACH NICHT FUNKTIONIERT 14 Eigentlich ganz einfach. Alles, was das alte System kann. DAS RICHTIGE PRODUKT RICHTIG ENTWICKELN RISIKOREDUKTION STEHT IM VORDERGRUND Eigentlich ganz einfach. Alles, was das alte System kann.! Aber auf jeden Fall brauchen wir auch noch Vor dem Projektstart (Iteration zero) 17 18

4 Wie arbeiten die Kunden? Agiles Requirements Management Single wring able neck! Verantwortet das Produkt What to do? Entwickelt Produktvision Priorisiert Anforderungen (User Stories) uct Prod r n w O e Product Management nunde Endk ht sic Fachliche Anforderungen! What to do? Entwickelt Produktvision Planung auf ebene mit Kunden Product Manager Domain 1 Jakob Product Manager Jakob Technische Anforderungen! What to do? Entwickelt Produkt Planung auf operativer Ebene Backlog Product Owner Kunde A Kunde B Kunde A Feature 1 Feature 54 Feature Alexander 21 RELEASE SUMMER 2014 Fachlich e und Technis che Sicht 22 -Domain Domain11 Backlog (All) Die Product Management Sicht Anforderungen (Epics) -Domain Domain 22 -Domain Domain 33 Epic 2013 Summer 2014 planung Handover Übergabe Team team11 Team team22 Domain 1 Grobe Definition der Features Team team33 Priorisierung im Backlog Gemeinsam mit Kunden Bereichspezifische Business Value steht im Vordergrund Cost of Delay Einschätzung Planungsmeeting Planing Meeting Task Sprint Backlog Komplexitätsschätzung Plan Kundenprojekte Sprint n Team 23 24

5 Feature Breakdown Backlog Backlog Sales Summer 2014 Feature 3 (Kunde A) Feature 3 (Kunde A) Backlog Sales Features müssen in einem fertig werden Komplexität wird geschätzt Verantwortliche Product Owner werden festgelegt Budget wird festgelegt Feature 54 (Kunde A) Feature 4 (Kunde A) Backlog Service Feature 18 (Kunde C) Spike 32 Story 24 Story 38 Story 12 Feature 3 (Kunde B) Domain Domain11 Backlog (All) Die Product Owner Sicht -Domain Domain 22 -Domain Domain Summer 2014 Themen (s) Thematische Gruppierung Handover Übergabe Epic Anforderungen (Spikes) Team team11 Team team22 Domain 1 Forschungsaufträge an das Team Team team33 Anforderungen (User Stories) Plan Kundenprojekte Bereichspezifische Funktionalität aus Benutzersicht Priorisierung im Team Backlog Definition der Akzeptanzkriterien Planungsmeeting Planing Meeting Technische Schuld (Debt Services) Refactorings Task Sprint Backlog Sprint n Bugs und Defects 27 Backlog Sales Feature 54 (Kunde A) Feature 4 (Kunde A) Product Development Backlog Service 1 Spike Backlog Service Feature 18 (Kunde C) Feature 3 (Kunde B) Team Lead 2 Base Teams RE BA CPO 7 Functional Team Architects TA Master SWE Product Owner Test Engieers 28 Projekt Feature 3 (Kunde A) Product Development Backlog Sales 1 Backlog Backlog Sales Summer 2014 Team RE BA Team Lead 1 Management Manager Architects TA Master SWE Product Owner Test Engieers Team Lead Master Product Owner Test Engieers 29 30

6 Requirements Engineering im verteilten agilen Projekt Die Team Sicht Fachexperte im Team! nts ireme Requ ineer g En Fachlicher Ansprechpartner für Oﬀ-Site Teams Vertritt Product Owner auf inhaltlicher Ebene Bearbeitet Kundenanforderungen RE BA TA SWE Product Owner Test Engieers 31 Epic Architects Master Development Tasks Quality Tasks Documentation Tasks Keine en Stund ngen u z t ä h sc Taskgrö ße < 1 Tag Task 32 -Domain Domain11 Backlog (All) -Domain Domain 33 Plan Kundenprojekte 2013 Summer 2014 Product Development Backlog Base 1 Sprint Backlog Base 1 Development Task Development Task Handover Übergabe Team team33 Quality Task Team team11 Team team22 Domain 1 Documentation Task Bereichspezifische Sprint 63 -Domain Domain 22 Development Task Quality Task Planungsmeeting Planing Meeting Documentation Task Sprint Backlog Sprint n Team Iteration Backlog Epic (CR) Analysis Spike Design Spike Debt Service Analysis Task Dev. Task Quality Task Doc. Task 35

7 User Stories und RE Epic ition Defin ne of Do Business Technically Preanalyzed analyzed pared Story Done InUser Progress In Verification Task Analysis Spike d Docu done Design Spike ZUSAMMENHÄNGE GESTALTEN SYSTEMSPEZIFIKATION IBM Jazz 4 Product Management Pläne Team Team RTC - Agiles Projektmanagement RRC: Systemdokumentation RQM: Testmanagement inkl. BDD Tests + 1,600 Work Items pro Monat Zusammenhänge Dokumentation entwickeln Zusammenhänge abbilden Geschäftsprozess Aktivitätsbeschreibung Funktionsbeschreibung Architektur Geschäftsprozesse Domänenmodell Rollen und Personas Leitlinien / Best Practices Aktivitäten Konzepte Funktionen Mockups 41 42

8 Geschäftsprozesse Funktionsbeschreibung 43 Systemspezifikation 44 Toolübergreifende Traceability Dokumente Planungsartefakte Prozessmodell Epic Systemfunktionen Konzepte Aktivitäten Domänenmodelle Mockups Artefakte Task Testpläne Ergebnisse Test Management System Specification (RRC) Test Cases (RQM) Business Processes User Stories (RTC) Activity Descriptions User Stories (RTC) Test Cases (RQM) Function Description 47 48

9 KUNDENZENTRIERTES REQUIREMENTS ENGINEERING SELBSTORGANISATION DER TEAMS DEN KUNDEN INVOLVIEREN PULL PRINZIP Dr. Michael Amann Dr. Michael Amann - KEINE KOMPROMISSE FORTSCHRITT MESSEN UND VISUALISIEREN BUGS UND NICHT ERFÜLLTE ANFORDERUNGEN KOSTEN ZEIT PERMANENTES FEEDBACK Dr. Michael Amann Customer Requirements by state 53 54

10 Essenz Agil ist nicht, was viele meinen Agilität heißt nicht, auf Anforderungen verzichten Agile Teams benötigen Agile Rahmenbed. Der Prozess entwickelt sich RE ist keine Frage der Tools - aber mit geht es oft leichter Kunde einbinden ist essenziell ProMind - Process and Software Engineering Dr. Michael michael.amann@pro-mind.com +43 (699)

Ähnliche Dokumente

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management