PRINCE2 og Scrum ? hånd i hånd?

Hvordan vil det egentlig se ud når PRINCE2 og Scrum holder hånd?

Illustration: Privatfoto

På Dansk ITs årskonference i sidste uge, som jeg tidligere har skrevet om, var der et glimrende indlæg af Dorte Hidan, Devoteam og Tina Siig, frontAvenue. Indlægget handlede om hvordan PRINCE2 og Scrum kan bruges sammen og bestod af en kombination af præsentation, rollespil og involvering af os, der lyttede med.

Budskabet fra Dorte og Tina er, at de to metoder har forskellige fordele:
- SCRUM sikre at kunden hurtigt får det der er vigtigt for dem
- PRINCE2 sikre med klar ledelsesinvolvering, en aktiv styring af projektets risici, ændringer og i sidste ende produktleverancer.

Og tænk hvis det var muligt at kombinere dem så vi kunne få det bedste fra begge verdener ud af det!

Tyngden af de to metoder var vidt forskellige. Som eksempel blev fremhævet at Scrum har 3 ledelsesprodukter (produkt backlog, sprint backlog, burn down chart), mens PRINCE2 har 30 ledelsesprodukter! Dorte og Tina mente, at der var potentiale for at Scrums 3 produkter kunne erstatte de fleste mest relevante af PRINCE2s produkter. Det ville i hvert fald spare nogle ressourcer til at udarbejde og vedligeholde produkterne. Men er det realistisk?

Der er mange udfordringer når PRINCE2 og Scrum mødes. Den mest grundlæggende er at PRINCE2 udøver ledelse gennem kontrol (og dermed egentlig er en fortsættelse af scientific management-traditionen) mens Scrum er selvledelse.

Udfordringerne gør, at der er nogle meget kritiske forudsætninger for at kombinere PRINCE2 og Scrum med succes:

  • Høj grad af tillid skal være til stede: Mellem kunde og leverandør, mellem styregruppe og team samt mellem projektleder og Scrum Master.
  • PRINCE2-tilhængerne skal være villige til at afgive kontrol. Specielt skal styregruppen være parat til at slække på kontrollen, hvilket kan være en stor kamel at sluge
  • Scrum-folkene skal kunne underlægge sig et vist mål af styring ? også en medium til large-size kamel for dem!
  • Tid til at modnes: Den lykkelige spadseretur hånd i hånd fungerer ikke fra dag 1.

Jeg må tilføje at det også kræver en nytænkning i forhold til den typiske kontraktmodel som ofte baserer sig på en underliggende vandfaldsmodel.

Men hvad mener du: Er det et arrangeret ægteskab mellem et sort får og en ulv i fåreklæder' Eller kærlighed ved første blik'

Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Kasper Vad

Hej Peter

Siden vi sidst arbejdede sammen er jeg blevet Prince2-certificeret og arbejder pt. med brug af agile metoder til softwareudvikling. Jeg har set lidt på Scrum (men ikke anvendt det), men arbejder pt. på at indføre DSDM Atern.

Prince2 og Scrum er to vidt forskellige ting der supplerer hinanden. Prince2 er en model for projektets organisatoriske rammer, mens Scrum handler om udvikling af selve produktet.

Generelt siger Prince2 selv, at omfanget af fx. ledelsesprodukterder anvendes i et projekt, afpasses efter omstændighederne. Dvs. at formalisering og bureaukratisering tilpasses projektet. Store og krævende projekter => høj grad af formalisering. Mindre projekter => mindre formalisering.

Prince2 og Scrum ikke noget "natural fit", men det er måske en populær målsætning, sikkert fordi der er gået mode i begge dele.

DSDM Atern i kombination med Prince2 er langt mere oplagt.

DSDM er ikke så kendt/udbredt i Danmark. Det er en agil udviklingsmetode a la Scrum, men er langt bedre dokumenteret og beskrevet. DSDM kommer fra OGC, der også står bag Prince2, og de to modeller supplerer hinanden udmærket.

Spændende diskussion!

Hilsen Kasper

  • 0
  • 0
#2 Thomas Watts

Kunne ikke være mere enig.

Har arbejdet med Scrum og et Prince2-agtitg rammeværk, og de varetager (eller... det bør de) to forskellige aspekter af et projekt.

Scrum giver, hvis det vinder godt indpas hos projektets team og interessenter, en fantastisk fremdrift og effektivitet båret af individers ansvarstagen, når de selv får tøjlerne og råderum til at gøre det, de gør bedst.

MEN fleksibilitet er kun noget værd, når rammerne er på plads. For virkelig at turde og kunne udnytte fleksibilitet, skal man vide, hvor langt man kan strække sig ressourcemæssigt, tidsmæssigt, nytænkningsmæssigt. Den type ramme kan sådan noget som Prince2 være med til at skabe.

Det er vist tydeligt, at jeg ikke er tilhænger af rigide processer i projekter, og jeg mener virkelig, at Prince2 og lignende kun hører til i kontekster, der lever og dør med gentagelige resultater og kvalitetskrav over det sædvanlige (medico f.eks.).

Lad folk gøre det, de er uddannet og ansat til, uden at putte deres arbejdsdag og metoder ind i faste rutiner, som ikke levner dem plads til at udfolde sig. Det giver gladere, mere produktive folk, og derved et bedre produkt. Men sørg samtidig for, at rammerne er der, og at de er forståede, så man kender sit råderum.

Basalt set handler det vel om, som Kasper siger, at sådan noget som Scrum er for teamet, mens Prince2 (et al) er for styregruppen. Hvor fleksibelt eller styret det ene eller det andet aspekt af et projekt skal være, afhænger af kontekst.

  • 0
  • 0
#3 Deleted User

Som Peter kort nævner, er der noget med kontraktskrivningen.

Den praksis jeg har oplevet at været en rammeaftale med betaling for løbende timer. Det betyder at det kun er kunden der bærer risikoen, og det er ikke godt for samarbejdet i længden.

Til gengæld kan det med Scrum være svært at være lige så præcis omkring hvad der leveres, så der er en udfordring at finde en model, hvor hverken kunde eller leverandør bærer en urimelig risiko.

Den kravspecifikatioinsproces man er igennem i den gamle vandfaldsmodel har den store fordel, at man får tænkt og afklaret en masse på forhånd, hvor ren Scrum har potentiale til at skabe et sublimt innovativt produkt, men også til at skabe en masse rod og uigennemtænkte løsninger, og dertil hørende mange timer til at redde fadæserne.

Derfor kunne man måske scrumudvikle på baggrund af en vandfalds kravspecifikation og aftale kontrakter i faser.

Dette får vi nok meget fornøjelse af i de næste par år.

Hilsen Christina

  • 0
  • 0
#4 Thomas Watts

Jeg er sådan set enig i dine overordnede betragtninger, men vil lige komme med min personlige holdning til især dine kommentarer om, hvad vandfaldsmodellen kan :)

Det er efterhånden gammel visdom, at med vandfaldsmodellen er det tidspunkt, hvor man planlægger mest, det tidspunkt, hvor man ved mindst.

Med mindre man arbejder afsondret fra verden udenfor, er det min erfaring, at den infleksible tilgang, der skabes (kontraktuelt, men nok egentlig især opfattelsesmæssigt "det er jo det, vi har bestemt!"), giver store problemer og frustrationer hen ad vejen, og hindrer ordentlige løsninger.

