Alle udviklere laver fejl: De farligste er gætterier om huller i kravene

Sommertour: Det kræver en særlig personlighed at være tester på softwareprojekter, og derfor bør det ikke være udviklerne selv, der står for testen, mener Danmarks 'Fru Test'.

Al software indeholder fejl lige fra et manglende semikolon i dit første 'Hello World' program til et dokumentstyringssystem, der ikke har en søgefunktion. Derfor er test en vigtig disciplin, og det kræver en helt bestemt personlighed.

»Testere er et specielt folkefærd. Du skal elske at finde andre folks fejl og have et lidt destruktivt gen. Udviklere bygger ting, så udviklere skal ikke teste,« siger Anne Mette Hass fra Devoteam.

Hun har arbejdet med test og sikkerhed i en årrække og underviser i dag på kurser i softwaretest og er også del af en ISO-arbejdsgruppe, som er i færd med at udarbejde en ny standard for test.

De fleste udviklere er nok selv opmærksomme på logiske fejl i programkoden. Det kan være et større end-tegn, der skulle have været et mindre end-tegn. Men den type fejl udgør kun en lille del af fejlene i softwareprojekt.

»De fleste fejl opstår i kravene. De slemme er der, hvor der mangler krav, fordi der er områder, som ikke er beskrevet, fordi der enten ikke er nogen, der vidste det, eller fordi man troede, at alle vidste noget. Så sker der desværre tit det, at den, der skriver koden, gætter i stedet for at gå tilbage og spørge. Desværre gætter de som regel forkert, fordi der er flere forkerte svar end rigtige,« forklarer Anne Mette Hass.

Der kan også være tale om krav i kravspecifikationer, som er inkompatible. I sådan en situation burde udvikleren gå tilbage til den, der har skrevet kravene, men ofte gætter udviklerne blot på, hvilket af to modstridende krav, der får lov til at stå.

Et vigtigt princip i softwaretest er derfor også, at testeren skal være uafhængig. Hvis man skal finde fejl i sin egen kode eller de krav, man selv har skrevet, så har man ganske vist let ved at sætte sig ind i indholdet, men man er ikke motiveret til at finde sine egne fejl.

»Den ideelle tester er en person, der ved hvad han eller hun bidrager med. Du skal være pernittengrynet, og man skal synes, det er vigtigt, og vide at det giver værdi,« siger Anne Mette Hass.

Det er også vigtigt, at testeren er klar over, at det ikke er alle fejl, der bliver rettet. Opgaven er i lige så høj grad at gøre projektlederen klar over, hvilke fejl der findes, så de kan træffe en beslutning om, hvorvidt de skal rettes eller ej. På den måde bliver softwaren måske stadig leveret med fejl, men alle er klar over, hvilke fejl det drejer sig om, og hvad konsekvenserne er.

»Desværre brænder mange testere ud, fordi de ser fejl, de har fundet, blive sendt ud alligevel,« siger Anne Mette Hass.

Det er også én af grundene til, at hun underviser i softwaretest. Hun vil nemlig gerne give sin erfaring videre til den næste generation af testere.

»De nye skal vide alt det, jeg ved. Alt det, hvor jeg har tænkt, hvorfor var der ingen, der fortalte mig det?« forklarer Anne Mette Hass.

Da mange af de alvorlige fejl opstår allerede, når kravspecifikationen skal skrives, hvor arkitekterne glemmer funktioner eller ikke beskriver dem grundigt nok, så ville Anne Mette Hass også gerne have flere testere med tidligt i processen.

»Personligt synes jeg, at professionelle testere og professionelle kravsfolk skulle lave kravene sammen, så kravene er direkte testbare. Dem, der laver kravene, er de kreative, som er en meget anderledes type end testerne. Hvis man sætter de to sammen, så tror jeg, man kommer et kæmpe stykke vej,« siger Anne Mette Hass.

Hun påpeger, at kravene, der skal videre til udviklerne, under alle omstændigheder skal være entydige, og derfor kan man lige så godt få testerne med tidligt i processen til at hjælpe med at gøre kravene klare.

»Det kan godt være, det tager lidt længere tid, før man kommer i gang med at kode, men hvis man har mod til at lave ordentlige krav, så er der også store gevinster at hente. Jo mere testforståelse, jeg har fået, jo mere kravler jeg over i kravene og vil hellere bidrage der. Der er ingen tvivl om, at kravsfolkene gør deres bedste, men de er bare ikke uddannet godt nok,« siger Anne Mette Hass.

