RE im agilen Umfeld - Waste oder Value?

1.615 Aufrufe

Veröffentlicht am

Das Thema Requirements Engineering wird in der agilen Community durchaus immer noch kritisch gesehen. Es wird gerne gleichgesetzt mit einer „vollständigen“ Vorabspezifikation und einem Wasserfall-Vorgehen – kurz Waste.
Requirements Engineering (RE) ist kein Selbstzweck. Sehen wir RE jedoch als eine Disziplin im Software- oder Systems-Engineering, die uns hilft die richtigen und qualitätiv hochwertige Produkte und Systeme zu entwicklen, verfolgen wir damit einen Großteil der Ziele von agilen Vorgehensweisen.
In diesem Beitrag beleuchten wir, am Beispiel von Scrum wie Requirements Engineering in einer agilen Umgebung Value liefert. Hierzu betrachten wir den Product Owner, der eine zentrale und dennoch stiefmütterlich behandelte Rolle im Scrum Team spielt. Wir zeigen auf, wie RE-Methoden ihn und das Entwicklungsteam in seiner Arbeit da unterstützen, wo Scrum keine Antworten liefert.
Abschliessend machen wir uns auf die Suche nach Ursachen, die dazu führen, dass Aktivitäten des RE in einem agilen Umfeld als Waste empfunden werden: Sind Erhebungstechniken, Spezifikation, Qualitätskriterien, Traceability oder auch Requirements Management tatsächlich Waste?
Teams und Umfeld sind nicht alle gleich – ein „ideales“ Scrum-Umfeld, indem genau ein Team genau ein Produkt entwickelt ist nicht überall gegeben. Die Verwendung von RE in Organisationen, die z.B. mit vielen Teams ein Produkt entwickeln, wird notwendiger sein, als in dem oben beschrieben „idealisierten“ Scrum-Umfeld.
Wie erreichen wir auch in solchen Konstellationen ein Umdenken zu einem Umgang mit Requirements Engineering, um echten Value aus agilem Vorgehen zu erzielen?

0 Kommentare
5 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.615
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
161
Aktionen
Geteilt
0
Downloads
40
Kommentare
0
Gefällt mir
5
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