Scrum skal jo som disciplin ikke innovere - det er ikke formålet. Formålet er at levere som man udvikler (for nu at tale programmeringsprojekter specifikt) - modulært. Afgrænsede, fungerende elementer, der stykkes sammen til en helhed hen ad vejen, som de færdiggøres. At man med denne tilgang ikke er nær så fastlåst når forandring trænger sig på, eller en bedre måde/teknologi viser sig på banen, turde være åbenlyst, så herigennem åbner Scrum og relaterede metoder for at innovere.

Se på IT projekter for 10 år siden, for 5 år siden, idag - er vi blevet bedre til at styre dem mht. ressourceforbrug og slutproduktets kvalitet og anvendelighed? Uden at have statistik at basere det på, vil jeg vove den påstand, at svaret i mangt og meget er et rungende NEJ.

Giver Scrum flere problemer og uigennemtænkte løsninger end vandfaldsarbejde? Jeg ved det ikke, men min erfaring og intuition siger "tværtimod". Der, hvor scrum løber ind i problemer, ville vandfaldsarbejde givetvis have skabt langt større problemer! Det udstilles bare hurtigere med en fleksibel og mere iterativ tilgang. Og det giver så i princippet bedre mulighed for at rette skuden op, før det er for sent ... er min uvidenskabelige påstand.

Det er indlysende for mig, at den måde vi traditionelt har arbejdet på med rammerne om projekter, og især hvad angår opstartsfasen, ikke slår an, og at der skal findes alternativer.

Scrum er født som en god måde at arbejde på, men ender ofte som en måde at forsøge at komme de problemer til livs, som projektets vandfaldsopstart har skabt. Men det er en lappeløsning på et kendt problem, og så river jeg mig i håret over, at der ikke gøres noget ved det.

HVAD der skal gøres er så det store spørgsmål, og jeg har desværre ikke svarene (ellers sad jeg ikke og skrev kommentarer her - så var jeg ude at byde på Stein Baggers yacht og nogle villaer på solkysten...). Men netop problematikken omkring at udfærdige kontrakter, der kan holde til fleksibilitet og gradvis, modulorienteret leverence, er det, der holder mange tilbage, for "det kan man jo ikke - hvor er ansvaret, hvordan betaler man, hvad får man" etc.

Og med den traditionelle hat på, giver man på forhånd op overfor de problematikker, og tager the Devil you know, og prøver så efterfølgende at indføre metoder til at rette op på de selvforskyldte problemer.

Men det er ikke godt nok - det ved vi.

  • 0
  • 0
#5 Dorte Hidan

Først og fremmest vil jeg sige, at Prince2 og Scrum IKKE er valgt, fordi det er smart eller på mode:-)

Prince2 og Scrum er valgt netop fordi de komplementere hinanden og begge er produktorienteret. Fordi de er komplementerende er det også tydeligere hvem der arbejder efter hvilke processer, Prince2s eller Scrums. Det jeg også meget gerne ville opnå er at vi indser og respekterer, at der er forskellige roller i et projekt med forskellige behov til processer og styring. Det mener jeg, at Prince2 og Scrum tilsammen tager højde for. Både Prince2 og Scrum, er to velafprøvet metoder, så det var ikke spørgsmålet om at opfinde en ny tallerken, men mere om at udnytte det bedste fra hver især.

Det problem jeg så med DSDM er, at for mig at se, er DSDM blot Prince2s, og dermed projektlederens, forlængede arm med en masse produkter, der skal udfyldes og vedligeholdes. Det jeg mangler i DSDM, men som Scrum fokusere meget på er de 'bløde' processer. Her mener jeg hvordan teamet arbejder sammen og kommer i mål med deres leverancer. Manta’et i Scrum er : spørg teamet!, hvilket for nogle projektledere kan være grænseoverskridende, men det giver større commitment og ansvarsfølelse.

Nu var det egentlig ikke en lovsang jeg ville synge om Scrum. Men da jeg i sin tid begyndte at kigge på at sammenkoble Prince2 og Scrum, var det efter at have arbejdet meget med Scrum i et større software udviklingsprojekt og i gentagne situationer stået overfor projektledere der enten ikke forstod Scrum eller bare brugte en masse tid på at producere ledelsesprodukter i Prince2. De havde aldrig et retvisende billede af hvor projektet var henne og vi, Scrumteamet, havde svært ved at genkende de planer og estimater, som blev præsenteret til styregruppen.

Det burde kunne gøres bedre!

  • 0
  • 0
#6 Kasper Vad

Hvor mange har hørt om DSDM? Hvor mange har hørt om Scrum?

Jeg tror der er større kendskab til Scrum end DSDM, og derfor forekommer kombinationen Prince2+Scrum mere naturlig. Det er en generel observation og ikke møntet på nogen specifikt.

Jeg er ikke Scrum-ekspert, men DSDM er jo baseret på nogle (8 stk) principper hvoraf ét er Colloboration, som bl.a. understreger at "... members of the team are empowered to take decisions...".

Et andet princip handler om dokumentation: "Keep documentation lean and timely". Man dokumenterer efter behov, ikke efter princip.

Jeg opfatter ikke DSDM som mindre blød end scrum, men jeg tror at scrum er mere åben overfor fortolkning. DSDM er en centralt styret standard, hvorimod scrum er mindre formaliseret og styret (tror jeg...)

Anyway, jeg tror at afstanden mellem styregruppe og udviklere altid vil være stor. Det bør den vel nærmest også være af princip? Opgaven for projektlederen er bl.a. at mindske den forståelsesmæssige kløft mellem styregruppe og projektdeltagere.

  • 0
  • 0
#7 Marc de Oliveira

Som det fremgår af ovenstående er der en udbredt holdning om at dokumentation er noget, man så vidt muligt bør undgå, at det er spild af tid og at det er trivielt at dokumentere.

Jeg er stor fan af dokumentation (se evt min video om implicit og eksplicit viden):

http://podcast.SimplifySys.dk (episoden fra 17/2)

En af mine største anker imod Scrum (og Agile i det hele taget) er netop dette syn på dokumentation, som noget overflødigt, der tager tid fra det "rigtige" arbejde.

I mine øjne er dokumentation mindst lige så vigtig som produktet, da det er dokumentationen, som kan behnadles og diskuteres af alle interessenter fra slutbrugere og hele vejen op igennem ledelseshierarkiet. God dokumentation sikrer, at det er de rigtige beslutninger, som bliver taget på lang sigt. Det er god dokumentation, der gør, at en virksomhed for alvor er "Agil" (behendig).

Grunden til denne misforståelse er nok at man har set mange eksempler på dårlig dokumentation. Dokumentation er nemlig ikke god i sig selv. God dokumentation handler om at nedfælde det der er relevant. Det betyder hverken at det skal være så meget som muligt eller så lidt som muligt.

  • 0
  • 0
#8 Thomas Watts

Nej det er nu ikke korrekt, Marc.

Der er ingen her, der er imod dokumentation. Man er imod dokumentation for dokumentationens skyld. Der skal være et formål med de ting, der nedskrives, og det skal holdes "lean and timely" som Kasper siger.

Der er intet i Agile eller specifikt Scrum der går imod dokumentation. Om noget så tværtimod, da Scrum går på at få folk til at tage ejerskab, hvilket i min erfaring generelt fører til, at de leverer bedre og mere koncis dokumentation, end hvis de leverer til et stort og tungt dokumentationssystem, hvor de ved at 30-50% er unødvendig. Slutbrugerdokumentation med krav om beskrivelse af XML har jeg f.eks. været ude for...