Hun er også tilknyttet IT-Universitetet som ekstern lektor og ærgrer sig over, at de studerende næsten ingenting skal lære om udarbejdelse af kravspecifikationer og endnu mindre om test.

Hun deltager som nævnt også i en arbejdsgruppe under ISO, som er i færd med at udarbejde en ny standard for softwaretest, fordi der i dag ikke findes en standard, der dækker test som helhed, men blot enkelte dele af test.

Under det arbejde har hun blandt andet flere gange været til møder i lande i Fjernøsten, hvor der i lande som Malaysia, Japan og Sydkorea som regel er adskillige repræsentanter for landenes regeringer med til møderne.

Det betyder også, at eksempelvis Malaysia har planer om at gøre standarden til national standard i det offentlige.

»Når man ser, hvordan landene i Østen håndterer det her på regeringsniveau, så går der ikke længe, før de overhaler os,« siger Anne Mette Hass.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Lundin

Igår måtte jeg rette den værste programmeringsfejl jeg er blevet gjort opmærksom på i adskillige år.

Den blev fundet i et nyt projekt, hvor vi netop har fundet en ekstern Ph.D. studerende med viden på området samt tid og motivation til at komme med resultater.

Problemet var, at jeg havde gættet (forkert) på meningen med en uklarhed i en specifikation.

Min næste fejl kommer helt sikkert til at skyldes noget andet.

  • 1
  • 0
Morten Andersen

Jeg ved ikke hvad jeres erfaring er, men min erfaring med "profesionelle" testere er utrolig dårlig. De finder stort set ingenting - det er først når produkterne kommer ud hos kunderne problemerne opstår.

Jeg tror det afhænger af udviklerens dygtighed. Alle laver selvfølgelig fejl, men en dygtig og ansvarsfuld udvikler er trods alt i stand til at levere et nogenlunde fejlfrit produkt i hvert fald med hensyn til de forudsagte scenarier. Og det er typisk dem som testeren, med udgangspunkt i kravspecifikationen, vil test igennem. Men den helt store udfordring for koden er at komme ud i den virkelige verden. Uanset hvor godt noget er testet, sker det ofte at tingene fejler af - ofte ganske trivielle - grunde når det kommer ud i et system med større load, større diversitet i klientplatforme, større diversitet i brugsmønstre osv. Og det er altsammen ting som selv en prof. tester har svært at ved at adressere.

Jeg har set følgende mønster gang på gang: Et nyt, stort (og dyrt) IT-projekt starter, og alle har en følelse af at "denne gang skal det være rigtig kvalitet" så konsulenthusene sender massere af testere og projektledere med de fineste uddannelser og modeller for projektledelse ind. Hvis det skal være rigtig dyrt er der GUI-folk, usability og accessibility eksperter osv. osv.

Og i starten af projektet er der ganske vist også en følelse af at der er styr på det hele, og at arbejdsgangene er i system og at man nok skal lave et fejlfrit produkt (!). Spol tiden frem til 1 måned før levering: Alle sidder med poser under øjnene fordi de har arbejdet hele natten. Udviklerne sidder febrilsk og kigger på lange traces, kigger kode og suser rundt i debuggeren for at finde den obskure fejl - og som ender med at blive løst af et hack eller to der aldrig bliver skrevet ned noget sted.

upportmailboxen er pludselig fyldt med rapporter fra de første brugere om "pinlige fejl" - mystiske fejldialoger der dukker op i ellers tilsyneladende simple scenarier... samt stavefejl, knapper der står skævt osv. osv.
Fejl, som egentlig er ret åbenlyse og som trods alle de fine metoder på en eller anden måde har fået indsneget sig. :S

Jeg har set dette mønster så mange gange, at jeg frygter det er en iboende del af IT... der er altid et par jokere i et stort system, og det er ikke noget som selv en stringent udviklings- og testmetodik kan løse, selvom man har de bedste intentioner hver gang.

Mit bedste råd er at finde nogle prøveklude der gider at teste koden og så få dem til at gøre det så hurtigt som muligt - det tager nok det værste, men der vil stadig være jokere når systemet skaleres på (= der sker mange mærkelige ting i halen af sandsynlighedsfordelingen).

  • 3
  • 1
Anne Mette Hass

