Agil: Slår dig (nok) ikke ihjel

Jeg har hørt den vittighed med en astronom, en fysiker og en matematiker. Mig bekendt er statistikere ikke mere pain-in-the-ass end matematikere..

Tja. Jeg ved ikke helt, hvad vi diskuterer, men altså. Det er fint nok at have nej-hatten på, det er der sikkert nok også brug for.

Jeg vil nu gå et skridt videre (?) og sige:

"Enhver rimelig metode er bedre end ingen metode."

Jow, rimeligt kommer an på så meget. Et eksempel på en ikke-rimelig metode kunne være at slå alle verdens jøder ihjel, for så bliver det hele nok meget bedre.

Det stærke ved en metode er, at man gør tingene på nogenlunde samme måde igen og igen. Det giver i sig selv en række fordele.

Jeg tror for det første "man selv har det godt" (og trygt) ved at kende fremgangsmåden (og sin rolle) - det giver luft til andre ting. Det må være en fordel at dele et begrebsapparat og en nogenlunde fælles måde at se tingene på, men dem, man laver dem sammen med. For det andet, og vigtigt, så giver det også omgivelserne en lettere forståelse af, hvad der foregår - og de kan regne med at næste gang, så foregår det nogenlunde ligesådan. For det tredie så giver det mulighed for at sammenligne (måle, veje, justere) i forhold til sidste gang.

"Agile"-metoder over en bred kam forekommer mig at være rimelige metoder, fordi der er basisværktøjer nok til at lære at gøre tingene på en ensartet måde, og der er luft nok til at være et almindeligt (nogenlunde) rationelt tænkende og kreativt menneske.

Det er jeg meget enig I. Den første fordel ved agile metoder, og visse andre, er at man med meget lidt overhead opnår struktur og fokus i arbejdet. Efter min erfaring kommer det ikke af sig selv, selv om der er tale om nok så kompetente udviklere. Der er så en række andre fordele ved netop agile metoder, såsom korte feedback cykler, og styr på regressionsproblemer med automatisk test.

Glemte lige, den der pille-metafor generer også lidt ... det er nu noget lettere at guffe en pille, end det er at indføre en metode. Derfor stemmer jeg altså for, med henvisning til mit forrige indlæg, man kommer ind i kampen, og napper en metode. Og ikke står på sidelinjen, og venter på det "endelige videnskabelige resultat". Spis løs.

Enhver rimelig metode er bedre end ingen metode.

Det kommer jo gevaldigt an på hvad man forstår ved [i]både[/i] "rimelig metode" og "ingen metode".

Hvad synes du fx om PHKs foretrukne metode: (1) Man tager en lille gruppe virkelig kompetente udviklere, som er motiverede nok til hver især at føle ansvar for hele det færdige produkt, og stoler nok på hinandens evner til at dette ansvar ikke fører til at de giver sig til at mikromanage indbyrdes. (2) Så beder man dem om at lave sådan-og-sådan et produkt. (3) Profit!

Jeg kan forestille mig at mange vil opfatte dette som "ingen metode". Men hvis man har ingredienserne til at gennemføre den, virker den konsekvent bedre end enhver anden metode udført uden PHK-ingredienser.

Det stærke ved en metode er, at man gør tingene på nogenlunde samme måde igen og igen. Det giver i sig selv en række fordele.

Hvis man gør det samme igen og igen, får man den samme kode ud af det. Vil det så ikke være en smartere metode bare at sørge for at have en backup af det sidste projekt, som man kan trække frem i løbet af en halv times tid?

Det der kendetegner udvikling er at man gør [i]nye[/i] ting, fordi krav og mål er anderledes end sidste gang man gjorde noget. Og nye ting er nødvendigvis på nye måder. Ting man gør på nøjagtig samme måde fra gang til gang er en [i]svaghed[/i] i processen, fordi de burde have været automatiseret eller genbrugt. (Hvilket naturligvis er en grov overgeneralisering, fordi det ikke er alt automatiserbart der kan betale sig at automatisere. Men det betyder ikke at mængden af hjerneløst automatiserbart men ikke-automatiseret arbejde man udfører er noget at prale af).