Du siger det jo selv til sidst - man har set eksempler på dårlig dokumentation. Det har intet med Scrum at gøre - det er alm. sjusk, og det må ikke ske.

  • 0
  • 0
#9 Marc de Oliveira

Dårlig dokumentation er der eksempler på i alle miljøer, men det er forkert at tro, at vandfaldsmodellen kræver dokumentation for dokumentationens egen skyld. Det er der mig bekendt ingen udviklingsmetoder, der kræver.

Agile, derimod, har en negativ holdning til dokumentation. Her er det målet at dokumentere så lidt som muligt og kun at gøre det, når det er absolut nødvendigt. Scott Ambler skriver i bogen Agile Modeling "Focus on software, not documentation... your primary goal is to develop software, not documentation".

  • 0
  • 0
#10 Erik Maaløe

Hej Peter.

Et spændende emne og gode kommentarer.

PRINCE2 sammenfatter best practice inden for projektledelse/projektstyring. Mens Scrum og andre agile metoder prøver at finde best practices inden for udviklingsforløbet, bl.a. i erkendelsen af den traditionelle vandfaldsmodels svagheder. Det SKAL kunne forenes, håber og tror jeg.

Her handler det ikke mindst om at finde en balance mellem den styring, som er i fokus for kunden/aftageren samt for PRINCE2, og det råderum, der skal være for kreative udviklere (herunder ikke mindst arkitekter ;-)) og de erkendelser, der kommer hele vejen i udviklingsforløbet.

Dermed er der også sagt nej tak til en meget rigid kontrol. Men at identificere PRINCE2 med det er efter min mening en misforståelse. Rammerne sættes af kunden og PRINCE2, men rammen skal kunne rumme agile udviklingsmetoder. Det kan gøres på forskellig vis og på forskelligt detaljeringsniveau. PRINCE2 siger blot, at det skal være defineret på forhånd og besluttet i styregruppen.

Vi har begge deltaget i det VAS-projekt, som er meget tæt på at være afsluttet - se artiklen i Version2, http://www.version2.dk/artikel/10841-it-udfordringen-fang-sociale-bedrag.... Jeg repræsenterede kunden i dette projekt og har kørt projektet efter PRINCE2. Du har været en del af leverandørens udviklingsteam. Har du følt, at rammerne var for snævre til det optimale udviklingsforløb? Det håber jeg ikke, for det har bestemt ikke været hensigten.

VAS-projektet ydre rammer har mindet om vandfaldsmodellen, med en designfase efterfulgt at en udviklingsfase og en testfase. Det kan givetvis gøres bedre, og det skal vi prøve at lære. Men selv med EU-udbudsbetingede rammer kan og skal der efter min mening være rum for agile udviklingsforløb.

Det kræver imidlertid, at de to sider - kunden og leverandøren - respekterer hinanden og de krav, som vi hver især er underlagt. Men det oplever jeg som regel også er tilfældet.

/Erik

  • 0
  • 0
#12 Dorte Hidan

Jeg er enig i at grundlaget oftes etableres med kontrakten.

Hvis man arbejder i det offentlige regi, så kan man glæde sig over at ITST er i gang med at få udarbejdet en vejledning i at benytte agile metoder under K02 kontrakten. Så har vi også juraen på plads.

Hvis man ikke er underlagt en K02 kontrakt, fx private virksomheder, så vil jeg anbefale at kigge på PS2000, som er den norske pandang til K02: http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpe...

Sitet indeholder også en rigtig god vejledning til "smidigutvikling" med PS2000.

En af de forudsætninger der skal være til stede for at få en godt projekt med fx Scrum, er tillid mellem kunde og leverandør (også selv om de er interne). Dette kan blandt andet opnås ved at der defineres tydelige roller, forventninger og (beslutnings)processer mellem parterne allerede i kontakten, i stedet for kun at fokusere på hvordan man kan retsforfølge eller udstede boder hvis projektet kører af sporet.

Omkring hvordan man deler risikoen, så findes der flere modeller. Her er fx 10 forskellige kontrakt muligheder beskrevet, som man kan blive inspireret af: http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

Men uanset hvilken kontrakt man anvender, så er tillid mellem to parter, noget der skal bygges op. Derfor vil man typisk i starten af et projekt se at alle aftaler nøje følges og beskrivelser udarbejdes, og efterhånden som tilliden skabes/øges, vil man kunne slække på kravene – især til dokumentation.

Her er det Prince2 kommer tilbage i billedet. Prince2 har nogle udmærkede processer og ledelsesprodukter, som hjælper med at styre og informere de rette instanser, som fx SG, når der sker større afvigelser end forventet. Hvis det er i leverancedelen, så er det typisk når den aftalte tolerance overskrides. Men det kan også være styring af risici, som dukker op eller indtræder undervejs i projektet. Der vil altid dukke uforudsete ting op i et projekt og/eller tidsestimater der ikke holder. Det er i sig selv ikke et problem, eller bør ikke være det, men det er måden og timingen på hvornår vi reagere, der kan få (nogen gange fatale) konsekvenser.

Scrum giver os mulighed for at reagere tidligt og Prince2 giver os mulighed for at reagere hensigtsmæssigt i forhold til omgivelserne.

  • 0
  • 0
#13 Marc de Oliveira

Hvor sødt, Kim :-)

... og du troede, at alle var blevet enige om, at dokumentation mest var til besvær...

Men det er da godt, at vi kan hygge os her på siden alligevel :-)

Dokumentationen udgør den eksplicitte viden virksomheden har om sine systemer, og dermed er den helt central, hvis en virksomhed skal kunne omstille sig i en konstant skiftende verden. Selv om det for udviklerne ser ud som om deres programmer er det vigtigste i verden, så ser tingene ikke helt sådan ud, når man ser det fra virksomhedens ledelse. Mange forretningsledere kunne måske godt undvære den nyeste widget, hvis de til gengæld kunne få adgang til mere viden om systemerne.

  • 0
  • 0
#14 Peter Nørregaard Blogger

Jeg er helt enig med Erik i behovet for at finde de vises sten – eller i mangel af bedre, at finde balancen mellem styring og råderum. I forbindelse med VAS-projektet var jeg ikke helt tæt på projektledelsen efter de indledende design-overvejelser (selvom jeg har bidraget i forbindelse med de nærmere overvejelser omkring data) så jeg ved ikke om rammerne har strammet. Dog ved jeg at projektledelsen har fokuseret noget på og talt meget om produkterne, så de har fyldt en del for dem. Måske har de fyldt mere end strengt nødvendigt? Mit umiddelbare bud er dog, at rammerne for selve udviklerne ikke har været for snævre.

Et modspørgsmål til Erik kunne være: Har du som kundens repræsentant har fået flere informationer og mere detaljeret information end du havde brug for til at styre projektet? Eller ville du evt. kunne have klaret dig med mindre information og i stedet forlade dig på din tillid til og respekt for leverandøren? Hvis svaret er ja, så har rapporteringen fyldt mere end nødvendigt for projektlederne.

Christina skriver om det uacceptable i at risikoen ved Scrum ligger hos kunden, specielt hvis der er tale om en ramme-aftale om medgået tid i stedet for en kravspecifikation. Det er som altid risikabelt at overlade beslutninger til andre end en selv, og det er en meget valid pointe at kunden ikke kan være tjent med at bære hele risikoen selv.

