It-kontrakter iterative forløb

Transkript

1 It-kontrakter iterative forløb v/ Nicolai Dragsted Bender von Haller Dragsted Århus, den 1. april 2009

2 Indledning 2

3 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

4 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

5 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

6 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 6

7 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

8 Bonnerup-rapporten Side 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

9 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. modularity.asp 9

10 Vandfald ctr. Agile metoder 10

11 Å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

12 Eksempler på metoder Dynamic Systems Development Method DSDM DSDM Consortium Microsoft Solutions Framework - MSF Rational Unified Process RUP (Booch e.a.) extreme Programming XP Rapid Application development (RAD) Scrum 12

13 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

14 Å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

15 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

16 Udvalgte reguleringstemaer 16

17 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

18 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

19 Kravspecifikation Indhold Forretningsmæssigt orienteret Mindre detaljeret Fastlægger absolutte mindstekrav Business case 19

20 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 20

21 21

22 Modenhed Publikationen Modenhed i it-baserede forretningsprojekter selvangivelse / kompetenceprofil 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

23 Modenhed = et dialog værktøj Kunden beskriver egen modenhed og angiver rammerne for leverandørens tilbud Modenhed = en del af parternes ydelser 23

24 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

25 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

26 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

27 Rådgivning Den valgte metode Den valgte teknologi Ressourceforbrug Estimat som led i rådgivning om økonomi 27

28 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

29 Ø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

30 Kontraktskabelon 30

31 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

32 SKI rammeaftaler SKI Leverandøren driver processen Projekter og vedligeholdelse Vejledning SKI konsulentydelser Kunden driver processen 32

33 SKI leveringsaftaler Direkte tildeling/ Mini-Udbud Mini-Udbud Leveranceform: Forbrugsafregning Forbrugsafregning med maksimalpris Fast pris Projekter Implementering og korterevarende projekter (K01 baseret) Længerevarende Projekter (K02 baseret) Vedligeholdelse Samlet pakke: Leveringsaftale i 12 versioner med bilag - Samme bilagsstruktur i alle Leveringsaftalerne! 33

34 Projektaftalerne i SKI K O M P L E K S I T E T Projekter Korterevarende projekter (K01 model) Længerevarende projekter (K02 model) Forbrugsafregning (16 sider, 28 er) (27 sider, 40 er) (36 sider, 40 er) Forbrugsafregning med maksimalpris (16 sider, 28 er) (28 sider, 41 er) (39 sider, 41 er) Fast pris (15 sider, 27 er) (25 sider, 40 er) (38 sider, 40 er) Fleksibilitet 34

35 Fremtidige publikationer 35

36 Publikationer SKI vejledning - offentliggøres d.d. brug under (og 02.15) ITST ultimo 09 vejledning BvHD + Dahl K01 og K02 versionering 36

37 Agile metoder i offentlige itprojekter IT-arkitekturkonferencen 2009 Onsdag den 1. april Specialkonsulent Frederik Siegumfeldt Kontoret for it-styring og grøn it IT- og Telestyrelsen Videnskabsministeriet

38 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

39 Prosa-artikel

40

41 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

42 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

43 Business.dk-artikel

44 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

45 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!

46 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)

47 Faseopdeling eller iterativ udvikling?

48 Faseopdeling eller iterativ udvikling?

49 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

50 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

51 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 Norge PS 2000 Standard contract ) Skal vi fastlåse området med en standardkontrakt?

52 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

53 Målgruppe Offentlige myndigheder (i princippet alle niveauer i beslutningsprocessen) Fagchef Direktion Itansvarlig Kontraktansvarlig Administration Projektansvarlig Legitimere valget Informere om metode

54 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

55 Proces for udarbejdelse af vejledningen K02-arbejdsgruppen (karakter af agreed document ) Løbende brugerinddragelse Kunder Leverandører Afsluttende høring Sommer 2009

56 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)

57

58 Kontaktoplysninger Specialkonsulent Frederik Siegumfeldt IT- og Telestyrelsen Holsteinsgade København Ø Tlf Mail: