20081022 Smidig prosjektmetodikkv1.prosjektnorge.no/files/events/73/20081022-smidig... · 2013. 12. 3. · Utvikling/test Leveranse Dette burde vi tenkt på i spesifieringen Hvordan

Smidig prosjektmetodikk – hva skal til for å lykkesTemadag smidige prosjekter 22.10.2008 Oslo

Jon Tysdahl

Avenir AS > slide 2

Jon Tysdahl

Hovedfag informatikk

Mellomfag i arbeids og organisasjonspsykologi

Lang erfaring som prosjektleder for store utviklingsprosjekter

Bred strategi- og rådgivningserfaring

Manager i konsulentselskapet Avenir AS

Ansvarlig for smidig metode i Avenir AS

Avenir AS > slide 3

Smidig prosjektmetodikk – hva skal til for å lykkes

1. Hvorfor smidig

2. Hva er smidig metode

3. Smidige varianter

4. Smidig prosjektledelse

5. Noen sentrale utfordringer - hva skal til for å lykkes

6. Gode prinsipper

7. En generisk modell

Avenir AS > slide 4

1. Hvorfor smidig?

Vi ønsker å kjøre dette utviklings-prosjektet!

Hva skal det inneholde og hva vil det koste, og

når blir det ferdig?

Vi har begrensede ressurser til prosjektet. Hva er våre viktigste

mål og hvordan bør vi fokusere vår innsats for å nå disse best mulig?

Avenir AS > slide 5

Utviklingsprosjekter - ofte preget av høy usikkerhet

Kostnad

Omfan

g TidKvalitet

Usikker eller begrenset finansieringTotalt kostnadsbilde ikke kjent

Knapp tid til rådighet (Time to market)Lang vei til ferdig løsning

Løsningens innhold ikke fastlagtHva er viktig og hva er detalj?

Store krav til kvalitetHva er godt nok?

Skiftende rammebetingelserKonkurrenters trekk

Avenir AS > slide 6

Ikke så smidig….

Spesifisering

Utvikling/test

Leveranse

Dette burde vi tenkt på i

spesifieringen

Hvordan vil dette fungere i

leveranse

Avenir AS > slide 7

Smidiggjøring av prosjektet?

Spesifisering

Utvikling/test

Leveranse/ Innføring

Må vi gjøre hvert trinn helt ferdig med en gang?

Må vi gjøre hvert trinn bare en gang?

Avenir AS > slide 8


Smidig (Eng.: Agile -> “the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion) endringsdyktig, fleksibel, tilpasningsdyktig

“Agile proponents claim that the focal aspects of light and agile methods are simplicity and speed. (Abrahamsson et al., 2003, p. 1)

– In development work, accordingly, development groups concentrate only on the functions needed immediately,

– delivering them fast,

– collecting feedback

– and reacting rapidly to business and technology changes”

Avenir AS > slide 9

Smidig utvikling i sin basale form

Bygg noen krav

Bygg noen krav

Bygg noen krav

Tilbakemeldinger

Tilbakemeldinger

Bygg noen krav

Systemet vokser inkrementelt

1-6 uker

Tilbakemeldinger

1-6 uker 1-6 uker 1-6 uker

Avenir AS > slide 10

Det opprinnelige ”Smidige Manifest”:

Individer og interaksjoner fremfor prosesser og verktøy

Fungerende software fremfor omfattende dokumentasjon

Samarbeid med kunden fremfor forhandling av kontrakt

Imøtekomme endringer fremfor å følge en plan


SMIDIG - litt av gangen

GEVINSTER:– De viktigste gevinstene,

så tidlig som mulig

– Tidligere erfaringer med hele kjeden

– Endringer håndteres løpende

– Kun nyttige funksjoner utvikles

Spesifisering

Utvikling/test


Spesifisering

Utvikling/test


Spesifisering

Utvikling/test




I praksis et mylder av ulike metoder som dekkerulike deler av systemutviklingsprosessen:

– SCRUM,

– Crystal

– LEAN

– EVO

– XP, Extreme programming,Adaptive software developmentAgile modeling, Feature-driven development, Internet-speed development, Pragmatic programmingM.fl….


SCRUM

Sprint Backlog

Kjørbar kode

Scrum Møte

Product backlog

1-4uke

24 t


Crystal Clear

Crystal kjennetegnes ved:– Forenklet kommunikasjon ved samlokalisering

– Hyppige leveranser av kjørbar kode til brukerne

– Forbedringer basert på refleksjon underveis