Hvis det kun drejer sig om økonomi, kan man måske justere prisen ud fra en række succes-parametre efterfølgende, fx målte procesforbedringer, brugertilfredshed og den slags. Men hvis en organisation får en forkert løsning er der meget mere på spil end blot kontraktsummen. Så ideen om at scrumudvikle på baggrund af en vandfalds kravspecifikation og at aftale kontrakter i faser er bestemt ikke dårlig. Man kan vel også scrum-udvikle en kravspecifikation?

Spændingsfeltet mellem kontrol og frihed som midlet til at lave det sublime bliver ikke fuldt belyst lige med det samme – nok hverken af mig, os eller af it-faget som sådan. Hvis jeg havde svaret, havde jeg overbudt Luhmann og sad på yachten (hvis den ellers var stor nok til mig).

  • 0
  • 0
#15 Henrik Jensen

Dokumentationen udgør den eksplicitte viden virksomheden har om sine systemer, og dermed er den helt central, hvis en virksomhed skal kunne omstille sig i en konstant skiftende verden. Selv om det for udviklerne ser ud som om deres programmer er det vigtigste i verden, så ser tingene ikke helt sådan ud, når man ser det fra virksomhedens ledelse.

Jeg tror Marc at det du hentyder til det primært er dokumentation på "enterprise-niveau", hvor når mange snakker om agile metoder/dokumentation så hentydes der ofte primært til den meget kodenære dokumentation som er rettet mod udviklerne.

Jeg giver dig helt ret i at en dokumentation af forretningsprocesser og sammenhængen til IT-understøttelsen er vigtig hvis man er en større organisation hvor det ikke er let/hensigtsmæssigt at nogle medarbejdere bare render rundt med denne viden oppe i hovedet (for et eller andet sted bør denne viden jo være). Men hvis man kun kunne vælge én ting så ville jeg da stadig foretrække systemerne. Jeg mener ellers så ville dokumentation jo udelukkende være af manuelle forretningsprocesser, da der ikke er nogen sammenhæng til systemer at dokumentere.

På samme vis er også f.eks. driftsdokumentation og brugervejledning vigtigt da det er rettet mod folk (driftsfolk + slutbrugere) som ikke ville kunne opnå denne viden på anden vis. Selvfølgelig skal det dog stadig være i passende mængder. Intuitiv brugergrænseflade skal foretrækkes frem for lange brugervejledninger, og det værste jeg har set vedrørende brugervejldninger er kravspecifikationer hvor at kunden har bedt om mange forskellige typer af brugervejledning (online hjælp, papirbaseret brugermanual, e-learning m.v.) uden at stille krav om at der findes en løsning hvor at dette kan generes ud fra fælles data. At for alt tid fremover at skulle vedligeholde 3+ forskellige typer af "brugervejledninger" når der sker småændringer m.v. til systemet, det er bare rigtig tungt og koster mange penge, så man skal virkelig være helt sikker på brugerne også har behovet.

Men når der i agile metoder snakkes om kun at dokumentere efter behov så hentydes der ofte primært til design- og systemdokumentation (på papir) som er rettet udelukkende mod udviklerne. Og her har jeg bestemt også set min andel af

1) Enorme designdokumenter som der var brugt store mængder af ressourcer på at udarbejde og som viste sig alligevel ikke at holde under udviklingen, simpelthen fordi at man blev klogere som en del af processen eller fordi at verden ændrede sig.

2) Store systemdokumentations dokumenter hvor en stor del af dem aldrig blev benyttet fordi at den abstraktion der var mellem papirdokumentation og koden faktisk i flere tilfælde forvirrede mere end den gavnede og som det var enormt tungt at vedligeholde, hvilket kunne medføre misvedligehold.

Det er dog ikke det samme som at design + systemdokumentation helt skal undgås, man skal blot virkelig spørge sig selv i hvert enkelt tilfælde, hvilken værdi det giver at udarbejde den pågældende dokumentation og om man er villig til at vedligeholde den fremover. Samtidigt skal man lade være med at skrive dokumentation som forsøger at kompensere for dårlig applikationsarkitektur og kodekvalitet, så hellere rette op på disse ting.

  • 0
  • 0
#17 Deleted User

Hej Peter og Erik,

I skriver om den balance der skal være mellem den styring og kontrol, som er i fokus for kunden og det råderum, der skal være for kreative udviklere.

Jeg er netop ved at læse en bog om Lean (sorry, det er ikke for at føre debatten ud ad en ny tangent) og hér udtaler fremtidsforsker Anne-Marie Dahl de vise ord:

”På den ene side har vi et klart ledelsesmantra, med at alt skal kunne måles, vejes og kontrolleres. Ned til mindste detalje. På den anden side har vi kreativitet, design og science, som ikke kan måles, vejes og sættes i systemer. Det er et kæmpe skisma på arbejdspladserne”.

Jeg taber nærmest pusten når jeg læser de linjer og jeg mener, som projektleder, at netop dette skisma er enormt interessant at arbejde med og én af de helt afgørende problemstillinger der ligger til grund for at jeg har forsøgt mig udi at få PRINCE2 og SCRUM til at gå hånd i hånd.

Man vil jo gerne holde sin ledelse (sin egen og kundens) glad og tryg via det (kontrol)system de sætter op (for at de mener at de kan være glade og trygge), samtidig med at man gerne vil sætte teamet fri af (kontrol)systemer fordi de (desværre) oftest kan føles som en spændetrøje.

Tag for eksempel et helt trivielt eksempel som den traditionelle kravspecifikation. Hvor mange af os har ikke prøvet at sidde med i en stor udbudsforretning og besvaret 200+ krav i de sene nattetimer. Når projektet så starter så tror vi alle (leverandør, kunde, bruger) at vi ved hvad det er for et system der skal komme ud i den anden ende. Men det ved vi slet ikke. Det bliver et helt andet system.

Jeg havde en projektleder kollega på et tidspunkt, som startede sine (kravspecifikation baserede) projekter op med ordene: ” I tror alle sammen, I ved hvad det er for et system, I får – men jeg vil gerne med det samme slå fast at det system, I får, bliver et helt andet”.

Så hvad skal det til for – hele dette traditionelle kravspecifikation set-up? Tjoh, det vil ledelsen gerne have, det er sådan en trygheds-ting og man har noget man kan falde tilbage på hvis der opstår uenigheder eller tvist.

I projektet kan vi sjældent bruge de omfattende kravspecifikationer særlig længe. Vi bliver meget hurtigere klogere end hvad kravspecifikationen lægger op til og så går kravspecifikationen hen og bliver en spændetrøje. Det er ikke ret behageligt og er ødelæggende for kreativiteten og designet.

Hvad kan man så gøre ved dét. Jo, man kan fx. sikre sig en kontrakt der giver mulighed for at ”scum-udvikle kravspecifikationen” (og jo, det kan man godt gøre, Peter). Det er én af de ting jeg har forsøgt mig med og det kan varmt anbefales.

  • 0
  • 0
#18 Marc de Oliveira

Som svar på Henriks indlæg vil jeg lige fastslå, at jeg ikke kun taler om dokumentation på entreprise-niveau. Det er vigtigt, at dokumentationen hænger sammen fra de mest abstrakte planer og ned til den konkrete implementering, sådan at der er en "rød tråd" i projektarbejdet, og sådan at alle involverede taler om det samme og trækker projektet i samme retning.

Denne "røde tråd" ser jeg også som løsningen på kommunikationsproblemet mellem udviklere og ledelse, som er blevet nævnt i så godt som alle indlæg i denne diskussion. Mit indtryk er at udviklerne (og designerne) ikke bryder sig om at dokumentere fordi de ikke føler, at det har nogen værdi. De føler, at deres dokumentation ikke bliver brugt og at den ikke hænger sammen med hvad lederne går og arbejder med.

