EVO en av flere agile metoder Fordeler og

EVO – en av flere agile metoder Fordeler og utfordringer ved bruk av agile metoder av Knut Harald Langøren www. fundator. no

Oversikt • Hvem står bak EVO • Hvorfor ”smidige metoder” • Viktige nøkkelord i EVO • EVO som metode • Oppsummering • EVO vs Scrum vs XP vs Fossefall vs. . . • Brainstorming Slide 2 www. fundator. no

Hvem står bak EVO www. fundator. no

Hvem står bak EVO • Tom & Kai Gilb (www. gilb. com) • Mange virkelig store firma har gode resultater • Nokia • Sun • Alcatel • . . . • Skalerer fra de minste til de største prosjekter • Trenger ikke være IT-prosjekter Slide 4 www. fundator. no

Hvorfor ”Smidige metoder” ? • Den perfekte verden • Den virkelige verden • Smidige metoder løser alt ! www. fundator. no

Hvorfor ”smidige metoder” ? – Den perfekte verden Gamle fossefallsmetoden fungerer utmerket ! • Hvis du har alle krav på forhånd • Hvis kunden ikke endrer mening om hva som er viktigst • Det ikke er noen misforståelser internt eller eksternt • Hvis du har tatt høyde for alle tenkelige og utenkelige hendelser på forhånd • Hvis alle holder det de lover • Hvis alle estimeringer stemmer Og sannsynligheten for dette er ? ? ? Slide 6 www. fundator. no

Hvorfor ”smidige metoder” ? – Den virkelige verden I den virkelige verden • En eller annen tulling kommer alltid med ett nytt krav • Kunder er ubesluttsomme vimsekopper som alltid endrer mening • Noen er alltid litt uklare, og vet kanskje ikke helt hva de vil, så misforståelser skjer alltid • Få utviklere og prosjektledere er synske, så det å forutsi alle tenkelige og utenkelige hendelser på forhånd er lite trolig • Ingen klarer å holde det de lover til enhver tid • Alle punktene ovenfor gjør at estimeringen aldri blir riktig • Så konklusjonen må bli at den gamle Fossefallsmetoden sannsynligvis aldri vil kunne fungere • BTW : Står man på toppen av en foss og skal ned, så selv om man treffer der man sikter, så har man ett problem hvis fossen har en viss størrelse. Så hva er løsningen ? ? ? Slide 7 www. fundator. no

Hvorfor ”smidige metoder” ? – Smidige metoder løser alt Vi starter med en “Smidig metode” ”Smidige metoder” løser alle disse problemene ! (vel. . . ikke helt) • Det blir lettere å håndtere problemene • Man oppdager at man har ett problem tidligere, og kan gjøre noe med det før det er for sent • Kunden kan få det som er viktigst til enhver tid ”Smidige metoder” innfører noen nye utfordringer • Selv om man kjører i korte sykluser må noen ha den store oversikten • Total-Estimering blir ikke lettere, men kortsiktig estimering blir enklere • Utfordring å selge til kunden når man ikke kan si når man blir ferdig Estimering eller kontroll • Nøyaktig estimering er umulig for komplekse tekniske prosjekter, men å holde avtalte budsjetter er fremdeles mulig med bruk av tilbakemeldinger og endringer. Hvordan kommer man seg så ned et fossefall? • På samme måte som en stuntmann faller ned en trapp “Ett trinn av gangen!” Slide 8 www. fundator. no

Viktige nøkkelord i EVO www. fundator. no

Viktige nøkkelord i EVO Stakeholders • Any person, group of people, or product that has or we want to have an interest in our project should be considered. Stakeholder values • The achievement, benefit, experience, saving or profit that a Stakeholder value. Product Qualities • Interaction between a product (or a system) and other entities, like other products, systems or people. Requirement • Requirements are; anything Stakeholders require Solutions • Stakeholder Value & Product Quality Requirements are something desired in the future, an end state. Solutions are means of getting there. Solutions, a “package” of Function and Quality to deliver to the Requirements level above. Function • A Function is what a system does. A Function is binary, i. e. it either does it or it does not do it. Sub-Function • Sub-Function is a breakdown of the Function, what the system does. Slide 10 www. fundator. no

EVO som metode • Top principles • Deming’s Plan-Do-Study-Act cycle • Krav – Oppgave • Krav – Eks. • Krav – Oppgave • Start – Eks. Enkel IET • Start – Eks. Avansert IET • Front room • Back room www. fundator. no

