SieITMCi. Anforderungen in Agilen Frameworks: Mit KANBAN und Scrum zu ScrumBAN Synergien für Projekte und Organisationen. Wien

Transkript

1 SieITMCi Anforderungen in Agilen Frameworks: Mit KANBAN und Scrum zu ScrumBAN Synergien für Projekte und Organisationen Business-Analyse, Requirements und DevOps Day Wien

2 Inhalt Einleitung - Zum Thema Agilität und Einfachheit Beobachtungen bei der Einführung von Agilität im RE Irrtümliche Vereinfachungen und Probleme daraus Hindernisse überwinden Lösungen - Synergien Einsatz von Methoden und Werkzeugen Zusammenfassung Q&A 2

3 Einleitung - Zum Thema Agilität und Einfachheit HURRA, WIR SIND AGIL. Einige Thesen dazu: 1. Der Umgang mit Agilität (in IT-Projekten) ist nicht so einfach, wie leichtfertig angenommen wird. 2. Scrum ist gut, aber es passt eben nicht für alle Arten von Projekten / Teams 3. Die Einführung von Agilität beginnend beim Requirements Engineering erfordert Veränderungen: AUCH IN DER ORGANISATION Reflexion anhand von Beobachtungen in Beratungen 3

4 Das magische Dreieck Termin Kosten - Umfang Was ist Agilität?.. Iterative Entwicklung von inkrementellen Lieferungen mit einem agilen, adaptiven Framework wie SCRUM, Crystal, XP, DSDM, etc. UMFANG KOSTEN ZEIT agil traditionell KOSTEN ZEIT UMFANG Literaturhinweis: 4

5 EINFACH KOMPLIZIERT - KOMPLEX Klassische Vorgehensmodelle / PM Agile Modelle 5

6 Beobachtungen bei der Einführung von Agilität im RE 1. Anforderungen bleiben Anforderungen ob in klassischen oder agilen Methoden bearbeitet. Der Unterschied liegt nur im Zeitpunkt der Festlegung. -> Beobachtung: In agilen Projekten brauchen wir das nicht so genau. 2. Die Frameworks Scrum und KANBAN sind scheinbar einfach, aber müssen verstanden werden. -> Beobachtung: Erforderliche Kompetenzen (!) sind oft in der Organisation nicht vorhanden aber es wird begonnen 3. Auch die Abwicklung von Projekten mit agilen Frameworks erfordert geeignete Werkzeuge -> Beobachtung: Post-IT, Excel, Word, sind nach wie vor die Favoriten - UND TICKETS 6

7 Erforderliche Kompetenzen IREB CPRE Foundation Level + RE@Agile Tage IREB CPRE Advanced Level Management Level 3 Tage IREB CPRE Advanced Level Modeling Level 3 Tage Scrum Einführung Scrum.org basiert 3 Tage Kanban Einführung Anderson basiert 2 Tage Kostentreue HERSTELLEN AUFW 2 Tage An die individuelle Kundensituation angepasstes Curriculum (5-10 Tage) Scrum Master / Product Owner / Training / Coaching (Add On) Tage Analyse Prozesse / Werkzeugeinsatz für Agiles RE und Agile SW- Entwicklung (Scrum, Projektbeauftragung, Jira, Confluence, ) 2+n Tage BABOK IIBA 3 Tage 7

8 Irrtümliche Vereinfachungen und Probleme daraus Anleitung zum Scheitern : 1. Agiles Vorgehen ist so einfach, da braucht es nicht viel Ausbildung -> Probleme: Es reicht NICHT 1-2 Experten zu haben 2. Unverständnis über die Rollen besonders die der Scrum Master und Product Owner -> Probleme: Ein (externer) AGILER COACH reicht nicht! 3. Neue Vorgehensweisen sollen eingeführt werden, aber es soll sich in der Organisation nichts ändern -> Probleme: Weder das Alte, noch das Neue funktionieren 4. Schätzmethoden degenerieren zu Glücksspielen -> Probleme: Wozu Erfahrungsdaten. adaptiv wozu? Wenn es nicht klappt, probieren wir halt etwas anderes 8

9 Interfaces des Scrum Masters Entwicklungs- Team Kunde Anwender Product Owner Scrum Master Manager Artefakte Meetings Charts Prozess / Framework 9

10 Moderation Coaching Fähigkeiten / Kompetenzen eines Scrum Masters Trainieren / Mentoring Beobachten Hindernisse beseitigen Siehe auch Sochova, The Great Scrum Master S. 52 ff 10

11 Zum Handlungsfeld BEOBACHTEN Aus der Beobachtung (!) lassen sich Prognosen über die Team Perfomance machen 1 von 6 Beobachtungs- Kategorien Scrum Master als 360 Grad Beobachter Quelle: Journal for Software and Systems Engineering