For mig at se er løsningen ikke at lederne skal gøre, hvad de synes, og lade udviklerne gøre, hvad udviklerne selv synes. Nej, løsningen er at få alle parter til at forstå værdien af at dokumentationen hænger sammen hele vejen igennem virksomheden. Denne "røde tråd" er en oplagt mulighed for udviklerne til at få ledelsen til at forstå, hvilke implementeringer udviklerne har valgt at lave, og få kommunikeret de evt endnu bedre løsninger tilbage i organisationen, sådan at kæden ikke knækker når den når til udviklilngsgruppen, og at værdien af hele resten af virksomhedens dokumentation ikke dermed undermineres.

Det er vigtig for hele virksomheden at få fanget de ting, der ikke blev implementeret som man havde forestillet sig det i kravspecifikationen. Der er jo en vigtig grund til at man valgte at skifte retning. Det skal kommunikeres tilbage sådan at ledelsens viden om IT-systemerne fortsat er korrekt, og dermed giver virksomheden de bedste muligheder for at tage de rigtige beslutninger fremover.

  • 0
  • 0
#19 Henrik Jensen

Denne "røde tråd" ser jeg også som løsningen på kommunikationsproblemet mellem udviklere og ledelse, som er blevet nævnt i så godt som alle indlæg i denne diskussion

Men det er jo igen et spørgsmål om hvor du først skal fokusere på at finde denne røde trød.

Det du siger er jo reelt at du mener at den røde trød skal skabes via dokumentation, jeg mener derimod at den røde tråd skal findes helt nede i koden.

Tag f.eks. sådan noget som en forretnings-applikation og brug af begreber i objektmodellen. Jeg har tidligere set eksempler på løsninger hvor at udviklerne har fundet deres egne begreber m.v. ud fra deres forståelse af forretning og som ikke har passet helt overens med forretningens brug af begreber. Og så har man så lavet noget dokumentation der reelt forklarer hvordan at man mapper begreberne i koden til begreberne som forretningen benytter, ved at dokumentere begreberne benyttet i objektmodellen.

Mit bud er spare noget af denne dokumentation og så i stedet tilrette begreberne i objektmodellen, så det sikrers at udviklerne og folk med den største forstand på forretningen de i højere grad benytter de samme begreber og snakker samme sprog uden at skulle sidde og slå op i noget dokumentation for at "oversætte".

Nej, løsningen er at få alle parter til at forstå værdien af at dokumentationen hænger sammen hele vejen igennem virksomheden. Denne "røde tråd" er en oplagt mulighed for udviklerne til at få ledelsen til at forstå, hvilke implementeringer udviklerne har valgt at lave

Men her er det jo igen vigtigt at skelne mellem dokumentation af den forretningsmæssige understøttelse i en given løsning og så den tekniske implementering.

Om der er benyttet MVC, MVP eller helt tredje design pattern til implementering af brugergrænsefladen, om der er benyttet OR/M Tool A, B eller C, om der blev benyttet cunstructor eller setter-baseret dependency injection o.s.v. det er altså bare teniske detaljer som jeg ofte ser at ledelsen ikke er så interesseret i at blande sig i. Sådan dokumentation er altså direkte henvendt til andre udviklere der senere skal vedligeholde og videredudvikle koden, og på dette niveau er min erfaring altså bare at kvaliteten af koden + dokumentation i koden er langt vigtigere end papirdokumentationen. Det er som tidligere sagt stadig ikke ensbetydende med at der slet ikke skal være noget papirdokumentation overhovedet.

Jeg mener hvis du designer en bil hvor der kun kan skiftes dæk ved at afmontere hele for- eller bagakslen og hvor der er en afhængighed så hvis du skifter tændrør så skal du også udskifte autoradio og påfyldning af olie skal foretages 8 forskellige steder og der er ingen indikation ved navn eller sigende ikon på olie/kølervæske/bremsevæske/sprinklervæske som angiver hvad der er hvad, for det har man fundet irrelevant da det står i manualen, så vil jeg jo stadig mene at det er en dårlig designet bil som er svær at vedligeholde, uanset hvor meget og godt du så dokumenterer disse ting i manualen.

  • 0
  • 0
#20 Marc de Oliveira

Jamen det er jo IKKE irrelevant om man har anvendt Tool A, B eller C. Her kan standardisering netop hjælpe til at alle udviklerne lærer af hinandens erfaringer og får skabt designmønstre, som alle holder sig til. Det vil også ofte give slutbrugeren en roligere og mere ensartet oplevelse af grænsefladen, for selv når man forsøger at implementere den samme funktionalitet, så giver det tit en lidt forskellig oplevelse, hvis der er brugt forskellig fremgangsmåde til implementeringen.

Der kan sidde udviklere langt fra hinanden, der arbejder på elementer, der ikke er direkte relaterede til hinanden. Derfor er det stadig vigtigt, at man på et højere niveau er i stand til at udnytte best practice på tværs af virksomheden. Derfor er udviklernes dokumentation også vigtig i den samlede (enterprise-)dokumentation.

Og for lige at svare på dit meget morsomme eksempel med dårlige designløsninger, så vil jeg hævde at en klar dialog via eksplicit dokumentation netop er en forudsætning for at man får skabt de bedste løsninger, der tager højde for den samlede løsning, og dermed undgår sub-optimering ved at een gruppe laver den mest effektive olietank, mens en anden gruppe laver den bedste autoradio, som i sidste ende kommer til at genere hinanden. Det er forkert at tro, at de enkelte udviklere selv ved, hvad der er den bedste løsning. Systemudvikling er en kollektiv process.

  • 0
  • 0
#21 Deleted User

Interesting discussion about PRINCE2 and Scrum!

On the 15th October 2009 is the PRINCE2 Nordic Forum in Stockholm. It is an event with project managers and executives from all the Nordic countries.

All though the program is still secret I can tell you that one of the speaker is an Icelandic company who will speak about their experiences of implementing Scrum & PRINCE2. There will also be presentations about MSP, P30, PRINCE2 2009 etc

More information about this event will come in August at www.qrpmmi.dk You can already reserve your free ticket at hanna.gustafsson@qrpmmi.dk

  • 0
  • 0
#22 Henrik Jensen

Jamen det er jo IKKE irrelevant om man har anvendt Tool A, B eller C

Det siger jeg heller ikke. Jeg siger at hvis du har foretaget nogle dårlige valg af tools, af design mønstre m.v. så kan du dokumentere lige så meget du vil oven på og du har stadig en løsning som ikke er optimal at vedligeholde. Men ledelsen er normalt ikke interesseret i om du har benyttet OR/M tool A, B, eller C de er interesseret i den afledte fleksibilitet, kostpris ved udførelser af ændringer m.v, altså det forretningsmæssige resultat de de tekniske detailbeslutninger.

Og samtdgigt så lige så snart at det omhandler meget kodenære elementer så vil papirdokumentation (bemærk når jeg siger papirdokumentation så mener blot dokumentation som ikke er en del af selve koden, jeg mener ikke nødvendigvis dokumentation der vitterligt er udskrevet på papir) altid indeholde en eller anden grad af abstraktion hvor man mister detaljer og præciseringsgrad. Det er også fint til at kunne skabe overblik over arkitektur, design mønstre m.v. Men når man skal foretage selve vedligeholdelsen af en given løsning så er man nu engang nødt til at dykke ned i selve koden for det er her at implementationen skal ændres. Er koden så af dårlig kvalitet, så er det stadig svært at vedligeholde.

