Projektbar (på vej hjem møde) Scrum og agile Torsdag d. 29. november 2007
Agenda Scrum kort overblik Portefølje og Roadmap pplanlægning g Scrum Implementation
Atives produkter Scrum Team Agile coaching: Proces Det gode håndværk Agile softwareudvikling
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
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 www.agilemanifesto.org 2001
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. 859-866). 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!
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)
Motivation for Scrum Fokus på færdiggørelse Minimere risiko Større fleksibilitet Forudsigelige leverancer
Scrum process Sprint Planning Daily Scrum Running Tested Features Product Backlog Sprint Backlog Sprint 2-4 w Demo and Retrospective
Scrum sådan virker det Product Owner Løbende dialog Teamet Forretningens domæne Definitionen af færdig Implementeringsdomæne Product Backlog Sprint Backlog
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
Planlægning PO + Team
Sprint planen
Advarsler - eksempler
Advarsler - eksempler
Advarsler - eksempler
Færdig-færdig Alle funktionelle og ikke funktionelle krav overholdt Sikkerhed, svartider, dokumentation, usability osv. Testet Integreret Installeret Idriftsat Ingen løse ender
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
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 email Verificer at butikken underrettes
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.
Nedbrydning er vigtigt
Userstory opgaver
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
Brug opbygget viden Baseline: opgaver sammenlignes i forhold til kendte opgaver Estimer userstories relativt i forhold til hinanden. Minimer risiko via planning poker
Planning gpoker
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!
Beregning af velocity
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
Hvis tiden er givet Roadmap Besluttet release 1. Apr. 2008 dato Dags dato 1. Okt. 2007 Antal sprints 6 Lav velocity 15 Will Have 6 * 15 Might Have 6 * 20 Høj velocity 20 Won t Have
Hvis scope er givet Total antal story points 120 Lav velocity 15 Høj velocity 20 Roadmap 120 20 120 15
Roadmap måling 25 20 15 10 Sprintdata Current Average Worst 5 0 sprint 1 sprint 2 sprint 3 sprint 4 sprint 5 sprint 6 sprint 7
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.
Scrum Portefølje Styring Sprint Backlog Product Backlog Roadmap Vision 3 år 1 år 2-4 uger 2-3 måneder
Scrum roadmap
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.
Hør mere DAUG: Torsdag den 6. december kl. 14-17 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?
Kontakt Jan Elbæk, je@ative.dk, +45 2966 2174 www.ative.dk blog.ative.dk