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

Presentasjon om: "EVO – en av flere agile metoder Fordeler og utfordringer ved bruk av agile metoder av Knut Harald Langøren."— Utskrift av presentasjonen:

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

2 www.fundator.no Slide 2 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

3 www.fundator.no Hvem står bak EVO

4 www.fundator.no Hvem står bak EVO Slide 4 Tom & Kai Gilb (www.gilb.com)‏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

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

6 www.fundator.no Hvorfor ”smidige metoder” ? – Den perfekte verden Slide 6 Og sannsynligheten for dette er ??? Hvis du har alle krav på forhånd Gamle fossefallsmetoden fungerer utmerket ! 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

7 www.fundator.no Hvorfor ”smidige metoder” ? – Den virkelige verden Slide 7 En eller annen tulling kommer alltid med ett nytt krav Kunder er ubesluttsomme vimsekopper som alltid endrer mening I den virkelige verden 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 ???

8 www.fundator.no Hvorfor ”smidige metoder” ? – Smidige metoder løser alt Slide 8 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!”

9 www.fundator.no Viktige nøkkelord i EVO

10 www.fundator.no Viktige nøkkelord i EVO Slide 10 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.

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

12 www.fundator.no EVO som metode – Top Principles Slide 12 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  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.

13 www.fundator.no EVO som metode - Deming’s Plan-Do-Study-Act cycle Slide 13 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.

14 www.fundator.no EVO som metode – Krav - Oppgave Slide 14 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.

15 www.fundator.no EVO som metode - Krav Slide 15 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”

16 www.fundator.no EVO som metode – Krav – Eks. Slide 16 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.

17 www.fundator.no EVO som metode – Krav - Oppgave Slide 17 Ett eller annet system trenger mulighet for å registrere personer. Systemet brukes av også av personer med bevegelseshemninger Evo-krav: (6 min)‏ Brukervennlighet.RegistreringFødselsdato Måleskala : Minimum antall musetrykk for å få registrert en dato, og maks antall flyttinger av 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

18 www.fundator.no EVO som metode – Start Slide 18 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

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

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

21 www.fundator.no EVO som metode – Front room Slide 21 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

22 www.fundator.no EVO som metode – Back room Slide 22 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

23 www.fundator.no Oppsummering

24 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

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

26 www.fundator.no EVO vs Scrum vs XP vs Fossefall vs... Slide 26 å vaske gulv ??? 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 Vann eller Vin? Hva er best til 42 !!! For å vite svaret så må vi først vite spørsmålet

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

28 www.fundator.no Brainstorming

29 www.fundator.no Brainstorming Slide 29 “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 ?