• Ingen resultater fundet

2.1Demangeperspektiver 2.PROCESSERNE

N/A
N/A
Info
Hent
Protected

Academic year: 2022

Del "2.1Demangeperspektiver 2.PROCESSERNE"

Copied!
38
0
0

Indlæser.... (se fuldtekst nu)

Hele teksten

(1)

I dette kapitel vil vi kigge nærmere på processerne: dels selve projektledelsesprocessen, dels udviklingsprocessen som er den måde man udvikler software på, og endelig de læreprocesser som er involveret. Projektledelse er nemlig en multiperspektivisk disciplin.

2.1 De mange perspektiver

En historie som ofte bruges til at beskrive nødvendigheden af et multiperspektivisk syn, er historien om de blinde mænd og elefanten. Den stammer fra et digt af den amerikan- ske digter John Godfrey Saxe (1816-1887) som igen baserer sig på en gammel indisk for- tælling. Digtet er langt, så her genfortælles det kun (find det evt. selv på nettet):

Projektledelse er ligesom en elefant: det afhænger af den vinkel man ser det fra, og et perspektiv (eng.: view) er netop en synsvinkel, dvs. måden at se tingene på ud fra et be- stemt ståsted. Overordnet kan vi anlægge tre hovedperspektiver:

PRODUKTPERSPEKTIVETser projektet som noget der skal frembringe et produkt med bestemte egenskaber.

INTERESSENTPERSPEKTIVETeller samarbejdsperspektivet ser projektet som et samspil mellem mennesker.

PROCESPERSPEKTIVETser projektet som en løbende proces der bringer os fra en situa- tion til en anden.

2 . P RO C E S S E R N E

De blinde mænd og elefanten

Seks blinde mænd bliver præsenteret for en elefant. Den første ramler ind i siden på dyret og udbryder: – En elefant er som en mur. Den næste kommer til at føle på stødtanden og me- ner at en elefant er som et spyd. Den tredje føler på snabelen og udtaler kategorisk at en ele- fant er som en slange. Den fjerde får fat i et ben, så en elefant må være som et træ. Den fem- te rører ved øret og er overbevist om at der er tale om en vifte, mens den sjette som rører halen, synes at en elefant er som et reb. Herefter skændes de så om hvordan en elefant egentliger.

(2)

Herunder kan anlægges forskellige specialperspektiver som typisk afhænger af hvad man mener er vigtigt i projektet:

STYRINGSPERSPEKTIVETser projektet som en række aktiviteter der gennemføres i en nærmere planlagt rækkefølge.

FORRETNINGSPERSPEKTIVETser projektet som et middel til at understøtte virksomhe- dens forretning. Her kan der f.eks. være fokus på effektivisering og profitmaksi- mering.

BRUGERPERSPEKTIVETser projektet som noget der skal opfylde brugernes behov. Her drejer det sig om at involvere brugerne i projektet, brugbarhed og brugervenlighed osv.

LÆRINGSPERSPEKTIVETser projektet som en række læreprocesser hvor vi gradvist bli- ver klogere mht. de forskellige dele.

KVALITETSPERSPEKTIVETser projektet som en række delprodukter som hver for sig skal leve op til aftalte kvalitetskriterier. Her er der fokus på inspektioner og test.

INFORMATIONSPERSPEKTIVET ser projektet som en række informationer (data) som skal indsamles, gemmes og behandles.

ARKITEKTURPERSPEKTIVETser projektet som en struktur opbygget af en række kom- ponenter der arbejder sammen.

osv.

Nogle af disse perspektiver kan være sammenhængende, men de afspejler hver for sig en måde at opfatte projektet på, et ståsted at se det fra, et verdensbillede. Man ser det samme projekt, men fra vidt forskellige synsvinkler. Nogle af perspektiverne kan bru- ges til at drive projektet, dvs. til at styre hvad der skal ske hvornår. Der er således udvik- lingsmodeller som er use case-drevne, arkitekturdrevne eller risikodrevne.

Ligesom med de blinde mænd er alle perspektiverne en del af helheden. Og det er en god ide at bruge flere perspektiver. Forskellighed gør stærk. Vi vender senere tilbage til disse specialsyn i afsnittet om Interessentanalyse.

Disse perspektiver kan også have andre navne, f.eks. dimensioner, aspekter, facet- ter, parametre, fokusområder eller discipliner.

2.2 Andre brancher

Mennesker organiserer udviklingsprocessen på mange forskellige måder, afhængigt af hvad man skal lave. Alligevel er der visse fælles træk, og man kan lære meget af at se hvordan andre gør, så lad os starte med at se hvordan man griber udviklingsprocessen

(3)

an uden for it-branchen i nogle af de brancher som man ofte sammenligner it-udvikling med. Se i øvrigt også det senere afsnit om Store ledere (side 68).

Brobygning

Ofte sammenlignes it-udvikling med brobygning. Ikke, at vi i it-branchen skal falde på halen for de dygtige brobyggere der kan levere til tiden, bare “sådan lige” og helt uden problemer. For det kan de som bekendt ikke. Fejl, dårlig kvalitet, fordyrelser og store forsinkelser finder også sted i brobygningsbranchen. Jf. Storebæltstunnelen der først blev oversvømmet og siden brandhærget (havde det så endda blot været samtidig!). Al- ligevel kan it-udviklere lære meget af brobyggere.

Et af de steder hvor it-udvikling adskiller sig mest fra brobygning, er at vi ofte har mulig- heden for at udvikle systemerne i mindre bidder. Som bekendt kan man ikke starte en bro med et frit spænd på 1.600 meter ved at sige: “Nu lægger vi lige en planke over, og så tager vi det lidt ad gangen”. Og når ankerblokkene er støbt i mange tusind tons beton, kan man heller ikke lige komme og bede om at få dem flyttet et par meter mod nord. Men ved ud- vikling af et it-system kan man som regel lave det i en iterativ proces hvor man i gentagne

Tacoma-broen

I staten Washington i det nordvestlige USA havde man byg- get en hængebro over Tacoma-snævringen,Tacoma Narrows Bridge. Det var en af de første hængebroer, så man havde ikke mange erfaringer med denne brotype. Den 7. november 1940 gik det helt galt. Når vindhastigheden bliver for høj, kan

hængebroer nemlig sættes i en voldsom kombination af vridninger og lodrette svingninger (såkaldt flutter). Dette kan forhindres ved at gøre brodækket tilstrækkeligt vridningsstabilt.

Imidler tid havde designeren af Tacoma-broen – i øvrigt på trods af advarsler – valgt en min- dre vridningsstabil løsning for derved at gøre broen billigere. Broen blev simpelthen vredet itu og faldt ned. Heldigvis kom ingen mennesker noget til (har du ikke set de spektakulære bil- leder, findes der videoklip på nettet). Brobyggerne lærte en masse af den historie, og i dag er det normalt at den slags anlæg testes i en vindtunnel, så man ved hvordan de opfører sig i blæsevejr. Tilsvarende burde det være helt normalt at alle større it-systemer gennemgik per- formancetest og test i et brugervenlighedslaboratorium før de blev sluppet løs.

(4)

delleverancer føjer mere og mere funktionalitet til systemet. Denne teknik åbner desuden mulighed for at måle på kvaliteten af systemet undervejs. Desværre åbner fastpriskontrak- ter sjældent mulighed for en sådan iterativ proces, og det er egentlig synd – for alle parter.

Men der er ikke noget i vejen for at en fastpriskontrakt kan stille krav om kvalitetsmålinger undervejs (se historien side 329 om Øresundsbroens pyloner).

Ofte bruges ingeniørdisciplin generelt som metafor for it-udvikling. Tidligere talte man ligefrem om “software engineering”. Det vi kan lære af ingeniørernes tilgang, er den detaljerede planlægning før vi går i gang (i det omfang det er muligt) samt den præcise kvalitetsstyring undervejs. Og at vi skal kende vores teknikker før vi bruger dem i stor skala. Man skal kravle før man kan gå.

Krigskunst

Ordet “kunst” i denne forbindelse, hvor det handler om at slå mennesker ihjel, er ilde valgt. Alligevel er det den betegnelse man sommetider ser anvendt af dem som gør sig tanker om det at føre krig. Ofte drages også paralleller mellem krigskunst og it-udvik- ling. Sammenligningen er forståelig. Begge dele handler om at:

– gennemføre en – ofte svær – opgave som ikke er prøvet før – mange menneskers koordinerede indsats er nødvendig – planlægning, koordinering og kommunikation er essentiel

– handlekraft når virkeligheden viser sig at være anderledes end planerne, er lige så essentiel

– ord som strategisk, taktisk og operationel er anvendelige til at anskue processen fra forskellige detaljeringsniveauer.

Og så kan vi lære noget fordi tingene bliver tydeligere (mere accentuerede) når de kom- mer ud i ekstremerne. I [Munk-Madsen96] fremhæves således et af de vægtigste mili- tærteoretiske bidrag i moderne tid, von Clausewitz’ bog “Vom Kriege”, der beskriver strategiens betydning ved ledelse af vanskelige og usikre opgaver. Det var her forståel- sen af krigen som politikkens fortsættelse blev introduceret. Her slås det bl.a. fast at vi ikke kan planlægge i detaljer præcist hvordan slaget vil forløbe – der er for mange ukendte faktorer, og virkeligheden ser alligevel altid helt anderledes ud end vi tror.