Mortens beskrivelse af et it-projekt er desværre virkeligheden for alt for mange. Men beskrivelsen synliggør også præcis, hvad problemet er: ”Mit bedste råd er at finde nogle prøveklude der gider at teste koden…” skriver Morten.
NEJ – det er alt for sent og misbrug af testere! Testere og folk med faglig indsigt skal arbejde i dybden med kravene og vigtigst af alt - teste disse, inden kodningen går i gang.
Lad os prøve at sammenligne det, vi gør i dag i it-branchen, med bygningen af et hus:
Den kommende husejer hyrer en arkitekt, og siger til hende, at han godt kunne tænke sig et hus med de og de værelser, bl.a. et køkken. Husejeren beskriver, at når han laver morgenmad, tager han brød, ost og æg ud af køleskabet, han koger ægget og sætter det i et æggebæger, og mens det koger, laver han en ostemad. Han laver også en kop kaffe. Desuden kan han godt lide rødt, så nogle af køkkenlågerne må gerne være røde.
Arkitekten udarbejder tegninger, både grundplaner og snit af rummene, og hun laver også en 3D fremstilling af køkkenet. Husejeren gider dog ikke se på tegningerne, der er alt for mange streger og tal, og han regner med, at det har håndværkerne nok styr på. Håndværkerne kommer og laver huset med køkken og det hele. Undervejs har husejeren bedt nogle bekendte kigge efter om det nu også er godt nok. De synes det ser nogenlunde ud, men foreslår lidt ændringer her og der ud fra deres smag og erfaringer.
Husejeren kommer og kigger. Han er noget utilfreds med køkkenet. Godt nok er nogle af lågerne røde, men resten er gule, og det kan han bestemt ikke lide. Der er et køleskab, men der er ingen fryser. Til gengæld sidder der en flot espresso-maskine indbygget i væggen; det synes han er helt overgearet, for han drikker som regel bare Nescafe.
Ikke særlig realistisk, vel? Men sådan gør vi, når vi laver it-projekter. Forventningerne til systemet bliver ikke ordentlig gennemarbejdet og alt for meget overlades til udviklere med for sen involvering af testere. Brugerne (læs: relevante interessenter) kan ikke forstå kravene, er argumentet. Vel kan de så! Brugere er ikke dummere end andre. Hvis forventningerne bliver udtrykt, så de kan forstås af brugerne og af udviklerne, og sådan at det kan eftervises om de er opfyldt, og hvis brugerne tager det fornødne ansvar, kan udviklingen ske på et meget mere sikkert grundlag – og det gælder både for store ’vandfaldsprojekter’ og for agile projekter.
I byggesager bruger de fleste kommende husejere meget tid på at diskutere tegninger og alverdens valg (f.eks. farver på køkkenlåger) med arkitekten, og under opførelsen vil en eller flere med byggefaglig forstand føre løbende tilsyn med, hvordan byggeriet skrider frem og hvordan det passer med tegninger og beslutninger. De fleste ansvarlige arkitekter har også en medarbejder, der gennemgår tegningerne for fejl undervejs.
Dvs. at både grundlaget for byggeriet (kravene og arkitekturen) og selv huset (system) testes løbende undervejs af byggefaglige (udførende testere) under kyndig ledelse (test manager). Sådan skulle it-projekter være. Testere skal involveres fra den første dag, ikke klistres på, når koden er skrevet (når lågerne er malet og det ikke længere er muligt at få plads til en fryser). Og de udførende testere skal ledes af en veluddannet test manager. Så undgår vi overarbejde, udbrændte testere og utilfredse kunder og brugere.

  • 4
  • 1
Morten Andersen

Hej Anne, vi kan godt blive enige om at grundig test er en god ting. Men jeg skrev jo ikke at testerne først skulle på banen sidst i forløbet - i mine øjne skal de i gang så snart første funktion virker. Derudover var min pointe, at uanset hvor professionel en test det er, så vil der alligevel være alle mulige fejl der dukker op i produktion. Fejl som ingen test (uden bagklogskabens klare lys) ville kunne fange, fordi de først viser sig ved skalering med en faktor 10-100.000x -- enten fordi tilfældene er meget usandsynlige eller fordi de er direkte afhængige af høj load m.m.
Jeg har endnu ikke set et eneste projekt hvor det ikke har været tilfældet. Jeg vil næsten påstå, at hvis det sker, så har systemet været for simpelt :D