Der er så en række andre fordele ved netop agile metoder, såsom korte feedback cykler, og styr på regressionsproblemer med automatisk test.

Sådan et udsagn er meningsløst uden en angivelse af fordele I SAMMENLIGNING MED HVAD?

Hvad synes du fx om PHKs foretrukne metode: (1) Man tager en lille gruppe virkelig kompetente udviklere, som er motiverede nok til hver især at føle ansvar for hele det færdige produkt, og stoler nok på hinandens evner til at dette ansvar ikke fører til at de giver sig til at mikromanage indbyrdes. (2) Så beder man dem om at lave sådan-og-sådan et produkt. (3) Profit!

Er det "metoden" i sin fulde længde? :) Bliver ikke så meget klogere, synes jeg. Det lyder da meget sødt - sådan lidt fluffy-hippie-agtigt. Jeg lærer mere om "metoden" ved at vide, at det er "PHK's metode", end at læse ovenstående punkter i hvertfald :)

Er det "metoden" i sin fulde længde? :)

Jeg burde nok ikke have udtalt mig så udtrykkeligt på PHKs vegne, men det var ihvertfald hvad jeg fik ud af hans forrige blogindlæg.

Spørger du om hvad fordelen er ved korte feedbackcykler er i forhold til korte? Det er at man hurtigere opdager problemer af en enhver slags - tekniske, usability og bugs.

Eller Automatiske test skrevet og vedligeholdt af udviklerne, i forhold til ingen automatiske test? Det medfører at visse typer feedback bliver meget langsom. f.eks den feedback man får når en ny version er i driftt hos kunden, og man opdager et problem, som skal løses ASAP

Hvor er det nu at vi har den videnskabelige dokumentation for PHK metodens effekt? Jeg har personlig set at punkt 1,2 være opfyldt uden at det medførte 3.

Spørger du om hvad fordelen er ved korte feedbackcykler er i forhold til korte?

Nej. Jeg tror korte feedbackcykler giver akkurat samme resultat som korte.

Du påstår at "agile" mirakelpillen giver fordele. Jeg påpeger at dette udsagn ikke giver mening uden at du specificerer hvilken behandling eller ikke-behandling du sammenligner din pille med. Det er kategorisk meningsløst at tale om "fordele" uden at gøre det i relation til en konkret sammenligning.

Eller Automatiske test skrevet og vedligeholdt af udviklerne, i forhold til ingen automatiske test?

Påstår du hermed at det eneste mulige alternativ til at følge et eller andet "agile"-evangelium er ikke at have automatiske tests?

Der er noget Bent Jensen ikke har forstået.

Det han ikke har forstået er at det ikke kan betale sig at diskutere med dig. Du er alt for god til at få din modstander til at ligne en lallende idiot. Selv vil jeg derfor aldrig rode mig ud i noget med dig, men jeg vil da gerne komme med nogle forsigtige spørgsmål! Det er bare spørgsmål og den slags må jo som bekendt gerne være dumme, så gå efter dem og ikke mig.

1) Mener du vi ville være bedre tjent med udelukkende at benytte os af metoder og produkter som er videnskabeligt beviste? (Der kan nok føres et induktivt bevis for at vi aldrig ville have været i stand til at tørre os selv i måsen, hvis vi mennesker havde fulgt en sådan regel)

2) Er den måde du udvikler software på baseret på videnskabelige beviser, eller følger du din erfaring?

3) Er al din viden om software-udvikling empirisk, eller har du kan-ske lyttet lidt til hvordan andre kloge mennesker har gjort tingene?

4) Vil du ikke anerkende at metoder i software-udvikling i stor udstrækning handler om at formidle erfaringer?

Jeg mente naturligvis korte feedback cykler i forhold til lange.

Påstår du hermed at det eneste mulige alternativ til at følge et eller andet "agile"-evangelium er ikke at have automatiske tests?