Det vi ikke bør lære af krigskunsten, som den er praktiseret op gennem historien, er den militæriske kadaverdisciplin og kæft-trit-og-retning-mentalitet hvor en ordre skal følges, uanset hvad. Det virker sjældent på it-udviklere som bare kan tage deres gode tøj og gå over til et andet firma. Og som man i den moderne militærverden har erkendt, virker det heller ikke på nutidens soldater.

(5)

Flyvning

Der er mange lighedspunkter mellem en flypilot og en projektleder:

– begge har det overordnede ansvar for opgaven

– ingen af dem kan løse opgaven tilfredsstillende uden andre – ingen af opgaverne kan løses uden dem

– begge er underlagt højere myndigheder i udførelsen af opgaven

– det er i dårligt vejr og med brand i den ene motor at de for alvor skal vise hvad de dur til.

Det vi kan lære af piloterne, er den udelte opmærksomhed på at materiellet og for- udsætningerne er på plads, gennemprøvede og i orden inden vi går i gang. Også bru- gen af tjeklister og fornuftige systemer som løbende forbedres når vi opdager fejl og uhensigtsmæssigheder.

Det vi ikke bør lære, er de nøje fastlagte flyruter som moderne flyvning gør brug af.

Hertil er it-udvikling for uforudsigelig.

Filmproduktion

Når der skal produceres en film, skal man først have en god historie: den fælles vision.

Her bruges et story board (opfundet af Walt Disney til brug ved tegnefilmproduktion).

Der laves detaljerede planer for optagelser af de enkelte scener. Ofte i total forvirring i forhold til den færdige film. Skal der bruges to scener i den samme kulisse, men to for- skellige steder i filmen, er det smartest at optage begge scener når man har hele holdet samlet det rigtige sted. Og så klippe det sammen senere. Men det kræver en detaljeret planlægning (scripting). Holdet forsøges også sammensat så optimalt som muligt i en casting hvor man finder de bedste skuespillere til rollerne.

Så her kan vi lære noget om detaljeret planlægning af de enkelte scener (i it-sammen- hæng: planlægning af de enkelte iterationer), men sandelig også om nødvendigheden af improvisation undervejs. F.eks. når skuespillerne begynder at leve sig ind i rollen og kommer med ændringsforslag.

Det vi ikke bør lære af filmproduktion, er at hele manuskriptet skal være detaljeret fastlagt inden vi går i gang. Det kan kun sjældent lade sig gøre ved it-udvikling.

Planteavl

Selv holder jeg meget af at betragte projektlederen som en gartner. Der er en række go- de paralleller mellem gartneri og projektledelse:

– Man høster som man sår. Dvs. udbyttet er afhængigt af de frø man starter med.

– En god gødning er med til at få planterne til at udvikle sig.

(6)

– Gartneren skal beskytte planterne mod angreb fra skadedyr.

– Det betaler sig at forebygge angreb f.eks. ved sprøjtning.

– Et godt (rod-)netværk er vigtigt for plantens vækst.

– Mange planter elsker sol og varme.

Af gartneren kan vi lære at tålmodighed og forudseenhed betaler sig. Gartneren kan ik- ke selv lave frugter, det kan kun planterne.

2.3 Projektledelsesprocessen

Selve projektledelsesprocessen er en generisk proces som det kan være hensigtsmæssigt at have gjort sig klart. Den vil vi se på i dette afsnit, og i det senere afsnit om Udvik- lingsprocessen vil vi se på hvordan den udmøntes til softwareudvikling.

Vi skelner mellem ledelse og styring. Ledelse handler om at gøre de rigtige ting, mens styring handler om at gøre tingene rigtigt. Begge dele er vigtige at kunne for en projektleder. Men faktisk har vi tre niveauer:

For god ordens skyld skal du vide at denne trekant normalt bruges på hele virksomhe- den. Her bruger vi den dog “kun” på projektet.

I “A guide to the project management body of knowledge” – den såkaldte PMBOKÒ Guide fra Project Management Institute ([PMI2000]) – skelnes mellem fem projektledelsesprocesser:

Fig. 2.1: De tre styringsniveauer

(7)

OPSTARThvor projektet etableres

PLANLÆGNINGhvor målet lægges fast, og kursen udstikkes – UDFØRELSEhvor arbejdet rent faktisk udføres

OPFØLGNINGhvor det sikres at vi laver det vi aftalte

NEDLUKNINGhvor projektet bringes til en kontrolleret afslutning.

Denne opdeling kan også bruges på mindre faser i et større projekt. Og du vil kunne genfinde alle elementerne i de kommende kapitler.

Der findes andre bud på en generisk projektledelsesproces, f.eks. den engelske PRINCE2 (bl.a. beskrevet i [Hughes99]).

2.3.1 Kunsten at styre

Når vi bruger ordet “styre”, har vi allerede en intuitiv fornemmelse af hvad der menes.

Det er nærliggende at lave analogier til andre situationer hvor vi “styrer”, f.eks.:

– når vi kører bil, styrer vi. Vi gør det for at komme det rigtige sted hen og for at kom- me uden om forhindringer

– når man flyver, sidder der en pilot forrest i flyet og styrer det.

Men styring er ikke bare at dreje på rattet. Styring involverer flere discipliner:

Før turen:

– Hvor skal vi hen? Der skal ske en fastlæggelse af målet.

– Hvordan kommer vi det? Hvilken vej skal vi? Er der evt. risiko for uvejr eller andre forhindringer på en del af ruten, så vi skal lægge vejen udenom? Der skal ske en plan- lægning.

– Hvor lang tid tager det? Der skal ske en tidsestimering.

Undervejs:

– Er der forhindringer forude? I bilen kan vi blot kigge ud ad forruden for at opdage eventuelle forhindringer. I fly kan vi bruge radar og automatiske landingssystemer, i ubåde kan vi bruge sonar osv. I projektet må vi også benytte os af indirekte metoder til at kigge fremad. Vi må “synliggøre” vejen foran os. Og det er betydeligt vanskeli- gere at synliggøre it-udvikling end mere fysiske fænomener (som f.eks. klippeskæret foran ubåden). Vi gør det i form af projektplaner, statusrapporter, reviews, kravspeci- fikationer, evalueringer osv.

(8)

– Aktiv styring: drej på rattet når der skal skiftes kurs. I projektet foretages ændring af bemanding, ændring af opgaver, igangsættelse af nye aktiviteter osv.

– Er vi hvor vi tror? Uforudsete ting kan bringe os ud af kurs (kastevinde, vildspor), og en gang imellem skal vi kontrollere at vi er der hvor vi tror vi er. Vi bruger her mile- pælene langs vejen eller andre kendingsmærker på landkortet. På havet, hvor der in- gen kendingsmærker er, må vi navigere efter andre pejlemærker, f.eks. stjerner. Og i dag har de fleste installeret en GPS-navigator som bestemmer positionen ved hjælp af satellitter. I projektet må vi bruge de fastlagte tjekpunkter til at finde ud af hvor vi er.

Efter turen:

– Kan vi gøre det bedre næste gang? Her skilles de professionelle fra amatørerne. De sidste er glade for at være kommet frem, men de professionelle ved at de skal på den igen. Så de sætter sig ned sammen med kollegerne og diskuterer hvad der skete på turen, og om det var gået bedre hvis de havde handlet anderledes end de gjorde. Det gælder også i projektet hvor der skal foretages en projekt-evaluering når projektet er slut, for at finde ud af hvilke ting vi kan gøre bedre næste gang.

2.3.2 Syvlagsmodellen

Det kan være nyttigt at betragte selve styringsprocessen ud fra følgende “syvlags-mo- del” som står for min egen regning (HIPEVOD-modellen):

Fig. 2.2: Syvlagsmodellen

Lagnavn Aktiviteter

Handlingslaget Informationslaget Planlaget Estimeringslaget Vilkårslaget Opgavelaget Domænelaget

Styring

Opfølgning, status Planlægning, tjekpunkter Bestemmelse af omfang Risikoanalyse, interessentanalyse Kravspecifikation

Foranalyse

(9)

Hovedformålet med styringsaktiviteterne er at blive i stand til at foretage den egentlige styring (øverst i modellen) når det viser sig nødvendigt. Altså at ændre på prioritering, bemanding, planer osv. Det kan vi kalde handlingslaget. Her finder vi også aktiviteter som kontraktstyring, underleverandørstyring, kvalitetsstyring osv.

Men for at kunne styre er det nødvendigt at have noget information at styre ud fra.

Det får vi via det næste lag, informationslaget, som f.eks. forsyner os med rapporter indeholdende grafiske oversigter, tabeller og nøgletal for projektets status. Heraf kan vi f.eks. læse at en bestemt aktivitet er ved at blive forsinket i forhold til planen, og at en anden aktivitet der netop skal til at starte, godt kan vente uden derfor at forsinke pro- jektet. Dette sætter os i stand til at træffe beslutningen (“foretage styringen”) om at om- bemande således at hende der netop skulle til at starte på den ikke-kritiske aktivitet, i stedet hjælper med til at afslutte den kritiske. Men denne beslutning er vi kun i stand til at træffe fordi vi har vores rapporter, planer osv.

For at vi kan frembringe informationerne i rapporterne, må vi tidligere have lavet en planlægning. Planerne er nemlig forudsætningen for at vi kan udtale os om hvorvidt en aktivitet er forsinket eller ej. Uden en plan ville vi ikke vide hvad aktiviteten var for- sinket i forhold til. Bemærk i øvrigt at planerne næsten altid ændres undervejs fordi målet ofte flytter sig.

Og en forudsætning for denne planlægning er nogle gode og realistiske estimater.

Planerne bliver nemlig kun så realistiske som de estimater de baserer sig på. Estimerin- gen indgår ofte som en integreret del af planlægningen.

