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