• Share
  • Email
  • Embed
  • Like
  • Private Content
RE und Scrum - auf den zweiten Blick ein geniales Team
 

RE und Scrum - auf den zweiten Blick ein geniales Team

on

  • 374 views

Ist der häufig in agil arbeitenden Organisationen zu hörende Satz „wir arbeiten agil und benötigen kein RE mehr“ tatsächlich zutreffend? Ist die Zeit des RE durch die Verbreitung von agilen ...

Ist der häufig in agil arbeitenden Organisationen zu hörende Satz „wir arbeiten agil und benötigen kein RE mehr“ tatsächlich zutreffend? Ist die Zeit des RE durch die Verbreitung von agilen Methoden (z.B. durch das Scrum-Framework) abgelaufen? Der Eindruck könnte auf den ersten Blick entstehen, da die Aktivitäten des Requirements Engineering in der agilen Entwicklung nicht isoliert betrachtet werden.

Auf den zweiten Blick stellt sich heraus, dass Kenntnisse rund um RE-Methoden im agilen Umfeld nötiger sind denn je. Dies ergibt sich aus der Tatsache, dass immer größere Organisationen den Umstieg von ihren an Phasen und Dokumenten orientierten Prozessen zu einer agilen Entwicklung anstreben. Dies hat zur Folge, dass diese Organisationen häufig nicht individuell für genau einen Kunden implementieren, sondern zahlreiche Produkte für eine größere Kundenanzahl entwickeln. In einem agil-skalierten Umfeld.

Ein kleines Beispiel: In einem Review Meeting mit mehreren anwesenden Stakeholdern erhalten die Anwesenden einen Einblick in die bisherige Produktimplementierung und ergänzen die bisherige Implementierung mit neuen Wünschen - also mit weiteren Kundenanforderungen. Diese Anforderungen können sich widersprechen und schon muss der Product Owner die Anforderungen konsolidieren – eine typische RE-Aktivität.

Dieser Vortrag orientiert sich an zahlreichen dieser kleinen Beispiele, die in der alltäglichen Praxis vorkommen, und belegt dadurch die wachsende Bedeutung von RE-Kenntnissen im agil-skalierten Umfeld.

Statistics

Views

Total Views
374
Views on SlideShare
344
Embed Views
30

Actions

Likes
0
Downloads
4
Comments
0

2 Embeds 30

http://www.agile-by-hood.de 29
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Es muss nicht immer agil verwendet werden.Einfache = leicht erkennbar, wiederholbare MusterKompliziert = nicht einfach, aber immer noch erkennbar, das System ist vorhersehbarKomplex = nicht vollständig erkennbar, aber teilweise vorhersehbarChaotisch = weder erkennbar noch vorhersehbar.Bsp.:Mein Autoschlüssel ist einfach.Es dauerte etwa drei Sekunden, um zu verstehen, wie meine Autoschlüssel funktioniert. OK, vielleicht ist das nicht ganz richtig. Meiner hat eine Batterie drin. Wenn ich es auseinander zu nehmen, es könnte mich noch drei Stunden, um die Details zu verstehen. Aber ja, ich bin klug, ich werde zu verwalten.Mein Auto ist kompliziert.Es würde mich Jahre zu verstehen, wie mein Auto funktioniert. Und ich habe nicht die Absicht. Aber wenn ich es täte, dann eines Tages in ferner Zukunft würde ich mit Sicherheit der Zweck jeder Mechanismus und jedem Stromkreis kennen. Ich würde verstehen, wie sie zu kontrollieren, und ich wäre in der Lage, mein Auto auseinander nehmen und wieder zusammenbauen, fahren sie genau so, wie ich früher. In der Theorie, natürlich. In der Praxis tun nur echte Männer solche Dinge.Auto Verkehr ist komplex.Ich kann reisen und auf der gleichen Straße für 20 Jahre, und die Dinge würden jedes Mal anders. Es gibt keinen Weg, um vollständig zu verstehen und wissen, was um mich herum passiert auf der Straße, wenn ich fahre, wie andere Fahrer ihre Fahrzeuge zu betreiben, und wie die Menschen in den Straßen zu interagieren. Ich kann Vermutungen anstellen, und ich kann in Erfahrung Prognosen zu gewinnen. Aber ich werde nie sicher wissen.Auto Verkehr in Lagos (Nigeria) ist chaotisch.Wenn die Dinge zu komplex zu bekommen, sie leicht chaotisch. Verkehr in Lagos ist so schlecht, es ist nicht einmal vorhersehbar. Schlechte Infrastruktur und Planung, Haufen von Abfall, Umweltverschmutzung, mangelnde Sicherheit, Überschwemmungen und viele mehr Probleme machen es zu einem der schlimmsten Orte der Welt zu sein, als eine einfache Autofahrer.