En forudsætning for realistiske estimater og planer er kendskab til det vi skal lave samt de vilkår vi skal arbejde under. I vilkårslaget laver vi risikoanalyse og interessent- analyse for at få uddybet opgavebeskrivelsen (kravspecifikationen).

I opgavelaget finder vi kravspecifikationen som handler om det det hele drejer sig om, genstanden for vores projekt, domænet med dets mennesker og/eller maskiner i den rigtige verden.

Grunden til at så mange projekter er blevet forsinkede i tidens løb, er ofte at man har taget for let på ét eller flere af trinene i modellen. Hvis man f.eks. begynder med en utilstrækkelig kravspecifikation, vil dette forplante sig opad således at også tidsestima- terne bliver for små. Og dermed vil planerne ikke afspejle virkeligheden. Så når man styrer efter disse (for korte) planer, vil man selvfølgelig blive forsinket i forhold til dem.

Når et projekt er forsinket, er det nemlig altid i forhold til en plan. Så i stedet for at tale om forsinkede projekter, burde man hellere tale om forkerte planer. Derfor er det vigtigt at de hele tiden holdes opdaterede.

Ovenstående proces kan gennemføres ad flere gange, som vi skal se i det senere af-

(10)

snit om iterative modeller. Den viste proces kan f.eks. benyttes til softwareudviklings- projekter. Der findes andre projektledelsesprocesser til andre typer af projekter.

Mestrer du alle de ovenstående lag, er der en god chance for at du vil undgå nogle af de værste katastrofer. For det er det bedste man kan opnå. Der kan ikke gives nogen kogebogsopskrift på hvordan man får succes hver gang. Men hvis du følger rådene og arbejdsmetoderne i denne bog, vil du aldrig komme helt galt af sted.

2.3.3 Trekanten

Traditionelt taler man om trekanten, bestående af tid, omkostninger og funktionalitet.

Ideen er at man ikke kan nøjes med at ændre én af dimensionerne – de hænger ulø- seligt sammen. En klassisk projektledervits siger: “Jeg kan lave systemer billigt, hurtigt og med megen funktionalitet. Vælg selv to!” Fordi projektlederens opgave bl.a. er at ha- ve styr på at den givne funktionalitet leveres til den givne tid med de givne omkostnin- ger, kaldes projektlederen af nogle ligefrem for trekantsbestyrer.

Bemærk at der med “tid” menes kalendertid – ikke persontid som er en del af omkost- ningerne.

Funktionalitetsdimensionen omfatter også kvaliteten af systemet. Hvis kvaliteten er lige meget, kan vi lave hvad som helst på ingen tid (også kendt som “den nulte soft- warelov”, se [Weinberg97]).

Som regel vægtes de tre dimensioner i trekanten forskelligt. I nogle projekter kan det være altafgørende at nå en bestemt deadline, så her er tiden vigtigst. Andre gange er det omkostningerne. Endelig kan funktionaliteten være det helt afgørende. Derud-

Fig. 2.3: Styringstrekanten

(11)

over skal man vide hvad det mindst vigtige er – her har vi nemlig vores reserve – det som vi eventuelt kan fire på. Så hvis tiden f.eks. er vigtigere end funktionaliteten, kan vi udskyde nogle af funktionerne for dermed at blive færdige til tiden.

Der kan dog ligge en fare i den mekanistiske betragtning omkring resurseforbrug (omkostninger) som trekanten lægger op til. Hvis man f.eks. bliver presset på tiden, for- søger man måske at vælge “the chinese army approach”: man sætter mange udviklere på projektet i håb om dermed at gøre det hurtigere. Ud fra en ide om at hvis 2 mand kan grave en grøft på 10 dage, så kan 20 mand grave den på 1 dag. Det holder imidler- tid ikke altid for it-projekter, bl.a. på grund af læreprocesserne som vi skal se på i et se- nere afsnit. Sammenligningen skal snarere være at to kaniner løber ikke dobbelt så hur- tigt som én kanin. Eller: hvis 1 kvinde kan føde 1 barn på 9 måneder, hvor mange kvinder skal der så til for at føde 1 barn på 1 måned?

Det er en central problemstilling i it-projekter at forholdet mellem trekantens sider (tid, funktionalitet og omkostninger) låses fast på et tidspunkt hvor grundlaget slet ikke er til stede. Adskillige projekter er kommet galt af sted fordi man har lavet en fastpris- kontrakt hvor både pris og afleveringsdato lå helt fast, men reelt kendte man ikke funk- tionaliteten. Det går galt. Hver gang. Vi skal senere vende tilbage til denne problemstil- ling og se på andre metoder til at løse den.

2.4 Udviklingsprocessen

I dette afsnit vil vi se på den proces som gennemgås når man udvikler software. En ud- viklingsmodel er en beskrivelse af udviklingsprocessens forløb, dvs. “Hvem gør hvad hvornår?” Vi opererer også med begrebet livscyklusmodeller som er tiden fra produktide- en fødes, og til sidste version er faset ud (hvor udviklingsmodellen kun omfatter tiden indtil afleveringen til kunden).

En hel livscyklus kan typisk se således ud:

– Forundersøgelse – Udvikling – Udrulning – Vedligeholdelse – Udfasning

Der kan indgå mange elementer i en udviklingsmodel. Mest typisk er at modellen be- skriver:

(12)

PROCES, hvilke aktiviteter gennemføres i hvilken rækkefølge.

ROLLER, hvem laver hvad?

METODERtil f.eks. analyse, krav, design, test.

VÆRKTØJER, f.eks. CASE, programmering, test.

TEKNISKE AKTIVITETER.

KVALITETSSTYRINGSAKTIVITETER, f.eks. hvornår laves test og inspektioner.

KONFIGURATIONS-, VERSIONS-ogDOKUMENTSTYRING.

MELLEMPRODUKTER(eng.: artifacts), hvilke skal laves hvornår, og hvad skal de inde- holde.

DOKUMENTER(som også er mellemprodukter), herunder specifikationer og planer.

Formålet med overhovedet at have en udviklingsmodel er først og fremmest at have en fælles referenceramme for udviklingsprocessen – “Sådan gør vi her”. Det giver dels en billigere uddannelse når der kommer nye projektdeltagere, dels sparer det mange dis- kussioner i kampens hede. Ikke, at vi skal undertrykke diskussionerne – vi tager dem bare på andre tidspunkter end midt under projektet. Og når vi alle sammen i hele virk- somheden gør tingene på samme måde, har vi bedre mulighed for procesrelateret er- faringsudveksling. Endelig giver det alt andet lige en lettere planlægning samt en mu- lighed for at måle på processen og dermed en større sandsynlighed for succes.

Overordnet set findes der to typer udviklingsmodeller: fasemodeller og iterative mo- deller.

2.4.1 Fasemodeller

En klassisk kopifitti om projektfaser lyder:

De seks projektfaser:

– Vild entusiasme – Desillusionering – Total forvirring – Jagt på de skyldige

– Afstraffelse af de uskyldige

– Forfremmelse af dem der ikke deltog

Mere seriøst inddeler vi i fasemodellerne udviklingen i et antal faser, typisk:

– Analyse

– Kravspecifikation

(13)

– Design – Kodning – Test – Udrulning

Disse modeller kaldes ofte for vandfaldsmodeller fordi man “falder” fra den ene fase til den næste. Dette er dog en sandhed med modifikationer, for de fleste fasemodeller rummer mulighed for “tilbageløb”. Hvis man således i kodningsfasen opdager et nyt krav, kan man gå tilbage til kravfasen og tage det med.

Struktureret ProgramUdvikling (SPU) er et eksempel på en fasemodel (med tilbage- løb) – se [Biering-Sørensen88].

Alt flyder

At udvikle systemer ud fra en specifikation er ligesom at gå på vandet: det hjælper hvis det er frosset! I øvrigt er det som regel en illusion at man kan fastfryse kravene. I de fle- ste situationer vil der være en person med tilpas mange stjerner (om ikke andet, den administrerende direktør) som kan overrule beslutningen og beordre et nyt krav med- taget – og så er vi lige vidt. Ved du i øvrigt hvad ligheden er mellem fastfrosne krav og den afskyelige snemand? Jo, begge er myter, og begge smelter når det bliver tilstrække- ligt varmt. Nogle siger ligefrem at kravspecifikationen er at opfatte som en kontrakt der skal genforhandles dagligt med alle interessenter. Det vender vi tilbage til i det senere afsnit om Kravstyring. Mekanismen har været kendt længe: den græske filosof Hera- klit, som levede omkring 500 f.Kr., sagde at “alt flyder” hvormed han mente at intet er uforanderligt, alting ændres hele tiden. Det gælder også systemkrav.

2.4.2 Iterative modeller

De iterative modeller går frem med små skridt. Først udvikler vi en lille bid af syste- met. Så leverer vi det til brugerne og ser hvordan det virker. Og så udvider vi det med lidt mere. Derfor kan du også høre ordene inkrementel, gradvis eller trinvis udvikling brugt om iterativ udvikling. Tidligere kaldte man de iterative modeller for RAD (Rapid Application Development).

I nogle udviklingsmodeller starter man (som i en vandfaldsmodel) med at gennem- analysere og designe hele systemet hvorefter man udvikler det i mindre bidder.

Man kan også starte med at udvikle en lille del af systemet og så lade systemdelen vokse sig gradvis større og større gennem en række iterationer. Det kaldes evolutionær ud- vikling. Her kan vi opfatte hver iteration som et gennemløb af faserne i en fasemodel:

(14)

