Haj til nedbrydning juni 2015
•
0 likes•538 views
Et vigtigt redskab i arbejdet med backloggen er at nedbryde store features og funktionsområder til mindre, så de fx. passer ind i en iteration eller er overskuelige at implementere for et team. Men nedbrydning handler ikke kun om en passende størrelse. Det kan også være et afgørende bidrag til effektiv prioritering og planlægning, og kan sågar mindske behovet for estimering. Nedbrydning er også et generelt princip, der med fordel kan bruges på andre og større områder end blot en enkelt backlog.
Haj til nedbrydning juni 2015
- 1. Bliv en haj +l nedbrydning 22. juni 2015 Jesper Thaning, partner BestBrains AS
- 2. Agenda • Produktnedbrydning • Hvorfor nedbryde? • 9 metoder +l nedbrydning • Es+mering? • AHængigheder
- 3. DeKe er ikke … User Story Task 1 Task 2 Task 3 Task 4
- 4. GOD PRODUKTUDVIKLING FAST FEEDBACK – SMÅT ER BEDRE Nedbrydning
- 5. 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
- 6. 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
- 7. 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)
- 8. 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
- 9. 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
- 10. Start Indtast Indsend Kvittering Data Alder + køn Email Adresse Navn Nedbrydning Metode#3 Variationer i data Hvilke typer af data skal systemet kunne håndtere. Hvad er den mest basale type?
- 11. Start Indtast Indsend Kvittering Behandling Registrering Nedbrydning Metode#4 Operationer De forretningsmæssige operationer kan være spredt over flere forskellige opgaver og roller.
- 12. Start Indtast Indsend Kvittering Behandling Registrering §1 §2 §3 Nedbrydning Metode#5: Hver enkelt forretningsregel Eller grupper af forretningsregler der hører sammen
- 13. 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
- 14. Start Indtast Indsend Kvittering Behandling Registrering Nedbrydning Metode#7 Input metode Hvordan ser den simple brugergrænseflade ud? Den mere brugervenlige og smarte?
- 15. 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?
- 16. 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)
- 17. Start Indtast Indsend Kvittering Behandling Registrering Data Alder + køn Email Adresse Navn §1 §2 §3 Stor indsats PoC 2 s 20 ms Nedbrydning – 9 teknikker Simpel Kompleks
- 18. 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)
- 19. HAR VI BRUG FOR ESTIMERING?
- 20. 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
- 21. 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
- 22. Risici Mister vi overblikket? Jesper Thaning jt@bestbrains.dk