Embed Size (px)
DESCRIPTION
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?
Citation preview
Nøkkelen til å lykkes med smidige prosjekter
Olav Folkestad
IT-Tinget, 24. september, 2009
Dr. Winston W. Royce…
IT-Tinget 24. oktober 2009 Side 2
Kilde: Dr. Winston W. Royce ”Managing the development of large software systems”, 1970, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
På side 2…
IT-Tinget 24. oktober 2009 Side 3
Systemer som ikke løser forretningsbehovene
IT-Tinget 24. oktober 2009 Side 4
Source: S. Jarzombek, ”Proc Joint Aerospace Weapons Systems Support, Sensors and Simulation Symp.”, Gov’t Printing Office Press, 1999
34 %
46 %
20 %
$37 mrd DoD-prosjekter basert på 2167A
System som ble tatt i bruk direkte (34%)
System som aldri ble tatt i bruk (46%)
System som krevde omfattende tilpasninger før bruk (20%)
På siste side…
IT-Tinget 24. oktober 2009 Side 5
”I my experience, however, the simpler method has never worked
on large software development efforts...”
Kort om smidige metoder
HVA
Tradisjonell systemutvikling
IT-Tinget 24. oktober 2009 Side 7
Beh
ov
Kra
v
Ko
nsep
t
Sp
esifik
asjo
nPlattform
Arkitektur
Overordnet design
Detaljert design
Kode
Test
Produksjon
HV
OR
DA
N
HVA
HV
OR
DA
N
Smidig systemutvikling
IT-Tinget 24. oktober 2009 Side 8
Inkrementelt
Iterativt
Evolusjonært Hyppige leveranser
=Hyppig
feedback
HVA
HV
OR
DA
N
Smidig systemutvikling
IT-Tinget 24. oktober 2009 Side 9
Evolusjonært Hyppige leveranser
Hyppigfeedback
Inkrementelt
Iterativt
Fra krav til kode
IT-Tinget 24. oktober 2009 Side 10
Krav Kode
TDD
Fra prioriterte krav til produksjonsklar kode
IT-Tinget 24. oktober 2009 Side 11
Prioritertekrav
Produksjonsklarkode
Kontinuerlig integrasjon
Automatisert testing
Dem
on
stra
sjo
n
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
Hyppige leveranser
#1
Kortere prosjekter har større sannsynlighet for å lykkes
IT-Tinget 24. oktober 2009 Side 14
Kilde: Jim Johnson, et al. 1998. ChAOS: A recipe for success, 1998.
0 %
10 %
20 %
30 %
40 %
50 %
60 %
6 9 12 18 24 36
Måneder
23.000 prosjekter
Én leveranse
IT-Tinget 24. oktober 2009 Side 15
TID
VERDI
Verdi
Fire leveranser
IT-Tinget 24. oktober 2009 Side 16
TID
VERDI
Når går ”vinningen opp i spinningen”
IT-Tinget 24. oktober 2009 Side 17
TID
VERDI/KOST
Produkteier med sterkt eierskap– fokuserer på verdi
#2
Produkteier må sikre verdifokus
IT-Tinget 24. oktober 2009 Side 23
Omfang Verdi Estimat
KR
AV
Produkteier eier prioriteringer
Dynamisk Kontrollert
Arbeid med de høyest prioriterte krav hele tiden
IT-Tinget 24. oktober 2009 24
Iterasjon
Leveranse
Produkt
Ver
di
HØY
LAV
Nye idéer/krav for fremtidige leveranser
IT-Tinget 24. oktober 2009 25
Iterasjon
Leveranse
Produkt
Nye idéer/krav som ønskes inn i pågående leveranse
IT-Tinget 24. oktober 2009 26
Iterasjon
Leveranse
Produkt?Forlenge prosjektetØke innsatsenRedusere omfang
Beslutning kreves!
IT-Tinget 24. oktober 2009 27
Iterasjon
Leveranse
Produkt
Dynamisk krav – spesifisert som tester
#3
Faktisk bruk av implementerte krav spesifisert initielt
IT-Tinget 24. oktober 2009 Side 29
Kilde: J. Johnson 2002
7 %
13 %
16 %
19 %
45 %Alltid
Ofte
Av og til
Sjelden
Aldri
Analyse og design gjennomføres løpende
IT-Tinget 24. oktober 2009 Side 30
Krav Krav Krav Krav Krav?
Krav Krav Krav Krav Krav KravKrav
TestUtviklingAnalyse og
design
KravKrav
Tra
dis
jon
elt
Sm
idig Analyse og design
Utvikling
Test
Lik innsats – forskjellig disponering
IT-Tinget 24. oktober 2009 Side 31
Utnytt læringskurven
IT-Tinget 24. oktober 2009 Side 32
TID
VERDI
Reell feedback
Detaljering følger prioritering
IT-Tinget 24. oktober 2009 33
Iterasjon
Leveranse
Produkt
Ver
di
HØY
LAV
Det
alj
erin
gsn
ivå
HØY
LAV
Og kravene detaljeres (så langt det er mulig)
gjennom å spesifisere tester
– fortrinnsvis automatiserte
Leverer produksjonsklar kode – hver iterasjon
#4
Fra prioriterte krav til produksjonsklar kode
IT-Tinget 24. oktober 2009 Side 35
Prioritertekrav
Produksjonsklarkode
• Utviklet• Testet• Integrert• Dokumentert
Dette sikrer et empirisk mål på fremdrift i prosjektetog gjør at prosjektet på et tidlig stadium kan ta kvalifiserte beslutninger
IT-Tinget 24. oktober 2009 Side 36
0
2
4
6
8
10
12
Planlagt
Faktisk
Est. fart
Snitt
Tilpasser arbeidsprosessen– basert på læring/empiri/evne
#5
Oppsummert
Utfordringer
IT-Tinget 24. oktober 2009 Side 40
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
Gevinster
IT-Tinget 24. oktober 2009
Side 41
Realisere verdi raskere Redusere risiko tidligere
Øke visibiliteten Bedre kvalitet over tid
Smidig
Tradisjonelt
Jevnere ”stressnivå”
Reduserte endringskostnader
BEKK CONSULTING ASSKUR 39, VIPPETANGEN. P.O. BOX 134 SENTRUM, 0102 OSLO, NORWAY. WWW.BEKK.NO
Olav Folkestad
Adm. direktør
+47 982 19 400