først finder vi ud af hvad vi skal lave (analyse og krav)så finder vi ud af hvordan vi skal lave det (design)så laver vi det (kodning)

og så tester vi det.

Denne måde at arbejde på er ikke nogen ny ide. Allerede i 1950’erne udarbejdede den amerikanske kvalitetsekspert Dr. W. Edwards Deming sin såkaldte Deming-cycle: Plan- lægge-Udføre-Vurdere-Ændre (eng.: PDSA-cycle, Plan-Do-Study-Act. Nogle siger dog

“Check” i stedet for “Study”: PDCA.). Den illustrerer at man i en stadig vekslen mellem disse fire aktiviteter vedvarende forbedrer sine processer. Den blev i starten en stor suc- ces i japansk kvalitetsledelse hvor begrebet kaizen (løbende forbedringer, alting kan al- tid gøres lidt bedre) i dag er kendt verden over. Den er grundlaget for mange moderne forbedringsprocesser og altså også for iterative it-udviklingsprocesser.

De forskellige iterative modeller har hver deres bud på hvordan denne proces foregår.

Af fremherskende modeller kan nævnes:

– Rational Unified Process (RUP), se side 44.

– Microsoft Solution Framework (MSF), se side 45.

– eXtreme Programming (XP), se side 46.

– Objektorienteret Analyse og Design (OOA&D, også kaldet Aalborgmetoden. Se [Mathiassen01]).

– Dynamic System Development Model (DSDM, se [Stapleton97]).

– Structured Systems Analysis and Design Method (SSADM, se [Weaver02]).

– Scrum (se [Beedle01]).

Fig. 2.4: Deming-cyklen

(15)

Mange virksomheder har i tidens løb udviklet deres egne modeller (eventuelt med af- sæt i en af de etablerede).

Der er forskellige bud på hvad en iteration omfatter. I nogle iterative modeller fast- holder man f.eks. tiden: den næste iteration skal være færdig om (f.eks.) 6 måneder.

Med andre ord: vi når det vi når. Og når tiden er gået så er vi færdige. Det kaldes time boxing. Man kan også fastholde omkostningerne (resurserne). Det kaldes money boxing. Og endelig kan man fastholde funktionaliteten (function boxing) i en use ca- se-drevet proces: den næste iteration implementerer disse to use cases.

Ofte lader man den første iteration omfatte det helt basale system, dvs. f.eks. plat- formen, database-serveren, web-serveren osv. Man starter med andre ord med at “få hul igennem”. I RAD lægger man vægt på at få den første release søsat så hurtigt som muligt (deraf navnet). Derfor var det også i forbindelse med RAD man første gang introducerede begrebet time box.

En af grundene til at det som regel forholdsvis hurtigt lykkes at få lavet et brugbart system, er Paretos 80/20-regel som siger at den funktionalitet som af brugerne vil blive brugt i 80% af tiden, laves på 20% af udviklingstiden.

De iterative processer virker så godt fordi de har indbygget feedback. Vi får mulig- hed for at tage højde for det vi lærer undervejs i processen. Med vandfaldsmodellerne skal vi vide det hele på forhånd – hvad man meget sjældent gør. Og vi må vente til al- lersidst med at drage nytte af det vi lærer undervejs. Vi skal senere se på disse lærepro- cesser og på hvor nyttigt det er at kunne få feedback undervejs.

Adrætte metoder

Mange udviklingsmodeller indeholder detaljerede retningslinjer for præcis hvilke skridt man skal udføre. Sådanne præskriptive modeller har nærmest karakter af koge- bøger. Som modvægt mod disse overvægtige metoder har der i 1990’erne (samtidig med den fedtfrie slankebølge!) været en tendens hen mod modeller med mindre

“gør-dit-og-gør-dat” (f.eks. XP, DSDM og Scrum). De kaldtes tidligere letvægtsmetoder (eng.: lean), men i dag kaldes de adrætte metoder (eng.: agile). Det har givet anledning til det “adrætte manifest” (se www.agilealliance.org samt [Cockburn01]):

– Individer og samspil frem for processer og værktøjer.

– Kørende software frem for fuldstændig dokumentation.

– Samarbejde med kunden frem for kontraktforhandling.

– Reaktion på forandring frem for at følge en plan.

Det kan ses som en modreaktion mod de meget store og tunge metoder (lidt i stil med

(16)

dogmereglerne for filmproduktion: tilbage til rødderne). Ideen er at projektet skal foku- sere på de værdiskabende aktiviteter og så i øvrigt være tunet til at kunne reagere hur- tigt når tingene ændrer sig.

2.4.3 Rational Unified Process

Rational Unified ProcessÒ(forkortet RUPÒ) er en konkretisering af Unified Process (se [Jacobson99]). RUP har opnået stor udbredelse fordi den er både operationel og værk- tøjsunderstøttet, men andre virksomheder har også lavet deres bud på hvorledes Unifi- ed Process kan instantieres.

RUP er en use case-drevet, arkitekturcentreret, iterativ udviklingsmodel. Den rum- mer følgende hovedfaser:

BEGYNDELSE(eng.: inception) hvor ideen fødes, de vigtigste use cases beskrives og der laves overordnet arkitektur og plan.

UDDYBNING(eng.: elaboration) hvor de fleste use cases beskrives, arkitekturen udar- bejdes og resten af projektet estimeres og planlægges.

KONSTRUKTION(eng.: construction) hvor implementeringen foregår.

OVERGANG(eng.: transition) hvor der laves betatest, rettes fejl, trænes brugere og rul- les ud i organisationen. Dette er med andre ord produktmodningsfasen.

At modellen er iterativ, betyder at man i de enkelte hovedfaser gennemløber et antal iterationer. Hver iteration består af kravfastlæggelse, analyse, design, kodning og test.

De fleste iterationer foregår af gode grunde i konstruktionsfasen.

Gennem hele udviklingsforløbet udføres ni aktiviteter (eng.: work flows). Dels seks kerneaktiviteter:

FORRETNINGSMODELLERINGsom sørger for koblingen mellem de forretningsproces- ser som it-systemet indgår i, og selve it-systemet. Er det det rigtige vi udvikler?

KRAVsom beskæftiger sig med en grundig forståelse og beskrivelse af kravene til sy- stemet. Der laves vision, identificeres aktører og beskrives use cases. Hvad skal vi lave?

ANALYSEogDESIGNbeskæftiger sig med hvordan vi rent faktisk vil implementere sy- stemet. Det er her vi tænker på delsystemer, arkitektur og grænseflader.

IMPLEMENTERINGhvor vi udvikler koden og tester at enkeltkomponenter virker.

TESThvor vi tester at komponenter og delsystemer virker sammen, at hele systemet virker og at alle krav er implementeret korrekt.

UDRULNINGhvor vi i en række delleverancer indfører systemet i brugerorganisatio- nen og hjælper brugerne med at tage det i anvendelse.

(17)

Dels tre støtteaktiviteter:

PROJEKTLEDELSEsom handler om faktisk at få gennemført de nævnte aktiviteter på en afbalanceret måde.

KONFIGURATIONS- ogÆNDRINGSSTYRING som holder styr på alle de mange krav, mellemprodukter og releases undervejs.

UDVIKLINGSMILJØsom sørger for at dels udviklingsprocessen, dels de værktøjer som projektgruppen har behov for, er til stede og tunet til opgaven.

Men det er vigtigt at understrege at disse ni aktiviteter forløber gennem hele projektet.

Der bliver dog ikke lagt lige meget arbejde i dem i alle faserne. F.eks. lægges der flere kræfter i arbejdsgangen implementering i konstruktionsfasen.

Du kan læse mere om RUP i f.eks. [Kruchten00].

2.4.4 Microsoft Solution Framework

MSF er en ramme for systemudvikling, det er ikke en egentlig metode. Den er udviklet af Microsoft gennem mange år og indeholder essensen af hvad Microsoft mener er best practice. MSF består af en række modeller:

PROCESMODELLENsom beskriver hvordan udviklingsprocessen forløber.

ROLLEMODELLENsom beskriver de forskellige roller i projektgruppen. Den vender vi tilbage til i det senere afsnit om Organisation (side 164 ).

APPLIKATIONSMODELLENsom beskriver applikationens arkitektur.

RISIKOMODELLENsom beskriver hvordan projektet skal forholde sig til risici gennem hele forløbet.

Procesmodellen beskriver at projektet overordnet inddeles i fire faser:

VISIONSFASEN(eng.: Envisioning phase) hvor vi danner overblikket over projektets omgivelser og mål: Hvad går det ud på?

– Planlægningsfasen (eng.: Planning phase) hvor vi laver kravspecifikation og over- ordnet projektplan.

UDVIKLINGSFASEN(eng.: Developing phase) hvor produktet udvikles og testes. Ud- viklingen sker iterativt, evt. i parallelle forløb.

MODNINGSFASEN(eng.: Stabilizing phase eller Deployment phase) hvor produktet te- stes i den virkelige verden og gradvist tages i brug.

Bemærk at MSF, ligesom RUP, er en hybrid mellem en vandfaldsmodel og en iterativ model. Man har taget det bedste fra begge verdener.

(18)

MSF er i øvrigt en del af et endnu større koncept, nemlig ESF, Enterprise Services Framework. Det omfatter:

– Microsoft Readiness Framework (MRF) som er en foranalyse der skal afdække de forskellige løsningsmuligheder og deres egnethed i relation til de forretningsmæssi- ge mål.

– Microsoft Solution Framework (MSF).

– Microsoft Operations Framework (MOF) som omfatter drift og vedligehold.

