Anforderungen im Spannungsumfeld von Scrum

Transkript

1 Anforderungen im Spannungsumfeld von Scrum Raphael Auf der Maur Business Analyst & Project Leader Dipl. Inf. Ing. ETH, CSPO, Certified Professional RE

2 Motivation Der wesentliche Unterschied Requirements Management in Scrum Die Rolle des Requirements Engineers in Scrum Fazit

3 Motivation

4 Scrum Übersicht

5 Motivation Der wesentliche Unterschied Requirements Management in Scrum Die Rolle des Requirements Engineers in Scrum Fazit

6 Mindset

7

8 Kostenfaktor Big Requirements up-front (BRUF) Nutzungsrate von Funktionen Source: Jim Johnson of the Standish Group, Keynote Speech XP Nie Selten Manchmal Oft Immer

9 Problematik Big Requirements up-front

10 Klassisches vs. agiles Requirements Engineering Klassisches RE Gesamtheit aller Anforderungen vorgängig erfassen Möglichst wenige Änderungen nach Umsetzungsstart Auftragsorientiert RE findet vor allem vor Implementationsbeginn statt vollständigkeitsorientiert Stabilitäts- und Abgrenzungsorientiert Abgleich über Dokumentenreview Optimierung der Anforderungen ARE Wichtigste Themen zu konkreten Anforderungen detaillieren. Änderungen können jederzeit am Backlog vorgenommen werden. Produktorientiert Kontinuierliches RE während ganzem Projekt prioritätenorientiert Permanente Verfeinerung, möglichst hohe Flexibilität Abgleich über lauffähige Software Optimierung des Produkts

11 RE Aufwand Iteration Iteration Iteration Oft praktiziert Grob- Spezifikation Detailspezifikation Architektur Testing iteratives Projekt Zeit

12 RE Aufwand Anti-Pattern Grob- Spezifikation Detailspezifikation Architektur Umwandlung in User Stories Testing Scrum in der Umsetzung -Projekt Zeit

13 RE Aufwand Scrum Vision & initiales Backlog The Real Scrum Erster Release zweiter Release Zeit

14 Motivation Der wesentliche Unterschied Requirements Management in Scrum Die Rolle des Requirements Engineers in Scrum Fazit

15 DEEP - Product Backlog Product Backlog DEEP Mai Juni Q3 Feingranulare, detaillierte Stories mit Akzeptanzkriterien, bereit für die Umsetzung im nächsten Sprint. Noch unklare Requirements, die in den kommenden Sprints noch detaillierter abgeklärt werden müssen. Detailed appropriatly Estimated Emergent Priorized 2012 Epic oder Features, die der Kunde für das Produkt haben will, die für die ersten Prototypen oder Releases noch nicht relevant sind.

16 User Story As a <type of user>, I want <some goal> so that <some reason>. Story Description As a skilift operator, I want to be able to count all lift rides grouped by ticket type, so that I am able to account the tickets with other skilift companies in the ressort at the end of the month. Acceptance Criteria - show screen where all ticket types are shown with ticket name, the total lift ride count for the season per line. - Screen must be pixel and color accurate with User Interface Design, Page 13 - ticket names which are too long for one row shall be shortened with Elipsis. - report selection criteria must include from and to date as a date selector control. Dates must be changeable manually (format DD.MM.YYYY) and are validated on input time (from date must be after to date and in correct format). Validation error highlights box according UID. - Default selection times are 1st of november of current season (from) and 31st of april of current season (e.g ) - systems response time must be below 1 second in 90% of the cases and below 3 seconds in 100% of the cases. - On Demo: simulate a lift ride with an adult day pass ticket and show effect on summary report. Priority 633 Story Points 13 Comments Export to Excel, PDF, CSV will be part of another story. Story ID: 53.6

17 Communication

18 Eigenschaften einer User Story - INVEST Independent Negotiable Valuable Small Estimatable Testable

19 vertikale Requirements Story User Interface Business Layer Data Access Layer 1 Scrum Team Beispiel: The system shall be able to store a price in EUR, CHF and USD for a ticket. vs. As an operator, I want to be able to define ticket prices for the tickets defined in the system in the administration screen.

20 Inkrementell erweiterte Stories Als Verkäufer will ich in der Lage sein, Artikel mit einem Titel und einem Beschreibungstext in den Shop zu stellen, um unseren Kunden unser Sortiment zu zeigen und dies von Suchmaschinen finden zu lassen. Als Verkäufer will ich in der Lage sein, einen Artikel mit einem Titel, einem Text und einem Preis in den Shop zu stellen und diesen Artikel später ändern zu können, um unseren Kunden unsere aktuellen Angebote anzubieten und... Als Verkäufer will ich in der Lage sein, einen Artikel mit einem Titel, einem Text und einem Preis in den Shop zu stellen, diesen Artikel ändern und von den Benutzern bewerten und kommentieren zu lassen, um.

21 User Story vs. (?) Requirement Eine Story ist ein gutes Requirement Ähnlichkeiten mit Use Cases testbare Akzeptanzkriterien berücksichtigt Umfang der Funktionalität umsetzbar in einem Sprint im Zweifelsfall lieber zwei kleine Stories als eine Grössere beinhaltet eine Begründung, wozu die Funktionalität gebraucht wird. vertikaler Schnitt durch alle Umsetzungsebenen wird bei Bedarf mit Aktivitätsdiagrammen, Wireframes etc. ergänzt

22 Motivation Der wesentliche Unterschied Requirements Management in Scrum Die Rolle des Requirements Engineers in Scrum Fazit

23 Definierte Rollen in Scrum Scrum Master Stakeholders Product Owner Scrum Team

24

25 Requirements Engineer in Scrum Scrum Master Stakeholders Product Owner Scrum Team

26 Requirements Engineer in Scrum Scrum Master Stakeholders Product Owner Scrum Team

27 Requirements Engineer in Scrum Scrum Master Stakeholders PO Story Owner Scrum Team

28 Motivation Der wesentliche Unterschied Requirements Management in Scrum Die Rolle des Requirements Engineers in Scrum Fazit

29 Fazit Requirements werden nicht mehr komplett upfront, sondern just-in-time erstellt. Änderungen an Requirements sind willkommen jederzeit. Requirements Engineering findet bei Scrum konstant über die ganze Projektlaufzeit statt. Requirements umfassen vertikale Funktionalitäten, allenfalls mehrstufig beschrieben. Der Requirements Engineer übernimmt die Product Owner Rolle oder arbeitet mit dem Product Owner bei der Erstellung und Pflege des Product Backlogs.

30 Any questions?

31

32 Any questions?

33 Motivation