Jeg har ikke talt om noget evangelium. En vigtig del af de fleste fornuftige agile metoder er at have automatiske test. Hvis man har automatiske tests det eneste, er man alt andet lige bedre stillet end hvis man ikke har. Så enkelt er det.

[1] Da jeg var på MacDonalds "papirdug" kunne man læse at hvis man spiste en stor salat og drak en halv liter mælk, fik man sit daglige behov for kalk dækket. De gjorde sig ikke engang umagen med en fodnote til at fortælle at MacDonalds ikke solgte mælk.

De sælger nu godt nok 1/4l mælk som man ka vælge i stedet for til sit happy meal f.eks.

Jeg er i store træk enig med dig her, men din kommentar nedenfor er lidt et selvmål.

Men det allerbedste er det "rimshot" der kommer til sidst: "... med automatisk test". Det kan man da kalde at smykke sig med lånte fjer[1]: Automatisk test har nul og nix at gøre med "Agil".

Det skal ikke anfægtes at automatiserede tests er en gammel idé, men det er de adrætte metoder, og måske endda deres jubel-idiotagtige/glade entusiasme, som har gjort dem så udbredte som de er idag. Det er jeg ikke i tvivl om.

Hed agil udvikling da jeg blev uddannet. Det stod i kontrast til etablerede metoder som vandfaldsmodellen. Andre metoder som RUP og RAP var på den tid 'hot'.

Der findes forsvinde lidt videnskabelig forskning om udviklingsmetodiker. Det er stadig et umodet område inden for IT og et slaraffenland for heksedoktorer.

Georg Strøm havde her på version 2 for nogle uger siden et ganske interessant blogindlæg: Kunsten at lære af fejltagelser i projekter [*]. Det skitsere tydeligt hvad agile udvikling ikke kan. Desværre sælges agil udvikling netop som kur mod den slags problemer.

[*] http://www.version2.dk/artikel/16100-kunsten-at-laere-af-fejltagelser-i-...

Hvor i Georg Strøms indlæg finder du belæg for at man ikke kan lære af sine fejltagelser når man anvender agil udvikling??

Jeg vil hellere stille tre andre spørgsmål:

1) Er de 12 praktikker i agil udvikling dårlige?
2) Er agile metoder nye?
3) Er agile metoder en garanti for succes?

Ad 1) Nej! Jeg har set en del projekter, der er røget i hegnet og en del projekter, der er sluppet rimelig heldigt afsted. En meget stor andel af dem, der er røget i hegnet, forbrød sig mod over 9 af de 12 praktikker. Af dem, der gik godt, var hovedparten udviklet under en form, der lænede sig godt op af de agile principper.

Ad 2) Nej, de er ikke nye! De er observationer af noget, der er set virke. Det er masser af gammel vin, som er sat på (nye) flasker og fået etiket på. Men det er heller ikke mit indtryk, at f.eks. Kent Beck påstår, at han har "opfundet" eXtreme Programming. Derimod er der nok en del naive disciple, som tror, at agile metoder er noget nyt og fancy.

Ad 3) Nej, der er ingen garantier for noget. Parprogrammering hjælper ikke, hvis begge programmører er nogle paphoveder. Unit tests duer kun, hvis man ikke forstår, hvad og hvorfor man tester. Planlægningsspillet er spild af tid, hvis der ikke er tillid mellem kunde/aftager og teamet. Man kan sidde med alle de fine principper og praktikker og lave noget værre 10rt, hvis man reelt ikke kan programmere. De fire dødssynder i agil udvikling er: Inkompetence, løgn, mistillid og procesdyrkelse. Det er desværre også de mest komplicerede at pille ud af folk.

Ca. en gang om året sidder jeg og ser TV-shop. Jeg bliver altid fascineret af alle de fine mirakelprodukter og alt det gas, der bliver sagt om dem. Specielt fitnessmaskiner er helt utrolige. Men når alt kommer til alt, så er det kun de fitnessmaskiner, der bliver brugt, der gør en forskel. Hvor mange mennesker i din omgangskreds kender du, der har købt det helt store kit, fordi de faldt for en reklame på TV, men som ikke har rørt det siden 14 dage efter købet?