Se i øvrigt mere om MSF på www.microsoft.com.

2.4.5 eXtrem Programmering

eXtrem Programmering (eng.: eXtreme Programming, XP) er et eksempel på en adræt metode. Her gives en kort oversigt over metoden.

Det centrale styringsredskab er de såkaldte user stories som er meget små funktiona- litetsbeskrivelser.

XP består af 12 selvstændige teknikker som tilsammen udgør XP:

PLANLÆGNINGSSPILLET(eng.: The Planning Game). Kunden og projektgruppen fast- lægger i fællesskab hvad den næste aflevering skal indeholde. Det er et tæt samspil mellem kundens forretningsmæssige prioritering og udviklernes estimater.

SMÅ DELLEVERANCERer nødvendige for hele tiden at have et kørende system.

METAFORENer et “billede” på systemet som alle kan referere til. Hvad handler syste- met om, fortalt på to linjer. Den fælles vision.

SIMPELT DESIGN betyder at vi under hele opbygningen holder designet på det simplest mulige. Vi tager altså ikke hensyn til at vi i næste uge skal lave en tilføjelse som kræver et mere kompliceret design. Så laver vi det mere kompliceret til den tid.

Men ikke nu. Dette er KISS-reglen: “Keep It Small and Simple” som vi senere vender tilbage til i andre sammenhænge.

TEST FØR KODNING. Hvis test er godt, så må vi teste hele tiden. Og her laver vi så te- sten før vi laver den kode der skal testes. Testen fejler (fordi koden den skal teste ikke er skrevet endnu), men når vi får skrevet koden, så virker testen. Alle disse tests auto- matiseres så vi hurtigt kan verificere at hele systemet virker indtil nu.

OMBRYDNING(eng.: Refactoring) betyder at vi hele tiden bliver klogere mht. hvordan designet af systemet skal være – og så tilpasser vi det løbende. Hvilket vi også er nødt til fordi designet skal holdes på det simplest mulige hele tiden. Vi er altså ikke bange for at lave noget om. Og det behøver vi heller ikke at være – for med den automatiske test har vi vished for at det virker, også efter ombrydningen.

(19)

PARPROGRAMMERING(eng.: Pair Programming) er nok den mest kendte af XP-tek- nikkerne. Det betyder helt bogstaveligt at to programmører sidder samtidig ved den samme skærm og hjælpes ad med at kode. Oftest skiftes de til at sidde med tasta- turet, og så koder og skriver den ene, mens den anden løbende tjekker at det er kor- rekt. Hvis review er godt, så lad os reviewe koden hele tiden.

FÆLLES EJERSKABbetyder at der ikke findes “dine moduler” og “mine moduler”. Det er “vores moduler” alle sammen, og hvis jeg har brug for at rette et sted i koden, så gør jeg det. Den automatiske test sikrer at der ikke sker ulykker. Egofri program- mering er i øvrigt et gammelt begreb som er omtalt allerede i 1971 (se [Weinberg98]).

FORTLØBENDE INTEGRATIONbetyder at vi integrerer hele systemet hele tiden. Så er vi sikre på at det vi har lavet, hele tiden virker.

37-TIMERS UGE. De fleste udviklere elsker denne regel. Baggrunden er den at når udvik- lere har været kreative en hel arbejdsdag, er de trætte. Og hvis de koder videre, laver de fejl. Det er billigere og bedre bare at lade dem gå hjem og hvile ud til næste dag.

KUNDEN TIL STEDEbetyder helt bogstaveligt at kunden skal være umiddelbart til- gængelig for udviklerne. Når vi ikke har en egentlig nedskreven detaljeret kravspeci- fikation, må vi kunne få afklaret alle tvivlsspørgsmål her og nu.

KODESTANDARDERer helt nødvendige når vi har fælles ejerskab til koden. Ellers bli- ver det noget rod.

Bemærk at alle disse teknikker skal være i anvendelse før man taler om eXtrem Pro- grammering. Hvis én eller flere mangler, virker metoden ikke optimalt.

I det senere afsnit om Organisation (side 167) ser vi på de roller som findes i eXtrem Programmering. Du kan i øvrigt læse mere om XP i [Beck00] og [Beck01].

I øvrigt findes der en konkretisering af Unified Process som til forveksling ligner eXtrem Programmering. Den kaldes dX (læs det på hovedet). Den kan bruges hvis man skal bruge Unified Process, men gerne vil bruge XP.

2.4.6 Foranalyse

Inden der er taget endelig stilling til om projektet overhovedet skal startes, laves som- metider et foranalyseprojekt. Det kaldes også et forprojekt, et feasibility study eller et

“præjekt”. Det svarer lidt til at vi starter med at lave jordbundsanalyser inden vi påbe- gynder et byggeprojekt.

Som resultat udarbejdes en foranalyserapport (en business case) som fastlægger om projektet rent forretningsmæssigt kan bære. Den skal danne beslutningsgrundlag for hvorvidt projektet overhovedet skal sættes i gang.

(20)

Rapporten indeholder f.eks.:

– Formålet med projektet. Hvorfor laver vi egentlig det her? Hvilket problem vil vi løse?

– Overordnet beskrivelse af hvad det er vi vil lave.

– Beskrivelse af teknologien (hvis relevant).

– Risikoanalyse.

– Beskrivelse af projektets finansiering.

– Anslået tid og pris.

– Cost/benefit-analyse, kan det betale sig?

Dette dokument kan senere udbygges til at blive projektgrundlaget.

En del af arbejdet med foranalysen går ud på at få opbygget en forståelse for den opgave der skal løses. I diskussionen med brugerne om et eventuelt nyt system kan f.eks. anvendes mock-ups, dvs. skærmbilleder på papir. Eller man kan lave egentlige prototyper for at demonstrere og afprøve systemets grænseflader.

Men at analysere for længe er også farligt (eng.: analysis paralysis). I en misforstået angst for ikke at gøre det godt og grundigt nok bliver vi ved med at analysere langt ef- ter at vi skulle være gået videre til næste fase. Det gælder både foranalysen og en eventuel senere analysefase.

Flere udviklingsmodeller omfatter en foranalyse (f.eks. DSDM og Microsoft Readi- ness Framework). Du kan læse mere om foranalyse i f.eks. [Bødker00].

2.4.7 Kravspecifikationen

Inden vi går i gang med selve udviklingen, skal vi have styr på hvad det er vi vil lave.

Denne aktivitet kaldes kravspecifikation, og det er en videnskab i sig selv. Da det samti- dig er en af de væsentligste forudsætninger for projektets succes, er der al mulig grund til at tage kravspecifikationen alvorligt.

Tidligere lavede man næsten altid kravspecifikationen (eng.: SRS, Software Require- ment Specification) som en opremsning af produktkrav, dvs. præcise beskrivelser af funktionerne i systemet. I dag har man flere strenge at spille på, og også i forståelsen af kravene til systemet anvender vi en multiperspektivisk tilgang:

FORRETNINGSANALYSEN udarbejder en forretningsmodel som giver overblik over domænet og indplacerer it-systemet i den rigtige sammenhæng.

DOMÆNEBESKRIVELSENer en beskrivelse af de kommende brugeres arbejde – det ar- bejde som det nye system skal understøtte. Dette kan også omfatte en arbejdsgangsa- nalyse.

(21)

FUNKTIONELLE KRAVbeskriver de enkeltkrav der kan opstilles til systemets funktio- nalitet. Ofte beskrives disse i form af Use Cases (brugsmønstre).

BRUGERGRÆNSEFLADEKRAVENEbeskriver kravene til systemet set fra brugerens side.

INFORMATIONSMODELLEN giver overblik over hvilke informationer systemet skal holde styr på.

YDELSESKRAVENE (eng.: performance) skal også beskrives. Det kan være krav til transaktionsmængder (eng.: throughput), antal samtidige brugere, spidsbelastning (eng.: peak), databasestørrelse osv.

SIKKERHEDSKRAVENEbeskriver hvilke krav der stilles til datasikkerhed, adgangskon- trol, recovery osv.

ORDLISTENindeholder en alfabetisk liste over alle domænets ord, termer og begreber, med tilhørende definition og beskrivelse. Selve arbejdsprocessen med at udarbejde ordlisten vil som regel altid ske i samarbejde med en domæneekspert. Det kan i øv- rigt også være en læreproces for domæneeksperten at lave ordlisten. Begreber man har gået og brugt i det daglige, er ikke altid helt så enkle når de skal forklares, formu- leres og nedskrives.

I erkendelse af at det kan være særdeles vanskeligt at give fastpristilbud på et stort sy- stem uden at kende kravene, ses det ofte at udviklingen af selve kravspecifikationen la- ves som et forprojekt (eventuelt til fast pris). Når kravspecifikationen så foreligger, kan der gives tilbud på udviklingen af det egentlige system.

Omvendt skal vi også være klar over at det sjældent er en god ide at forsøge at de- tailspecificere ned til den mindste detalje. Hvis vi ikke kender området, er det bedre at holde kravene overordnet så vi kan drage fordel af læreprocessen undervejs.

Proportionalitetsreglen

Ved udarbejdelse af kravspecifikationer gælder proportionalitetsreglen: Små systemer – lille kravspecifikationsindsats. Store systemer – stor indsats. Proportionalitetsreglen si- ger generelt at der skal være sammenhæng mellem tingene, og der skal være måde med galskaben. Vi skal hverken skyde gråspurve med kanoner eller skyde elefanter med ærtebøsser. I forbindelse med kravspecifikationen betyder det altså at vi ikke skal køre det helt store apparat i stilling for at lave en lillebitte opgave. Men at det på den anden side er i orden at bruge mange kræfter på at finde ud af hvad systemet går ud på hvis det er meget stort.

