Scrum og agile. Torsdag d. 29. november 2007

Transkript

1 Projektbar (på vej hjem møde) Scrum og agile Torsdag d. 29. november 2007

2 Agenda Scrum kort overblik Portefølje og Roadmap pplanlægning g Scrum Implementation

3 Atives produkter Scrum Team Agile coaching: Proces Det gode håndværk Agile softwareudvikling

4 Hvilke problemer løser Ative lige nu? Elektronisk tinglysning af realkreditlån for 46 mia pr år Sharepoint portal til salg af boliglån Proces- og metode forbedring IT strategi realisering

5 Filosofien i Scrum: Det agile manifest Individer og samarbejde frem for processer og værktøjer Kørende software frem for omfattende dokumentation Samarbejdemed d kunden frem for kontraktforhandlingerk Reagere på forandringer frem for at fastholde planer

6 Dijkstra on Software Quality "The vision is that, well before the end of the seventies have run to completion, we shall be able to design and implement the kind of systems that are now straining our programming ability at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs. These two improvements go hand in hand. In the latter respect software seems to be different from many other products, where as a rule a higher quality implies a higher price. Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with. In other words, both goals point to the same change." Edsger W. Dijkstra in his 1972 Turing Award Lecture, "The Humble Programmer" (Communications of the ACM, October 1972, Volume 15, Number 10, p ). Ikke alene omtaler Dijsktra konceptet om høj hastighed via kvalitet, men han beskriver også j p j g g andre emner der stadig er aktuelle i dag som en del af agile/lean software development agendaen. 35 år gammel. Stadig anbefalet læsning!

7 Scrum er baseret på Lean Vi kigger blot på tidslinjen fra det øjeblik kunden giver os en ordre til det tidspunkt hvor vi modtager betalingen. Og vi forkorter denne tidslinje ved at fjerne det ikkeværdiskabende spild Taiichi Ohno: Toyota Production System (1987)

8 Motivation for Scrum Fokus på færdiggørelse Minimere risiko Større fleksibilitet Forudsigelige leverancer

9 Scrum process Sprint Planning Daily Scrum Running Tested Features Product Backlog Sprint Backlog Sprint 2-4 w Demo and Retrospective

10 Scrum sådan virker det Product Owner Løbende dialog Teamet Forretningens domæne Definitionen af færdig Implementeringsdomæne Product Backlog Sprint Backlog

11 Scrum 3*3 Roller Artefakter Aktiviteter Product Owner Product Backlog (PBL) Sprint planlægning Teamet (5-9 pers) Sprint Backlog (SBL) Daily Scrum ScrumMaster Færdig kode Retrospective

12 Planlægning PO + Team

13

14 Sprint planen

15 Advarsler - eksempler

16 Advarsler - eksempler

17 Advarsler - eksempler

18 Færdig-færdig Alle funktionelle og ikke funktionelle krav overholdt Sikkerhed, svartider, dokumentation, usability osv. Testet Integreret Installeret Idriftsat Ingen løse ender

19 User stories Kort beskrivelse En til to sætninger i brugersprog: Samtale Som bruger kan jeg... Afdække detaljer (samarbejde mellem PO og team) Bekræftelse Acceptkriterier for løsningen

20 User Story eksempel Samtale Som bruger Skal der sendes en bekræftelse? kan jeg Får man refunderet hele/dele af annullere en beløbet? ordre. Hvilke tidsfrister ste gælder? osv. Giver ofte anledning til nedbrydning i mindre user stories Acceptkriterier Verificer at guldkunder d kan annullere samme dag uden gebyr Verificer at der sendes bekræftelse pr Verificer at butikken underrettes

21 Gode User Stories Uafhængige så man kan implementere en ad gangen Kan forhandles fleksible: det er ikke kontrakter Kan værdisættes for kunden (ikke udviklerne) ellers omskriv ud fra kundeværdi Estimerbare Grundlag for planen Passende størrelse Små (større historier nedbrydes i mindre) Testbare Så vi ved hvornår vi er færdige.

22 Nedbrydning er vigtigt

23 Userstory opgaver

24 Planlægning med User Stories PBL som user stories Estimeres relativt sammenlignelige g størrelser Måling på hastighed user story point pr sprint Observeret hastighed afgør størrelsen af næste SBL. Selvkalibrerende pålidelig efter 2-3 sprints

25 Brug opbygget viden Baseline: opgaver sammenlignes i forhold til kendte opgaver Estimer userstories relativt i forhold til hinanden. Minimer risiko via planning poker

26 Planning gpoker

27 Storypoints og Velocity Velocity er ikke et udtryk for effektivitet i forhold til timers arbejde. Velocity er et mål for at vise hvor mange storypoints vi kan løse færdig-færdig. Velocity viser dermed mængden af usynligt arbejde sammenlagt med vores estimeringsusikkerhed (manglende domæne viden, tekniske udfordringer, sygdom og hvad der i øvrigt ellers påvirker). Vi bruger den opbyggede erfaring til at planlægge ud fra. Forudsætning: Et storypoint skal være et storypoint altid. Det er udfordringen nu!

28 Beregning af velocity

29 Roadmap Besvare spørgsmål som: Hvor meget er klar 1. april Hvornår shipper vi første featureset inden for systemområde ABC Hvor mange folk eller teams bør der være i dette projekt

30 Hvis tiden er givet Roadmap Besluttet release 1. Apr dato Dags dato 1. Okt Antal sprints 6 Lav velocity 15 Will Have 6 * 15 Might Have 6 * 20 Høj velocity 20 Won t Have

31 Hvis scope er givet Total antal story points 120 Lav velocity 15 Høj velocity 20 Roadmap

32 Roadmap måling Sprintdata Current Average Worst 5 0 sprint 1 sprint 2 sprint 3 sprint 4 sprint 5 sprint 6 sprint 7

33 Roadmap brug målte data Med vores dårligste velocity når vi hertil. Med vores gennemsnitlige velocity når vi hertil. Med vores bedste velocity når vi hertil.

34 Scrum Portefølje Styring Sprint Backlog Product Backlog Roadmap Vision 3 år 1 år 2-4 uger 2-3 måneder

35 Scrum roadmap

36 Det gode håndværk Test Driven Development Continuous Integration Deployment Automatisk accepttests Arkitekturr Versionskontrol Godt håndværk er forudsætningen for at kunne levere forretningsværdi og forudsigelige leverancer.

37 Hør mere DAUG: Torsdag den 6. december kl ved Ative. Sted: Ingeniørhuset, Kalvebod Brygge 31-33, 1780 København V, lokale 212 Dagens program: Velkomst ved Ative "Kunsten at øge evnen til at eksekvere - Det handler om kommunikation" v/ IT chef Lars Aagaard, IDA Stillet overfor krav fra forretningen om effektiv IT samt evnen til at være agile i relation til markedet, har IDA arbejdet med optimering af processerne. For at levere er der iværksat en ny planlægningsmetodik baseret på agile principper. En grundlæggende præmis for at få det til at fungere er: Kommunikation Kaffepause "Agile set fra kundeside" v/product owner Mette Tornøe, Topdanmark Indførelse af agile udvikling og scrum stiller helt nye krav til forretningen. Hvad siger kunderne egentlig til den nye måde at arbejde på. Hvordan har Topdanmark grebet udfordringerne an?

38 Kontakt Jan Elbæk, blog.ative.dk