Det er også argumentet for at undgå "big bang" migreringer - så hellere flytte en bid ad gangen og holde det gamle system i live lidt tid, så man har mulighed for fall-back.

Desuden er real-life test vigtigere end syntetisk test.

Jeg er da også enig i at det er hovedløst at gå i gang uden at forstå eller gennemtænke kravene. Men der er altid en bagside: For meget snak om detaljer i starten er "dyrt" (i tid og penge), og indebærer en risiko for at man i sin design og test fokuserer på en masse detaljer der egentlig ikke har den store betydning og grundlæggende er ret simple - mens der er gabende ladeporte andre steder, som man først alt for sent får hul på. Så er jeg mere stemt for at starte med at kode hurtigt, og så hurtigt som muligt få skidtet til at møde virkeligheden i en eller anden form.

Men som altid, alt med måde, og den optimale proces afhænger også af kompetencer og erfaringer for de enkelte medlemmer af udviklerteamet :)

  • 2
  • 0
Anne Mette Hass

Hej Morten,

Vi kan hurtig blive enige om, at uanset hvor dygtige og professionelle testere er, vil der altid være fejl, der først findes i produktion; dels fordi testere også laver fejl, dels fordi en 100% test er umulig, og endelig fordi en stor del af fejlene stammer fra manglende eller på anden vis dårlige krav, og det kan selv super-testere ikke kompensere for.

Min pointe er, at testere skal på banen, så snart den første user story skrives, ikke først når koden er skrevet; det er for sent.

Det er en myte, at det er for dyrt at gennemarbejde krav! Det koster 100-1000 gange (eller mere) så meget at rette fejl under test, som under kravarbejdet, eller også, hvis man ikke vil betale for sene rettelser, må man nøjes med et ringere produkt end man kunne have fået.

De samme fejl (ladeporte) bliver ved at komme igen og igen, fordi man ikke lærer af sine fejl – anden forklaring kan jeg ikke lige få øje på.

Vi må leve med, at ingen mennesker kan lave perfekte systemer; men det skal vel ikke forhindre os i at prøve.

  • 2
  • 0
Morten Andersen

Jeg tror grundlæggende vi er enige angående test.

Ang. krav, så er det jo et spørgsmål om hvor meget man gennemarbejder og om man fokuserer på det rigtige. Det vigtige er at de store ting er på plads, og ikke så meget præcis hvordan et skærmbillede ser ud.

Hvis kravene når op på 1000 sider er det projekt erfaringsmæssigt dømt til at gå helt galt (a la Rejsekortetsty eller Statens lønsystem).
Så er der brugt for mange penge på at penge på en masse ligegyldigt krav ud, og projektet vil ende i det rene dødvande på at implementere dem (og ofte vil der alligevel mangle noget i kravene).

Det er lidt som med ying og yan, der skal være lidt af det hele. Hvis udviklerne kører i fri dressur, kan det hurtigt gå galt og kunden vil ende med noget ustabilt som han ikke vil have.

Men der skal også være 'spræl' i et projekt, ellers går det galt - og bliver med sikkerhed dyrt og forsinket, og det vil alligevel lide af de børnesygdomme som jeg nævnte i første indlæg. Sygdomme som man paradoksalt nok ville forvente at den omfattende kravproces var garant for at man undgik, men som den rent kan forårsage, idet udviklerne drukner i detalje-krav så der ikke er tid (og ånd) til "polish".

  • 1
  • 0
Mark Gjøl

Spol tiden frem til 1 måned før levering: Alle sidder med poser under øjnene fordi de har arbejdet hele natten. Udviklerne sidder febrilsk og kigger på lange traces, kigger kode og suser rundt i debuggeren for at finde den obskure fejl - og som ender med at blive løst af et hack eller to der aldrig bliver skrevet ned noget sted.

Den har jeg set før - og prøvet. For mig at se er problemet mere dårlig projektledelse end dårlige udviklere. I sidste ende er det projektlederen (eller nogen over ham) der skal lave en realistisk tidsplan. Som man ofte hører det fra vores gange:" Jeg udvikler ved et konstant tempo, du må bare vælge hvordan jeg skal prioritere det". Hvis udviklere sidder og kæmper til langt ud på natten, så er det fordi der ikke er givet ordentlig tid til projektet. Det værste eksempel jeg har været ude for i et tidligere job har været afdelingslederen der spurgte projektlederen om hvornår vi var færdige. "Fredag". Afdelingslederen satte følgeligt afleveringen til onsdagen før, hvorfor vi måtte arbejde i døgndrift, og endda klare opdateringer fra et middlewarefirma efter midnat om onsdagen.

  • 1
  • 0