Sådan er det med agile metoder (og alle andre metoder): Hvis du vil skrive bedre software, så kig på dine (u)vaner og spørg dig selv: Hvad kan jeg træne mig selv til at gøre til en bedre vane? Gør så det i fire uger, og se om ikke den nye vane har hjulpet. Så kan du tage fat på den næste (u)vane.

Agile metoder er ikke et mirakelmiddel. Det er (som alt andet, der virker) lidt instrukser og så ellers bare hårdt arbejde. Der er ikke noget, der kommer af sig selv.

Thomas

Hvor i Georg Strøms indlæg finder du belæg for at man ikke kan lære af sine fejltagelser når man anvender agil udvikling??

Ingen steder. Min pointe var netop at de to ting er korrelerede: Fejlslagne projekter kan ikke reddes med agil udvikling.

Unit tests duer kun, hvis man ikke forstår, hvad og hvorfor man tester.

Det blev noget vrøvl. Der skulle have stået: Unit tests duer kun, hvis man forstår, hvad og hvorfor man tester.

Paphoved!

Thomas

Lav altid en prototype og sørg for at smide den væk, det ender du med under alle omstændigheder med at gøre, også hvis du leverer den til kunden.

En udpræget misforståelse består i at betragte et udviklingsprojekt som endeligt forstået før man går i gang. Med mindre man har laver præcis det samme projekt før, så er et udviklingsprojekt et læringsproces. Selv i elektronik branchen, hvor vandfaldsmodellen er udbredt, er virksomheder begyndt at interessere sig for f.eks. SCRUM.

At projekter stadig udbydes med færdige kravspecifikationer på op til hundredvis af sider med en dertil hørende detaljeringgrad, viser hvor udpræget misforståelsen er.

Georg Strøms indlæg om projektledes burde med tydelighed vise hvor vigtig en del af et projekt 'ledelse' er. Forudsætningerne for projektet og den ledelse hvormed projektet udføres, dikterer i høj grad muligheder for success.

Agil udvikling virker på mig som endnu et slag i luften i et forsøg på at løse overstående 2 problemer. Jeg benytter selvsamme principper i en erkendelse af at en vandfaldsmodel er ubruglig. Om det kaldes agil udvikling, RUP, SCRUM eller noget helt 4. virker på mig relativt uvæsentligt.

Igen er jeg enig med det meste, omend jeg ikke er bekendt med at der skulle være grund til kritik af Linus håndtering af udviklingen af Linux-kernen.

Men det pisser mig af at det præsenteres som noget nyt og fantastisk der er sket for nyligt.

Helt enig, men jeg er ikke sikker på at de er noget vi skal skyde metoderne eller deres fædre i skoene. Det skyldes den irriterende groupie-mentalitet, der er i vores branche.

Og hvis vi endelig er kommet igang med at undervise nytilkommerne i IT håndværk, er det så dette mismask der kaldes "agil" vi skal bruge ?

Dyrkelsen af agile metoder er for mig at se ikke anerledes eller mere skadeligt end den måde vores branche i det hele taget håndterer nye ideer (eller gamle ideer på nye flasker). Se på XML, web-services, SOA eller det sidste nye - Cloud Computing. En masse ting der virker fint bliver konstant lavet om efter årstidens modefarve, uden de på den måde bliver det mindste bedre.

Det er latterligt.

Den værste fejlopfattelse jeg er støt på, er den, at agil udvikling kan substituere systemudviklingsmetoder. Agile metoder er i min optik en måde at styre og lede systemudviklingsprocesser, men har intet at gøre med det håndværk, der transformerer ideer til et program/system. Selve håndværket udvikles stadigvæk med hjælp fra de gammelkendte metoder og værktøjer, der blev udtænkt/skabt i perioden 1970-2000. Selvom bogen The Elements of Programming Style af Kernighan og Plauger er 30 år gammel, er indholdet stadigvæk lige relevant i dag.

Summa sumarum: Agile metoder hører mere hjemme i projektlederens værktøjskasse end i programmørens.

