anders lisdorf bloghoved

Estimere? mig?

Sammenlignet med mange andre ting i verden, er det ikke svært at estimere software. Det handler blot om at bruge de rigtige teknikker og tilgange og på det punkt er IT industrien et u-land.

Udviklere har en indgroet mistillid til at estimere noget som helst. Jeg kan erindre mange samtaler, hvor jeg har spurgt om, hvor lang tid det ville tage at lave f.eks. en integration, og fået et blik tilbage, som om jeg spurgte efter forklaringen på mørkt stof eller beviset for Bose - Einstein kondensatet. Der er udviklet farverige metoder, såsom poker estimater eller T-shirt størrelser for at slippe for at sige, hvor lang tid noget tager. Eller man snakker om guestimate istedet for estimate, fordi man vil understrege usikkerheden (men ordet er blot en pleonasme for både guess og estimate betyder jo det samme). Der findes kort sagt en besynderlig modvilje mod at estimere.

For nyligt læste jeg en tråd på Quora om hvorfor det er så svært at estimere software udvikling. Her var der et svar som rummede et rigtigt godt billede på problematikken omkring estimering. Lad mig kort genfortælle den.

Estimering og lignelsen om vandreturen fra San Francisco til Los Angeles

Forfatteren beskriver i bedste bibelske stil en lignelse, som skal anskueliggøre problemerne med estimering. Det drejer sig ikke om en ørkenvandring, men dog en vandring. Forestil dig vi skal på en vandrertur fra San Francisco til Los Angeles for at besøge vores venner. Vi tager et kort frem og måler, hvor langt der er langs kysten for det er jo meget hyggeligere at gå her, end langs de tisporede motorveje. Vi får afstanden til 600 kilometer. Vi kan gå 6 kilometer i timen og 10 timer om dagen, så det burde tage ti dage.

Vi står tidligt op og starter vores tur, men pludselig opdager vi på kortet, at der er hundredevis af små krøller på ruten fordi kysten har fremspring og små bugte. Det betyder, at der ikke er nogen lige vej langs kysten, og derfor er afstanden meget længere.

Da vi kommer frem til kysten og skal starte vores tur opdager vi, at der også er store niveau forskelle og sand, som er svært at gå igennem. Det betyder at vi kun kan gå med 3 kilometer i timen. Altså halvdelen af den fart vi troede. Vi vil istedet gå 12 timer om dagen og ringe til vores venner og sige, at vi bliver lidt forsinkede.

Vi slår lejr, men sover over os næste morgen. Vi har sovet forfærdeligt så vi bliver nød til at gå efter 10 timer og så tage 14 i morgen. Pludselig kommer en tåge ind og vores ven får vabler. Den ene af os bliver nød til at gå 5 kilometer ind til nærmeste by for at købe plaster. Så har vi spildt endnu en halv dag.

Næste dag kommer vi op til tiden, men finder ud af at stien pludselig ender ud i det blå. Et jordskred har undermineret stien. Det kunne vi ikke se på kortet. Og så bliver min ven syg og vi må holde pause en dag….

Det går op for os at vi kun er nået 60 kilometer på 4 dage. Det betyder en gennemsnitshastighed på 15 kilometer om dagen istedet for de 60 vi troede. Det kommer altså til at tage 4 gange så lang tid som vi estimerede til at starte med.

Og fortolkningen af lignelsen viser…

159 mennesker på Quora syntes, at dette var et fantastisk svar, som virkelig beskriver virkeligheden for udviklere. Kommentarerne viser, at det virkelig har ramt en nerve. Det viser hvorfor det er umuligt for udviklere eller nogen andre at estimere, hvor lang tid noget tager.

Men er det nu det som lignelsen viser? Nu er jeg en af dem der sad med åben mund og polypper gennem hele B.S. Christiansens selvbiografi og jeg spørger altid mig selv, hver gang jeg bliver præsenteret for noget svært: “hvad ville B.S. have gjort?”.

  • 1) han havde nok ikke glemt plaster og basal nødhjælps kit
  • 2) han havde nok ikke lavet så overfladisk en planlægning at han ikke havde sat sig grundigt ind i terrænnet inden han gik i gang
  • 3) han havde nok spurgt nogen som vidste noget om vandreture i kystnært terræn, hvad man kunne forvente og lagt ind i planen, at der kunne opstå situationer, hvor der var tåge, stier som var underminerede og lignende
  • 4) han var nok ikke blevet overrasket over at nogen blev syg eller såret på turen
  • alt dette havde han nok taget med ind i planlægningen
  • 5) hvis han skulle nå frem til et sted bag fjendens linier til et bestemt tidspunkt, havde han nok ikke holdt pause eller sovet for længe.

Så jeg vil nok vende den om og sige, at hvis man virkelig synes, at det er et godt billede på, hvordan der estimeres, så viser den snarere hvor amatøragtigt og dilletantisk, man angriber den opgave ude i udviklingsafdelingerne i dag.

Lidt kontekst

Man kan også prøve at sætte IT udvikling ind i en kontekst: der er i sidste ende nogen, som betaler, og de vil nok gerne vide lidt om, hvad de betaler for. De betaler ikke med storypoints eller T-shirts, men i kroner som udregnes på baggrund af…ja, antal timer. Derfor er det vel helt i orden at blive afkrævet et bud på, hvor meget man tror det vil koste? Det er vel fair nok? Hvis du skulle engagere en håndværker til at bygge noget ville du så acceptere, at han sagde at det var umuligt at give et estimat? Ville du acceptere et tilbud udregnet i T-shirt størrelser eller smølfedollars?

