Agil: Slår dig (nok) ikke ihjel

Der er noget Bent Jensen ikke har forstået.

I hans seneste replik lægger han mig den påstand i munden at agil ikke virker og kører derfra ud af alle mulige tangenter og ender i rindalisme.

Det er præcis den totale mangel på respekt for fakta hos agil-missionærene jeg opponerer imod: Store armbevægelser der intet har med virkeligheden at gøre.

Min kritik har naturligvis intet med Rindalisme at gøre: Jeg ikke er en imbecil maskinarbejder der udtaler mig om kunst jeg ikke forstår, jeg er internationalt anerkendt kunstner der udtaler mig om kunst jeg selv praktiserer.

Hvis vi skal have en sammenligning, er det med den "naturmedicin" og de "slankepiller" der annonceres bag i dameblade og hustandsomdelte reklamepublikationer.

Hvis man har lavet en ny medicin, er der tre spørgsmål man skal have afdækket:

  1. Hvad er skadevirkningerne ?

  2. Virker det overhovedet ?

  3. Hvor godt virker der ?

Jeg er villig til at give Bent Jensen at punkt 1 er overstået, der er ingen relevant LD50 værdi for agil udvikling, SalesForce er her f.eks stadig.

Men præcis som alle "helseprodukterne" findes der intet faktuelt materiale der svarer på punkt 2 og 3[1].

Hurra-historien fra SalesForce fortæller os kun at der er ét får i Skotland der ser sort ud, set fra den ene side[2].

Selv om man tilføjer flere sådanne hurra-historier, øges vores viden blot til at de er flere får i Skotland der ser sorte ud fra den ene side.

Hvis punkt 2 skal besvares, skal der laves sammenlignende forsøg med placebo.

Hvis punkt 3 skal besvares skal der laves sammenlignende forsøg med andre metoder.

Præcis som for slankepillerne findes disse resultater ikke, for det kræver tid og penge at gennemføre.

Den korrekte markedsføring for agil udvikling er derfor den samme som for helseprodukter:

"Agil: Slår dig (nok) ikke ihjel."

Men parallelen til "helseprodukterne" stopper ikke her:

Det er nemlig videnskabeligt bevist, at kalkpiller, eller andre placebo[3], virker imod de fleste livsstilssygdomme.

Virkningen er at den daglige pille minder patienten om at de har et problem, hvilket påvirker deres livsstil i gavnlig retning.

Det svarer fint til min oplevelse af agil: Den eventuelle gavnlige effekt er alene at minde folk om at software udvikling er svært, hvad som helst andet der minder dem derom, vil virke lige så godt.

Skal jeg overbevises om andet kræver det dokumenteret statistisk signifikans fra veldesignede sammenlignende studier.

En annonce, hvor Bent Jensen påstår at have fået det meget bedre af at spise en "Agil" hver morgen det sidste halve år, overbeviser mig kun om at man kan tjene penge på at sælge agil.

phk

[1] EU har afvist over 80% af alle "health claims" fordi de er udokumenterede: http://www.bbc.co.uk/news/10240263

[2] Gl Vittighed: En Ingeniør, en matematiker og en statistiker er på vej til Edinburgh med tog og ser en flok får hvoraf et er sort. Ingeniøren siger "Nå, de har også sorte får i Skotland". "Nej" siger matematikeren, "vi ved kun at de har mindst ét sort får i Skotland", hvorefter statistikeren påpeger "Vi ved kun, at der i Skotland er ét får der ser sort ud, set fra den ene side".

[3] Placebo fås nu også i dobbelt styrke.

Kommentarer (44)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Anonym

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.

  • 0
  • 0
#3 Bent Jensen

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.

  • 0
  • 0
#4 Anonym

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.

  • 0
  • 0
#5 Henning Makholm

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).

  • 0
  • 0
#7 Anonym

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 :)

  • 0
  • 0
#9 Bent Jensen

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

  • 0
  • 0
#11 Henning Makholm

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?

  • 0
  • 0
#12 Thomas Søndergaard

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?

  • 0
  • 0
#13 Bent Jensen

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.

  • 0
  • 0
#14 Poul-Henning Kamp Blogger

Hvis "reklamen" for Agil havde overskriften "En rimelig metode" ville jeg nok ikke have brokket mig over det overhovedet.

Men det er ikke sådan Agil bliver (over-)solgt.

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/community/FullrateVaerdiskabendeUdvikling.pdf)

Ja, Go Dav Do!

Det handler om at det C-Team der blev installeret i Cybercity da Klaus solgte det, ikke anede hvad der var op og ned og derfor gik ud og smed et tre-cifferet millionbeløb efter en "billing & provisioning platform" fra et eller andet udenlandsk firma der også var vertikalt uorienteret.

Memo til Full-rate: Man har ikke "sparet en formue" bare fordi man undlader at smide den væk, lige så lidt som jeg har sparet en halv million menneskeliv ved ikke at angribe Moskva med en hær.