RE im agilen Umfeld - Waste oder Value?

  1. 1. Requirements Engineering in einer agilen Umgebung –Waste oder Value?Susanne Mühlbauer, HOOD GmbH HOOD GmbH Keltenring 7November 2012 82041 Oberhaching www.HOOD-Group.com
  2. 2. Unser GeschäftsfeldWir liefern unseren Kunden das Rüstzeug für die erfolgreiche Entwicklung komplexerProdukte, Dienstleistungen und Systeme durch Training, Beratung und Coaching.Unsere Kernkompetenz ist das Requirements Engineering mit all seinenSchnittstellen im Systems und Software Engineering. -2- © HOOD GmbH
  3. 3. HOOD- ExcellenceUnsere Konferenzen, Publikationen, Expertentalk REConf® Im HOOD Blog diskutieren wir ständig aktuelle Themen und Trends des Requirements Engingeering. Wir freuen uns darauf, Sie auf unserem Blog begrüßen zu dürfen: http://blog.hood-goup.comHOOD ist der Veranstalter vonEuropas größter RE-Konferenz -3- © HOOD GmbH
  4. 4. HOOD Portfolio -4- © HOOD GmbH
  5. 5. Was ist RE?Was ist Agile? Scrum und der Product Owner Wasteful und valuable RE Fazit -5- © HOOD GmbH
  6. 6. Requirements Engineering Verstehen Vereinbaren Sicherstellen Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt? Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechtevorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten. -6- © HOOD GmbH
  7. 7. Agile Scrum Guide Praktiken z.B. Scrum, XP, Crystal,… Agile Das agile Prinzipien Manifest Agile Werte -7-
  8. 8. Die Ideallinie für RE im agilen Umfeld finden! „So wenig wie möglich, soviel wie nötig.“ „Konventionell“ „Agile“ Schriftlich Konversation Spezifikation Just-in-Time „Vollständig“ Requirements Engineering Value-Orientiert Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechtevorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten. -8- © HOOD GmbH
  9. 9. Scrum undder Product Owner Wasteful undvaluable RE Fazit -9- © HOOD GmbH
  10. 10. Scrum – kurz und knapp Product Selected/ Backlog Sprint Backlog Potentiell lieferbares Sprint Produktinkrement Scrum Team -10- © HOOD GmbH
  11. 11. Wo haben wir es mit Anforderungen zu tun? Product Vision/ Implementation Scope Requirements Requirements Acceptance Product Selected/ Backlog Sprint Backlog Potentiell lieferbares Sprint ProduktinkrementBusiness/System Requirements Scrum Team -11- © HOOD GmbH
  12. 12. Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg Source: http://www.gamgea.com/wp-content/uploads/2009/04/the-incredibles-1-sized1.jpg Verantwortung des Product Owner • Product Backlog • Fachliche Klärung der Backlog Items • Wert des Produkts/ der Arbeit (ROI) PO • Priorisierung und Reihenfolge der Backlog Items Product Owner ist ein • Abnahme der Full-time Job Produktinkremente • Release Planung -12-
  13. 13. Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg Source: http://www.gamgea.com/wp-content/uploads/2009/04/the-incredibles-1-sized1.jpg PO Product Owner ist ein herausfordernder Job-13- • Project Management • Product Management • Fachliches Know How Fähigkeiten des Product Owner • Technisches Know How © HOOD GmbH • Requirements Engineering • Kommunikationsfähigkeiten
  14. 14. PO Scrum Team -14- © HOOD GmbH
  15. 15. Dem Product Owner gehört das Produkt – Konflikte mit anderen Rollen Business Analyst Unternehmens- führungProjektleiter ArchitektProdukt Manager Produkt/ System UX-Spezialist Product Marketing Owner Anforderungs- The Product Owner is responsible for maximizing the value of the product manager Vertrieb and the work of the Development Team. -15- © HOOD GmbH
  16. 16. Eine Lösungsmöglichkeit: Die bestehenden Rollen als Stakeholderbetrachten Requirements Engineering Product Owner Scrum Master Development Team Scrum Team Stakeholders -16- © HOOD GmbH
  17. 17. „Grooming the Backlog“Quelle: http://www.pfoten-und-co.de/fotos/pflegePferd.jpg • Detaillierte Requirements Analyse • Grosse Anforderungen splitten • (Re-) Priorisieren • (Re-) Schätzen -17- • Bearbeitungsreihenfolge LAS Zürich September 2012
  18. 18. Requirements Engineering innerhalb des Scrum Teams Systemintegration QM Product Architektur Owner Betrieb Scrum Master Development Team Scrum Team Stakeholders © HOOD GmbH
  19. 19. Wasteful und valuable RE Fazit Qualitäts-Erhebung Spezifikation kriterien Traceability -19- © HOOD GmbH
  20. 20. Magic Backlog Erhebungs- technikenSource: http://www.birgit-helfmann.de/pict/wunderlampe.jpg LAS Zürich September 2012
  21. 21. Beispiel: Von der Vision Visionzur User Story Business Business Plan Drivers Architektur- vision Minimum Marketable Product/ Feature Set Feature Feature Feature Feature Epic User User Epic Story Epic Story Epic User User Story Epic Story -21-
  22. 22. Product Vision - Beispiel Vision „All my music is in my pocket“ Apple Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten.Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten. -22- © HOOD GmbH
  23. 23. Requirements Engineering: Scope definieren Stakeholder Systemgrenze, -kontext und Analyse Schnittstellen -23- © HOOD GmbH
  24. 24. Erhebung und Priorisierung mit MuSCoW Product Backlog Feature/ MuSCoW EPIC EpicEPIC (ITEM) EPIC (ITEM) (ITEM) MuS CoW Feature/ Feature/ EPIC Epic EPIC Epic (ITEM) (ITEM)MuSCoW MuSCoW• Must Have – ohne das funktioniert das System nicht• Should Have• Could Have• Won‘t Have MuS CoW User EPIC Story EPIC (ITEM) User EPIC Story EPIC (ITEM) User EPIC Story (ITEM) (ITEM) (ITEM) -24- © HOOD GmbH
  25. 25. Architekturrelevante Anforderungen Architektur- vision 1. Architekturrelevante Anforderungen sind Anforderungen, die implizit oder explizit architekturrelevant sind. 2. Implizite Architekturanforderungen sind Anforderungen, die über ihre Eigenschaften als architekturrelevant eingeordnet werden.  Alle Anforderungen mit hohem Risiko, hoher Priorität oder geringer Stabilität können als architekturrelevant betrachtet werden. 3. Explizite Architekturanforderungen sind meist nicht-funktionale Anforderungen. Prinzip: Deferred Decisions -25- © HOOD GmbH
  26. 26. Evolving Architecture Architektur- vision Funktionalität Funktionalität validiert Architektur Quelle: Architektur nicht Architektur Codecentric, OS Information Days ohne Funktionalität 2012 t -26- © HOOD GmbH
  27. 27. Wasteful undvaluable RE Qualitäts-Spezifikation kriterien Traceability Fazit -27- © HOOD GmbH
  28. 28. Spezifikationen versus Product Backlog Product Backlog Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechtevorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten. -28- © HOOD GmbH
  29. 29. Was ist ein Backlog?Der Begriff „Backlog“ wird zum Beispiel in derAuftragsverwaltung verwendet und beinhaltet alle Product Backlogeingegangenen/ eingehenden Aufträge geordnet nachihrer Bearbeitungsreihenfolge.Über diese Liste werden alle nachfolgendenProzessschritte, wie Beschaffung und Produktion, geplantund gesteuert.Das Backlog findet nun in der agilen Softwareentwicklunganaloge Anwendung. Es enthält alle potenziellumzusetzenden Backlog Items, geordnet nach derReihenfolge ihrer Bearbeitung. Auf Basis dieser Listeerfolgt die Planung und Steuerung der Umsetzung. -29-
  30. 30. Aufbau eines Backlog Bearbeitungsreihenfolge Evolving Backlog -30-
  31. 31. Was sind Backlog ItemsBacklog Items sind solche Items, die geplant Ressourcen verbrauchen. Dazu zählenzum Beispiel: Features Issue Test Set (Test Run) Needs User Story Technische Anforderungen Market Requirement Defect Use Cases Nicht-funktionale Anforderungen -31-
  32. 32. Umdenken beim Requirements Engineering Funktionale Dekomposition Inkrementell, nutzenorientiert  Epic 1 Epic   User Story 1  User Story 1  User Story 2  User Story 3 User Story 2  Epic 2Ergebnis sichern – Gewinne realisieren  User Story 1 User Story 2 -32- © HOOD GmbH
  33. 33. „Wasserfallsprint“ Wasserfallsprínt -33-
  34. 34. „Wasserfallsprint“ Sprint 1 Input für Sprint Planning Realisation Requirements Definition Reviewt Wasserfallsprínt Baseline Approval  -34-
  35. 35. Iterativ und inkrementell Sprint 1 Sprint 2 Sprint 3 Sprint 4 Input für Sprint Planning Realisation Requirements Definition Reviewt  Baseline Approval Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der -35- HOOD Group verboten.
  36. 36. „Gut genug für den Moment“ 1. Minimum Marketable Product/ Feature Set 2. Walking Skeleton 3. Die einfachste Lösung, die funktioniert 4. Nur das Notwendigste wird vom System unterstützt 5. Was wäre, wenn wir heute liefern müssten (potentiell lieferbar) 6. Akzeptanzkriterien streichen 7. Bereits während der Erhebung priorisieren -36- © HOOD GmbH
  37. 37. Wasteful undvaluable RE Qualitäts- kriterien Traceability Fazit -37- © HOOD GmbH
  38. 38. Die Säulen der Qualität User Story I ndependent N egotiable AkzeptankriterienINVEST (Bill Wake) V aluable E stimable S mall T estable Card Conversation Confirmation -38-
  39. 39. Beispiel für Akzeptanzkriterien User Story: User Story „Als Marketing-MA will ich einen I ndependent Webseite Text auf der publizieren können.“ N egotiable Akzeptankriterien Akzeptanzkriterien: V 1. Das System muss ein aluable Review des Textes ermöglichen E stimable 2. Das System muss eine Freigabe des Textes S mall ermöglichen 3. … T estable Card Conversation Confirmation -39-
  40. 40. Qualität von Akzeptanzkriterien Verständlich User Story Atomar I ndependent Eindeutig N egotiable Akzeptankriterien Nachweisbar V aluable Widerspruchsfrei E stimable Notwendig Realisierbar S mall Lösungsneutral T estable Card Conversation Confirmation -40-
  41. 41. „Als Marketing-MA will ich einen Text auf der Webseite publizierenkönnen.“ Akzeptanzkriterien Text erstellen Review Aufgabe: Machen Sie daraus 3-4 User Stories Freigabe Publizieren -41-
  42. 42. Lösung:„Als Marketing-MA will ich einen Text auf der Webseite publizierenkönnen.“ Text erstellen 1. „Als Marketing-MA will ich einen Text erstellen können.“ Review Reihenfolge 2. „Als Marketing-MA will ich ein Review für einen Text durchführen können.“ Freigabe 3. „Als Marketing-MA will ich eine Freigabe für einen Text erhalten.“ Publizieren 4. „Als Marketing-MA will ich einen Text auf der Webseite publizieren können.“ -42-
  43. 43. Lösung 2:„Als Marketing-MA will ich einen Text auf der Webseite publizierenkönnen.“ Text erstellen 1. „Als Marketing-MA will ich einen Text erstellen und publizieren können.“ 2. „Als Marketing-MA will ich eine Freigabe für Review Reihenfolge einen Text erhalten.“ 3. „Als Marketing-MA will ich ein Review für einen Text durchführen können.“ Freigabe Publizieren -43-
  44. 44. Wasteful undvaluable RE Traceability Fazit -45- © HOOD GmbH
  45. 45. Bestehende Spezifikationen: Needs, Epics und Stories extrahieren Product Backlog Anforderungen „Miteinander reden statt - Verstehen - Gruppieren gegeneinander - Konsolidieren - Priorisieren schreiben“ - Abstimmen - Verlinken Quelle: mir leider unbekannt -46-
  46. 46. Traceability SW-Design dokumentiert Epic Benutzerdoku/ Fachliche Dokubeinhaltet testet Testfall Testlauf User Story realisiert User Source Story Code -47- © HOOD GmbH
  47. 47. Fazit -48- © HOOD GmbH
  48. 48. Requirements Engineering im agilen UmfeldSprint Verstehen Vereinbaren Sicherstellen Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt? Erheben Sprintziel Retro Scope Handschlag Automatisierung Vision MMP Doku Review Ziel Visualisieren DoD Akzeptanzkriterien Commitment frühes Feedback Konversation Fokus auf Value Traceability Stakeholder potentially Shippable Akzeptanzkriterien User Stories -49-
  49. 49. Nutzen Sie agile Werte und Prinzipien und werden Sie zu:http://www.drooglab.com/ -50- © HOOD GmbH
  50. 50. Fragen/ Diskussion
  51. 51. Kontakt Susanne Mühlbauer Susanne.Muehlbauer@HOOD-Group.com HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany http://blog.hood-goup.com Tel: 0049 89 4512 53 0 www.HOOD-Group.com -52- © HOOD GmbH
  52. 52. Quellen/ Links/ Zusatzinformation1. www.agilemanifesto.org2. www.scrum.org/Scrum-Guides3. Innovation Games: Creating Breakthrough Products Through Collaborative Play [Paperback], Luke Hohmann -53- © HOOD GmbH

×