Man kunne argumentere for at estimering er noget mere kompliceret, og at det derfor ikke er muligt. Men det argument holder heller ikke. IT udviklere har det ikke hårdt i forhold til kompleksitet og evne til at forudsige når man sammenligner med andre professioner. Hvis du f.eks. er aktieanalytiker eller børsmægler, så er du i en helt anden liga af kompleksitet end et e-commerce website eller en foto delings tjeneste. Argumentet svarer til at man i investeringsverdenen påstod, at det var værdiløst at prøve at lave kursmål og at bruge dem til noget fordi de alligevel aldrig holder. Selvfølgelig kan man give et bud, og det er ikke nogen skandale, hvis man ikke rammer.

Det ledelsesmæssige svigt
Det er her det grundlæggende problem viser sig. For problemet er ikke uvillige og kontrære udviklere, men et fundamentalt ledelsesmæssigt svigt i de fleste organisationer. Langt de fleste ledere opfatter estimering som en lageroptælling eller, endnu værre, et forhandlingsudspil, hvor man kan prøve at presse tiden ned. De har meget ringe forståelse for den kompleksitet og usikkerhed, der er involveret. Alt for sjældent bliver udviklere og projektlederes forbehold taget seriøst. Det optimistiske scenaries dead line bliver opfattet som en leveringsdato fra GLS. Man kritiserer udviklingsteamet, når de ikke når denne deadline, og antyder, at det er fordi, de er enten uduelige eller dovne. Dette har jeg aldrig set som primær årsag til forsinkelser. Tvært i mod er der få medarbejdergrupper der er villige til at give den så meget ekstra kul som udviklere.

Derimod er scope creep, upræcist formulerede krav, manglende prioritering fra opdragsgiveren blandt de helt centrale årsager. Men alle disse usikkerheder kan faktisk sagtens regnes med. Som sagt så kan andre og væsentligt sværere problemer sagtens estimeres med pæn præcision. Det handler bare om at finde metoderne.

Fem tip til estimering

Der findes nemlig nogle få tricks til at optimere estimeringen, så man kan få et relativt præcist billede af hvor lang tid noget tager. Jeg har selv været med til projekter i størrelsesorden 50 mandeår som ramte indenfor 10% af estimatet, så det er bestemt ikke muligt.

Man kan nemlig bruge samarbejde og Wisdom of Crowds tænkning til at booste præcisisonen af estimater. Det er ikke uden grund at bookmakere er de mest præcise indikatorer på vinderen af det amerikanske præsidentvalg. Det følgende er nogle få tips, man kan gøre brug af for allerede at starte optimeringen af estimering i dag.

Man skal:
* 1) fra ledelsens side helt fundamentalt anerkende specialisternes kompetence. Estimater må ALDRIG forhandles. Man forhandler jo heller ikke med vejrmanden. Man må gerne spørge ind i en åben dialog for at finde ud af hvor kompleksiteten ligger hvis noget, som opdragsgiveren troede var let, ser svært ud. Det kunne jo være man havde misforstået hinanden eller en ligegyldig detalje skabte en stor unødvendig kompleksitet.
* 2) gøre sig klart, hvad det er man estimerer. Hvis du spørger en udvikler hvor lang tid det tager at kode en funktion, så vil han typisk svare tilbage i effektiv kode tid. Men effektiv kode tid er en relativt lille del af den samlede tid det tager at udvikle. Der skal bruges tid til design af brugergrænseflade og arkitektur, projektmøder, unit test og test derudover bør der ligges en pulje til risiko og uforudsete hændelser. Bliv ikke overrasket hvis overhead på det estimat som kommer ud af udviklerens mund viser sig at være 100% eller mere af estimatet
* 3) få flere forskellige til at gøre det. Jo flere med relevant viden, der giver input jo bedre sandsynlighed er der, for at gennemsnittet ligger tæt på det reelle tidsforbrug. Det er det samme princip, som bruges med poker estimater i den agile verden. Her skal flere forskellige også give input til, hvor lang tid noget tager.
* 4) sørge for at de, som estimerer er uafhængige af hinanden i deres estimater. En stor fejlkilde er såkaldte information cascades eller det fænomen at folk kopierer/bliver påvirket af information fra andre istedet for information fra problemdomænet. Her følger de fleste efter den dominerende i en gruppe uanset om denne har kompetence indenfor området eller ej. Det er en dårlig ide.
* 5) sørge for diversitet i input. Når man estimerer er det vigtigt at få forskellige øjne på problemet, da forskellige specialister ser forskellige problemer.

Der er således ingen grund til, at man ikke skulle kunne estimere, og begynde at bruge det til at styre, hvad man vil udvikle. Det kræver dog en del overvindelse både fra ledelsens og specialisternes side.

Kommentarer (37)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Pelle Söderling

Problemet med estimering er ikke at udviklerne er dovne - problemet er at det er tidskrævende og dyrt og ingen gider betale prisen for det.

Hvis du vil planlægge din gåtur på B.S. niveau så vil det måske tage 14 dage at få styr på alle de her detaljer og finde frem til alle de problemer du måske vil rende ind i og finde ud af hvordan du vil komme udenom dem - det er en betydelig andel af den tid det vil tage at gennemføre selve turen også selvom du godt er klar over dit oprindelige estimat er i den optimistiske ende.

Hvis du er B.S. og har gennemført en lignende tur hundredevis af gange tidligere, så ved du self. i høj grad hvilke udfordringer du kan ske at rende ind i og så kan du måske gennemføre en ret præcis estimering på en halv dag for sådan en tur, men vi kan ikke alle være B.S. og her er udvikling lidt mere abstrakt end en gåtur - det er sjældent man gentager den samme form for udvikling igen og igen, man bevæger sig derimod konstant ind på nyt terræn med nye udfordringer. Pludselig er din kyststrækning erstattet med overfladen på Mars og du skal så til at finde ud af hvordan man gennemfører en gåtur i dette terræn.

Det er igen ikke fordi det ikke kan lade sig gøre - heck NASA har formået at sende robotter på gåtur deroppe - men det er en tidskrævende og dyr process. Og de fleste kunder (eller chefer) har meget lidt forståelse for at estimeringen koster penge at gennemføre - for små projekter ofte næsten lige så meget som reelt at gennemføre dem. Derfor giver det ofte ikke mening når projekterne er små nok - istedet binder man an på erfaring til at give et hurtigt overslag - med den usikkerhed det involverer og det er der sådanset ikke noget galt i hvis hverken kunde eller chef har lyst til at betale omkostningerne for at gennemføre estimeringen som det selvstændige projekt det reelt er.

Det vigtigste at forstå er at det er et ledelsesproblem hvis man føler sine udviklere skyder i øst og vest når det kommer til estimering - det er fordi man sætter en forventning om et hurtigt overslag og ikke er villig til at betale det som det koster at gennemføre en reel estimering.

Simon Mikkelsen

Chef til udvikler: Hvor lang tid til du det her vil tage?
Udvikler: Ca. 300 timer, men jeg skal bruge et par dage til at se på det, hvis du skal kunne bruge estimatet til noget.

3 måneder senere:
Chef til udvikler:
Vi har solgt den opgave du estimerede til 200 timer. Du har 4 uger til at være færdig.

Ps. Jeg blev tabt da jeg så ordet "pleonasme".

Anders Lisdorf

Jeg er helt enig i, at grundårsagen er et ledelsesmæssigt problem og den måde ledelsen tackler estimeringsprocessen på ofte er meget forsimplet.

Men jeg er langt fra enig i at software skulle være noget specielt eller specielt svært at estimere. Antyder du at B.S. Christiansens missioner var standardting, som han havde prøvet hundrede gange før? At der ikke er nogen overraskelser, når man er på hemmelig mission i fjendtligt territorium? Det er ikke det man kan læse i "Et liv på kantent" i hvert fald.

Jeg er også lodret uenig i, at der skulle være situationer, hvor det tager ligeså lang tid at estimere som at lave det. Det har jeg aldrig oplevet. Det tager ikke 200 timer at estimere en opgave til 200 timer.

Jeg kan blot konstatere, at der er en udpræget tendens til exceptionalisme når man snakker om software udvikling, altså at software udvikling skulle være noget med en kompleksitet af en helt anden verden. Vist er det kompliceret, men så er det heller ikke værre.

ole jeppesen

Tak Anders,

Af en eller anden grund har alt for mange software udviklere så mange argumenter mod at estimere at det bliver helt mistænkeligt.

Samtidigt har alt for få projektledere erfaring med estimerings-metoder til at de har indset hvilket formidabelt redskab de giver afkald på i deres projekt.

Hvis chefen heller ikke finder det nødvendigt at retfærdiggøre igangsætningen af et projekt baseret på så faktuel viden som muligt - ja, så går det jo ofte som i de berygtede projekter der kører helt af sporet som man jævnligt kan læse om i pressen.

Prøv det dog - det behøver hverken at være svært eller tidskrævende. Som alt andet gør erfaring mester. Jo mere erfaring man får med estimering jo mindre tid tager det og jo mere nøjagtig bliver det. De som virkeligt får noget ud af det er de som anvender metoden agilt og ikke blot betragter det som en on-off ting man laver ved opstart af et projekt, men som løbende vurderer og tilretter estimeringen undervejs i projektet (ja, versionsstyring er også en god ting ;-). Man bliver ikke blot klogere undervejs men de få notater der bør knytte sig til delresultater kan være uvurderlig både før, under og efter projektet.

Hvor svært kan det være?

Giv det dog en chance og se om du ikke også får mere succes med dit næste projekt.

Et godt udgangspunkt for at komme igang er dette lille dokument om 3-punkt estimering

Morten W. Jørgensen

Antyder du at B.S. Christiansens missioner var standardting, som han havde prøvet hundrede gange før? At der ikke er nogen overraskelser, når man er på hemmelig mission i fjendtligt territorium?


Jeg synes at huske at B.S. Christiansen i mange år svarede henholdene på om hvor vidt han havde været på en egentlig mission ud over øvelser (1).
Jeg synes også at huske at der for ikke så længe siden blev bekræftet at det havde han faktisk aldrig. Hvis det er tilfældet er alt det der med "...når det virkelig brænder på..." og "...sådan gør man altså bag fjendens linjer er..." blot akademisk øregas.

Men jeg kan jo huske forkert... ( http://www.bt.dk/nyheder/b.s.-har-aldrig-vaeret-i-krig )

(1): Hvor han I øvrigt selv har udtalt at han snød og fik vand af heikopterpiloterne og dermed skabte sig en fordel over for dem der legede rigtig soldat.

Hvis ikke jeg husker helt galt, er B.S.Christiansens største bedrift som soldat altså at han har været dygtig til at sælge historien om sig selv. Og så er det jo noget nemmere at være verdensmester i alting.

Med skeptisk hilsen,
Morten

Pelle Söderling

hvor lang tid det tager at estimere handler i høj grad om hvor høj præcision du er ude efter. Det er ikke ulig problematikken omkring outsourcing - hvis du helt ned på metode-niveau har brug for at dokumentere og udspecificere det som skal implementeres, så tager det ofte længere tid end blot at skrive koden. Men jo højere et abstraktions-niveau du vælger at gå op på jo større risiko er der involveret, for djævlen gemmer sig i detaljerne.

Det lyder som om du er en af dem som betragter software-udvikling som en ingeniør-diciplin, hvor man bare kan måle og opstille processer for det hele indtil det går op i en højere enhed - sådan var jeg selv tilbøjelig til at tænke engang, men efter mere end 20 år som software-udvikler er min konklusion at software-udvikling snarere i høj grad er en kunst-form og jeg er ikke længere istand til at forklare de processer der gør at jeg kan udvikle software på det niveau jeg idag er istand til - det handler i meget høj grad om erfaring, intuition, motivation, psykisk balance og mange andre faktorer.

De bedste dage er ikke hvor man producerer 1 dags arbejde - det er hvor man sparer sig selv eller andre betydelige mængder arbejde i både implementering og fremtidig vedligehold fordi man så en bedre vej til målet. I software-udvikling på en god dag kan den rigtige beslutning spare flere mandeår væk og de bedste udviklere er istand til at gennemskue disse scenarier dagligt baseret på store dele erfaring og intuition. Det betyder også at en udvikler kan være næsten uendelig meget mere værdifuld/produktiv end en anden udvikler - for det er ikke samlebåndsarbejde der er tale om her. Der er tværtimod tale om intellektuelle udfordringer på et ekstremt højt abstraktionsniveau - og ja det er forfærdelig komplekst, med al ære og respekt for B.S.

Morten Brørup

Her i SmartShare Systems, hvor vi udvikler netværksudstyr, bruger vi en udviklingsprojektestimeringsmetode inspireret af Wideband Delphi, men en hel del reduceret i forhold til originalen.

De relevante udviklere starter med - hver for sig - at bryde opgaven ned i midre delopgaver og estimere disse. For hver delopgave noterer udvikleren sit bud på minimum- og maksimum-tidsforbrug, og evt. en bemærkning om, hvilke problemer, udvikleren kan forudse at rende ind i.

Herefter mødes gruppen af udviklere, så de forskellige løsninger, delopgaver og potentielle problemer kommer på bordet og bliver diskuteret. Ind imellem har en udvikler et svar på en anden udviklers potentielle problem, og ind imellem har en udvikler identificeret et potentielt problem, som de andre havde overset. Ofte har nogle udviklere noteret delopgaver, som andre udviklere havde glemt, fx interoperabilitets-test. Man bliver nu enige om en samlet liste af delopgaver.

Herefter udfylder udviklerne - hver for sig - den fælles liste af delopgaver med sine personlige estimater på delopgaverne (med både minimum- og maksimum-tidsforbrug og evt. bemærkninger).

De samlede estimater giver et godt indtryk af, hvor der er koncensus (hvis estimaterne er nogenlunde ens), og hvor der er risici i tidsplanen (hvis estimaterne varierer meget, eller max-udviklingstiden ligger markant højere end min-udviklingstiden). Desuden giver det et samlet estimat for udviklingtiden, minimalt og maksimalt, samt estimatets nøjagtighed (ud fra estimaternes standardafvigelse).

Det er klart, at erfarne udviklere har bedre forudsætninger for at estimere delopgaver indenfor deres erfaringsområde end mindre erfarne udviklere. Vi ser også generelt mindre afstand fra min- til max-estimaterne fra de mere erfarne udviklere end fra de mindre erfarne.

Estimaterne angives i effektiv udviklingstid, så i tidsplanerne multiplicerer vi estimaterne med en faktor, der afspejler, at udviklerne ikke bruger 100 % af deres tid på effektiv udvikling, men også bruger tid på vedligeholdelse, møder og andet pjat. :-)

PS: Vi sælger ikke udviklingsprojekter til kunder, men udvikler egne produkter, så vi har ingen interesse i urealistiske estimater. Og det sidste er nok mindst lige så vigtigt!

Mvh
Morten Brørup
CTO, SmartShare Systems

Henrik Secher Jarlskov

Det er ikke min erfaring at udviklere er bange for at lave estimater eller guestimates.

Det de ofte frygter er hvordan forudsætningerne for estimaterne bliver behandlet.
Hvis du bliver bedt om at lave estimater på et meget løst grundlag og derved angiver en meget stor usikkerhed i dine estimater er det surt at blive mødt senere med at man har lovet at det kan udvikles indenfor estimatet.

Ofte gives estimatet ud fra den forudsætning at de angivne afklaringer holder, men når man når ind i udviklingsfasen og resultatet begynder at dukke op ændres folks ønsker til slutresultater - ofte uden at man vender tilbage til de oprindelige estimater.

I et projekt, hvor folk kender forudsætningerne for estimaterne, samt de usikkerheder der har været tilknyttet og der samtidig er god projektledelse er der intet problem i at give estimater. Men ændres forudsætninger må man tilbage og lægge en ny plan, da man står med en ændret situation.

Estimater er ikke mejslet i sten - noget som er let at glemme når først projektskibet er lagt fra havn og alle har afsat budgetter til netop estimaterne - og altid de laveste - uden at tage højde for usikkerheden.

Det udviklere hader er politikken og "The Blame Game" - ikke at bruge deres professionelle baggrund til at vurdere nye, spændende opgaver!

Pelle Söderling

Der er massere mere eller mindre kreative metoder oftest baseret på divide and conquer princippet og det virker fint hvis man f.eks. er en virksomhed der har specialiseret sig i at udvikle små kunde-websites eller lign. hvor det meste er kendt stuff.

Prøv tilgengæld at skulle estimere implementeringen af et Business Intelligence eller ERP-system i en større virksomhed og så vil jeg ønske jer held og lykke.

Niels Elgaard Larsen

Der er jo en forskel til de fleste andre professioner fordi opgaverne i IT-systemet som regel er ret forskellige fra noget, man har lavet før. For ellers ville man jo bare kunne genbruge koden fra sidste gang.

Hvis man fx bygger huse kan tegningerne, jordbunden, kloakeringen osv godt være forskellige, men når man har bygget nok af dem, har man nok en god fornemmelse hvor tiden og pengene bliver brugt. Men hvis man skal bygge noget helt anderledes som fx Melodigrandprix scene ....

Og hvis softwareprojekter ikke er sværere at estimere, hvorfor er det så, at vi hele tiden skal påduttes alle mulige nye estimeringsmetoder? Min boligforening skal have lavet et omfangsdræn. Jeg tror ikke at kloakmesteren samler alle svende og beder dem nedbryde opgaven og sætte pokerkort i panden.

Når fonde og pensionskasser investerer vores milliarder, så beder man ikke en flok analytikere give bud på kurser uafhængigt af hinanden, fordi man er bange for, at de bliver påvirket af den dominerende analytiker.

Jesper Louis Andersen

I mange softwareprojeker, der tror jeg det er forholdsvist nemt at lave et præcist estimat. Problemet er bare at et estimat ikke er til forhandling, så du kan ikke magisk reducere det. Og samtidig kan uforudsete hændelser i forbindelse med projektet gøre grumme ting ved estimatet.

I softwaresystemer hvor det er forholdvist velkendt hvilke komponenter der skal laves, og hvordan de skal spille sammen med det eksisterende system, der er det nemt at ramme præcist. Risikoen for en teknologisk wipeout hvor hele grundlaget skal redesignes er heller ikke specielt høj. Er kodebasen endvidere i god stand og er softwareprojektet designet modulært (I.e., gode gamle OO SOLID eller passende for dit sprogdomæne), så er det rigtigt nemt at gå til.

De projekter der er svære at estimere har nogen fælles faktorer:

  • Mange skiftende udviklere, hvor ingen har det større overblik
  • Rodet kodebase, dårligt design, bit-råddenskab, manglende test
  • Dårligt data-access: forkerte data-strukturer, kompleks tilgang til data, kommunikation med mange delsystemer
  • Dårlige grunddata: ringe struktur, så man ikke kan gå formelt til værks, men må angribe datasættet på heuristisk vis for at kunne behandle det. Alt er gemt i tekststrenge, dårlig typestruktur og så videre
  • Legacy-platforme. Det medfører at du er nødt til at indføre en masse anti-korruptionslag for det nyudviklede software

Og så fremdeles. Jeg ser hovedårsagen til estimeringer er svært som et symptom på hvor umodent softwareudvikling er. I andre brancher med mere modenhed, der er der nogen etablerede procedurer der gør, at kvaliteten af det producerede har en hvis højde.

Hver gang du åbner et nyt delmodul i systemet og alle skeletterne rasler ud af skabet, der ved du at estimatet lige er gået fløjten. For det var ikke en del af dine oprindelige antagelser.

Det hænger så igen sammen med at man kun kan finde de relevante delmoduler med en velkendt og velspecificeret opgave. Men i dagens "Agile" miljø, der er det åbentbart normalt at man midt i projektforløbet ender med at redefinere store dele af opgaven. Måske mestendels fordi man glemte at lave det indledende arbejde ordentligt.

Pelle Söderling

Lige præcis - godt skrevet. Jeg synes faktisk ikke udvikling er specielt relaterbar til andre traditionelle erhvervs-fag - jeg ser det relateret tættere til forskning og måden man her arbejder på.

Det samme gør sig nemlig lidt gældende at det i høj grad er erfaring og intuition der giver kvantespringene og en dygtig forsker kan opnå resultater mange gange hurtigere end en knap så dygtig forsker der kan forske i årevis uden at nå nogen vegne. Og man behøver blot at kigge overfladisk på polsag for at se hvordan det er muligt for en masse udviklere at lave noget hvor det hele tiden er 1 skridt frem og 2 tilbage. Den slags ser man altså ikke ret tit når det gælder f.eks. kloakering eller endda at bygge en bro eller en rumraket - de folk der står for den slags har ofte opbygget erfaring på meget lignende projekter og har kunnet genanvende den erfaring 98-99%.

Det er let at kalde software-udvikling simpelt og hvis det man laver er tilpas simpelt så er det da også sandt nok - men når software-udvikling bliver komplekst, så er det noget af det mest komplekse vi som mennesker endnu har kastet os ud i - det er abstraktionslag ovenpå abstrakstionlag ovenpå abstraktionslag.. og der er lang vej til at forstå alle de lag en vilkårlig operation går igennem i form af både software og hardware og hvilke konsekvenser det kan have når man har brug for f.eks. at presse grænserne for ydelse. Og så er det ikke usædvanligt at du den ene måned bygger en rumraket og den næste bygger en storebæltsbro, man opbygger selvfølgelig noget generel anvendelig erfaring - men vi taler ikke om at 98-99% kan overføres direkte fra tidligere projekter, sådan som det ofte er tilfældet indenfor mere tradtionelle erhverv.

Carsten Frigaard

Det er symptomatisk for it-industrien at anvende en eller anden udvandet 'analogi-fortælling', her en vandre tur (med eller uden BS), i stedet for at diskutere de reelle faktorer. Det kan være fordi software er svært at lugte, røre og visualisere.

Det ville hjælpe konkretisere "rigtige teknikker" i stedet for at væve rundt i abstrakte gåture...også i forbindelse med estimering.

.carsten

Morten Brørup

@Morten Brørup. Jeg ser tit at problemet ligger i effektiv udvikling og reel udvikling.
Hvilken faktor bruger I til at udregne den effektive tid? Er den udregnet individuel, efter erfaring, løbende tilbagemeldinger eller bare en fast faktor?

Vi bruger en individuel faktor for hver udvikler.

Udviklerne registrerer ugentligt, hvor meget tid de har brugt på forskellige projekter og alt muligt andet, inkl. møder og decideret tidsspilde som fx bøvl med deres computer.

Idet hver udviklers andel af tid brugt på nyudvikling i forhold til andre opgaver normalt er nogenlunde ens hver måned, har vi udviklerens faktor herfra.

Det forudsætter naturligvis, at vi ikke ændrer udviklerens opgavemix.

På den anden side betyder det også, at vi kan accelerere nye projekter ved at reducere mængden af andre opgaver. I praksis betyder det, at de andre opgaver udskydes til senere, og belaster efterfølgende tidsplaner tilsvarende negativt. (Og det er naturligvis kun anden udvikling og vedligehold, der kan udskydes til senere. Mængden af supportopgaver, møder, computerbøvl og andet tidsspilde kan desværre ikke reduceres midlertidigt.)

mvh
Morten Brørup
CTO, SmartShare Systems

Anders Lisdorf

Ja, det er jo den gode gamle med, at de andres job, det er let. Men mit job det er vildt svært. Tro mig, det er derfor IT folk altid har problemer med forretningsfolk, for de synes også at IT, det er da nemt, men deres job voldsomt kompliceret.

Grunden til at andre professioner ser så simple ud er generelt, at man ikke ved noget om dem. Derfor synes jeg også at IT udviklere burde have en smule mere respekt for andres professioner, hvis de vil have respekt for deres.

Udvilklere har også patterns, standard libraries og allehånde ting som pakker kompleksiteten ind. De sidder ikke i dag og skriver maskin kode, så hvis en entreprenør kiggede på IT udvikling ville han se det samme, som du gør når du kigger på entreprenører: en masse standardting som bare lige skal kombineres og 98 -98% kan genbruges.

Udviklere i dag sidder ikke og laver storebæltsbroer den ene dag og rumraketter den næste, så det synes jeg er en forkert analogi. Der er i dag ingen udviklere som den ene dag sidder og roder med noget objective C, den næste lidt konfiguration af en CentOS server og så noget assembly kode og derefter lidt PROLOG til at gå hjem på. Det er de færreste udviklere i dag som laver noget som er meget forskelligt. Det er klart at udviklere har en imponerende bredde og ofte kan meget forskellige sprog og discipliner, men storebæltsbroer og rumraketter, der tror jeg ikke vi er.

Hvis man synes at software skulle være det mest komplicerede menneskeheden skulle have beskæftiget sig med, siger det mere om den viden, man har om, hvad menneskeheden har beskæftiget sig med.

Tue Wennerberg

For at få estimering til at virke, skal man have:

  1. En systematisk, standardiseret estimeringsmetode
  2. Feedback loop på estimater

Estimering i timer, story points eller kategorier og hvorvidt man skal bruge min-max, poker planning eller gange med en fast faktor er stadig relevant, men kun hvis man får styr på ovenstående.

Peter Stricker
Nikolaj Brinch Jørgensen
Nikolaj Brinch Jørgensen
Pelle Söderling

Ja, det er jo den gode gamle med, at de andres job, det er let. Men mit job det er vildt svært. Tro mig, det er derfor IT folk altid har problemer med forretningsfolk, for de synes også at IT, det er da nemt, men deres job voldsomt kompliceret.

Grunden til at andre professioner ser så simple ud er generelt, at man ikke ved noget om dem. Derfor synes jeg også at IT udviklere burde have en smule mere respekt for andres professioner, hvis de vil have respekt for deres.

Som software-udvikler ved jeg mere om andre professioner end de fleste gør - jeg har bl.a. designed løsninger til at assistere regnskabsafdelinger, revisorer, lagermedarbejdere, butiks-konstruktører, marketingsfolk, HR og leveret Business Intelligence løsninger til top-ledelsen i Enterprise-organisationer og jeg har også arbejdet som projektleder, arkitekt, selvstændig konsulent og drevet 3 virksomheder selvstændigt med ansatte (så jeg ved også lidt om hvad det vil sige at være entreprenør). Jobbet som udvikler handler i høj grad om at kunne sætte sig ind i andre mennesker (og professioners) arbejdsgange og forretningsområder. Jeg tror faktisk ofte det undervurderes hvor meget udviklere faktisk ved om andre professioner fordi vi udvikler de softwareløsninger som de sidder og bruger dagligt til at udføre deres arbejde.

Udviklere har også patterns, standard libraries og allehånde ting som pakker kompleksiteten ind. De sidder ikke i dag og skriver maskin kode, så hvis en entreprenør kiggede på IT udvikling ville han se det samme, som du gør når du kigger på entreprenører: en masse standardting som bare lige skal kombineres og 98 -98% kan genbruges.

At pakke kompleksitet ind gør det ikke mindre komplekst - tværtimod, det skjuler den blot i et ekstra lag.
Jeg kender ingen Enterprise-udviklere der arbejder på den måde du beskriver, ihvertfald ikke som er successfulde med det de foretager sig.

Udviklere i dag sidder ikke og laver storebæltsbroer den ene dag og rumraketter den næste, så det synes jeg er en forkert analogi.