F.eks var der et foredrag fra Fullrate om hvorledes de havde "sparet et tre-cifferet millionbeløbe" ved at bruge agil udvikling (http://version2.dk/annoncer/communi...) Ja, Go Dav Do!

Heh. Njah - nok lidt fri tolkning. Hvis du tror, Fullrate tror, at agile udviklingsmetoder er lutter-fed-lykke, og forklaringen på alt-success-i-verden, så bliver du nok lidt skuffet (eller glad?). Så naive ved jeg heldigvis, de ikke er.

Jeg ser ikke denne "hoved-under-armen-spiser-bare-mirakelpillen"-mentalitet, du snakker om. Agile metoder bliver oversolgt ligesom så meget andet. Hvis folk ikke kan forholde sig nuanceret til en metode, uanset hvad det er for en, så er man på spanden under alle omstændigheder. Det synes jeg også, jeg hører dig sige (hvis man lige blæser lidt i røgen). Er det så besiddelsen af denne egenskab, vi vil diskutere, eller brugsværdien af elementerne faktisk indeholdt i metoderne?

Jeg håbede, vi var kommet til punkt 2 på dagsordenen.

Den værste fejlopfattelse jeg er støt på, er den, at agil udvikling kan substituere systemudviklingsmetoder.

Hvis ellers Wikipedia står til troende, har det en ganske god artikel om udviklingsmetodik:
http://en.wikipedia.org/wiki/Software_development_methodology

Med hensyn til de 12 praktikker, så er det til at brække sig over at IT håndværk defineres af hvad der kan være på to standard slides i powerpoint helvede.

Jeg er uenig i det, du skriver; men jeg tror, at jeg er enig i det, du mener.

Problemet er nok i virkeligheden (powerpoint-) slides, og at vi kan gå til lækre konferencer og høre en masse "feel good"-budskaber. Så går vi hjem og tror, at nu kan vi alt, for nu har vi hørt profeten.

Som jeg skriver, er (agil) udvikling hårdt arbejde. Ikke alene det, det er arbejde, der kræver naturlige evner, lang erfaring og personlig disciplin. De tolv praktikker er lette at lære udenad og rigtig svære at lære "indenad". Det er som at sætte sig ved siden af en zen-munk og spørge: "Ku' du ikke lige fortælle mig, hvad zen er for noget? Kan jeg ikke lige få tolv praktikker til agil living?"

Hvad blev der f.eks af "Lav altid en prototype og sørg for at smide den væk, det ender du med under alle omstændigheder med at gøre, også hvis du leverer den til kunden." Var det ikke værd at gemme på ?

Det er da meget agilt, ikke? "Make the simplest solution, that could possibly work", "Refactor, when needed". Det virker for mig. Hvis jeg er i tvivl (nyt library, en løs ide) så skriver jeg en simpel snip, der gør et eller andet. Nogle gange smider jeg den væk, andre gange gemmer jeg den. Men den "overlever" sjældent i et projekt. Men det vigtigste er, at det bringer mig ud af et dødvande, hvor angsten for at "skrive med blæk" forsvinder.

Jeg så en gang en gammel bonde på TV, som drev landbrug på helt gammeldags maner. Han blev spurgt om, hvad han syntes om økologi. Jeg var ved at dø af grin, da han sagde: "Det er noget nymodens pjat. Jeg driver landbrug, som jeg altid har gjort!" Han var mere økologisk end de fleste, for han brugte ikke kunstgødning, sprøjtede ikke og brugte sin egen udsæd fra sidste høst. Men økolog ville han ikke kaldes. Er det ikke dig, PHK? Der er ingen, der skal kalde dig for agilist, selv om du er mere agil end de fleste?

Thomas

THINK-skiltet er en god ide. Bare det ikke bliver en ny (tom) metodik: Når jeg går i stå, så læser jeg mit THINK-skilt, og så sker der nok noget. :-P

Det er lørdag aften men for helvede. Når det snakkes om korncirkler vil jeg være med.

i Sverige har vi et meget godt navn for metode fanatikere. De kaldes RUP nisser. Nu er RUP ikke på catwalken men det lyder bedre end Agil nisser.

Jeg synes at denne metode fokusering er et symptom på at vi har fået en masse, og nu vil jeg bruge et formidabelt svensk ord, "Förståsigpåare". Altså mennesker det står på sidelinjen og har meninger om hvordan spillet skal spilles. De spiller ikke selv, siger at de gjorde det for mange år siden men har bare simpelhen ikke tid til det mere. Speciellt ikke efter MBA kurset.

Ah. Tilbage til fjernsynet og familjen og på mandag venter Emacs og en kop kaffe.

Hilsen fra Skåne,
/björn

Du er alt for god til at få din modstander til at ligne en lallende idiot.

For den dumme 3. part måske, lidt a'la Se&Hør, men ikke for den kloge, som nærlæser det ping/pong, der er i diskussionerne med ham (tag GodMode diskussionen eller den om, hvorvidt virtuel memory findes i pensum).

Med hensyn til agil udvikling, så er der vel projekter, hvor det egner sig, og projekter, hvor det ikke egner sig.

Et eksempel, hvor det ikke egner sig, er nok Microsoft Office.

Man kunne forestille sig, at man af tilfældighedens vej havde designet noget som:

Documents[a].Pictures[b].Page;

Men at man senere finder ud af, at man ofte har behov for at iterere gennem alle billeder på en given side, end omvendt. Altså Documents[a].Pages[b].Pictures

.  
   
Der skal temmelig omfattende ændringer til for at tilrette den slags i et produkt som Office, fordi objektmodellen er kollossalt stor, og fordi den skal have en langvarig bagudkompatibilitet, både internt og overfor VBA applikationer udviklet af andre.  
   
Så det er nok bedst med en meget lang og grundig problemorienteret analyse forinden.

Jeg er helt enig. Man kan ikke bruge alt det anekdotiske evidens til noget som helst. Derfor accepterer jeg heller ikke nogen som helst udviklingsmetode, som ikke har været igennem den samme stringente videnskabelige sammenligning, som man kræver, når der skal nye lægemidler på markedet.

Så er spørgsmålet: Hvilke metoder er der til rådighed, hvor dette er tilfældet?

Posterboy for denne DotCom regression kunne pasende være Linus Torvalds der brugte 10 år på at fatte hvad versionskontrol er godt for

Fnis, men du må da indrømme at han er kommet meget godt efter det...

"Posterboy for denne DotCom regression kunne pasende være Linus Torvalds der brugte 10 år på at fatte hvad versionskontrol er godt for"

Hvor kom Linus Torvald ind i agil billedet?

Så er spørgsmålet: Hvilke metoder er der til rådighed, hvor dette er tilfældet?

For omkring et år siden røg jeg i en diskussion omkring Test-Driven-Design, hvor det viser sig at der er et par papers:

http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-syndrome

Bemærk venligst at ObjectMentor har et farvet standpunkt omkring TDD.

Jeg læste et par af de papers og jeg var ikke specielt imponeret over behandlingen. Deres eksperimenter ville ikke gå på et statistikkursus kan jeg godt afsløre :)