Crystal metodikken fokuserer på effektivitet og praktisk brukbarhet.

Krever enkel tilgang til ekspertbrukere

Teknisk fokus er på automatisert test, konfigurasjonsstyring og hyppigintegrasjon

Crystal Clear er beskrevet av Alistair Cockburn.


Lean Software Devleopment

Basert på ”lean” filosofien i japansk bilproduksjon, men tilpasset for utvikling

Fokuserer på følgende prinsipper:

1. Eliminate waste

2. Amplify learning

3. Decide as late as possible

4. Deliver as fast as possible

5. Empower the team

6. Build in integrity

7. See the whole


Verdi-syklusen

EVO

PLANLEGG

• Identifisere interessenterog avdekke deres verdierog mål

• Kvantifisere de viktigstemålene for prosjektet

• Bestem ønsket målnivå og

• Evaluer et sett med alternativer og velg ut den beste for implementeringførst. akseptabeltminimum for disse målene

REVIDER

• Skal prosjektet fortsettes?

• Raffiner mål og planer

• Tilpass arbeidsprosesser

STUDER

• Kontroller målbar verdi avleveranse

• Verifiser teamets ytelse ogleveranseevne

• Evaluering

LEVER

• Planlegg med bruk av iterasjonerpå max 4 uker og max 10% avbudsjettet

• Teamene skal være tverrfagligeog ha tett tilgang tilinteressentene

• Produser en testet ogdemonstrert del-løsning i hveriterasjon


XP Extreme Programming

Basert på følgende generelle praksiser:

1. Sitt sammen

2. Komplette team

3. Informative omgivelser

4. Produktiv, - ikke utbrent (”Energized work”)

5. Uke-syklus

6. Kvartals-syklus

7. Slakk

Og følgende mer programmeringsrettede praksiser

Par-programmering

Historier (”System Metaphor”)

10-minutters bygging

Kontinuerlig Integrasjon

Test-først programmering

Inkrementell design



Innebærer å løpende vurdereog styre prosjektet i forhold tilde konkurrerende kravene til:

..i styrte sykluser/iterasjoner

Kostnad

Omfan

g TidKvalitet

Risiko


Smidig prosjektledelse

Prosjektledelse er anvendelse av – kunnskap,– ferdigheter, – verktøy og – teknikker

innen et bredt spekter av aktiviteterfor å møte interessentenes behov og forventninger til prosjektet og sikre at prosjektet når sine mål innenfor de gitte rammebetingelser

Smidig gjennomføring stiller nye krav til prosjektleder!


Fossefall vs. smidig samarbeid

Tradisjonelt ansvar og

risikodelingSmidig ansvar og risikodeling


Typisk smidig gjennomføringArbeidet gjøres i repeterende sykluser av varighet 1-4 uker.

Etter hver syklus en del-leveranse

Etter hver syklus ny vurdering av hva som nå skal gjøres ut fra målene, hva bidrar mest på kort sikt?

Daglig oppfølging av status i korte møter for hele teamet

Hver syklus inneholder– Planlegging av arbeidet

– Gjennomføring av arbeidet

– Grovplanlegge neste syklus

– Evaluering

Til enhver tid: komme lengst mulig i måloppnåelse


Hva er anderledes i et prosjektledelsesperspektiv

Prosjektprosessen omgjort fra unik til repetetetiv, ved at prosjektet brytes ned i deler der utvikling av hver del blir en repeterende aktivitetSterk fokus på deler av løsningen av gangen. Kun delvise spesifikasjoner underveis. Mindre fokus på detaljerte funksjonelle krav - "better roughlyright than exactly wrong”Meget sterk styring av tid og innhold i hver syklusMindre fokus på langsiktige planer og totale estimater Meget sterk fokus på å håndtere læring og endringer underveis. Det er aldri for sent!Kraftig delegering og stor beslutningsmyndighet tillagt den enkelte prosjektdeltagerStørre fokus på team, mindre på ansvarsdeling og den enkelte person


Prosjektleder må passe på at:

Teamet sitter samlokalisertMest mulig heltidsressurser i prosjektet

Flest mulig personer som kan fylle mer enn en rolle

Planen skal tilgjengeliggjøres og vedlikeholdes synlig for hele teamet

Scrum møtet gjennomføres som et kort og målrettet møte.

Fordeling av oppgaver og oppfølging av status skjer i daglig scrummøte

Syklusens lengde fravikes aldri

De aktuelle utførende ressurser skal involveres i planlegging og estimering av neste syklus

Evaluering skal gjennomføres i hver syklus.