(22)

Videre studier

Du kan læse mere i [Lauesen00] som er en introduktion til området, eller i [Lauesen02]

som er den autoritative bog om kravspecifikation. Også [Wiegers99] og [Robertson99]

rummer god indsigt i området. Use Case-teknikken er beskrevet i [Schneider98]. [Bi- ering-Sørensen88] rummer også et kapitel om kravspecifikation. Bruger du RUP, kan [Leffingwell99] anbefales. Endelig rummer [IEEE830] et udmærket forslag til en ind- holdsfortegnelse for kravspecifikationer.

2.4.8 Valg af udviklingsmodel

Et af de klassiske problemer i it-projekter er at man glemmer at være bevidst om sin udviklingsmodel. Man behøver ikke nødvendigvis vælge en af de etablerede (selv om det er det letteste fordi de er så velbeskrevne). Man kan sagtens lave sin egen tilpassede (eng.: tailoring). Bare man har en.

Når projektet (eller virksomheden) står over for at skulle vælge en udviklingsmo- del, er der flere hensyn at tage:

– Hvor godt forstår vi (og kunden) anvendelsesområdet?

– Vil kravene ændre sig undervejs?

– Hvor godt kender vi udviklingsmiljøet?

– Hvor godt kender vi den organisation som skal modtage systemet?

– Hvor meget styr har vi på designet af denne type applikationer?

– Kræves der fast pris, tid og funktionalitet?

– Hvor mange personer skal deltage i udviklingen?

Er der tale om udvikling til fast pris og tid inden for et velkendt domæne, kan det være mest praktisk med en vandfaldsmodel. Er der derimod tale om ukendt land, vil en iterativ model med indbygget udnyttelse af læreprocesserne være at foretrække. Det kan godt være at det kræver nogen pædagogisk overtalelse af projektsponsoren, men tro mig: det er det værd.

Skift af model

Det tager ofte lang tid at få en udviklingsmodel ind under huden. Så man skal ikke skifte udviklingsmodel for tit – man når simpelthen ikke at lære dens styrker og svagheder til- strækkeligt godt at kende, og man går glip af læreprocessen med at anvende modellen.

Men behersker man flere modeller, og er der tale om et stort system inden for et ukendt område, kan man også vælge en adræt model i starten, for siden at gå over til f.eks. RUP.

(23)

Regler eller ej?

Når mange mennesker skal arbejde sammen, er et vist mål af regler nødvendigt. Hvis alle blot gør hvad der passer dem, ender det hele i anarki. Vi har behov for nogle færd- selsregler som sikrer at vi ikke modarbejder hinanden. Nogle regler er lette at få udvik- lerne til at forstå – og følge. F.eks. at vi skal benytte et fælles versionsstyringsværktøj så vi undgår problemer med at flere udviklere vil rette i de samme filer samtidig, og så vi altid kan genskabe tidligere releases. Andre regler kan det være sværere at håndhæve.

F.eks. regler omkring kodestandarder (“Jeg har altid lavet 4 indrykninger efter en if!”).

Se også det senere afsnit om Standarder (side 173) i kapitlet om Projektetablering.

Jo flere personer der er involveret i projektet, jo større er behovet for fælles regler.

2-4 udviklere kan sagtens koordinere ved at snakke sammen hele tiden. Når vi bliver ret mange flere, går der alt for lang tid med diskussion hvis vi ikke følger de samme retningslinjer.

Imidlertid er vi her oppe imod store kræfter. For det første menneskets iboende dovenskab. De fleste vil helst springe over hvor gærdet er lavest (eng.: Path of least resistance). Dette kaldes dovenskabsreglen eller reglen om den mindste modstand. Det ses f.eks. når der trædes stier den direkte vej hen over en græsplæne – selv om der er anlagt “officielle” flisegange.

For det andet er vi oppe imod menneskets særdeles kreative evner når det handler om at omgå love og regler. Jeg vil illustrere dette med en berømt fangeflugt:

For god ordens skyld: det er ikke Lorentzen der har fundet på dette ordsprog – det er ældgammelt og findes i flere kulturer.

Hvor der er en vilje

I 1949 brød fangen Carl August Lorentzen ud fra sin celle i Horsens Statsfængsel. Han havde fjernet bagklædningen i det lille skab i cellen og kunne derved bryde gennem muren til et lille trapperum. Ad den vej tilbragte han nætterne i det meste af et år med at grave en 20 meter lang tunnel ud under fængselsmuren. Den bortgravede jord gemte han på loftet. Efter flugten fandt man i det lille skab i cellen en seddel hvor han havde skrevet de senere så berømte ord:

“Hvor der er en vilje, er der også en vej!”

(24)

Så hvis du tror at du kan styre folk gennem regler som de ikke er enige i, så husk på

“hvor der er en vilje”-syndromet. I den virkelige verden finder den ofte anvendelse omkring omgåelse af skattelovene. I naturen finder den anvendelse når mælkebøtterne bryder frem gennem asfalten (derfor kaldes det også undertiden mælkebøttesyndro- met). Og ofte ledsages den af bemærkninger som “Så må vi jo finde på noget andet”,

“Det skal de i hvert fald ikke bestemme” og lignende.

Men bevidstløst regelrytteri er også galt. Det er tilladt at bruge indersiden af hove- det og træffe velovervejede beslutninger – også selv om reglerne siger noget andet (eng.:

Engage your brain).

2.4.9 Softwarehåndbogen

Udviklingsmodellen beskrives typisk i en softwarehåndbog (også kaldet en projekt- håndbog). Den skal helst være tilgængelig online på virksomhedens intranet. Soft- warehåndbøger på papir er for vanskelige at holde opdateret, og så forældes de lyn- hurtigt.

Men selv en nok så god softwarehåndbog er intet værd hvis udviklerne ikke kender dens indhold. Så den skal under alle omstændigheder suppleres med undervisning i dens brug når der kommer nye udviklere. Og de gamle kan formentlig også trænge til at få den frisket op en gang imellem.

2.5 Læreprocesserne

Forestil dig at du hver den 1. i måneden bliver bedt om at være projektleder på udvik- lingen af et givet system. Og det er nøjagtigt det samme system du skal udvikle måned efter måned. Det er naturligvis en tænkt situation, men mit gæt er at du vil blive i stand til at udvikle systemet på stadig kortere tid – indtil en vis grænse. Denne grænse kan vi kalde idealtiden, dvs. den tid det tager at udvikle systemet hvis alting bare flasker sig, og hvis vi ved det hele. Tiden som du de første gange bruger ud over idealtiden, kan vi kalde overtiden. Altså den tid du bruger “for meget”. Lad os kigge på hvad overtiden egentlig bruges til. Den bruges nemlig til en række læreprocesser. Vi skal blive klogere mht. PIP:

– Produktet, dvs. f.eks. anvendelsesområdet og den konkrete applikations design.

– Interessenterne, dvs. f.eks. kundens forhold og samarbejdet i projektgruppen.

– Processen, dvs. f.eks. udviklingsmiljøet.

(25)

Produktet

Læreprocesserne omkring anvendelsesområdet (domænet) handler om at vi skal tileg- ne os viden om den verden systemet skal virke indenfor. Er det f.eks. et system til pati- entadministration, skal vi vide noget om hvordan et hospital fungerer. Er det et system til styring af et kraftværk, skal vi vide noget om hvordan et kraftværk fungerer. Derfor kan det sommetider være en god ide at tilbringe nogle dage i det miljø hvor systemet skal bruges ([Bødker00]).

Vi skal opbygge den konkrete applikations design. Vi skal lave en arkitektur som egner sig til denne applikation. Vi skal finde ud af hvilke komponenter systemet skal bestå af. Og hvordan de snakker sammen. Vi skal måske opbygge (eller genbruge) hele application frameworks, dvs. standardarkitekturer for denne type systemer.

Interessenterne

Projekter er bl.a. kendetegnet ved at det er forskellige personer der deltager fra gang til gang. Kunden er sjældent den samme. Brugerne er forskellige. Og projektgruppen sammensættes ofte på ny hver gang. Derfor skal vi lære os hvordan projektets interes- senter denne gang er skruet sammen. Hvilke behov de har. Hvordan de kan takles bedst muligt. Hvordan vi sikrer at så mange af deres interesser som muligt opfyldes. Vel vi- dende at de kan være modstridende.

Processen

Læreprocesserne omkring udviklingsmiljøet handler om at vi skal sætte os ind i udvik- lingsværktøj, compiler, standardkomponenter, biblioteker, udviklingsplatform, konfi- gurationsstyringsværktøjer osv.

Læreprocesser tager tid

Det er ofte læreprocesserne som er skyld i at it-udvikling underestimeres. Vi glemmer simpelthen at tage højde for alle de ting som vi ikke ved, og som vi skal sætte os ind i (lære) hen ad vejen. I andre brancher kaldes fænomenet “begyndervanskeligheder” el- ler “børnesygdomme” – begreber som dækker over at vi udmærket godt ved at ting kan gå galt når vi starter på noget nyt. Vi snakker om at “al begyndelse er svær”.

I øvrigt siger man lidt i spøg at det først er det tredje system (af samme slags) man udvikler som rammer rigtigt, både hvad angår funktionalitet og resurseforbrug. På det tidspunkt har man nemlig gennemført så mange af læreprocesserne at overtiden og

“skæverterne” er kommet ned på et acceptabelt niveau. Det minder lidt om følgende historie om at tegne en hane:

(26)

Nu behøver du ikke tage denne historie som udtryk for at du bare kan forsinke projektet til det tredobbelte fordi det så bliver sublimt.

De iterative processer har deres styrke ved at læreprocesserne indbygges i selve ud- viklingsforløbet. Ved hver iteration bliver vi lidt klogere mht. de tre læreprocesser. Ved de første iterationer gætter vi sædvanligvis meget galt. Men fordi vi bliver klogere og klogere hen gennem udviklingsforløbet, rammer vi mere og mere præcist. Nøgleordet er feedback. Fordi vi bliver i stand til at udnytte vores forøgede viden i løbet af selve projektet, kan vi løbende tilpasse såvel produkt som proces.

Den amerikanskfødte (og norsk bosatte) it-guru Tom Gilb har sagt det meget ram- mende: “Hvis du ikke ved hvad du har med at gøre, så lad være med at gøre det i stor skala.” Eller som det mere poetisk er udtrykt af Piet Hein i dette Gruk:

Du skal bruge en del af dit snilde til at trylle din opgave lille.

Når du først har lagt seletøj på den - lad den gro sig så stor, du kan få den!

Eller med et gammelt ordsprog: Man skal kravle før man kan gå. Start i det små indtil du har styr på hvad du har med at gøre, dvs. indtil du har været igennem læreproces- serne. Så kan du altid sætte turbo på bagefter.

2.5.1 Nyt eller gennemprøvet?

“Vi skal tjene penge og have det sjovt. Men vi skal ikke tjene så mange penge at vi ikke

At tegne en hane

Det fortælles om Kejseren af Kina at han bestilte en tuschtegning af en hane hos en dygtig tegner. Tegneren sagde at den kunne være klar om fire år. Fire år senere var den dog endnu ikke klar, men tegneren lovede at om fire år mere ville den være færdig. Fire år senere gentog historien sig. Da Kejseren efter nu tolv års forløb troppede op med hele sit følge hos teg- neren, sagde denne atnuvar den klar. Han tog et nyt stykke papir, og med sin pensel tegnede han i én eneste hurtig bevægelse en helt ufatteligt livagtig hane. Da Kejseren spurgte hvorfor han skulle bruge tolv år, tog tegneren ham med ind i rummet ved siden af hvor der lå stabler af tegninger fra gulv til loft – af haner!

Frit efter [Bastian88]

(27)

har det sjovt. Og vi skal ikke have det så sjovt at vi ikke tjener penge”. Sådan lyder en klassiker fra ledelseslitteraturen. Og den kan overføres til it-udvikling. Nogle gange har vi det så sjovt at vi får udviklet for lidt og forkert. Vi har så meget fokus på hele tiden at anvende den ultimative og nyeste teknologi at vi glemmer det vigtigste: at vi skal lave gode systemer til kunderne. Her bør vi satse mere på det gode håndværk, frem for at forfølge de nyeste (og sjoveste) værktøjer og ideer for enhver pris. Det er nemlig ikke altid brugerne opdager at deres system er lavet med en meget fancy, ny indmad – og som regel er de også ligeglade.

Man kunne stille spørgsmålet: For hvis skyld er det så vi uophørligt jagter det nye- ste? Er det i virkeligheden for udviklernes egen skyld? For at de kan have det sjovt? Og vise at de er med på noderne? Og at det er sjovt at arbejde her hos os, så vi kan tiltræk- ke og fastholde de dygtigste udviklere? Dette kaldes også Mount Everest-syndromet: vi bruger den nyeste teknologi bare for at bevise at vi kan. Og nogle kalder ny teknologi for “udviklernes opium”: de skal have noget nyt at lege med en gang imellem. Selvføl- gelig skal vi hele tiden holde nyhederne under observation, men måske ville vi en gang imellem stå os bedre ved lige at vente lidt og få andre til at indhøste erfaringer med nye værktøjer, mens vi koncentrerer os om at få løst opgaven til kundens tilfredshed.

Og så er der lige det med læreprocessen: når vi endelig er blevet gode til en bestemt teknologi eller et bestemt værktøj, kan vi jo lige så godt have glæde af det – i stedet for straks at ile videre til det næste og dermed starte forfra på læreprocessen.

Men man skal heller ikke vente alt for længe med at tage nye teknologier i brug.

Det kaldes Thomas Lawson-syndromet hvis man krampagtigt forsøger at holde fast i en kendt teknologi længe efter at man burde være skiftet til en ny:

Eller med den amerikanske psykolog Abraham Maslows ord: “hvis du er god til at bru-

T h o m a s L a w s o n

I slutningen af 1800-tallet, da dampskibene begyndte at fortrænge sejlskibene, forsøgte nogen at bygge større og større sejlskibe ud fra ideen om at det var en kendt teknologi, og de var prisbillige at sejle med. F.eks. byggede man både fem- og seks-mastede skonnerter. Og i 1902 byggede man verdens enestesyv-mastede skonnert, Thomas Lawson. For at håndtere sejlene havde den installeret en lille dampmaskine! Skibet var i øvrigt ikke særligt manøvredygtigt, og det sank i 1907.

(28)

ge en hammer, så ligner alle problemer søm”. Nogle har en tendens til udelukkende at løse problemer med de teknologier de nu en gang behersker (“Det vi har brug for her, er en større hammer”, [Senge99]). Det er også galt. Vi skal beherske så tilpas mange tek- nologier at vi er i stand til at vælge den bedst egnede til opgaven. Det er kompliceret, det her. Sammenlign i øvrigt med det multiperspektiviske syn – nogle har en tendens til at anskue verden ud fra et enkelt perspektiv. Så kender du kun til at bruge en ham- mer, bruger du “hammerperspektivet”.

2.5.2 Sølvkugler

I den mørke middelalders Transsylvanien – dengang ulvene tudede, bjørnene brølede og vampyrerne føg om ørerne på folk – mente folkeovertroen at man endegyldigt kun- ne dræbe en varulv ved at skyde den med en sølvkugle. Disse sølvkugler (eng.: silver bullet) er siden blevet synonyme med en enkeltstående, hurtig løsning på et slemt pro- blem (se [Brooks87]). Inden for it-verdenen har vi i tidens løb hørt om mange sådanne

“frelserteknologier”, f.eks.:

– CASE-værktøjer – Objektorientering (OO) – Genbrug og komponenter – Design Patterns

– Use Case-teknikken – Java

– XML

– eXtrem Programmering

Hver for sig udmærkede teknologier. Men fælles for dem er at ved deres fremkomst blev de udråbt som revolutionerende og med et potentiale til at løse (næsten) alle pro- blemer. Hvilket selvfølgelig er noget sludder. Så lad være med at tro at alle dine proble- mer med it-udvikling kan løses af én enkelt teknologi. Der er specielt grund til at tænke sig om ved anskaffelse af værktøjer. Det er før set at værktøjer er blevet oversolgt så nogle har fået det indtryk at de kunne løse flere problemer end tilfældet faktisk var.

Hvis man konsekvent halser efter de nyeste teknologier, kaldes det i spøg for Manage- ment by Buzzwords.

Som tidligere nævnt findes der heller ikke simple løsninger inden for projektledel- se. Hvis nogen prøver at bilde dig det ind, så lad være med at tro på dem. Det er og bli- ver kompliceret, det her.

(29)

2.5.3 Videndeling

Videndeling er vigtigt at beskæftige sig med som projektleder, og det vil vi kigge lidt på i dette afsnit.

Kan viden overhovedet deles?

I filmen The Matrix oplevede vi hvordan ny viden blev downloadet direkte ind i hjer- nen. Der går nok lige et par år før udviklerne kan dele deres viden på denne meget it-agtige måde. Spørgsmålet er om man i det hele taget kan dele sin viden med andre.

Viden er snarere noget som hver enkelt selv skal tilegne sig, og derfor er det også vig- tigt at man giver udviklerne muligheden for at tilegne sig hinandens viden. Det skal altså være politisk acceptabelt i virksomheden at man tilegner sig hinandens viden.

F.eks. gennem mesterlære (som i XP), gennem interne foredrag, gennem sparring og spørgen til råds, gennem review af hinandens kode osv.

Genbrug er besværligt

Dybe tallerkener er uhyre nyttige – ellers blev de vel heller ikke opfundet så tit. Der kan ligefrem gå sport i det. For mange it-udviklere er det i hvert fald en yndet beskæftigelse at genopfinde allerede kendte løsninger, og det er egentlig en skam, for det er både dyrt og forsinkende.

I ganske mange år har ordet genbrug været et magisk ord (en sølvkugle) blandt le- dere i it-branchen. Man så for sig hvordan udviklerne kunne spare enorme mængder af tid ved “blot” at genbruge tidligere udviklet kode i nye sammenhænge. Men efterhån- den har man indset at udviklernes iboende trang til tallerkenopfinding har stukket en effektiv kæp i hjulet for de altomfattende genbrugsbiblioteker. Dygtige udviklere ud- vikler hver for sig deres egne genbrugsbiblioteker hvorfra de klippe-klistrer kodestum- per og moduler. Men udviklerne imellem er det meget sværere. Dels skal man over psykologiske barrierer (NIH: Not Invented Here - det er ikke mig der har fundet på det). Dels skal man over økonomiske barrierer (det koster en del tid at gøre kode gen- brugelig). Og endelig skal man over tekniske barrierer (det er ikke helt let at organisere et genbrugsbibliotek så tingene faktisk er lette at genfinde). Derfor har kun ganske få virksomheder succes med genbrug ud over få standardmoduler.