Og for lige at svare på dit meget morsomme eksempel med dårlige designløsninger, så vil jeg hævde at en klar dialog via eksplicit dokumentation netop er en forudsætning for at man får skabt de bedste løsninger, der tager højde for den samlede løsning.

Mener du derved at man bør benytte rigtig mange ressourcer på at lave et omfattende design før man starter udviklingen?

Og i så fald er du aldrig løbet ind i at man er blevet klogere under vejs i udviklingen eller at omverdenen har ændret sig, så en vis portion at det oprindelige arbejde er blevet overflødigt?

Faktisk så er min "dårlige bil design" joke, heller ikke taget ud af ingenting, lad mig give et par eksempler.

8 steder at påfylde olie -> For snart en hel del år siden blev jeg involveret i vedligehold af en ehandelsløsning som blandt tilbød specielle tilbud m.v. ud fra en automatisk kundekategorisering, så virksomheden havde defineret nogle forretnings-regler for hvad der kunne betegnes som guld, sølv og bronze kunder. Problemet var at reglerne for dette var duplikeret en hel del gange i koden, jeg husker ikke om tallet var præcist 8 men det var i den størrelsesorden. Det var tydeligt at når udviklerne var kommet til et sted i løsningen hvor de havde behov for at diffentiere på kundekategorien så implementerede de blot den definere forretningsregel på ny. Så der var altså de her omkring 8 steder spredt udover brugergrænseflade, forretningslag og sågar indlejret i stored procedures i databasen som indeholdt denne forretningslogik.

Udviklerne havde faktisk været så flinke at dokumentere hvor disse omkring 8 steder var, og selvfølgelig giver jeg dig ret i at dokumentation af dette var rart. Men du må også give mig ret i at at det havde været endnu mere rart hvis de havde struktureret deres kode så denne forretningsregel kun var defineret ét sted. For at skulle ind og rette 8 forskellige steder med tilhørende test når kunden ændrede sin opfattelse af guld, sølv og bronze kunder, det er altså bare mere besværligt end at rette ét sted uanset hvor god dokumentation så er. Lige som det er nemmere kun at fylde olie på bilen ét sted end 8 steder, uanset om det så står i manualen hvor de 8 steder er.

Jeg vil også vove at påstå at havde de struktureret deres kode så denne forretningsregel kun var defineret ét sted og de havde sikret sig at det var pænt indkasplet og kunnne findes hvor man forventede at finde en sådan regel f.eks. i kunde objektet i forretningslaget, men ikke havde dokumenteret dette, så ville jeg stadig hurtigere kunne havde foretaget ændringen, fordi at den tid jeg skulle bruge på at finde hvor at forretnings-reglen var placeret i koden ikke ville være længere end at rette + teste de ca. 7 ekstra steder i koden på trods af at jeg vidste hvor.

Ingen indikation ved navn eller sigende ikon på olie/kølervæske/bremsevæske/sprinklervæske -> denne er lidt mere søgt men den illustrerer faktisk meget godt hvorfor at dokumentation på det rette sted er vigtigt og at dette rette sted i nogle tilfælde er tættest på implementationen og ikke i noget særskilt dokumentation.

Når jeg står med den nyindkøbte sprinklervæske i hånden og har åbnet motorhjelmen så er det da mere effektivt hvis der er noget implementationsnær dokumentation (f.eks. et navn/eller ikon på beholderen) som gør at jeg ikke skal hen og fremfinde manualen for at påfylde sprinklervæske. Det er så sikkert en god idé også at dokumentere det i papirmanualen men det forringer effektiviten hvis det kun er angivet i en papirmanual. På samme vis når en udvikler skal ind og ændre i noget kode, så øger det effektiviten gevaldigt hvis koden er selvforklarende, eller hvis dette ikke er muligt så at der er angivet forklaringer i selve koden på hvorfor at den ser ud som den gør. Med mindre at man er supermand så tager det altså bare længere tid at gå hen til reolen og hente de 4 ringbind med dokumentation og herefter finde det rigtige sted der beskriver den kildekode man ser foran sig. Igen det betyder ikke at så skal alt dokumentation udover det som findes i kildekoden undgås, men det betyder at man skal vælge sit medie med omhu, og man skal ikke tro at papirdokumentation kan rette fuldstændigt op på dårlig kode.

Skifte tændrør medfører at du også skal udskifte autoradio -> den type underlige afhængigheder som medfører at der rettes i en del af koden og så der pludselig opstår utilsigtede og ulogiske bivirkninger i andre dele af løsningen, har de fleste udviklere nok oplevet, og for at minimere dette handler det i høj grad om at havde en god struktur, at sikre en ordentlig opdeling, løs kobling mellem de enkelte dele der udgør ens løsning m.v. Det siger sig selv at har man sådanne problemer i sin løsning så er det selvfølgelig fint nok at dokumentere dem, så andre er klar over disse udfordringer, men det er da endnu bedre hvis man undgå dem.

Og når det handler om at undgå dem og i det hele taget udvikle kode af god kvalitet, så er min erfaring at så er et omfattende forudgående design-dokument ikke nogen silver bullet. Måske det er fordi at jeg er en dårlig udvikler men jeg har det sådan at når jeg udvikler noget som er lidt komplekst, så rammer jeg sjældent helt rigtigt i første forsøg (første indskrivning af koden). Jeg bruger gerne efterfølgende et par iterationer med refactorings til at højne kvaliteten på koden til det niveau jeg ønsker. Og det er ikke fordi at jeg ikke tænker over kvaliteten i første forsøg, det er simpelthen fordi at det bliver lettere at se hvordan der kan forbedres når det første forsøg er på plads. Men når jeg har hører fra andre så tror jeg faktisk at det måske er meget normalt, at man ikke altid rammer rigtig i første forsøg. Men hvis det netop nu er sådan, hvad er det så der får nogen til at tro at hvis de nu sætter sig ned og skriver første version på papir (design) så rammer de helt sikkert mere rigtigt end hvis de gør det i kode?

Igen jeg siger ikke at derfor skal forudgående design helt undgås, men jeg ved i hvert fald fra mig selv at der er grænser hvor dybt jeg skal gå i det forudgående design, før at jeg ryger ned på et detaljeringsniveau hvor at jeg under alle omstændigheder ikke rammer rigtigt i første forsøg hvad angår den kodekvalitet jeg ønsker. På samme vis er min erfaring også at mange forretningsfolk/ brugere har en lignende grænse for hvor dybt de kan gå i et forudgående design når det omhandler funktionalitet. De fleste af os har nok oplevet at bruge lang tid på at debattere og nedskrive funktionalitetskrav til en løsning under en designfase, for derefter først at få at vide hvad kunden virkelig ønsker sig, når man viser dem første version af det som de bad om under designet.

Men der er ingen tvivl om at som så meget andet her i livet så handler det jo om en balancegang, hvor intet dokumentation ikke er godt og rigtig meget dokumentation heller ikke er godt, og så ligger det rigtige svar gemt et eller andet sted indimellem.

  • 0
  • 0
#23 Marc de Oliveira

Wow, Henrik, det var da en ordentlig omgang fra een, der ikke tror på så meget dokumentation :-)