EVO som metode – Top Principles Evolutionary Project Delivery top principles are : • Learning Evolutionary Delivery is a Learning cycle. Learn from reality. Learn from experience. Learn what works and what does not. • Early Learn early enough to change what needs changing before it is too late. • Small Evo Cycles gives small risk. By keeping the delivery cycle small, little is lost when, not if, a cycle fails to deliver. • Simpler The complex gets simpler and easier to handle by dividing it up into smaller parts. Slide 12 www. fundator. no

EVO som metode - Deming’s Plan-Do-Study-Act cycle The very simple explanation of doing a simplified Evolution project : • Plan-a • Make a high-level overview plan. • Plan-b Split that plan into increments. And select one increment to be done first. • Do Do the first increment. Aim to give some real improvements to Stakeholders within a short period of time. • Study Measure and study how well the increment did, compare it to the expectations and learn from that experience. • Act Based on what we learned, keep the increment, throw it out or make the necessary changes! • Repeat Then we start all over again, and we continue circling until the project is done. • Learning cycle We divide the process into four main steps that makes a learning cycle. This is known as Deming’s Plan-Do-Study-Act cycle. Slide 13 www. fundator. no

EVO som metode – Krav - Oppgave Ett eller annet system trenger mulighet for å registrere personer. Systemet brukes av også av personer med bevegelseshemninger Krav: (3 min) Under registrering av en person, skal fødselsdato kunne registreres. Slide 14 www. fundator. no

EVO som metode - Krav • Skiller seg ut fra andre metoder, og er derfor et kjennetegn og en meget viktig del av EVO • Krav sorteres under ett begrenset antall “End-State-Requirements” • The 7 Whys ? and 1 step back. • Hjelpemiddel til å få ”gamle” krav over på EVO krav og for å finne ”End-state Requirements” • TOC i brukermanualen : Hvorfor? -> God brukermanual : Hvorfor? -> God brukervennlighet : Hvorfor? -> Lavere opplærningskostnader: Hvorfor? -> Må skape profitt : Hvorfor? -> ”Stakeholder” liker penger -> OK. Utenfor vårt prosjekt, gå tilbake ett hakk -> Profitt er ”End state Requirement” • Planguage benyttes til å navngi alle elementer med unike navn • Alle krav skal være kvantifiserbare, dvs. det skal kunne måles i etterkant hvor godt kravet er tilfredstilt, dette gjelder både ”Stakeholder values” og ”Product Qualities” • ”Triks” som benyttes er : ”How well” and not ”How” • En Mini og en Ferrari har samme funksjoner, så hvorfor foretrekke den ene foran den andre • Ved kvantifiserbare krav så er det enklere å estimere påvirkningen av en valgt løsning • Erfaringer tilsier også at denne type krav fører til mere kreativitet i teamet, og større “commitment” Slide 15 www. fundator. no

EVO som metode – Krav – Eks. Stakeholder Values Sale. Paperwork Scale: average time spent, per sale, doing paperwork related activities. Meter: look it up in the time management tool. Past [2004] 2 hours. Goal [2006] 15 minutes. User-Friendliness. Operate. Install Scale: average time in minutes, to install, the system. Meter: have 3 people install the system, time them, and average the time. Past [2004] 120 min. Goal [2006] 30 min. Slide 16 www. fundator. no

EVO som metode – Krav - Oppgave Ett eller annet system trenger mulighet for å registrere personer. Systemet brukes av også av personer med bevegelseshemninger Evo-krav: (6 min) Brukervennlighet. Registrering. Fødselsdato Måleskala : flyttinger av Minimum antall musetrykk for å få registrert en dato, og maks antall musepeker Målemetode : Registrer 5 fødselsdatoer med bruk av bare mus, og ta gjennomsnittet Før : 10 trykk og 10 flyttinger Godkjent : 4 trykk og 5 flyttinger Mål : 2 trykk og 5 flyttinger Slide 17 www. fundator. no

EVO som metode – Start • Finn løsninger • Gå gjennom kravene og finn “løsninger” til alle krav • Ved store prosjekter, så deles det inn i serier med sykluser • Impact Estimation Table ett meget kraftig verktøy for prioritering og styring • Alle løsninger grovestimeres • Bestem hvilke “End state requirements” som skal prioriteres først. • Detaljestimer de løsninger som er prioritert blant de som påvirker de prioriterte “End state requirements” Estimer påvirkning av kravet Estimer kostnad Estimer usikkerhet Estimer påvirkning av å ha gjort ting før eller ikke • De løsninger som gir mest ”pay-off” tas med først Slide 18 www. fundator. no

EVO som metode – Start – Eks. Enkel IET A simple IET Slide 19 www. fundator. no