NIH-syndromets modsætning er at man sætter en ære i at genbruge så meget som muligt: “Steal with pride, share with delight”.

Mønstre er viden

Midt i 1990’erne blev mønstrene (design patterns) heldigvis opfundet. Det er en metode

(30)

til at beskrive gode løsninger på bestemte problemer: – Når du står med dette problem, så er løsningen sådan-og-sådan. Og man satte oven i købet navn på. Nu kunne man høre udviklere snakke om et singleton-pattern, et observer-pattern osv. Hver udvikler behøvede nu ikke længere genopfinde de samme løsninger på de problemer som man tidligere havde opfundet udmærkede løsninger på. Det var et godt skridt i den rigtige retning. At det så er for få udviklere der sætter sig ind i de tilgængelige mønstre – ja, det er en helt anden sag. Hvis du vil gøre noget ved dette problem, kan du f.eks. lave en studiekreds hvor I hver gang diskuterer et bestemt emne som en af udviklerne så skal komme med oplæg til. Det er en god måde at holde hinandens viden ved lige på. I øvrigt taler man også om anti patterns som er mønstre for at gøre noget på den forkerte måde. Disse er f.eks. beskrevet i [Brown98] og [Brown00].

Lægerne bruger teknikken

Inden for andre erhverv er det velkendt at man deler sin viden til gavn for hinanden – og kunderne. F.eks. ser læger hinanden over skuldrene når de opererer. Noget der har sparet mange menneskeliv. Det er et eksempel på brug af den gamle mesterlære. Man betragter “Mesteren i arbejde” og lærer derved hvordan man selv skal gøre. Det er en effektiv teknik når man ikke er i stand til at sætte ord på sin viden. Sådan ordløs viden kaldes i øvrigt tavs viden eller implicit viden (i modsætning til den viden man kan skri- ve ned – den kaldes eksplicit viden).

It-udviklere i mesterlære

Den mest omtalte af de teknikker der tilsammen udgør eXtrem Programmering, er par-programmering: kode udvikles af to udviklere samtidig ved den samme skærm.

Og det er i realiteten en fantastisk måde at lære af hinanden på. God programmerings- skik er nemlig en vanskelig evne at sætte ord på. De fleste dygtige udviklere kan kende god programmering når de ser den. Men at beskrive det.... Derfor foregår der ekstremt meget videndeling når udviklerne benytter XP. Det forudsætter dog at det faktisk er god programmeringsskik der videreføres – og ikke unoder. Derfor er en vis rokering en god ide, så man lærer fra forskellige og ikke udelukkende fra den samme. Se i øvrigt [McConnell93] omkring god programmeringsskik.

Procesviden kan også deles

Vidensteoretikerne har en model som fortæller hvordan viden skabes i en stadig vek- slen mellem tavs og eksplicit viden. Man nedskriver, man læser og sammensætter fra flere kilder, man ser hinanden gøre tingene, man begynder selv at gøre dem:

(31)

SOCIALISERING(eng.: Socialization). Tavs-tavs. Her videregives den tavse viden fra én person til en anden, uden at sætte ord på. Det er typisk for bl.a. mesterlæren hvor lærlingen ser hvordan mester gør. Jf. parprogrammering i XP.

EKSTERNALISERING(eng.: Externalization). Tavs-eksplicit. Her sætter vi ord og begre- ber på den tavse viden, dvs. vi gør den eksplicit. Det sker f.eks. når man laver en soft- warehåndbog hvor man nedskriver de arbejdsgange vi hidtil blot har udført uden at tænke nærmere over det.

KOMBINERING(eng.: Combination). Eksplicit-eksplicit. Her opstår nye måder at gøre tingene på ved at sammenstille andre. Det sker f.eks. når man i to projekter har gjort tingene på hver sin måde og så mødes og finder på noget helt tredje som tager det bedste fra de to andre. Det er f.eks. det vi gør under projektevalueringen.

INTERNALISERING(eng.: Internalization). Eksplicit-tavs. Her bruger udviklerne den beskrevne, eksplicitte viden i praksis, og derved får de den ind under huden så den til sidst bliver en del af deres tavse viden – sådan gør vi altså her i huset.

Modellen stammer fra [Nonaka95] og kaldes SECI-modellen (efter forbogstaverne i de engelske betegnelser). Læring er den proces at viden bliver til erkendelse som bliver til kunnen.

Hvis udviklingsafdelingen begynder at få fokus på selve udviklingsprocessen, vil det at deltage i udviklingsprojekterne øge udviklernes viden om hvordan man laver god udvikling. Men det forudsætter altså lige en lille detalje: der skal være fokus på processen. Den skal diskuteres, den skal nedskrives, den skal bruges, den skal ændres.

Det er i øvrigt sådan man skaber de gode vaner som en projektkultur består af. En må- de at dele procesviden på er gennem projektevalueringer. Når projektet er slut, evalu- erer projektgruppen hvordan det gik (se kapitlet om Projektevaluering på side 361). Og de positive og negative erfaringer formidles så til de udviklere som ikke selv var med i projektet. Det er nu heller ikke uden problemer. Bedst er det hvis man kan sætte navn på de “mønstre” man oplevede i projektet. Så kan udviklerne nemlig huske dem når de næste gang står i en lignende situation.

It som formidler af viden

Mange har forsøgt at understøtte videndelingsprocessen med it-systemer (SECI-model- lens eksternalisering). Det kaldes også Knowledge Management. Men ifølge sagens natur må den viden der gemmes i et it-system være eksplicit. Tavs viden kan selvsagt ikke repræsenteres i et it-system. Den eksplicitte viden kan derimod godt – og bliver det.

F.eks. viden om hvem der ved hvad. Dette benyttes i større organisationer hvor man ad

(32)

denne vej kan finde frem til kolleger som besidder viden inden for et bestemt felt. Men lige så snart man forsøger at overføre den konkrete viden med et it-system som mel- lemled, opstår problemerne. Det er hundesvært at lave en ordentlig beskrivelse og end- nu sværere at få den formidlet ind i hovedet på modtagerne så de faktisk bruger den.

Brug hinanden

It-udviklerne skal udnytte hinandens viden i langt højere grad end tilfældet er mange steder. Og i udviklingsafdelingerne skal man begynde at udbygge de processer der understøtter videndeling. Måske ligefrem stille krav om at man forsøger at bruge hinan- den. Der er store resurser gemt her. Både økonomisk og kvalitetsmæssigt. For slet ikke at tale om den menneskelige dimension: det er sjovt at tilegne sig ny viden. Og kan man oven i købet få den fra en god kollega, så er det med til at udbygge sammenholdet blandt udviklerne. Det optimale er at udviklerne i fællesskab kan skabe ny viden. F.eks. review af hinandens produkter, evaluering af projekterne og diskussion af gode løsninger.

To-timers-reglen

I en dansk elektronikvirksomhed har man indført en totimersregel som betyder at hvis en udvikler har forsøgt at løse et problem, men ikke har løst det inden for to timer, har vedkommende pligt til at få hjælp af en kollega. Flere par øjne ser ofte bedre end et par, og man mener her at det simpelthen er spild af virksomhedens tid hvis en medarbejder sidder alene og kæmper med et problem uden at komme videre. Især hvis en kollega kunne have givet en hjælpende hånd.

Her hjælper det i øvrigt meget hvis man har et godt og velplejet netværk. Folk er mere villige til at hjælpe hvis de på forhånd kender den som kommer og spørger efter hjælp.

Læs mere om videndeling på arbejdspladsen i [Bjerrum03].

2.6 Modenhed

Modenhed handler ikke kun om at være voksen og følsom. Det er i denne forbindelse en betegnelse der beskriver en virksomheds evne til at udvikle it-systemer – en evne der i øvrigt også omfatter de mere bløde kompetencer. I det følgende vil vi beskrive nogle af de modeller der ofte bruges i denne sammenhæng. Men bemærk at det er virk- somhedens modenhedsniveau der beskrives – ikke det udviklede system.

Referencer

RELATEREDE DOKUMENTER

I lighed med præciseringen og konsolideringen af de øvrige MedCom meddelelser gennemføres et tilsvarende arbejde med dokumentation af anvendelsen af MEDREQ til rekvirering af klinisk

Vi vil afslutningsvis perspektivere de overordnede konklusioner, som utvivlsomt på den ene side peger på, at en overvejende del af de unge, der starter i brobygning, lever op til

Roserne trækkes op med rødder med en sløv saks monteret på en minigrave- maskine... eller ikke særlig effektive. Små bevoksninger kan nedskæ- res. Man skal starte lige efter

(('oral management':ti,ab,kw OR 'dental hygiene':ti,ab,kw OR 'oral care':ti,ab,kw OR 'mouth rinse':ti,ab,kw OR 'tooth cleaning':ti,ab,kw OR 'teeth cleaning':ti,ab,kw OR

Held Dig da, naar i din Hvilestund Med gode Venner et Glas Du kunde tomme;!. Thi da hæved’ sig fra Glassets Bund Den muntre Gud, og Mismod

”Fra blandt andet Norge ved vi, at de unge kriminelle bestemt ikke oplever møderne med deres ofre som rund- bordssamtaler.. De unge, der har prø- vet begge dele siger, at samtalerne

Efter en årrække ændredes anbefalingerne til tidlig afnavling som led i blødningsprofylaksen og efterfølgende blev der i 2010 endnu engang ændret i afnavlingspraksis

Det sidste jeg husker fra besættelsen var fra festsalen sent om aftenen, Ralf Pittelkow (dekoreret med et enormt halstørklæde) som dødtræt sagde at hvis ikke man havde klare krav