Definisjonen av vellykkede IT-prosjekter er som regel ”on time - on budget”. Men hva hjelper dette dersom løsningen eller produktet ikke løser forretningsbehovene?
1. Nøkkelen til å lykkes
med smidige prosjekter
Olav Folkestad
IT-Tinget, 24. september, 2009
2. Dr. Winston W. Royce…
Kilde: Dr. Winston W. Royce ”Managing the development of large software systems”, 1970, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
IT-Tinget 24. oktober 2009 Side 2
4. Systemer som ikke løser forretningsbehovene
$37 mrd DoD-prosjekter basert på 2167A
20 % System som ble tatt i
bruk direkte (34%)
34 %
System som aldri ble tatt i
bruk (46%)
System som krevde
omfattende tilpasninger
46 % før bruk (20%)
Source: S. Jarzombek, ”Proc Joint Aerospace Weapons Systems Support, Sensors and Simulation Symp.”, Gov’t Printing Office Press, 1999
IT-Tinget 24. oktober 2009 Side 4
5. På siste side…
”I my experience, however,
the simpler method has never worked
on large software development efforts...”
IT-Tinget 24. oktober 2009 Side 5
7. Tradisjonell systemutvikling
Produksjon
HVORDAN
Test
Kode
Detaljert design
Overordnet design
Plattform
Arkitektur
HVA
Behov
Krav
Konsept
Spesifikasjon
IT-Tinget 24. oktober 2009 Side 7
8. Smidig systemutvikling
HVORDAN Evolusjonært Hyppige
leveranser
=
Iterativt
Hyppig
feedback
HVA
Inkrementelt
IT-Tinget 24. oktober 2009 Side 8
9. Smidig systemutvikling
HVORDAN Evolusjonært Hyppige
leveranser
Iterativt
Hyppig
feedback
HVA
Inkrementelt
IT-Tinget 24. oktober 2009 Side 9
10. Fra krav til kode
Krav Kode
IT-Tinget 24. oktober 2009 Side 10
11. Fra prioriterte krav til produksjonsklar kode
Kontinuerlig
integrasjon
Demonstrasjon
Prioriterte Produksjonsklar
krav TDD kode
Automatisert
testing
IT-Tinget 24. oktober 2009 Side 11
12. Hvordan lykkes med smidige prosjekter
1. Hyppige leveranser (< 3 mnd)
2. Produkteier hos kunden med sterkt eierskap og beslutningsevne
3. Dynamisk krav (endringer er bra!) - spesifisert som tester
4. Leverer produksjonsklar kode hver iterasjon (integrert og testet)
5. Tilpasse prosess og produkt basert på læring/empiri/evne
IT-Tinget 24. oktober 2009 Side 12
14. Kortere prosjekter har større sannsynlighet for å lykkes
60 %
23.000 prosjekter
50 %
40 %
30 %
20 %
10 %
0%
6 9 12 18 24 36
Måneder
Kilde: Jim Johnson, et al. 1998. ChAOS: A recipe for success, 1998.
IT-Tinget 24. oktober 2009 Side 14
17. Når går ”vinningen opp i spinningen”
VERDI/
KOST
TID
IT-Tinget 24. oktober 2009 Side 17
18. #2
Produkteier
med sterkt eierskap
– fokuserer på verdi
19. Produkteier må sikre verdifokus
Dynamisk Kontrollert
Produkteier eier prioriteringer
KRAV
Omfang Verdi Estimat
IT-Tinget 24. oktober 2009 Side 23
20. Arbeid med de høyest prioriterte krav hele tiden
HØY
Iterasjon
Leveranse
Verdi
Produkt
LAV
IT-Tinget 24. oktober 2009 24
21. Nye idéer/krav for fremtidige leveranser
Iterasjon
Leveranse
Produkt
IT-Tinget 24. oktober 2009 25
22. Nye idéer/krav som ønskes inn i pågående leveranse
Iterasjon
?
Leveranse
Forlenge prosjektet
Øke innsatsen
Redusere omfang Produkt
IT-Tinget 24. oktober 2009 26
25. Faktisk bruk av implementerte krav spesifisert initielt
7%
13 %
Alltid
45 %
Ofte
Av og til
16 %
Sjelden
Aldri
19 %
Kilde: J. Johnson 2002
IT-Tinget 24. oktober 2009 Side 29
26. Analyse og design gjennomføres løpende
Krav Krav Krav Krav ? Krav Krav Krav
Tradisjonelt
Analyse og
Utvikling Test
design
Krav Krav Krav Krav Krav Krav Krav
Smidig
Analyse og design
Utvikling
Test
IT-Tinget 24. oktober 2009 Side 30
27. Lik innsats – forskjellig disponering
IT-Tinget 24. oktober 2009 Side 31
29. Detaljering følger prioritering
HØY HØY
Detaljeringsnivå Iterasjon
Leveranse
Og kravene detaljeres
Verdi
(så langt det er mulig)
Produkt
gjennom å spesifisere tester
– fortrinnsvis automatiserte
LAV LAV
IT-Tinget 24. oktober 2009 33
31. Fra prioriterte krav til produksjonsklar kode
Prioriterte Produksjonsklar
krav kode
• Utviklet
• Testet
• Integrert
• Dokumentert
IT-Tinget 24. oktober 2009 Side 35
32. Dette sikrer et empirisk mål på fremdrift i prosjektet
og gjør at prosjektet på et tidlig stadium kan ta kvalifiserte beslutninger
12
10
8
6 Planlagt
4 Faktisk
Est. fart
2 Snitt
0
IT-Tinget 24. oktober 2009 Side 36
33. #5
Tilpasser arbeidsprosessen
– basert på læring/empiri/evne
35. Utfordringer
Mister ”tryggheten” ved å ha alle krav definert før arbeidet starter
Utfordringer synliggjøres mye tidligere
– kan skape inntrykk av at prosjektet ikke går på skinner
Sikre helhet – evnen til å se lengre enn én iterasjon
Krevere en del nye praksiser (test-drevet, kontinuerlig integrasjon, …)
Krever involvering av kunde (produkteier) kontinuerlig
– evne og vilje til å prioritere og ta beslutninger
IT-Tinget 24. oktober 2009 Side 40
36. Smidig
Gevinster Tradisjonelt
Realisere verdi raskere Redusere risiko tidligere Jevnere ”stressnivå”
Øke visibiliteten Bedre kvalitet over tid Reduserte endringskostnader
Side 41
IT-Tinget 24. oktober 2009