Jeg er helt enig med dig om at god kode med en høj grad af genbrug er bedre end dårlig kode med mange gentagelser. Jeg synes bare, at du sætter tingene lidt forkert op ved at sige at god kode med dårlig dokumentation er bedre end dårlig kode med god dokumentation. Mit argument er jo netop, at din kode bliver bedre, hvis tingene er dokumenteret godt. Så mit argument lyder at med god dokumentation får du god kode, og med dårlig dokumentation får du dårlig kode. Det er nemlig meget sværere at kommunikere, hvis kommunikationen beror på implicit viden end hvis viden er gjort eksplicit i dokumenter, der er tilgængelige for alle.

"er du aldrig løbet ind i at man er blevet klogere under vejs i udviklingen eller at omverdenen har ændret sig, så en vis portion at det oprindelige arbejde er blevet overflødigt?"

Det kan da sagtens ske at man bliver klogere undervejs i udviklingsforløbet eller at verden ændrer sig. Jeg mener netop at det underminerer den dokumentation, der allerede er lavet, hvis man ikke kommunikerer nye beslutninger tilbage i systemet. "Vandfaldet" går ikke kun een vej. Udviklerens implementationsbeslutninger er også relevante for designeren. Designerens designbeslutninger er også relevante for arkitekten. Arkitektens løsningsmodeller er også interessante for forretningslederen, og forretningslederens opfattelse er også relevant for direktionen. Hvis man ikke løbende informerer hinanden så sander dokumentationen til og mister sin værdi.

Jeg er derimod uenig i at det skulle være billigere at lave et hurtigt design og så rette fejlene i udviklingsforløbet. De målinger, jeg har hørt om, siger at for hver gang du opdager og retter en fejl i strategifasen, så har du sparet ca 10 gange prisen i forhold hvis du først havde opdaget fejlen i analysefasen. Tilsvarende kan du spare en faktor 10 ved at opdage en fejl i analysefasen frem for at det først sker i designfasen. Tilsvarende besparrelser er der ved at finde fejl i designfasen frem for udviklingsfasen, og ved at finde dem i udviklingsfasen frem for efter idriftsættelsen. Disse tal skal nok tages med et gran salt, men de viser tydeligt, at jo tidligere i et udviklingsforløb man retter en fejl, des billigere bliver projektet. Så, ja, jeg mener man skal ofre mange ressourcer på analyse og design, også selv om man bliver klogere og klogere i løbet af projektet. Visse ting kan ikke opdages før til sidst, men for hver ting der kan opdages tidligt i forløbet undgår man en masse ekstraarbejde.

Til sidst vil jeg også lige anfægte din opfattelse af dokumentation som noget man skal hen og finde frem i nogle gamle ringbind. Sådan behøver det jo ikke at være. Jeg er helt klart tilhænger af at man placerer dokumentationen så tæt på koden som muligt, men den skal være i en form, så den kan tilgås af andre end udviklerne. Så kommentarer i selve koden er som udgangspunkt en dårlig ide, med mindre man laver et værktøj, der kan trække kommentarerne ud i en læselig form. Alternativt kan man registrere dokumentationen som metadata til kodefilerne eller evt have den liggende i et dokument ved siden af koden. Der er mange måder at gøre det på. Det vigtige er at 1) det bliver naturlig for udviklerne at holde dokumentationen synkroniseret med koden, og 2) at dokumentationen nemt kan findes af intressenterne.

... og når først udviklerne ser hvordan deres guldkorn bliver brugt af andre, indgår i ledelsesdokumenter og at de oven i købet får betydning for ledelsens fremtidige beslutninger, så opfattes dokumentation ikke længere som den klods om benet, som så mange oplever det!

Og de levede lykkeligt til deres dages ende... :-)

  • 0
  • 0
#24 Henrik Jensen

Mit argument er jo netop, at din kode bliver bedre, hvis tingene er dokumenteret godt. Så mit argument lyder at med god dokumentation får du god kode, og med dårlig dokumentation får du dårlig kode.

Der er jeg så bare ikke helt enig, ikke at jeg derved er fuldstændig uenig for det er som sagt en balancegang. Men dokumentation er jo blot en abstrakation af systemet, dvs. det har ikke samme detaljeringsgrad og præcision som koden. Og jeg har set mange eksempler på hvor at noget har set fint ud på abstraktionsniveauet i dokumentation men selve koden har ikke set godt ud.

Et eksempel jeg lige husker var en applikation hvor der i dokumentation var optegnet en flot lagopdelt arkitektur, med brugergrænseflade, forretningslag, dataadgangslag, infrastrukturlag m.v. Det så alt sammen kønt ud og der var gode forklaringer af hvorfor at lagopdeling er en fordel, hvad der var ansvarsområdet for de enkelte lag, hvordan at afhængigen var mellem de enkelte lag m.v.

Nede i koden viste det sig dog at der faktisk var et par steder i forretningslaget hvor der direkte blev genereret HTML og sendt tilbage til brugergrænsefladen, og det viste sig faktisk også at der i forbindelse med nogle søgninger direkte blev genereret dele af nogle SQL strenge helt oppe i brugergrænsefladen og sendt ned igennem forretningslaget og til dataadgangslaget. Der var altså slet ikke den fine lagopdeling i koden som der var illustreret og beskrevet i dokumentationen.

De målinger, jeg har hørt om, siger at for hver gang du opdager og retter en fejl i strategifasen, så har du sparet ca 10 gange prisen i forhold hvis du først havde opdaget fejlen i analysefasen. Tilsvarende kan du spare en faktor 10 ved at opdage en fejl i analysefasen frem for at det først sker i designfasen. Tilsvarende besparrelser er der ved at finde fejl i designfasen frem for udviklingsfasen, og ved at finde dem i udviklingsfasen frem for efter idriftsættelsen.

Disse tal skal nok tages med et gran salt.

Jeg giver dig ganske ret i den sidste sætning. Jeg husker også at havde set denne "cost of change" kurve et eller andet sted, som jo faktisk ender op med at påpege at fejl og mangler som bliver opdaget efter løsningen er gået i produktion er en faktor 10.000 dyrere at rette end hvis de blev opdaget allerede i forbindelse med udarbejdelse af kravspecifikationen.

Jeg tror den der har udarbejdet denne teori har siddet og tænkt hvis jeg nu finder en fejl og det så kun tager mig 1/2 minut at rette den i mit design, så kunne det godt havde kostet mig 50+ timer at rette denne fejl i udviklingsfasen, så.....

Problemet med denne tankegang er at udarbejdelse af kravspecifikation + stort design består langt fra udelukkende af små 1/2 minutters iterationer som hver gang sparer dig for 50 udviklingstimer. Hvis det var tilfældet så burde man jo efter 1 måneds design være nede på at udviklingen tilnærmelsesvis skulle tage 0 timer :-) Rent faktisk er det slet ikke ualmindeligt at man nogle gange kan side og bruge n timer i designfasen og så alligevel ende op med i første omgang at vælge den forkerte løsning fordi at man bliver klogere eller verden ændrer sig undervejs.

I mange andre tilfælde end lige det specielle hvor man sparer 50 timers udvikling ved at bruge ½ minut på at tilrette designdokument, der ser talene efter min mening meget anderledes ud.

Lad mig tage et eksempel. For nyligt implementere jeg en række småændringer for en kunde til et system som efterhånden har været i drift i 7 år. Jeg fakturerede kunden ca. 100 timer for arbejdet.

Ud fra denne "cost of change" kurve så skulle det jo være en faktor 10.000 dyrere for mig at foretage disse ændringer til systemet nu, systemet har jo været i produktion i næsten 7 år og det var en "fejl" at kunden glemte at stille krav om dennne funktionalitet for 7+ år siden da de udarbejdede kravspecifikationen.