Hvis vi skræller Fullrate historien helt ind til benet, har de en udviklingsafdeling på 8-10 kompetente mennesker, der får lov til at definere og løse opgaven bedst muligt, uden unødvendigt eller uønsket PHB input.

Hvor svært er det lige at få det til at lykkes ? Havde de været lidt mere til S/M kunne de også have fået den mest rigide version af vandfaldsmodellen til at virke med samme gode resultat.

Men uha nej, det var agil der sparede et treciffert millonbeløb.

Eller prøv at skil det ad, som Bent siger ovenfor:

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.

"meget lidt overhead" (Sammenlignet med hvad ?)

"opnår struktur og fokus" (Hvor meget ? Sammenlignet med hvad ?)

"korte feedback cykler" (Hvor meget kortere ? End hvad ?)

"styr på regressionsproblemer" (--//--)

Det er rent reklamegas:

Ny!

Bedre!

Forbedret!

Nu med 25% ekstra!

Det suger så meget at man bliver helt tør i halsen og mine veninder skal også have det godt når jeg bringer Werthers Echte ind i legen.

BVADR!

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".

Læs f.eks i "The Bug Heard Around The World" hvorledes den første rumfærge ikke kom op, fordi en p=1/65536 initialiseringsfejl aldrig var kommet op i deres automatiske regression-tests.

Allerede omkring 1960 var der artikler om hvorledes "automatisk test" blev brugt til at undgå regressionsfejl i software.

Jeg vil faktisk påstå, at man er inkompetent som softwareudvikler hvis man ikke anvender automatisk test og inkompetent som leder hvis man lader sine udviklere lade være.

Når vi skræller alt reklamegasset af Agil, ender vi med noget jeg er villig til at kalde "en rimelig metode der (nok) ikke slår dig ihjel".

Indtil nogen dokumenter, ved videnskabelig sammenligning, at de 150 mand i en eller anden Banks IT afdeling der bruger Agile metoder måleligt producerer bedre, billigere og hurtigere, end de 150 mand der ikke gør, er det hvorledes agil bør sælges.

Poul-Henning

[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.

  • 0
  • 0
#15 Jørgen Asmussen

[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.

  • 0
  • 0
#16 Thomas Søndergaard

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.

  • 0
  • 0
#17 Poul-Henning Kamp Blogger

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.

Er vi så ikke også enige om, at det vi taler om er fundamental mangel på kompetance til at begynde med ?

Så er vi sådan set hjemme hvor jeg startede: Agile metoder er gammel vin på nye flasker...

Der er mange der overser at i perioden 1995-2000 exploderede IT branchen med en faktor 10-100.

Alskens overløbne sporvognsførere og tidligere hønsefangere fik job hvis bare de kunne finde ud af at smide ti liniers Perl Cgi script sammen.

Det er ikke en urimelig påstand at Dot-Com boblen satte IT som håndværk 10-20 år bagud.

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

Det er fint at vi er ved at indhente noget af det tabte, det skal jeg være den første til at approbere.

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

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 ?

Eller burde vi tage hele Mythical Man-Month med, også de dele som agil-præsterne ikke har fattet rækkevidden af ?

Poul-Henning

  • 0
  • 0
#18 Carsten Sonne

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-...

  • 0
  • 0
#20 Thomas Ammitzbøll-Bach

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

  • 0
  • 0
#21 Carsten Sonne

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.

  • 0
  • 0
#23 Poul-Henning Kamp Blogger

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?

Man kan med fordel bruge et eller andet mantra som mentalt fokusobjekt for denne øvelse. F.eks et lille skilt på skrivebordet hvor der står "THINK" :-)

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.

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å ?

Eller hvad med "Det eneste der er værre end at generalisere fra ét eksempel, er at generalisere fra slet ingenting"

Poul-Henning

  • 0
  • 0
#24 Carsten Sonne

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.

  • 0
  • 0
#25 Thomas Søndergaard

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.

  • 0
  • 0
#26 Michael Rasmussen

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.

  • 0
  • 0
#27 Anonym

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.

  • 0
  • 0
#29 Thomas Ammitzbøll-Bach

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

  • 0
  • 0
#30 Björn Sveinbjörnsson

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

  • 0
  • 0
#31 Lasse Reinholt

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.
  • 0
  • 0
#32 Henrik Schmidt

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?

  • 0
  • 0
#35 Rasmus Pedersen

"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?

  • 0
  • 0
#36 Jesper Louis Andersen

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".

  • 0
  • 0
#37 Henrik Schmidt

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.

  • 0
  • 0
#39 Henrik Schmidt

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.

  • 0
  • 0
#40 Michael Rasmussen

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

  • 0
  • 0
#42 Carsten Sonne

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.

  • 0
  • 0
#43 Bjarke Walling

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 ..."

  • 0
  • 0
#44 Carsten Sonne

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.

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