Som regel vil du se "Case studies" i forbindelse med softwareudviklingsmodeller. Det er simpelthen fordi, det er umuligt at sætte et passende kvantitativt eksperiment op, med mindre du tager 200 studerende på indledende programmering som gidsler i et fag. "Case studies" er formentlig vel ment; man skal bare være opmærksom på at de fungerer bedst som kvalitative observationer og ikke som kvantitative ditto.

Der er desværre en tendens til at blande de to ting sammen. Så et case study bliver pludselig ophøjet til at have egenskaber som analyseformen slet ikke har. Det kommer til udtryk når et tilfældigt study, hvor en given metode var anvendt, bliver ophøjet til at denne metode virker i alle tilfælde.

Et interessant modtræk: Kan du finde et eksempel på et case study, hvor der anvendes metode X, og hvor studiet kommer frem til at metoden har gjort at projektet fejlede med et brag? Vel at mærke uden undskyldningen at "Teamet ikke praktiserede metode X rigtigt".

Takker. Jeg kigger på det.

Nu var det en sarkastisk bemærkning, så jeg kan ikke give et modeksempel. I bund og grund er der en ret stor mangel på publisering omkring eksperimenter, der ikke fungerede, i hvertfald indenfor andre områder.

...Men TDD er jo ikke projektstyring, så jeg efterlyser stadig nogle reelle undersøgelser på området, og bare at stikke mig 2*25 års tidskrifter og en påstand i fjæset synes jeg ærligt talt er lidt frækt. Jeg har dog forsøgt at søge, men fandt ikke noget brugbart. Jeg fandt ikke engang ud af, hvordan man søgte i Datamation, da det ikke længere eksisterer.

