haj til nedbrydning juni 2015
TRANSCRIPT
Bliv en haj +l nedbrydning 22. juni 2015 Jesper Thaning, partner BestBrains AS
Agenda
• Produktnedbrydning • Hvorfor nedbryde? • 9 metoder +l nedbrydning • Es+mering? • AHængigheder
DeKe er ikke …
User Story
Task 1 Task 2 Task 3 Task 4
GOD PRODUKTUDVIKLING FAST FEEDBACK – SMÅT ER BEDRE
Nedbrydning
Hvordan kan et produkt nedbrydes? Produkt
(Projekt)
Release
Feature
User story
Acceptkriterie
Finde værdien og målene
Finde ”the Minimal Marketable Feature”
Finde den minimale implementa+on
Finde den simpleste måde at opfylde et behov på
Finde det næste ”Product Increment”
(Afgrænsning af projektet – foretræk små projekter)
IMPLEMENTÉR
Nedbrydning
Mål
User story
Hvorfor nedbryde noget?
1. Prioritere 2. Småt er bedre 3. Afdække aHængigheder 4. Undgå gold pla+ng 5. Undgå “gidsler”
Batch size reduc+on Don Reinertsen
User story
1
2
3
Hvordan nedbryder du en user story – og andre +ng!
9 metoder +l nedbrydning
Produkt
(Projekt)
Release
Feature
User story
Acceptkriterie
hKp://www.agileforall.com/2009/10/paKerns-‐for-‐splidng-‐user-‐stories/ hKp://bit.ly/PuCoC2 (Engelsk cheat sheet -‐ 1 PDF)
Start Indtast Indsend Kvittering
Nedbrydning
Metode#1: Handlinger i en arbejdsproces For at kunne implementere en simpel end-to-end og putte komplicerede trin på bagefter
Start Indtast Indsend Kvittering
Nedbrydning
Simpel
Kompleks
Metode#2 Simpel vs. kompleks Hvad er den simpleste version af denne funktionalitet? De mere komplekse variationer følger efter
Start Indtast Indsend Kvittering
Data
Alder + køn
Adresse
Navn
Nedbrydning
Metode#3 Variationer i data Hvilke typer af data skal systemet kunne håndtere. Hvad er den mest basale type?
Start Indtast Indsend Kvittering Behandling Registrering
Nedbrydning
Metode#4 Operationer De forretningsmæssige operationer kan være spredt over flere forskellige opgaver og roller.
Start Indtast Indsend Kvittering Behandling Registrering
§1 §2
§3
Nedbrydning
Metode#5: Hver enkelt forretningsregel Eller grupper af forretningsregler der hører sammen
Start Indtast Indsend Kvittering Behandling Registrering
Stor indsats
Nedbrydning
Metode#6 Stor indsats og efterfølgende Den første user story bærer den tekniske byrde for de efterfølgende
Start Indtast Indsend Kvittering Behandling Registrering
Nedbrydning
Metode#7 Input metode Hvordan ser den simple brugergrænseflade ud? Den mere brugervenlige og smarte?
Start Indtast Indsend Kvittering Behandling Registrering
2 s 20 ms
Nedbrydning
Metode#8 Ydeevne Hvordan får vi det til at fungere? Hvordan får vi det til at gå hurtigt?
Start Indtast Indsend Kvittering Behandling Registrering
PoC
Nedbrydning
Metode#9 Undersøgelse (spike) og implementation Ved dårlig forståelse af løsning eller manglende afhængigheder. Et nyt område enten teknisk eller forretningsmæssigt. Et Proof Of Concept (PoC)
Start Indtast Indsend Kvittering Behandling Registrering
Data
Alder + køn
Adresse
Navn
§1 §2
§3
Stor indsats
PoC 2 s 20 ms
Nedbrydning – 9 teknikker
Simpel
Kompleks
Kombinere metoder I et User Story Map
Nedbrydning -‐ Data -‐ Regler -‐ ...
Handlinger Detaljer
hKp://www.agileproductdesign.com/presenta+ons/user_story_mapping/index.html hKp://bit.ly/1fiSfBm (Quick Reference PDF -‐ 2 pages)
HAR VI BRUG FOR ESTIMERING?
Det store dyr i nedbrydningen
Mul+ team setup -‐ retningslinier • Etabler en klar doktrin om hvordan aHængigheder generelt
skal håndteres (program level) • Skub beslutninger om, hvad der skal gøres med de konkrete
aHængigheder nedad (team level) • Udbyg tværgående kommunika+on (team +l team) • Etabler en klar prioritets-‐kæde hele vejen op +l øverste
niveau
AFHÆNGIGHEDER Hvad – Hvordan – Hvornår
Product Owner
Chief Product Owner
Product Manager
Product board
Doktrin omkring aHængigheder
Hvordan håndteres aHængigheder • Et team har en produktejer, en projektleder, en arkitekt og et
udviklingsteam • Det er i sidste instans teamet som har et behov, der har ansvaret for
at anmode om en funk+onalitet hos et andet team, samt at beskrive det som user stories
• Det implementerende team har ansvaret for at aolare og koordinere omkring funk+onalitet, som flere teams har brug for, samt at sikre at langsigtede mål bliver +lgodeset
• Prioriteter afgøres via følgende hierarki: produktejer, programchef, programbestyrelse