EVO som metode – Start – Eks. Avansert IET Vis eksempel med en IET som vi har brukt i ett prosjekt. Slide 20 www. fundator. no

EVO som metode – Front room Normal Syklus • Foregår i ”Front room”, dvs. det skal leveres noe av målbar verdi til ”Stakeholder” • Lengde er normalt 1 -2 uker (2 -5% av prosjektets totale tid) • Korte sykluser for å tvinge frem nødvendigheten av automatisk bygging, testing og måling • Korte sykluser er lettere når alle krav kan sjekkes ved målinger • Mindre fallhøyde når man har gjort noe feil • Starter med syklusmøte • Alle legger frem syklusdokument, med hvilke krav de skal jobbe med, involverte ”Stakeholders”, evt. behov for møte med ”Stakeholders”. . . • Alle utviklere, nær prosjektledelse og rep. fra ”Stakeholders” er med. • Prioriteringsmøte i siste del av syklusen Det prioriteres ut i fra EIT-tabell, hva som skal gjøres i neste syklus Prosjektledelse og ”Stakeholders” er med. • Statusmøte i slutten av syklusen Alle rapporterer om deres syklus har gitt forventet leveranse – En leveranse er ikke godkjent før den er levert, testet, dokumentert og MÅLT! Alle utviklere, nær prosjektledelse og rep. fra ”Stakeholders” er med. • Alle team-medlemmer har ellers ansvar for å kalle inn til de møter de trenger for å få gjort sin jobb Slide 21 www. fundator. no

EVO som metode – Back room Intern syklus • Foregår i ”Back room” • Lengden kan variere noe mere enn for en normal syklus, men ikke mange ganger mere enn normalen • Resultatet skal være en leveranse som gir prosjektet en målbar forbedring, men ikke noe som nødvendigvis ”Stakeholder” ser direkte • Møter kjøres på samme måte som i front room Slide 22 www. fundator. no

Oppsummering www. fundator. no

Oppsummering • Sier lite om hvordan teamene best skal håndteres og styres • Klare retningslinjer på hvordan man best spesifiserer, sorterer og prioriterer krav på en effektiv måte • Ved kvantifiserbare krav er det aldri noen tvil om ett krav er nådd eller ikke • Ved å gi alle informasjonsenheter egne navn, så blir det lettere å holde styr på hva man snakker om og mindre misforsåelser • Måten krav, kvaliteter, End state requirement, mv. organiseres på, gir en god oversikt over hva det egentlig er man jobber med, og hjelper til med å holde fokus på de riktige punktene underveis. • Det er en ny måte å tenke på, så metoden vil møte motstand under innføring Slide 24 www. fundator. no

EVO vs Scrum vs XP vs Fossefall vs. . . www. fundator. no

EVO vs Scrum vs XP vs Fossefall vs. . . 42 !!! Vann eller Vin? Hva er best til å vaske gulv ? ? ? For å vite svaret så må vi først vite spørsmålet Hva står vi ovenfor ? • Type prosjekt • Lengde på prosjektet • Hvilke prosjektdeltakere finnes • Hvordan er organisasjonen som skal leve med prosjektet Ta det beste fra alle verdener som du tror kan gi positiv effekt • Scrum har en god kontroll på hvordan team skal organiseres og drives • Evo gir deg verktøy for spesifisering og kontroll på krav • XP gir deg metoder for å jobbe effektivt under programmering (par-prog) • Alle setter fokus på små steg i gangen • Automatiserte tester og bygging • Test first Slide 26 www. fundator. no

The Road To Wisdom : Piet Hein "The road to wisdom is plain and simple to express, to err, and err again, but, less, and less. " Piet Hein, (Danish Philosopher, Scientist) Slide 27 www. fundator. no

Brainstorming www. fundator. no

Brainstorming “Det perfekte prosjekt” Ikke tenk på hva som er Scrum, EVO, XP, . . . , fokuser på hva man vet virker, og på det som høres fornuftig ut som man ennå ikke har prøvd. Hva funker når man skal kjøre ett stort prosjekt ? Hva funker ikke ? I grupper: Brainstorm og sett opp de 10 viktigste ting til hvert spørsmål. (kun stikkord !!!) • 5 Min på Hva funker • 5 min på hva funker ikke • 5 min på å finne de 10 viktigste på hver Samlet : Alle gruppene skriver opp sine lister på tavla, bare les opp stikkord, ingen forklaringer. (5 min) Kjør diskusjon ! (25 min) Hva kan de forskjellige smidige metodene gi oss av det som står på pluss-siden? Hva kan de forskjellige smidige metodene ta bort av det som står på minus-siden ? Slide 29 www. fundator. no