Måske dette er, hvad du søger:
http://www.brighthub.com/office/project-management/articles/67087.aspx

Hendes konklusion er, at det er et godt spørgsmål, hvilken metode er den bedste, og måske er det en blanding. Det er godt nok ret vagt.

Mit spørgsmål var egentlig: Hvilke metoder for projektstyring lever op til: "dokumenteret statistisk signifikans fra veldesignede sammenlignende studier."?

Hvis svaret er "ingen", som helt ærligt er min mistanke, hvordan kan man så nogensinde overbevise PHK om noget som helst? Hvor er dokumentationen for, at hvis man sætter 10 dedikerede mennesker ind i et rum og lader dem være i fred, så producerer de et lige så godt resultat? Og hvis der ikke er nogen dokumentation, der lever op til PHK's krav, hvordan er han så kommet til sin overbevisning? Anekdotisk evidens?

Er det i det hele taget rimeligt, at sammenligne med lægemidler, når PHK bagefter svarer, at man naturligvis ikke kan sammenligne?

Ærligt talt, så ligner det her bare en ganske almindelig flamewar, hvor den ene råber rindalist mens den anden råber religiøs fundamentalist.

Mit spørgsmål var egentlig: Hvilke metoder for projektstyring lever op til: "dokumenteret statistisk signifikans fra veldesignede sammenlignende studier."?

Som også kan læses af artiklens vage konklusion: Statistisk dokumenteret undersøgelse af projektstyringsmetoder findes ikke.

Den primære årsag til dette skal nok findes i følgende tre udsagn:
1) Ingen projekter er ens
2) Ingen projektgrupper er ens
3) Vurderinger af projektstyringsmetoder tager primært afsæt i subjektive holdninger

Vis mig én falsificerbar teori om en given udviklingsmetode. Det findes nok ikke... IT-udvikling er ikke en videnskab, så vi kommer nok ikke et svar nærmere. Diskutere kan man selvfølgelig altid.

IT-udvikling er ikke en videnskab, så vi kommer nok ikke et svar nærmere.

Hvad med psykologi, neurologi eller lingvistik? IT er både et håndværk og en videnskab. Endnu en relativt umoden af slagsen sammenlignet med de ældre langt mere etablerede videnskaber.

At sige noget er hævet over en videnskabelig tilgang og videnskabelige metoder for herefter at påpeje sandheden er blot et spørgsmål om holdning, er præcis hvad kendetegner religon, kvakksalveri og mirakelmagere.

Jeg mener at en diskussion af udviklingsmetoder hører under sociologi. Man kan lave visse interessante analyser i det fag, men eksakt videnskab er det ikke. Af den grund fremsættes tilsyneladende gyldige argumenter for modstridende hypoteser - typisk baseret på egne erfaringer og anekdoter.

Jeg synes hele diskussionen hviler på det forkerte præmis at vi på en eller anden måde kan afgøre hvad der er den/de rigtige udviklingsmetoder. Et mere korrekt svar er formentlig at "det afhænger af situationen ..."

Jeg mener at en diskussion af udviklingsmetoder hører under sociologi...

Jeg mener at viden om udviklingsmetoder og projektledelse bør baseret på videnskabelig forskning frem for "egne erfaringer og anekdoter".

Indtil da kan vi snakke i øst og vest uden vi får meget mere konkret viden ud af det.