12 Hindernisse überwinden Lösungen - Synergien Beharrlichkeit ist gefragt 1. Unrealistische Erwartungen -> Lösungsansatz: Der Organisation / dem Team Zeit geben 2. Unzureichende Kompetenzen -> Lösungsansatz : Ausbildung auf ALLEN Ebenen (auch HR) 3. Schwierige Organisationsanpassungen -> Lösungsansatz : MUT zu Neuem KLARE Lösungen 4. Fehlende Methodenanwendung -> Lösungsansatz : Standards und Erfahrungen nutzen 5. Unzureichende Werkzeuge -> Lösungsansatz : Evaluierung Pilotierung - Konsequenz 6. Das passt für uns nicht -> Lösungsansatz : Anpassung aber kein ScrumBUT -> ScrumBAN als hilfreicher Weg 12

13 Lösungsansatz: Scrum Rollenprofile Subjektive Einschätzung was erforderlich ist (R.S.) Skala: 0 nicht vorhanden 100 ausgeprägt vorhanden 13

14 Lösungsansatz: Kanban - Anwendung Blockade 5 Kanban Board (fast komplett) Thema Innovation Input Queue Analyse In Arbeit fertig Entwicklung In Arbeit fertig Test PULL Prinzip Fertig 2 Kunden- Projekte 2 Wartung Planungs- Meeting 14

15 Lösungsansatz: Methoden Kennzahlen im Requirements Engineering: Ableitung mit GQM Methode Goal Informationsbedarf Kundenzufriedenheit Fragen Question Question Wie schnell wird eine neue Anforderung realisiert? Wie vollständig ist die gelieferte Funktion? Metric Metric Metric (engl.) -> Kennzahl (dt.) Messung Umsetzungszeit Anforderung -> Realisierung Zurückgewiesene Fehler mit normales Verhalten 15

16 Was ist in KANBAN anders als in Scrum Wir können sofort (evolutionär) beginnen -> keine neuen Rollen erforderlich, vieles wiederverwendbar -> keine (prinzipiell) neuen Meetings erforderlich, nur EINES Eine genauere Betrachtung des Prozesses der Leistungserstellung (Prozess-Analyse) -> Voraussetzung für ein individuelles Kanban-System Eine andere Art der Priorisierung von Tickets -> Einführung von Serviceklassen -> Priorisierung auf der Basis von Verzögerungskosten Begrenzung der Arbeit durch Einführung von WiP Limits -> Limitierung gesamt, auf Serviceklasse, auf Arbeitstypen Ebene Einführung des Pull Prinzips statt des Push-Prinzips -> FUNDAMENTAL (!) Abarbeitung des Boards von rechts statt Sprint Ausführliche Metriken -> Umfangreiche Metriken zur laufenden Optimierung (Kundennutzen) 16

17 Scrum + KANBAN = ScrumBAN Hier gibt es viele Diskussionen Geschäftsfälle Mir geht es um: Tailoring: Das Beste von allen Methoden SCRUM KANBAN Synergien statt Ersatz SCRUM: Entwicklung KANBAN: Wartung / Support ScrumBAN: Kombination 17

18 Einsatz von Methoden und Werkzeugen Ein paar Leitgedanken zum Einsatz von Werkzeugen 1. Agiles Vorgehen schließt den Einsatz von Werkzeugen nicht aus. IM GEGENTEIL -> Herausforderung: Es müssen halt die richtigen Werkzeuge RICHTIG genutzt werden 2. Hilfreiche Methoden sind mit Werkzeugen besser umsetzbar. -> Herausforderung: Viele Werkzeuge sehr komplex zu bedienen 3. In vielen Domänen sind Methoden verpflichtend, die nur mit geeigneten Werkzeugen handhabbar sind -> Herausforderung: Die zu erfüllenden Standards oft unbekannt Agilität ist kein Synonym für Pfusch und Fahrlässigkeit 18

19 Lösungsansatz: Werkzeugeinsatz I Quelle: 19

20 Epics Storys - Planung Lösungsansatz: Werkzeugeinsatz II Reihenfolge User Activities und User Tasks Auch die Einführung solcher neuer Methoden -> Scrum Master 20

21 Zusammenfassung Q&A Requirements Engineering (RE) und das Management von Anforderungen erfordert auch in AGILEN PROJEKTEN genau so viel Aufmerksamkeit, Methodik und Genauigkeit wie in klassischen Projekten NUR alles zur richtigen Zeit. Beobachtungen in Projekten zur Einführung von Agilität zeigen, das Simplifizierungen zu Problemen und oft auch zum Scheitern der Projekte führen. Aber in agilen Frameworks ist adaptive Anpassung auch der Vorgehensweisen möglich. Anforderungen können (und sollen) auch in agilen Frameworks mit geeigneten Werkzeugen bearbeitet werden Es lohnt sich! 21

22 SieITMCi Siebenhofer.Consulting e.u. IT Beratung und Dienstleistung Ingenieurbüro für Informatik und Nachrichtentechnik Unternehmensberatung und Training A-4400 STEYR Christkindlweg 8 Tel.: +43(0) Fax: +43(0) Mob.: Siebenhofer@SieITMCi.com Web: Rudolf SIEBENHOFER, CMC 22