RE und Scrum - auf den zweiten Blick ein geniales Team RE und Scrum - auf den zweiten Blick ein geniales Team Presentation Transcript

  • Andreas Becker Agile-by-HOOD 18.03.2014 RE und Scrum – auf den zweiten Blick ein geniales Team
  • Inhalt • Einleitung • Refinement • Vision • Planung • Abstimmung • Erhebung und Feedback • Weitere Rollen • Zusammenfassung oder muss es immer Scrum sein?
  • Klassische RE-Aktivitäten 3 Umfang definieren (Scoping) Erheben Spezifizieren VerwaltenModellieren Konsolidieren Konkretisieren Ableiten Abstimmen / Review Abnehmen Stakeholder- Management
  • Scrum: 3 – 3 – 5 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Stand: Scrum Guide 2013
  • In welchem Umfeld arbeiten Sie? 6 Kunde Product Owner ScrumMaster Entwicklerteam Kunde Product Owner ScrumMaster Entwicklerteam Kunde = Kunde Kunde Kunde Kunde Kunde Kunde Kunde Kunde KundeKunde Kunde Kunde Kunde Kunde Kunde Kunde
  • Refinement
  • Scrum - Framework 8 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 User Stor y
  • User Story 9 Als Administrator möchte ich Nutzer des Portal sperren können, um Missbrauch zu verhindern Rolle Funktionalität Nutzen / Grund Kommunikationsgrundlage
  • Quelle: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=4 Backlog Refinement
  • Scrum - Framework 11 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 Story Time User Stor y „…10% der Zeit des Entwicklungsteams für die Beschäftigung mit zukünftigen Anforderungen…“
  • Akzeptanzkriterien – es müssen nicht immer Stichworte sein 12 Tabellen Als Nutzer möchte ich mein Profil löschen können, um keine Daten im Netz zu hinterlassen.  Given - der Nutzer ist eingeloggt  and er hat keine aktuellen Buchungen von Mitfahrgelegenheiten  When - der Löschbutton wird betätigt  die Anfrage wird bestätigt  Then - der Nutzer bekommt eine Bestätigungs- eMail  and die Daten des Nutzers werden aus der Datenbank gelöscht Konkretes Beispiel
  • Schätzung und Dialog 13 User Stor y
  • Von der Idee zur Umsetzung 14 Epic User Story Erste Vorstellung der User Story + Akzeptanzkriterien Vollständig verstandene User Story + Akzeptanzkriterien Kommunikative Ergänzungen zur User Story R E F I N E M E N T Sprint Planning Story Time Sprint Product Backlog Schätzung der User Story Story Time
  • Backlog-Management Agilität erleben Portfolio Backlog Feature Backlog Product Backlogs Sprint Backlogs NFA Architektur- entscheidungen User Story User Story User Story User Story User Story User Story Task Task Task Task Task Task Task Task Task GesetzeGf-Ziele Use Case Feature ….. 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- … … …. Nachverfolgbarkeit z.B. Sicherheits- anforderungen Akzeptanz- kriterienAkzeptanz- kriterienAkzeptanz- kriterien
  • Status „Ready“ und „Done“ • READY – Qualität der User Story (Anforderungen) • DONE – Abnahmekriterien für User Story (Anforderungen) 16 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkreme ntSprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage R E A D Y D O N E
  • Vision
  • Scrum 18 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 Vision
  • Quelle: Alice im Wunderland, Film 2010
  • "Würdest Du mir bitte sagen, welchen Weg ich einschlagen muss?" "Das hängt in beträchtlichem Maße davon ab, wohin du gehen willst" "Oh, das ist mir ziemlich gleichgültig" "Dann ist es auch einerlei, welchen Weg du einschlägst" Quelle „Alice im Wunderland“ Lewis Carroll / 26. 11 1865
  • Vision Board 21
  • Planung
  • „Wir können nicht hinter den Horizont schauen“ (Mike Cohn) -24-
  • Scrum 25 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013
  • Abhängig vom Planungskontext sind unterschiedliche Planungshorizonte* notwendig *: basierend auf Ellen Gottesdiener PO und ManagementPO-Team Scrum-Team Sprint Release (1-6 Monate) Roadmap (6 Mon. – 2 Jahre)
  • Ziele der Planungshorizonte *: basierend auf Ellen Gottesdiener  Ausblick auf kommende Themen / Epics / Feature  Gemeinsames Verständnis erzielen  Konkrete Fragen des Teams beantworten  Akzeptanzkriterien ergänzen  User Stories schätzen  Ermittlung von Abhängigkeiten  Epics / Feature  Epics in User Stories splitten  Grobe Varianten erörtern und schätzen Nächste 1-2 Sprints Release- Vorschau Das große Ganze Roadmap
  • Abstimmung
  • Scrum – ein Blick ins Daily 29 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013
  • Daily - Scrum 30 „…und ich mach die Toten“ …Ich mache den Task „DB-Modell“ anpassen … …Ich mache den Task „Menueleiste anpassen„… ? „…die Toten machen wir nicht…“
  • Scrum – mit vielen POs 31 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 PRE Planning
  • Product Owner Pre-Planning -32- Velocity Velocity Velocity Produktvision  Abgleich der geplanten Backlog Items mit Strategie  Fachliche Abhängigkeiten  Technische Abhängigkeiten  Know How Transfer Sprint oder Release Architektur- Vision Chief Product Owner PO Pre-Planning Product Owner Product Owner Product Owner Abgestimmtes Backlog
  • Anforderungserhebung
  • 34
  • Sprint Review – die traurige Realität ScrumMaster Entwicklerteam Product Owner
  • Sprint Review als Feedback- und Erhebungsworkshop „Das Ergebnis des Sprint Reviews ist ein potentiell neu organisiertes Product Backlog, bei dem die am höchsten bewerteten Product Backlog-Einträge am wahrscheinlichsten für das nächste Sprint Planning ausgewählt werden.“ Quelle: Scrum Guide 2013 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done
  • Umdenken Funktionale Dekomposition Agiles nutzenorientiertes Umfeld Epic User Story 1 User Story 2 User Story 3    Epic 1 User Story 1  Epic 2 User Story 1  Feedback Potentiell lieferbares Produkt- inkrement Feedback Potentiell lieferbares Produkt- inkrement User Story 2 User Story 3  
  • Feedback im agil skalierten Umfeld Hotline Endanwender Session-basiertes Testen …. Beta-Kunden / Pilotierung Endanwender EndanwenderPilotierungskunden Optionale Nutzung Product Owner Review-Event (Feedback- & Erhebungsworkshop) Videoaufzeichung Scouts beim Endkunden Usability Prototyping UX Usability Testing
  • Rollen im Business-Team
  • Der PO – ein Superheld? 40 Product Owner
  • Terminator Quelle: http://www.fuenf-filmfreunde.de/2009/04/23/ist-arnold-schwarzenegger-im-neuen-terminator-salvation-doch-zu-sehen/
  • NORMator Quelle: http://prem666.deviantart.com/art/Terminator-Robot-Face-398031009
  • NORMator – der Mann / die Frau für das regulierte Umfeld NORMator
  • Dokumentation 44 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkreme ntSprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done NORMatorDoR / DoD Sprint Notes Team Charta Architecture Notes Release Notes Test Documentation Prozess
  • NORMator im Überblick Agilität erleben 45 NORMator Validierung der Gebrauchstauglichkeit - User - Gebrauchsformen - Szenarien - Schnittstellen Risikomanagement - Risikoanalyse - Maßnahmen - Dokumentation Traceability sicherstellen …… Vollständigkeit der Dokumentation - Prozessvorgehen - Sprintnachweis - Architektur - Teamcharta - ….
  • Business-Team mit PO und NORMator 46 NORMator Product Owner
  • Der Business Analyst – was wird aus ihm? 47 Business Analyst
  • Story Mapping Prozess (zeitlicher Ablauf) … … … …… Aktivitäten R a n k i n g Aufgaben/ Tasks …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. ……..
  • Story Mapping – Beispiel „Buchversand“ Prozess (zeitlicher Ablauf) Buchung finden Angebote sichern Bestellen- daten Bestellinfor- mationen Zahlungs- möglichkeiten Aktivitäten R a n k i n g Aufgaben/ Tasks Warenkorb legen Merkliste speichern Wunschliste speichern Lieferadresse eingeben Rechnungs- adresse eingeben Voraus- überweisung Per PayPal zahlen Bestellstatus- Informationen einsehen Kreditkarte nutzen Suche durch Titel Suche nach Autor Suche nach ISBN-Nr …….. Per Rechnung zahlen
  • Business-Team mit PO, BA und NORMator 50 NORMator Product Owner Business Analyst Prozess (zeitlicher Ablauf) Aktivitäten R a n k i n g Aufgaben / Tasks
  • Zusammenfassung
  • Scrum und mögliche Erweiterungen 52 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Scrum Guide 2013 Story Time User Stor y Vision R E A D Y D O N E PRE Planning NORMator
  • Software-Entwicklung ist häufig komplex Technologie Anforderungen bekannt unbekannt bekanntunbekannt
  • Merkmale eines agilen Requirements Engineering – es muss nicht immer Scrum sein  RE ist eine kontinuierliche Tätigkeit und endet nicht nach einer Phase  Abkehr von der Vorstellung einer vollständigen Spezifikation / Änderungen sind willkommen  Direkte Kommunikation steht im Mittelpunkt und nicht die Spezifikation  „Wert“ einzelner Funktionen steht im Fokus und beeinflussen Rangfolge  Kontinuierliches Feedback  Teammitglieder und deren Know-how werden involviert  Abkehr einer „in Stein gemeißelten“ Kosten- und Zeitplanung am Anfang eines Projekts  Verschwendung vermeiden
  • Das Agile Manifest – 12 Prinzipien -55- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
  • Fragen und Diskussion
  • Andreas.Becker@HOOD-Group.com HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.Agile-by-HOOD.com Andreas Becker Agile Coach