Evaluering sammenliknes med evaluering fra forrige syklus


5. Noen sentrale utfordringer

Hvordan få tilstrekkelig forretningsmessig fokus inn som driver av smidige prosjekter?

Hvordan sikre at løsningen faktisk blir tatt i bruk og gir gevinstene den skal?

Hvordan velge/tilpasse/innføre smidig metode som støtter dette best mulig?


Forretningsfokus i SCRUM?

Sprint Backlog

Kjørbar kode

Scrum Møte

Product backlog

1-4uke

24 tHvordan sikre at løsningen lages slik at de forretnings-messige målene oppnås

best og raskest


Scope for scrum

Krav

Kode

Produsere kjørbar kode ut fra foreliggende krav, basert på trinnvis utviklingi en prosess der læring og forbedring er viktige forhold.


Fokus på forretningsverdi

Utviklingsprosjektet skal styres ut fra de forretningsmessige målene

– Det vil si å frembringe (del)løsningersom er unikt nyttig for kunden

– Så raskt som mulig– Med tilstrekkelig kvalitet

Det må inkluderes metodestøtte for dette, her gir EVO god støtte, mens de øvrige gir for svak støtte


Hvordan finne gevinstene?

Workshop med ledelsen for å fåfrem hovedmål/gevinster og en viss konkretisering av disse

Interessentanalyse for å avdekke posisjonene rundt målene

Nedbryting av hovedmål til delmål og konkretisering og operasjonalisering

Hva er det viktigste kravene og målene ( opp til 10 stk)


Kravanalyse

Koble kravene opp mot målene

Ferdigstille konkrete krav på de relevante områder

Gjennomgå evt. foreliggende kravliste og sortere som:

– Ekte krav

– Designforslag

– Begrensning

Avklare håndtering av ”uekte” krav


Vanlige problemer med krav

Hvem har bestemt at dette er et krav?

– ofte udokumentert eller uklart

Kravet er uklart eller tvetydigformulert

– Eksakt hva skal gjøres,

– når, og av hvem

– og på vilken måte

Koblingen til “avtalen” er ikke klar, – hva betyr kravet i forhold til avtalen – hva

er godt nok resultat?

– Hva er ønskelig, hva er minimum?


Fra løse og dårlige krav til klare mål:

Forretningsmessig mål: Tredoble besøket på våre web-sider.Delmål/krav:

Tre relevante nyheter hver dagGjennomsnittlig responstid på alle sider på under 1 sek


Vi må utvide scopet for å ta med FRA MÅL TIL KRAV

Krav

Kode

Mål


Sikre gevinstene?

Sprint Backlog

Kjørbar kode

Scrum Møte

Product backlog

1-4uke

24 t

Hvordan sikre at løsningen tas i bruk og gevinstene

faktisk fremkommersom forutsatt


Smidige gevinster

SCRUM og de fleste smidige metodene fokuserer på brukerens nytte og involvering av bruker.

Dette forutsetter at sluttbruker har fullgod kunnskap om alle sider ved mulige gevinster av systemet

Det er ikke slik at et krav nødvendigvis gir en gevinst.

Oppnåelse av gevinstene må kobles med kravene og målene, inn som testkriterier og må verifiseres i drift.

– Først da kan vi være sikre på at gevinstene innarbeides i løsningen og oppnås

– Først da kan vi være sikre på at læringssløyfen i syklusene er komplett


Vi må utvide scopet nok en gang!

Krav

Kode

Gevinst

Mål


Krav til smidig metodikk:

Sikre at de riktige målene danner grunnlag for arbeidet– Konkretisering og kvantifisering av målene,

– Håndtering av krav som ikke støtter målene

Sikre tidlige leveranser av de viktigste målene/gevinstene– All utvikling styres og prioriteres ut fra bidrag til måloppnåelse

Sikre at de mål/gevinster som er satt for prosjektet faktisk oppnås– Testing i forhold til måloppnåelse

– Leveranseprosessen styres ut fra måloppnåelse

– Det verifiseres at gevinstene er levert i drift i organisasjonen

Håndtere endringer på en proaktiv måte– God støtte for læring underveis og justeringer som følge av det

– God støtte for håndtering av endrede rammebetingelser


Dette betyr i praksis en kombinasjon av elementer fra flere smidige metoder

Mål-og krav håndtering fra EVO, med litt inspirasjon fra LEAN

SCRUM-møte og basis syklushåndtering og utviklingsdelen fra SCRUM, med noen elementer fra Crystal, LEAN og XP