Så jeg brugte ca. 100 timer, hvilket vil sige at hvis kunden havde husket at få det med under kravspecifikationsarbejdet for 7+ år siden så ville det altså dengang have kostet dem mindre end 1 minut. Ja det kan da godt være at det kunne ville havde kostet dem 1 minut at skrive det ind i kravspecifikationen, men det er vist overflødigt at kommentere på om det kun ville havde taget 1 minut at implementere, inkl. design, udvikling, test og dokumentation. Mit bud er at design, udvikling, test og dokumentation måske ville havde taget 30-50 timer dengang istedet for de 100 timer det nu gjorde. Men det er altså så også kun en faktor 2-3 og ikke en faktor 10.000

Men jeg giver dig ret i at selvfølgelig er det billigere at opdage fejl og mangler tidligt. Men problemet er hvis den eneste måde du forsøger at undgå dette er bedst muligt at forudsige fremtiden samt at dokumentere alt så har du det åbenlyse problem at hvad sker der så når kundens forretningen ændrer sig så deres løsning skal ændres efter idriftsættelse?

Hvis man først fortæller kunden at det er en faktor nn dyrere at rette noget efter at det idriftssat end hvis det opdages allerede meget tidligt i processen, så må man jo også samtidigt fortalt dem at det bliver meget dyrt for dem at udføre ændringer i systemet efter idriftsættelse.

Agile metoder handler jo bestemt ikke kun om at droppe design og dokumentation og så bare kode, men i langt højere grad om de forskellige praktiske tiltag der skal være med til at hjælpe med at flade "cost of change" kurven ud så det er billigere at foretage ændringer senere i forløbet. Det kommer jo så de kunder til gode vis clairvoyante egenskaber ikke rækker til at kunne se de 8-10 år ud i fremtiden som deres system måske skal være i drift, eller som måske bliver en del klogere allerede i udviklingsforløbet.

men de viser tydeligt, at jo tidligere i et udviklingsforløb man retter en fejl, des billigere bliver projektet.

Men se det mener jeg også taler for brug af flere af de praktiske tiltag som typisk anbefales i agile metoder så som små iterationer, continuous integration, automatiserede test, pair programming m.v. Det handler jo alt sammen om at få feedback samt finde fejl så tidligt som muligt i processen.

Forskellen er bare at mens man i et projekt med en stor designfase efter den første måned eller to stadig sidder og forsøger at finde fejl/mangler og modtage feedback fra kunden via et papirdesign, så gør man det samme i den agile proces men på det tidspunkt er man bare begyndt at finde fejl/mangler og modtage feedback ved at vise kunden den første kørende software (selvfølgelig med ekstremt begrænset funktionalitet). Og som tidligere sagt så har jeg mere end én gang oplevet kunder som bedst kan fortælle dig hvad de virkelig vil havde når de begynder at se det kørende system, fordi at designbeskrivelse- og modeller bliver for abstrakte for dem.

Samtidigt så får udviklerne via continuous integration, automatiserede test og eventuelt pair programming mulighed for at finde en stor del fejl meget tidligt. For ligesom det er hurtigere at rette en fejl som findes i designfasen frem for først i udviklingsfasen, så er det også hurtigere at rette en fejl som er introduceret for 2 minutter end for 14 dage siden.

1) det bliver naturlig for udviklerne at holde dokumentationen synkroniseret med koden,

Meget enig. Jeg fortrækker også dokumentation som udtrækkes fra koden, fra datamodel tilføjet beskrivende metadata direkte i databasen på tabeller + felter m.v., fra WSDL/XSD'er som er blevet annoteret med beskrivende tekst i selve filerne eller i koden, fra modeller som er en direkte afspejling af strukturen i koden og derfor kan automatisk genereres osv.

  • 0
  • 0
#25 Erik Maaløe

Hej Peter og Tina.

Først til Peters direkte spørgsmål. Jeg fik ikke flere og mere detaljerede informationer i VAS-projektet via de officielle kontrolpunktsrapporter, end jeg havde brug for. Tværtimod konkluderede Mikael (leverandørprojektleder) og jeg i skøn samdrægtighed, at jævnlige face-to-face-møder stadig slår al skriftlig kommunikation, hvad angår jævnlig og gensidig udveksling af information.

Modsat (måske) dig, Peter, ser jeg ikke noget problem i, at leverandørens projektledelse har været meget fokuseret på PRINCE2-produkterne. Det er det kun, hvis det ikke er de i sammenhængen rigtige produkter, der er tale om. Hvis PRINCE2 med andre ord ikke er ordentligt tilpasset det konkrete projekt. Og det er et væsentligt krav i PRINCE2, altså tilpasning af metoden til den aktuelle virkelighed. Det er en vist nok udbredt misforståelse, at PRINCE2 er ensbetydende med en masse (læs: overflødige - i hvert fald for mange af dem) produkter og dokumentation. Man skal kun bruge og medtage de produkter, der giver mening i det konkrete projekt - og i en brugbar form.

Hvad tilpasningen angår, er der stadig en del at lære. Hvilket behovet for jævnlige møder viste vis-à-vis kontrolpunktsrapporterne.

Mange af os har vist oplevet problemer med kravspecifikationer, hvor slutproduktet, altså it-systemet, ender et helt andet sted. Jeg kan også forestille mig, at kravspecifikationer scrum-udvikles. Men det løser kun en lille del af problemet.

Offentlige institutioner står som regel i en udbudssituation i kraft af de gældende EU-regler, og det gør mange private virksomheder også. Her bliver man nødt til at udarbejde en kravspecifikation som en væsentlig del af forarbejdet til et udbud. Det kan godt være og er som regel en givtig proces, hvor kunden afklarer sig så meget som muligt før udbuddet. Det bliver først problematisk, hvis kunden ikke erkender, at denne afklarings- og erkendelsesproces fortsætter efter udbuddet. Hvis kunden altså fryser sig fast på det erkendelsesniveau, som blev nået, da det sidste punktum i kravspecifikationen blev sat.

Også i VAS-projektet opstod der i design- og udviklingsfaserne spørgsmål og erkendelser, som vi ikke var nået til i kravspecifikationsfasen. Alle udviklere ved, at det er helt naturligt. Spørgsmålet er, hvordan vi håndterer det. Altså bibeholder et vist niveau af kontrol fra kundens side. Husk, at det er kunden, der betaler, og kunden, der skal bruge systemet.

I VAS-projektet valgte vi at bibeholde en særskilt designfase, hvor leverandøren kunne komme med sit input til og sin videreudvikling af kravspecifikationen. Hvor designspecifikationen med andre ord blev et vigtigt produkt i udviklingsforløbet. Det oplevede jeg på kundens side som en positiv ting. Som en vigtig og givtig milepæl i projektet. Så vidt jeg ved og husker, kodede leverandøren allerede noget i desigsfasen. Det har jeg det fint med. Og selvfølgelig sluttede afklarings- og erkendelsesprocessen ikke med designet. Så vi måtte også efter designfasens afslutning håndtere uddybende fortolkninger af kravspec og design samt tillige deciderede ændringer.

Spørgsmålet er: Kunne vi have gjort det bedre? Sandsynligvis ja. Helt at droppe milepæle som kravspec og designspec kan jeg dog ikke forestille mig som kunde. Det kunne imidlertid godt være andre milepæle, der er mere i tråd med Scrum. Men hvilke?

/Erik

  • 0
  • 0
Log ind eller Opret konto for at kommentere