Morten Andersen

Hej Mark, jeg er enig i det ofte skyldes dårlig ledelse. Men jeg synes især mønstret ses ved projekt der skal køres "efter bogen", d.s. efter nye smarte metoder som nogle projektledere har lært på diverse kurser. Ofte indebærer det regneark der med "komplicerede" (sic) formler hele tiden regner ud hvornår projektet er færdigt med sandsynlighedsfordelinger osv. Jeg tror den slags skaber en form for manglende ydmyghed i.f.t. de ting der rent faktisk skal til for at levere til tiden - og i høj kvalitet.
Programmer bliver ikke udviklet i regneark men ved udviklernes skrivebord. Ethvert program indeholder noget af den pågældende udviklers 'ånd'. Det er bare ikke så populært at snakke om, for projektledere vil hellere se det som en lang liste af tasks, der i princippet kan sendes i hovedet på og udføres af hvem som helst.

Min egen filosofi er at holde det simpelt, og at bruge resourcerne på nogle få meget dygtige udviklere der 90% af vejen er deres egne projektledere, i stedet for mange dårligere (eller evt. mange dårlige projektledere).

  • 1
  • 0
Anne Mette Hass

Hej Morten,
Måske er vi enige om test, men jeg tror ikke vi er enige om, hvordan man bedst udvikler et IT system. Du skriver:

"Men der skal også være 'spræl' i et projekt, ellers går det galt" og
" bruge resourcerne på nogle få meget dygtige udviklere"

som om projekterne er til for udviklernes skyld. Det er de ikke. De er til for de kommende brugeres og produktejeres skyld.

Udviklerne er håndværkere, der skal være gode til design og programmering, men ikke gøre sig kloge på, hvad brugerne har brug for.

Jeg har været på et projekt, der blev lukket før det blev færdigt og efter at der var brugt adskellige millioner Euro, fordi en 'klog' programmør ikke vidste noget om brugerne (astronomer, der skulle regne på mange observationsdata fra forskellige observationspunkter) og deres behov, og heller ikke var interesseret. Programmøren var super til at lave optimerede algoritmer, men det havde i den sidste ende ingen betydning. Hvad ved folk, der har gået på DIKU i 3- år om f.eks. hvordan tingbøger virker, eller hvordan dagligdagen er på et hospital. Ikke noget som helst. Og svage projektledere lader sådanne udviklere få alt for meget frirum.

Man ville ikke sætte en murersvend til selv af lege med, hvordan en mur skal være. Hvis han har lyst til at lægge stenene på den anden led eller lige lave et rundt vindue et sted uden at det er aftalt med kunden, skal mester nok få sat en stopper for det.

De dygtigste udviklere er dem, der kan forholde sig respektfuldt til de brugere, de betjener.

Vi må også leve med, at mennesker er forskellige og at der skal være arbejde til både de, der er naturtalenter, de der er almindelige, og de der har lidt svært ved det, men kommer igennem. Der er måske få virksomheder, der kan skumme naturtalenterne, men de er trods alt i mindretal.

Det er på tide den danske IT-branche bliver professionel.

  • 0
  • 3
Rune Larsen

Der hersker en tyrkertro på, at hvis bare kravspec er god, så skal projektet nok gå godt. Men det er fløjtende ligegyldigt, hvor detaljeret og præcis kravspeccen er - vandfaldsudvikling ender ALTID som Mortens beskriver, med poser under øjnene, udskudte deadlines og skuffede kunder.

Der er altid en prioritering af, hvilke dele af et it-system, der bør bruges penge på at udvikle eller forbedre. Men alle forudsætningerne for den prioritering ændrer sig løbende - især hvad de forskellige ting koster. Jo længere tid i forvejen man estimerer en udviklingsopgave, jo dårligere bliver estimatet.

Typisk er det sådan, at nogle features nærmest bliver gratis efterhånden som man bygger systemet, mens andre arkitektonisk viser sig kontrære og bliver meget dyre at bygge og vedligeholde. Disse løbende erfaringer skal med i prioriteringsprocessen for hvad der skal laves!