Fokus på leveranse av gevinstene i drift hentet fra EVO, med elementer fra XP og LEAN

Mål ogkrav

UtviklingLeveranse


Smidige erfaringer

Vi har høstet mye positiv erfaring med smidig prosjektgjennomføring, basert på en slik kombinasjon av metoder

– Kortere tid til leveranser og gevinster

– Lavere risiko

– Mindre slitasje på teamet

– Bedre støtte for læring underveis

– Bedre håndtering av skiftende rammebetingelser


6. Prinsipper for smidig prosjektgjennomføring

Forretningsmålene styrer arbeidet

Smidighet fra mål til gevinst

Små skritt– Små skritt krever mindre overhead. Hvis vi tar små skritt er det

enklere å ta et skritt tilbake og lavere risiko.

– Jevn strøm av leveranser og resultater fremfor ”Big Bang”.

Enkelhet– Utfordre den vanlige måten å tenke på: Spør (uavhengig av

kravene): Hva er den enkleste måten å få til dette på?

Forbedring– Ingenting er perfekt, men å forbedre(jobbe mot det perfekte),

basert på erfaringene som høstes underveis er nyttig.


Prinsipper for smidig prosjektgjennomføring

Muligheter– Angrip problemet som en mulighet til å løse oppgaven på en annen måte

Mangfold– Det er sunt at teamene består av et mangfold av kompetanse, erfaring

og perspektiver. – Vi har forskjellige styrker og svakheter, og dette er bra for teamet hvis

det utnyttes riktig. (Tenk fotball-lag).

Kommunikasjon og tilbakemelding - løpende– Nødvendig at alle skal vite hva de skal gjøre og for å avdekke problemer– Fordi vi ellers ikke kan vite om vi er på rett vei

Refleksjon og evaluering - løpende– Gode team gjør ikke bare jobben sin, men de tenker over hvordan de

gjør den og hvorfor.

Overlappende kvalitetsmekanismer– Sikre at feil og mangler blir avdekket (i tide) ved å ha et sett av flere

mekanismer, fordi ingen enkelt-mekanisme kan avdekke alt. Den viktgiste kvalitetssmekanismen er faktisk bruk og faktisk erfaring.


Fokus på korte leveransesykluser

Lange sykluser gjør reaksjonstiden ved endringer lang

Lange sykluser gir lang vei før det forefinnes noe resultat i det hele tatt

Lange sykluser gir ikke god støtte for læring underveis

Korte sykluser håndterer endringer løpende

Korte sykluser gir kort vei til et brukbart resultat

Korte sykluser gir god støtte for læring, og teamet blir dyktig på å levere


7. En generisk modell - Et smidig rammeverk basert på tre sykluser

Gevinst

Mål

UtvLev.

3


Mål og krav-syklus (Mye EVO)

Gevinst

Mål

UtvLev.

1

23

MålKravDesignforslag Prioritering

Mål og krav


Utviklings-syklus (Mye SRUM)

Gevinst

Mål

UtvLev.

1

23

Koding og testBrukerprøvingTilbakemeldingVerifisering

Utvikling


Leveranse-syklus (Mye OU)

Gevinst

Mål

UtvLev.

1

23

Driftsforb.OpplæringDriftsettingGevinstmåling

Leveranse


SMIDIG METODIKK – fra mål til gevinst

GevinstForankringMålKravDesignforslag Prioritering

Mål og krav

EVO

Utvikling

SCRUM

LeveranseDriftsforberedelseOpplæring og OUDriftsettingGevinstmåling

1 2 3

Koding og testBrukerprøvingTilbakemeldingVerifisering

Gevinst

Mål og krav

UtviklingLeveranse

1

23


Oppsummering

1. Fordi verden er usikker2. Hyppige leveranser,

forbedring og læring3. Det finnes mange4. Annerledes, men ikke enklere5. Forretningsfokus – tvers

gjennom

6. 12 prinsipper som gir effekt7. Tre sykluser satt sammen

1. Hvorfor smidig




5. Noen sentrale utfordringer - hva skal til for å lykkes

6. Gode prinsipper

7. En generisk modell


Mål

UtviklingLeveranse

Hovedleveranser fra syklusene

Kontrakt

Løsn. skiss.

Del-løsning

Gevinst

Vedl.

GevinsterKravLøsn. skissPlaner

Documents

20081022 Smidig prosjektmetodikkv1.prosjektnorge.no/files/events/73/20081022-smidig... · 2013. 12. 3. · Utvikling/test Leveranse Dette burde vi tenkt på i spesifieringen Hvordan