Iterativ betyder - Netamia
Iterativ betyder - Netamia
Iterativ betyder - Netamia
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
It-kontrakter – iterative forløb<br />
v/ Nicolai Dragsted<br />
Bender von Haller Dragsted<br />
Århus, den 1. april 2009<br />
www.bvhd.dk
Indledning<br />
www.bvhd.dk<br />
2
Vandfaldsmodellen<br />
Adskilte og sekventielt ordnede faser<br />
Alle krav fastlægges i detaljer før kontraktens<br />
indgåelse – kravspecifikationen styrer<br />
Alt designes før udvikling<br />
Alt udvikles inden testning<br />
Alt afprøves og overtages samlet<br />
Fokus på funktionelle krav i kravspecifikationen<br />
www.bvhd.dk<br />
3
Terminologi - iterativ<br />
• <strong>Iterativ</strong> <strong>betyder</strong> "gentaget".<br />
I et iterativt projekt gennemføres en række gentagne forløb (iterationer),<br />
der hver især kan være en miniudgave af vandfaldsmodellens faser.<br />
Beslutninger og erfaringer fra de enkelte forløb har indflydelse på<br />
indholdet af de efterfølgende forløb.<br />
Iterationer kan bruges til andet end aktiviteter med design, parameteropsætning,<br />
tilretning eller programmering. Der kan f.eks. Indgå<br />
elementer af forretningsanalyse, behovsafklaring og kravformulering.<br />
• Agile metoder<br />
Agile metoder er en fællesbetegnelse for metoder til softwareudvikling og<br />
implementering, hvor der løbende leveres til kunden gennem iterative<br />
forløb.<br />
• Inkrementel <strong>betyder</strong> "gradvist voksende”.<br />
I et inkrementelt forløb gennemføres en række kortere forløb, der ligger i<br />
forlængelse af hinanden. Systemet opstår i form af en meget lille del,<br />
som gradvist udbygges, til det endelige program er lavet.<br />
www.bvhd.dk<br />
4
Betydning af samarbejde<br />
Kernen i en iterativ proces er et tæt og dynamisk<br />
samarbejde mellem parterne, ofte via et fælles<br />
projektteam.<br />
Samarbejdet omfatter både ”forretningen” og<br />
udviklere.<br />
Metoden, projektledelsen og kontrakten skal<br />
understøtte dette samarbejde<br />
www.bvhd.dk<br />
5
ITST 15 skarpe – best practice anbefalinger<br />
Anbefaling 4:<br />
”Brug fleksible udviklingsmetoder<br />
Brug agile udviklingsmetoder – og spis elefanten<br />
i små bidder. Nedbryd opgaven i mindre<br />
komponenter, og test løbende løsningen i<br />
praktisk brug. Det giver bedre løsninger og<br />
mindre risiko for at overskride budget og<br />
tidsplan”<br />
http://www.itst.dk/arkitektur-ogstandarder/publikationer/arkitekturpublikationer<br />
www.bvhd.dk<br />
6
Bonnerup-rapporten (2001)<br />
Side 19 af 34:<br />
”….Det er arbejdsgruppens opfattelse, at store IT-projekter,<br />
der besluttes, udvikles og implementeres ”i ét hug”, hører<br />
fortiden til.<br />
...”<br />
http://www.tekno.dk/pdf/projekter/p01_Rapport_it_proj.pdf<br />
www.bvhd.dk<br />
7
Bonnerup-rapporten<br />
Side 23-24 af 34:<br />
”…….Erfaringerne fra de undersøgte projekter<br />
viser klart, at offentlige købere helt fra starten<br />
bør tage det udgangspunkt, at ikke alle krav til<br />
systemet kan fastlægges på forhånd.<br />
Der skal gøres plads til fleksibilitet og ændringer<br />
undervejs i projektforløbet. Detaljerede<br />
kontrakter bør derfor erstattes af mere åbne<br />
kontraktformer, der kan motivere køber og<br />
leverandør til et løbende samarbejde om de mest<br />
optimale løsninger. ……”<br />
www.bvhd.dk<br />
8
OGC (Office Government Commerce)<br />
Artikel: Application Development / Modularity<br />
”The focus has changed in favour of satisfying<br />
customer at the time of delivery, rather<br />
than at project initiation.”<br />
“Agile development methods are a response to<br />
business expectations, with the goal of<br />
reducing the cost of change throughout a<br />
development project.”<br />
http://www.ogc.gov.uk/delivery_lifecycle_application_development___modularity.asp<br />
www.bvhd.dk<br />
9
Vandfald ctr. Agile metoder<br />
www.bvhd.dk<br />
10
Årsager til fravalg af vandfaldsmodellen<br />
Behov for en ”lærende” proces<br />
afdækning af behov og teknologiske muligheder<br />
elementer af forretningsanalyse og BPR<br />
Det ønskes at Kundens projektdeltagere både bidrager<br />
med og opnår viden<br />
Kunden ønskes inddraget aktivt i udformning af<br />
løsningen<br />
Der ønskes fokus på fælles analyse af<br />
forretningsprocesser og understøttelse i it-systemer<br />
Udgifter og ressurceforbrug til ændringshåndtering<br />
ønskes reduceret<br />
Behov for hurtig idriftsættelse af delsystemer<br />
www.bvhd.dk<br />
11
Eksempler på metoder<br />
Dynamic Systems Development Method – DSDM<br />
DSDM Consortium – www.dsdm.org<br />
Microsoft Solutions Framework - MSF<br />
www.microsoft.com/business/services/mcmsf.asp<br />
Rational Unified Process – RUP (Booch e.a.)<br />
www.rational.com/products/rup<br />
eXtreme Programming – XP<br />
www.extremeprogramming.org<br />
Rapid Application development (RAD)<br />
http://en.wikipedia.org/wiki/Rapid_application_development<br />
Scrum<br />
http://da.wikipedia.org/wiki/Scrum<br />
www.bvhd.dk<br />
12
Scrum<br />
• Scrum indebærer afvikling af gentagne timeboxes af kort<br />
varighed. Kunden vælger løbende hvilke aktiviteter, der er<br />
vigtigst<br />
• Ved Scrum er udviklingsprocessen ikke en lineær proces.<br />
Scrum fastsætter ikke retningslinjer for i hvilken rækkefølge<br />
aktiviteterne skal implementeres.<br />
• Et projekt kan starte med en hvilken som helst aktivitet, og<br />
skifte til en anden aktivitet på ethvert tidspunkt. Det øger<br />
projektets fleksibilitet og produktivitet.<br />
• Kan beskrives som ”kontrolleret kaos”. Kontrakten bidrager<br />
til sikring af kontrollen<br />
www.bvhd.dk<br />
13
Årsager til valg af agil model<br />
• Ønske om hurtig idriftsættelse<br />
• Ønske om fokus på behov ved idriftsættelse og ikke<br />
ved projektinitiering<br />
• Krav til løsningen skifter ofte<br />
• Læring og innovation i projektet<br />
• Forretningsanalyse i projektet<br />
• Forandringsprojekt<br />
• Større sikkerhed for projektøkonomi end ved<br />
Vandfaldsmodellen<br />
www.bvhd.dk<br />
14
Agile/iterativ ctr. Vandfald<br />
Fokus<br />
Funktionalitet<br />
Idriftsættelse<br />
Kravspecifikation<br />
Overtagelsesprøve<br />
Samarbejde<br />
Ydelser<br />
Ændringshåndtering<br />
Agile<br />
Forretningsmæssigt:<br />
Understøttelse af behov og<br />
forretningsprocesser ved idriftsættelse<br />
og ikke ved projektinitiering<br />
Fastlægges endeligt i projektet.<br />
Løbende afprøvning i drift<br />
Fokus på forretningsprocesser,<br />
forretningsmæssige behov og<br />
fastlæggelse af mindstekrav<br />
Understøttelse af forretningsprocesser<br />
og øvrige krav opfyldt<br />
Dynamisk deltagelse fra begge parter,<br />
tillid til projektdeltagerne<br />
Projektledelse, rådgivning,<br />
metodekendskab, ressourcer<br />
Processen og metoden håndterer<br />
Vandfald<br />
Teknisk:<br />
Fokus på tekniske krav ved<br />
projektinitiering<br />
Kravspecifikation fastlægger<br />
”Big bang”<br />
= alt iværksættes og afprøves samlet<br />
Detaljeret angivelse af den<br />
funktionalitet, der skal etableres<br />
Kravspecifikation opfyldt<br />
Leverandøren udfører<br />
Etablering af funktionalitet<br />
Betydeligt ressourceforbrug, ændringer<br />
undgås helst<br />
www.bvhd.dk<br />
15
Udvalgte reguleringstemaer<br />
www.bvhd.dk<br />
16
Kontraktens formål<br />
Kontrakten skal sikre kunden relevante<br />
juridiske håndtag, som gør det<br />
forsvarligt, at indgå leveringsaftaler<br />
baseret på brug af iterative forløb<br />
www.bvhd.dk<br />
17
<strong>Iterativ</strong>e forløb<br />
Andre mekanismer end i K-kontrakterne<br />
• Krav: Kravspecifikationen får en anden rolle<br />
– Konkrete funktionalitet fastlægges undervejs<br />
• Procedurer og samarbejde: Større krav til<br />
forankring i kontrakten af projektledelse og<br />
procedurer.<br />
• Ydelser: Ydelserne er mere end blot etablering af<br />
forud fastlagt funktionalitet<br />
– Projektledelse<br />
– Ressourcestyring<br />
– Rådgivning<br />
www.bvhd.dk<br />
18
Kravspecifikation<br />
• Indhold<br />
– Forretningsmæssigt orienteret<br />
– Mindre detaljeret<br />
– Fastlægger absolutte mindstekrav<br />
• Business case<br />
www.bvhd.dk<br />
19
Business Case<br />
• Indhold<br />
– Forretningsmæssige mål<br />
– Baggrund for valg af iterativ model<br />
– Interessenter<br />
– Kunderessourcer til rådighed<br />
– Specifikke ”constraints”<br />
– Afhængigheder<br />
– Risici<br />
– **<br />
• Med i kravspec. + kontraktbestemmelse<br />
– Grundlag for prioritering og omprioritering<br />
– Styrende for iterationer<br />
• (Finansministeriet: Cirkulære om udarbejdelse af<br />
business case for digitaliseringsprojekter”<br />
http://modernisering.dk/da/projekter/business_case<br />
www.bvhd.dk<br />
20
www.bvhd.dk<br />
21
Modenhed<br />
• Publikationen ”Modenhed i it-baserede<br />
forretningsprojekter”<br />
– ”selvangivelse” / kompetenceprofil<br />
– http://www.itst.dk/it-styring/modenhed/maling-af-modenhed<br />
• Leverandørens modenhed (bilag 08 i K02 og 02.18)<br />
– Mindstekrav til Leverandørens ressourcer, procedurer og metoder<br />
• Kundens modenhed (bilag 11 i K02 og 02.18)<br />
– Beskrivelse af Kundens ressourcer, procedurer og metoder<br />
– Bør understreges, at Leverandøren ikke kan forvente bedre<br />
modenhed end angivet og skal indrette sine ydelser efter det<br />
oplyste.<br />
www.bvhd.dk<br />
22
”Modenhed” = et dialog værktøj<br />
Kunden beskriver egen modenhed og angiver<br />
rammerne for leverandørens tilbud<br />
”Modenhed” = en del af parternes ydelser<br />
www.bvhd.dk<br />
23
Projektorganisation<br />
• C.V. for alle deltagere<br />
– Kundens deltagere!!!!<br />
• Bør understreges, at Leverandøren ikke kan forvente bedre<br />
kvalifikationer end angivet og skal indrette sine ydelser efter<br />
det oplyste<br />
– Leverandørens deltagere<br />
• Kundens beslutningstagere i projektet<br />
• Hurtig/umiddelbar eskalationsvej<br />
• Styring af det fælles team<br />
www.bvhd.dk<br />
24
Projektledelse<br />
• Metoden angives i bilag<br />
• Styring af det fælles team<br />
– Styring af ressourceforbrug<br />
• Rapportering og opfølgning<br />
• Kvalitetssikring af alle bidrag<br />
• Koordinering af aktiviteter<br />
– Beslutninger i projektteams<br />
– Sammenhæng i system<br />
• Løbende idriftsættelse<br />
– Koordinering<br />
– Feedback fra brugere<br />
www.bvhd.dk<br />
25
Koordinering af aktiviteter<br />
”Arkitektur, Koordinering og sammenhæng:<br />
Leverandøren skal sørge for den indbyrdes koordinering<br />
af alle projektaktiviteter, samt sikre sig at der ikke<br />
træffes indbyrdes uforenelige beslutninger.<br />
Det er Leverandørens ansvar at sikre den indbyrdes<br />
sammenhæng i Systemets arkitektur og sammenhæng i<br />
øvrigt mellem Systemets enkelte dele.”<br />
www.bvhd.dk<br />
26
Rådgivning<br />
• Den valgte metode<br />
• Den valgte teknologi<br />
• Ressourceforbrug<br />
– Estimat som led i rådgivning om økonomi<br />
www.bvhd.dk<br />
27
Afregningsmodel<br />
• Forbrugsafregning<br />
• Forbrugsafregning med max pris (anbefales)<br />
• Fast pris<br />
• Bemærk at omfanget af funktionalitet aldrig er fast i et<br />
iterativt forløb. Det endelige omfang fastlægges undervejs<br />
i projektet, og er delvis bestemt af de ressourcer, der er<br />
til rådighed for projektet<br />
• Forbrugsafregning forudsætter fastlæggelse af krav til<br />
registrering af forbrug, rapportering samt bestemmelser<br />
om opfølgning i forhold til økonomi<br />
www.bvhd.dk<br />
28
Øvrige forhold<br />
• Fortrolighed + rettigheder<br />
• Kundens adgang til udtræden med kort varsel<br />
(ret til brug af leverancer, der er betalt for)<br />
• Kundens adgang til at øge egne bidrag<br />
• Kundens ret til omprioritering af ressourceforbrug<br />
www.bvhd.dk<br />
29
Kontraktskabelon<br />
www.bvhd.dk<br />
30
K02/K01/K-18/K-17/K-33 =<br />
Projektkontrakter der følger Vandfaldsmodellen<br />
Fast tid, pris og resultat<br />
Adskilte og sekventielt ordnede faser<br />
Alle krav fastlægges i detaljer før kontraktens<br />
indgåelse<br />
Kravspecifikationen er styrende<br />
Alt afprøves, testes og overtages samlet<br />
Fokus på funktionelle krav i kravspecifikationen<br />
www.bvhd.dk<br />
31
SKI rammeaftaler<br />
• SKI 02.18<br />
– Leverandøren driver processen<br />
– Projekter og vedligeholdelse<br />
– Vejledning<br />
• SKI 02.15 - konsulentydelser<br />
– Kunden driver processen<br />
www.bvhd.dk<br />
32
SKI 02.18 - leveringsaftaler<br />
Leveranceform:<br />
Projekter<br />
Implementering og<br />
korterevarende<br />
projekter<br />
(K01 baseret)<br />
Længerevarende<br />
Projekter<br />
(K02 baseret)<br />
Vedligeholdelse<br />
Direkte tildeling/<br />
Mini-Udbud<br />
Forbrugsafregning<br />
13.1.1<br />
13.2.1<br />
13.3.1<br />
13.4.1<br />
Forbrugsafregning<br />
med maksimalpris<br />
13.1.2<br />
13.2.2<br />
13.3.2<br />
13.4.2<br />
Mini-Udbud<br />
Samlet pakke: Leveringsaftale i 12 versioner med bilag<br />
- Samme bilagsstruktur i alle Leveringsaftalerne!<br />
Fast pris<br />
13.1.3<br />
13.2.3<br />
13.3.3<br />
13.4.3<br />
www.bvhd.dk<br />
33
K<br />
O<br />
M<br />
P<br />
L<br />
E<br />
K<br />
S<br />
I<br />
T<br />
E<br />
T<br />
Projektaftalerne i SKI 02.18<br />
Projekter<br />
Korterevarende<br />
projekter<br />
(K01 model)<br />
Længerevarende<br />
projekter<br />
(K02 model)<br />
Forbrugsafregning<br />
13.1.1<br />
(16 sider, 28 §er)<br />
13.2.1<br />
(27 sider, 40 §er)<br />
13.3.1<br />
(36 sider, 40 §er)<br />
Forbrugsafregning<br />
med maksimalpris<br />
13.1.2<br />
(16 sider, 28 §er)<br />
13.2.2<br />
(28 sider, 41 §er)<br />
13.3.2<br />
(39 sider, 41 §er)<br />
Fleksibilitet<br />
Fast pris<br />
13.1.3<br />
(15 sider, 27 §er)<br />
13.2.3<br />
(25 sider, 40 §er)<br />
13.3.3<br />
(38 sider, 40 §er)<br />
www.bvhd.dk<br />
34
Fremtidige publikationer<br />
www.bvhd.dk<br />
35
Publikationer<br />
• SKI vejledning - offentliggøres d.d.<br />
– brug under 02.18 (og 02.15)<br />
• ITST – ultimo 09 – vejledning<br />
• BvHD + Dahl – K01 og K02 versionering<br />
www.bvhd.dk<br />
36
Agile metoder i offentlige it-<br />
projekter<br />
IT-arkitekturkonferencen 2009<br />
Onsdag den 1. april 2009 13.00-14.00<br />
Specialkonsulent Frederik Siegumfeldt<br />
Kontoret for it-styring og grøn it<br />
IT- og Telestyrelsen<br />
Videnskabsministeriet
Agenda<br />
� Er store offentlige it-projekter dømt til at<br />
mislykkes?<br />
� Agile metoder vs. vandfaldsmodellen i<br />
offentlige it-projekter<br />
� Barrierer for anvendelse af agile<br />
projektmetoder i det offentlige<br />
� Vejledning om agil udvikling i det offentlige<br />
� Case: IT- og Telestyrelsens erfaringer med<br />
Scrum ifm. udvikling af digitaliser.dk
Prosa-artikel
Bonnerup-rapporten (2001)<br />
� Behovet for politisk forståelse og<br />
opbakning bliver endnu større i<br />
takt med, at projekterne bliver<br />
mere komplekse og krydser<br />
grænserne mellem flere dele af<br />
den offentlige forvaltning<br />
� Klar erkendelse af, at det er<br />
umuligt at fastlægge alle krav fra<br />
projektets start, og at der vil opstå<br />
ændringer undervejs i<br />
udviklingsforløbet.<br />
� Standardkontrakterne K18 og K33<br />
var forældede og meget ufleksible
Udviklingen siden 2001<br />
� Styrket fokus på bl.a. modenhed, it-strategi, itarkitektur,<br />
business cases og projektstyring i<br />
forhold til offentlige it-projekter<br />
� Fællesoffentligt samarbejde – service-/<br />
domænefællesskaber og koordination af udvikling<br />
i stedet for siloudvikling<br />
� Nye standardkontrakter – K01 og K02 – og bredt<br />
dækkende SKI-rammekontrakter - mulighed for<br />
faseopdeling og indkøb af konsulentydelser
Business.dk-artikel
Agile metoder vs. vandfaldsmodellen<br />
Undgå ændringer<br />
Plan – præskriptiv<br />
Opgaveorienteret<br />
Mistillid<br />
Tro på processer<br />
Teknologi driver mennesker<br />
Vandfald Agil<br />
Accepterer ændringer<br />
Empirisk – reaktiv<br />
Løsningsorienteret<br />
Tillid<br />
Tro på mennesker<br />
Teknologi støtter mennesker
Er agile metoder løsningen?<br />
� Får vi bedre it-løsninger med agile metoder?<br />
� Kan agil udvikling håndteres i den offentlige<br />
sektor?<br />
� Hvor kontraktunderstøttes agile projekter?<br />
� Tilsyneladende meget få eksempler fra det<br />
offentlige!
Hvorfor agil udvikling i det offentlige<br />
Klassisk it-udvikling<br />
(fyld nok ressourcer på til vi ikke mærker<br />
problemerne)<br />
Agil it-udvikling<br />
(Find og fjern problemerne i fællesskab)
Faseopdeling eller iterativ udvikling?
Faseopdeling eller iterativ udvikling?
Barrierer for anvendelse af agile<br />
projektmetoder i det offentlige<br />
� Politiske udfordringer<br />
� Politisk opbakning<br />
� Intern ansvarsplacering, når det går galt<br />
� Praktiske udfordringer<br />
� Organisation og beslutningsveje<br />
� Kompetencer<br />
� Mental holdning til ”usikre” metoder<br />
� Retlige udfordringer<br />
� Bevillingsretlige<br />
� Udbudsretlige<br />
� Økonomiske udfordringer<br />
� Faste budgetter<br />
� Rigsrevisionen
Potentiale ved øget brug af<br />
agile projektmetoder<br />
� Bedre løsninger<br />
� Dækker de faktiske behov<br />
� Hurtigere løsninger<br />
� Ingen kravspecifikationsfase<br />
� Ingen udviklingen af overflødige komponenter<br />
� Billigere løsninger<br />
� Risikominimering<br />
� Fokus på brugbare delløsninger<br />
� Opgør med ”Big bang”
Vejledning eller<br />
standardkontrakt?<br />
� K-kontrakterne var og er en kodificering af praksis i<br />
forhold til vandfaldsmodeller<br />
� Der er ingen fast praksis i forhold til agile<br />
udviklingsmetoder<br />
� Kan der overhovedet laves en standardkontrakt for<br />
agile projekter?<br />
� SKI’s rammekontrakt 02.18<br />
� Norge ”PS 2000 Standard contract”)<br />
� Skal vi ”fastlåse” området med en<br />
standardkontrakt?
Vejledning om kontraktunderstøttelse af<br />
agile projekter<br />
� Overordnede formål:<br />
� Understøtte den offentlige sektors indkøb af it<br />
� Sikre gode og brugbare it-løsninger på kortest<br />
mulig tid<br />
� Delmål:<br />
� Legitimere valget af agile udviklingsmetoder<br />
� Kvalificeret beslutningsgrundlag<br />
� Understøttelse af kontrakindgåelsen
Målgruppe<br />
� Offentlige myndigheder (i princippet alle niveauer i<br />
beslutningsprocessen)<br />
Projektansvarlig<br />
Fagchef<br />
Direktion<br />
Kontraktansvarlig <br />
Administration <br />
Itansvarlig<br />
Legitimere valget<br />
Informere om metode
Indhold af vejledningen<br />
� Agile udviklingsmetoder<br />
� Fordele og risici ved agile<br />
udviklingsmetoder<br />
� Projekter der egner sig til agile<br />
udviklingsmetoder<br />
� Kundens organisation og modenhed<br />
� Aftaleretlige spørgsmål<br />
Identifikation<br />
af<br />
behov<br />
Valg af<br />
udviklings<br />
-metode<br />
Forberedelse <br />
Kontraktindgåelse <br />
Udviklingsprocessen <br />
Ibrugtagning <br />
Videreudvikling
Proces for udarbejdelse af<br />
vejledningen<br />
� K02-arbejdsgruppen (karakter af ”agreed<br />
document”)<br />
� Løbende brugerinddragelse<br />
� Kunder<br />
� Leverandører<br />
� Afsluttende høring<br />
� Sommer 2009
Case: IT- og Telestyrelsens erfaringer<br />
med anvendelse af Scrum ifm.<br />
udvikling af digitaliser.dk<br />
� Ny fælles indgang til digitalisering for alle<br />
myndigheder, leverandører og andre, der<br />
ønsker at deltage i udviklingen af det<br />
digitale Danmark<br />
� Samlet overblik over standarder, itarkitekturdokumenter<br />
og services<br />
� Brugerdrevet indhold (Web 2.0)<br />
� Bygger på open source<br />
� Udviklet med agile metoder (Scrum)
Kontaktoplysninger<br />
Specialkonsulent Frederik Siegumfeldt<br />
IT- og Telestyrelsen<br />
Holsteinsgade 63<br />
2100 København Ø<br />
Tlf. 3545 0123<br />
Mail: frhs@itst.dk
Change language