Nej, det gør vi selvsagt ikke - det er en analogi og som med så mange andre analogier der forsøger at beskrive software-udvikling med real-life referencer er den ikke specielt god (hvilket i sig selv siger lidt om hvor abstrakt software-udvikling er) - men det ændrer ikke på det faktum at man som software-udvikler beskæftiger sig med rigtig mange områder som har meget lidt tilfælles og der konstant skabes nye teknologier som ændrer forudsætningerne.

der er i dag ingen udviklere som den ene dag sidder og roder med noget objective C, den næste lidt konfiguration af en CentOS server og så noget assembly kode og derefter lidt PROLOG til at gå hjem på. Det er de færreste udviklere i dag som laver noget som er meget forskelligt.

Som andre nævner så er det ret præcist hvad vi gør, omend teknologierne, sprog etc. self. varierer. Efter 20 år med software-udvikling beskæftiger jeg mig stadig med nye ting jeg aldrig har beskæftiget mig med tidligere i min karriere stortset hver eneste dag - hvor mange andre professioner gør dette sig gældende indenfor?

Hvis man synes at software skulle være det mest komplicerede menneskeheden skulle have beskæftiget sig med, siger det mere om den viden, man har om, hvad menneskeheden har beskæftiget sig med.

Istedetfor at være sarkastisk, kan du så ikke blot nævne et par eksempler?
Det eneste jeg kan pege på der er i samme kategori er som tidligere nævnt forskning (som iøvrigt oftest assisteres af ganske kompleks software idag).

Anders Lisdorf

Det samme gør sig nemlig lidt gældende at det i høj grad er erfaring og intuition der giver kvantespringene og en dygtig forsker kan opnå resultater mange gange hurtigere end en knap så dygtig forsker der kan forske i årevis uden at nå nogen vegne

Nu har jeg arbejdet som forsker på universitetet i nogle år og kan ikke genkende det billede. God forskning har ikke noget med hastighed eller "at nå nogen vegne". For det første er det uklart, hvad du mener med at nå nogen vegne. Er det antal publikationer? rejste forskningsmidler eller stillinger? Mange af de forskere der når alt det er ikke de bedste. Faktisk er det normalt omvendt, at de dygtige forskere tager væsentligt længere end dårligere forskere. De dårlige er normalt mere overfladiske og har derfor lettere ved at producere en masse i en fart.

Anders Lisdorf

Istedetfor at være sarkastisk, kan du så ikke blot nævne et par eksempler?
Det eneste jeg kan pege på der er i samme kategori er som tidligere nævnt forskning (som iøvrigt oftest assisteres af ganske kompleks software idag).

Beklager hvis det lød sarkastisk. I artiklen nævner jeg faktisk nogle eksempler. Jeg har selv lavet rodet med lidt hjerneforskning på universitetet, da jeg arbejdede der og det synes jeg da, var pænt kompliceret, men jeg var mere imponeret af fysikerne, for det er seriøst komplicerede ting de roder med. Jeg har også stiftet bekendtskab med kladistik og populationsbiologi, som jeg har brugt til at forstå sproghistorie og udbredelse af kulturer. For mig er det virkeligt kompliceret.

Uden sammenligning i øvrigt mener jeg også, at projekter som elektronisk patient journal og rejsekortet er langt mere komplicerede end folk aner, for det handler om at opnå enighed mellem mennesker, som ikke har nogen interesse i at blive enige. Kodning er, alt andet lige, et finit problem som har en hvis grad af forudsigelighed, da koden som oftest opfører sig ens. Det gælder ikke for mennesker. De samme mennesker vil ofte opføre sig forskelligt, selv under samme omstændigheder.

IT udvikling er ikke simpelt, men sammenlignet med visse andre ting er det heller ikke voldsomt kompliceret.

Peter Stricker

Ok, godt så, til alle jer haters derude.


Haters??? Jeg er en af dem, der har opponeret mod din beskrivelse af en udviklers hverdag. Men det har da intet med had at gøre. Pas lidt på med retorikken, for hvis det er skrevet med et glimt i øjet (hvad jeg da håber), så er det glimt ikke lige kommet med på skrift.

Find mig bare et jobsopslag...


Nu bliver du ret specifik, og som du kan læse i indlæggene, så kan der være store forskelle på, hvilke opgaver man forventes at løse.

1) Administration af visse fælles udviklingsværktøjer, opsætning og vedligehold af CI server, VM'er til test, valg af IDE'er og editorer, valg og opsætning af versionsstyringsværktøj,... Alt sammen opgaver, der ikke nødvendigvis er beskrevet i en jobannonce, men som det da slet ikke er utænkeligt, at overlade til udviklere.

2) Desktop, mobil og web applikationer er det da helt naturligt at lade udviklere om at udvikle. Meget muligt, at kun en af applikationstyperne er nævnt i jobopslaget, men det betyder da ikke, at de andre typer ikke senere kan komme til.

3) Udvikling i adskillige sprog efter flere forskellige udviklingsparadigmer som imperativ, deklarativ, OO, FP, AOP m.m. er da helt normalt, især i en "moden" organisation med en del legacy software. Og hvis virksomheden har en mainframe, hvor der programmeres i assembler jamen, så er det nok også snare programmører end forretningsanalytikere, man sætter til det. Igen er det ikke sikkert, at det hele er nævnt i stillingsopslaget, men det kan der jo være flere grunde til. For eksempel at man ikke vil skræmme ansøgere væk ved at afsløre, hvor rodet en produktportefølje virksomheden har.