Der er kun en løsning: Iterativ udvikling. Levér en feature af gangen og sørg for fra start, at få bruger-feedback-cyklussen op at stå. Brugerfeedback er vigtigere end de layout- og stavefajl, som professionelle testere typisk finder. Professionelle testere kan finpolere systemet, men det er aldrig dem, der gør projektet til en succes.

  • 3
  • 0
Morten Andersen

Anne Mette Hass, du drager helt forhastede konklusioner. Du citerer mig (korrekt) for "Men der skal også være 'spræl' i et projekt, ellers går det galt" og "bruge resourcerne på nogle få meget dygtige udviklere", men tilføjer så at "som om projekterne er til for udviklernes skyld. Det er de ikke. De er til for de kommende brugeres og produktejeres skyld."

Du kan da overhovedet ikke udlede jeg skulle mene projektet var til for udviklernes skyld.

Når jeg skriver at der skal være plads til spræl, er det jo netop fordi projektet ellers går fuldstændigt galt. Det er ikke fordi jeg ønsker at tage hensyn til udviklerne overhovedet - men det kan vel ikke overraske at de to ting følges ad?

Hvis udviklerne blot skulle arbejde 100% efter en 1000-siders specifikation efter din "klassiske" model (taget til ekstremerne), så vil de ikke brænde for arbejdet (=> lav produktivitet), og vil ikke kunne hjælpe dig med at stoppe de fejl og uhensigtsmæssigheder der uundgåeligt er i kravene. Changes bliver også enormt tunge at estimere og få igennem.

Det er det jeg mener med 'spræl' - specifikationen skal være tilpas udetaljeret til at der er plads til noget "common-sense" manøvrerum.

Jeg har set flere vandfaldsprojekter der fulgte ALLE metoder, og endte med 100 siders krav og 1000 siders specifikation. Alle som endte som >1 mia. fadæser der var forsinkede, dyre og i elendig kvalitet. Det du skriver lyder måske godt for en offentlig chef i teorien (total control paradigmet), men er en fin opskrift på hvordan et projekt går helt galt.

  • 3
  • 0
Anne Mette Hass

Jeg synes ikke, jeg på noget tidspunkt har fremhævet en vandfaldsmodel?

Min pointe er, at der er mange faktorer, der spiller sammen for at få succes med et IT-projekt; programmørernes motivation og bidrag er en af dem, men, efter min mening sjældent direkte afgørende. Uden god projektledelse, god konfigurationsstyring, godt gennemarbejdede krav, godt design, og effektiv test går det ikke godt.

Og det gælder for alt fra det tungeste vandfaldsprojekt til den mindste og mest agile projekt.

  • 0
  • 0
Per Michael Jensen

hvor forskellen mellem brugernes verden og udviklernes viser sig, er når fundne fejl klassificeres. Jeg har flere gange oplevet at udviklerne fandt en fejl ret ubetydelig, men brugerne mente at den væltede deres verden. Omvendt har jeg også set fejl som udviklerne fandt væsentlige, men som ikke betød noget for brugerne.

Kommunikation mellem udviklerne og brugerne er essentiel for at få det bedst mulige ud af projektets ressourcer. Men læg mærke til at det skal være de reelle brugere på det pågældende niveau, man snakker med.
Kunderepræsentanten eller den udpegede domæneekspert ved det ofte ikke, og spørger sjældent de rigtige brugere, men gætter i stedet - og det er mere fatalt end når udviklerne gør det!

Man skal huske at specifikationerne er testerens facitbog. Gode specifikationer er grundlaget for en grundig test. Uden facitbogen er testeren langt hen ad vejen nødt til at gætte, og så er vi lige vidt igen!

Mht. projektledelse er det ikke udviklingsmodellen der er problemet. Det går galt når projektlederen bruger al sin tid på administration, fedte med tidsplanen og rapporter til ledelsen, i stedet for at opsnuse og løse problemer, før de når at vokse sig store.

  • 0
  • 0
Anne Mette Hass

Hej Morten,

Jeg har tænkt meget over det, du har skrevet , bl.a.

"Det er det jeg mener med 'spræl' - specifikationen skal være tilpas udetaljeret til at der er plads til noget "common-sense" manøvrerum"

har du evt. nogle eksempler på sådanne situationer, hvor udviklernes "commen-sense" har givet ekstra udbytte i et projekt? Det kunne være interessant at lære af, tror jeg.

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