4) Implementering af løsninger indenfor alle de områder, som organisationen har brug for, må da også forventes at være en helt naturlig opgave for en udvikler. Der kan sagtens være opgaver indenfor virksomheden, som den enkelte udvikler grundet manglende kvalifikationer eller interesse ikke kommer til at beskæftige sig med. Det kan da sagtens være AI, men det kan også være GUI programmering eller mange andre opgaver, som det ikke lige er alle, der er bedst til. Men såfremt man udvikler AI, så er det da ingen garanti for, at man ikke skal lave brugergrænseflade eller integration til andre systemer. Men igen, det er nok ret usandsynligt at alle en udviklers opgaver bliver nævnt i en enkelt stillingsannonce, hvis denne skal fremstå blot en smule sammenhængende.

Så nej, lige det jobopslag, du beder om, kan jeg nok ikke finde. Men det er altså ingen "garanti" for at et job som udvikler bliver kedeligt og rutinepræget.

Anders Lisdorf
Peter Stricker

har du nogen sinde set nogen skrive haters på dansk uden et ironisk glimt i øjet?


Ja, jeg har altid opfattet det som et udtryk, der bruges af folk, der ikke kan tåle kritik. Og jeg har altid syntes at brugen af ordet er så taberagtigt, at Godwin burde lave en lov mod det. Det er muligt, at min forståelse af ordet er forkert, men det kan jeg nu ikke se ud af dit link.

Derfor glæder det mig, at du tilsyneladende ikke har brugt udtrykket som jeg opfattede det. Og jeg håber ikke, at du tager det ilde op, at jeg reagerede på det ord. Men jeg vil nu alligevel holde fast i min opfordring til, at du lader være med at bruge det i flæng.

Men lad os nu ikke afspore debatten med diskussion om et enkelt ord. Din blog har under alle omstændigheder peget på et vigtigt aspekt af dagligdagen for en udvikler, som man ikke kommer udenom, selvom det måske ikke eksplicit nævnes i jobopslaget ;-)

Jacob Christian Munch-Andersen

Uden sammenligning i øvrigt mener jeg også, at projekter som elektronisk patient journal og rejsekortet er langt mere komplicerede end folk aner, for det handler om at opnå enighed mellem mennesker, som ikke har nogen interesse i at blive enige.


Det kan du have ret I. Selve programmeringsdelen af projekterne burde i begge tilfælde være relativt simple datasystemer hvor den primære udfordring er at det skal kunne klare et stort antal brugere. Og der er jo ikke nogen grænse for hvor kompliceret bureaukrati kan blive.

Prøv i stedet at tage et kig på Linux-kernen og se om du kan forstå hvorledes nogen kan få over 15 millioner linjer kode til at hænge sammen. Hvis du ikke finder det utroligt er det fordi du aldrig har fattet hvad programmering handler om.

Uanset, så giver det ikke nogen mening at forsøge at svare på hvilket af fagene programmering, hjerneforskning og fysik der er mest komplekst. For alle tre fag er kompleksiteten primært begrænset af hvad det er muligt for et menneske at håndtere. Dermed er det ikke fagene, men de mennesker som udfører dem der bestemmer kompleksitetsniveauet.

Tine Andersen

Skal jeg tegne et billede af en kat- tager det 2 minutter. Skal jeg tegne et billede af din kat (efter foto)- tager det 1-2 timer (længere tid, hvis den er sort!) Skal jeg male en kat efter levende model- tager det måske en ½ time.(Der skal man være hurtig! ellers vågner den bare og går!)

Jeg synes, det er rigtig svært, at estimere hvor lang tid, ting vil tage for det kommer an på...

Er det opgave, der ligner noget, du har løst før- så kan det laves hurtigt-
Ligner det noget, men med noget nyt i- tager det længere tid.
Er det en helt bestemt skæddersyet løsning? Så tager det bestemt 2½ gang længere tid end, normalt.

Men det kommer også an på, hvor samvittighedsfuld man er.

Jeg ville fx aldrig vælge ruten langs kysten- den er længere, men kan jeg finde en rute (nok umuligt- motorveje ligger som regel, hvor de gør fordi, de følger gamle veje)- der er midt i mellem.

BS var faktisk nr 1 i i et andent amerikansk soldater halløj(Navy Seals?)- men hans spidskompetance er teamwork. Og det er han god til!

Han er et dårligt exempel- næh: Du skal ud og gå med Chris Mcdonald- og hvis du ikke æder din blendede grønkål- og ser sød ud- men er fed og får vabler og giver op- så!

Mvh
Tine- jeg hader, de der amerikanske lignelser- de er så... platte

Bjarke Meier

Er der nogen af jer, der arbejder ud fra de simple principper Tue Wennerbergs beskriver? Hvad er jeres erfaringer med estimering?

Hvis man ikke rent faktisk standardiserer eller har et feedback loop, så er det som at skyde på mål, men med et nyt våben hver gang og uden at kigge hvor man rammer. Det bliver man altså ikke ret meget dygtigere af uanset hvor længe man "øver" sig...

Kalle Larsen

Bogen blev udgivet første gang i 1975; men meget af indholdet holder stadig.

F.eks. det faktum at i en projektgruppe med f.eks. omkring otte udviklere, vil der være en forskel på en faktor ti mellem den hurtigste og den langsomste udvikler.

Estimatet vil måske hovedsageligt blive påvirket af een af de hurtige udviklere - og dermed i den lave ende.

Men projektlederen sætter den langsomme til at løse opgaven, da det er ham/hende, der 'er ledig' - og en ressource er jo en ressource - uden smålig skelen til effektivitet.

Bliver der re-estimeret pga. dette? Nej, prisen er jo allerede sat og meldt ud udfra det lave estimat.

Kan der opstå 'forsinkelse' pga. dette? Ja, det kan der!

Er det noget, vi oplever ude i den virkelige verden? Ja, også i den grad.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize