Agil udvikling er reaktiv og resignerende

I de gode gamle dage, da vi lavede software efter vandfaldsmetoden, var problemet altid at præmisserne ændrede sig undervejs, så den store forkromede plan man havde lavet up-front på hele processen, var forældet inden man nåede at gå igang.

Derfor gav det virkelig god mening at sætte fokus på forandringerne i en udviklingsproces. Det er vigtigt at kunden er manøvredygtig på markedet og kan justere i forhold til efterspørgsel og konkurrenter; Man bliver klogere undervejs; Vi troede kunden kendte deres eget domæne, men det gjorde de ikke; Nye situationer opstår, og nye behov fødes; Nogen ting kan man ikke forstå, før man sidder midt i dem; Kunden skal altid have nyt ERP system midt i anden nyudvikling; Misforståelser sker mellem mennesker i to forskellige verdener: Domæneeksperter og softwareudvikler taler ikke samme sprog. Ja, og sådan kan man blive ved.

Ud af det opstår fænomenet: agil udvikling. Det er et forsøg på at imødekomme forandringens problem, ved at formulere en praksisform, der er indrettet således at man kan håndtere ændringer undervejs i processen. Det er jo ikke alene sympatisk, men bestemt også en nødvendighed. Det kan vi godt blive enige om.

"Responding to change over following a plan", Manifesto for Agile Software Development, http://agilemanifesto.org/

Alle praksisformer i agile metoder handler om at reagere. Det er i min mening en fuldkommen resignation overfor det der egentlig er en stor del af softwareudviklerens fag: at skabe domænet sammen med kunden. Med agil udvikling vælger vi at betragte kunden og domænet som en black box: Vi kan sende beskeder ind, og så kommer der en respons ud. Stop.

Vi sidder som i skolegårdens leg, og venter på at de andre smider bolden over muren, og skal gribe den inden den rammer jorden. Vi bliver reaktive idet vi henfører årsagen til alt det vi gør til noget uden for os selv, og vi hensætter os selv i et afmagtsforhold til det der ændrer sig.

Derfor er det agile kun en del af historien. Det er givet at ting ændrer sig. Det skal vi kunne indstille os på. Men det betyder ikke, at vi skal undlade at undre os, undlade at prøve at forstå os på den verden vi skal modellere. Nej, vi skal være pro-aktive og risikovillige, og gå ind på kundens domæne med træskostøvler. Vi er ikke bare tilskuere der skal opsamle information. Den sværeste del af vores arbejde er, at være med til at skabe det område vi skal modellere med software. Vi skal ikke kun forstå og beskrive.

Vi prøver at lave et sprog med kunden, så vi fremover forstår hvad vi siger til hinanden, og vi udveksler dokumenter hvori vi forsøger at beskrive med fælles terminologi, hvad det er vi vil. Det bruger vi også tid på inden vi går igang med det tekniske. Hvorfor? Fordi det er en del af at skabe domænet. Omvendt, ved vi godt at vi ikke kan skabe og beskrive noget endegyldigt og så implementere dette, så samtidig ruster vi os til at være lette på fødderne, så vi kan indrette os efter de ændringer der kommer.

Det agile som dominant praksis er resignation, det er softwareudviklingsselvmord, og det er stærkt reaktivt. Vi er bedre end det og behøver ikke give op, inden vi er gået igang, og blot sidde og gribe tilfældige bolde. Vi er medvirkende i at udforme domænet og det skal vi være bevidste om og tage ansvar for. Vi skal være pro-aktive og tage styringen, for det os der har erfaringen, og det er vores fag.

Så lad os degradere det agile, pille det af tronen, og give plads til alle de andre praksisformer, der også er vigtige i softwareudvikling sammen med det agile, såsom handlen, undren, skabelse, beskrivelse og fokusering. (Mere om dem i senere posts)

Læs også præsentationsartiklen af Joachim Lykke Andersen

Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jesper S. Møller

Med frygt for at bryde ind i en længere tanke- og artikelrække ved at nitpick'e for tidligt: At kalde den agile tilgang til tingene for reaktiv er da en misforståelse af rang.

Hvis du som virksomhed eller organisation ser IT som et nødvendigt onde for at agere imod omverdnen, så er det dén indstilling og taktik, der er reaktiv. Hvis du i stedet bruger IT mulighederne til at skabe værdi på nye måder, på at "forstyrre" den herskende orden, kan man vel næppe kalde det "reaktivt", blot fordi du angriber det agilt.

Hvis du vælger at implementere dine strategiske IT tiltag på den klassiske vandfaldsmåde, som ikke kan eller vil tage højde for ændringer undervejs, så kan det godt være at du får udviklet det tiltag, du havde specificeret -- men hvis verden har ændret sig imens har du tabt din strategiske fordel.

Mit gæt er at laaangt de fleste "disruptive" projekter/produkter/virksomheder, der skyder op i disse år og udfordrer den gamle verden, arbejder agilt, om de kalder det eller ej. Ikke for at være reaktive, men fordi det er den fremgangsmåde, der skaber de hurtigste resultater. Selvfølgelig kan man også se det modsatte, f.eks. når den offentilige sektor innoverer, men de har jo lissom også et monopol at beskytte sig under...

"Reaktivt eller disruptivt" er dit "hvad", "agilt eller vandfald" er dit "hvordan". Fokusér på at gøre de rigtige ting!

  • 0
  • 0
#3 Marc de Oliveira

Jeg er helt enig med din pointe om at Agile metoder som udgangspunkt er reaktive, og at de ikke tillader udviklingsgruppen at danne sig den nødvendige forståelse for de problemområder, som de arbejder med. Men jeg mener at du er for hurtig til at afvise vandfaldsmodellen. Det er en meget udbredt misforståelse at vandfaldsmodellen fastlåser udviklingsforløbet. I hver fase af vandfaldsmodellen forsøger man at danne sig det bedste overblik over, hvad der skal arbejdes med i den næste fase. Ja, man kan sige, at man udformer en plan, hvilket hjælper til at skabe en forståelse for hvad og hvor meget arbejde der ligger forude, men det betyder ikke at vandfaldsmodellen er i opposition til Agile Manifestet om "Responding to change over following a plan". Det er en misforståelse, at det at man planlægger arbejdet med problemdomænet betyder, at man ikke kan erkende fejl, mangler og ændrede behov på et hvilket som helst stadie i vandfaldsmodellen. Det er meget muligt, at mange leverandører ofte vælger at bruge resultatet af analysefasen til at fastlåse en kontrakt om pris og leverancetid, men det er ikke en nødvendighed i vandfaldsmodellen. Analysefasen resulterer i den aktuelle viden om hvad der er behov for. Hvis man senere erkender at man tog fejl eller at behovene har ændret sig, er der ikke noget i vejen for at lave "laksespring" op ad vandfaldet for at rette præmisserne. Afhængigt af hvor sent erkendelsen indtræffer og arten af ændringen kan man skulle rette i implementationen, designet eller analysen. Det er selvfølgelig billigere, hvis der er opstået ændrede behov til måden systemet er blevet implementeret, end hvis de ændrede behov er så fundamentale, at de kræver ændringer i analysen. Uanset hvad situationen måtte være, tillader vandfaldsmodellen at man griber ind på den billigst mulige måde, og får tilpasset planen til de aktuelle behov. Som jeg ser det, skyldes de problemer, man oplever med vandfaldsmodellen at leverandører og kunder ikke er modne nok til at erkende at der kan opstå behov for ændringer i løbet af projektet, og at den oprindelige plan sandsynligvis vil skulle tilpasses efterhånden som projektet skrider frem. Det betyder at priser og tider vil ændre sig - uden at projektet af den grund er forfejlet. En del af disse problemer kan afhjælpes vha risikostyring, men det handler i bund og grund om modenhed og virksomhedskultur hos både leverandør og kunde (også når leverandøren er intern).

  • 0
  • 2
#4 Nicolai Møller-Andersen

Der er gode ting i agil udvikling, men der er også masser af problemer. Nogle af de mere oversete er, at man aldrig kan vide, hvad men ender med, hvornår det er færdigt, eller hvad det koster. Jeg oplever, at der i praksis er stor risiko for resignation. Udviklerne rammes simpelthen så tit af gennemgribende forandringer, at de holder op med at interessere sig for domænet og bare tager hovedet under armen. De af os, som har været med et stykke tid, læser blot endnu en bog, som udråber en metode til at være løsningen. YASB. Yet Another Silver Bullet. Måske må man indse, at skabelse af ny software er en kreativ process, og som sådan kan processen kun med besvær beskrives i overordnede termer og slet ikke i detaljer.

  • 0
  • 0
#5 Klaus Enevoldsen

Nogle af de mere oversete er, at man aldrig kan vide, hvad men ender med, hvornår det er færdigt, eller hvad det koster.

Hvis man allerede ved hvordan "noget" skal være, så er det vel at sammenligne med en masseproduktion. Der er pr. definition en masse usikkerheder omkring et udviklingsforløb, da det jo er et udviklingsforløb. :-)

Desuden er jeg ikke enig i at man aldrig ved, hvornår det er færdigt eller hvad det koster. Der findes gode metoder, man kan bruge til at estimere dette.

  • 1
  • 1
#6 Joachim Lykke Andersen

@Jesper S. Møller

Jeg mener ikke at det er en misforståelse. Umiddelbart så taler jeg ikke om det du betegner som "hvad", men kun om dit "hvordan". Det jeg siger er, at når det agile bliver den altdominerende faktor i indstillingen til softwareudviklingsprocessen, så har man tendens til i softwareudviklingsprocessen at blive reaktiv sit forhold til domænet.

@Bjørn Reese

Jeg kan ikke med sikkerhed sige hvordan præcis SEMAT adskiller sig fra de ting jeg beskæftiger mig med, men jeg kan sige at det er stærk relateret. Mit sigte er at arbejde hen imod et softwarefilosofisk grundlag for softwareudvikling, og det lyder unægteligt en del som SEMAT der dog har en mere videnskabelig ordbrug. Vores mål lyder som det samme, men indgangsvinkel nok lidt forskellig.

@Marc de Oliveira

Min pointe er skam ikke at afvise vandfaldsmodellen. Der er ting der traditionelt opfattes som vandfaldsmodel-aktiviteter og der er ting der opfattes som tilhørende det agile, men jeg er tilhænger af en inklusiv model, hvor vi finder sprog og ord for at kunne skabe en proces der favner det vi har brug for i en given kontekst, som kan komme flere steder fra.

  • 0
  • 0
#7 Thomas Watts

Arkitekten stikker lige hovedet frem og hæver (reklame)flaget :)

Hvis man ikke ved, hvor man vil hen, er metoden sgu ligegyldig. Powerpoint-platitude javist, men sand.

Planlægning på forhånd eller drypvis - begge tilgange (eller andre, nye) er med stor sandsynlighed dømt til at fejle. I større eller mindre omfang.

Det handler om at få styr på forretningskonteksten og se projektet ud fra det nuværende, og det ønskede. IKKE for projektet isoleret, men for forretningen og dette specifikke projekts plads i denne.

Dette er ikke en disciplin, forretningen historisk er specielt god til. Ej heller udviklere fra et ellers nok så kompetent team.

Giv et kompetent team noget at pejle efter, snarere end bud på sandheden eller "vi finder ud af det undervejs". SÅ er det straks noget andet. Giv dem endda ressourcerne til at påvirke projektet i en retning, der bedre sikrer det, forretningen ønsker at kunne om X år, ja så er jeg en glad mand.

Men hvis dette fundament ikke er på plads - det retningsangivende - så ender vi igen og igen i disse rodløse projekter.

Det er ikke metoden der er noget galt med. Jeg har kørt masser af både vandfalds- og agile projekter fra de helt små til de 3-cifrede millionbeløbs ditto - begge tilgange er fine, så længe man ikke følger dem slavisk, men tilpasser dem virkeligheden i projektet. Men i sig selv kan de ikke rette op på den mangel det er, at alt, alt for få projekter er forankrede i forretningen, og at selv hvis denne forankring er der, er der sjældent tænkt mere end et år eller så frem.

Så igen - der er intet i vejen med agil udvikling. Heller ikke vandfalds (selvom jeg hellere vil sidde med agil metode i en forretningskontekst, hvor der ikke er styr på retningen, må jeg sige).

Der er noget i vejen med, at man tror, udviklingsmetoden er bestemmende for, om et projekt lykkes i en forretning.

  • 3
  • 0
#9 Kim Hansen

"Alle praksisformer i agile metoder handler om at reagere." Jeg ser ikke manifestet som grundlaget for al agil udvikling. Manifestet er en række værdier, som nogle mennesker syntes var vigtige at fremhæve på det tidspunkt.

Der står heller ikke noget om "agile metoder". Agile metoder er den praksis der kommer ud af det, når man forholder sig til værdibegreberne i manifestet. Der findes sikkert mange agile metoder blandt os udviklere, som ikke virker særlig godt. Men man er jo fri til at finde på nogle bedre. Jeg kan ikke få øje på noget i manifestet eller principperne, der modarbejder ordentlige eller fornuftige metoder.

At pille en enkelt linje ud, og i øvrigt se bort fra vægtningen mellem de 2 modsætninger, er nok en overfortolkning.

Jeg har meget svært ved at se modsætningen mellem agil udvikling og begreber som "handlen, undren, skabelse, beskrivelse og fokusering". Det lyder lidt som en gentagelse af diskussionen fra dengang manifestet blev offentliggjort. Manifestet er jo ikke et blue-print til den perfekte udviklingsmodel, med svaret på alt.

Selveste meningen med livet kan også opsummeres i få simple værdier, selvom det også kan være vanskeligt i praksis: "Try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations." ;-)

  • 0
  • 0
#10 Joachim Lykke Andersen

@Kim Hansen

Det kan være citatet er mere forvirrende end godt, for du hænger dig i hvert fald for meget i det. Min kommentar handler ikke om det agile manifest alene, men om alt der gør det agile som omdrejningspunkt i en metodik. Citatet og det agile manifest er tænkt blot som et eksempel.

Det er netop det at sætte det "at være agil" som omdrejningspunktet i en metodik, som jeg anfægter, idet det at være agil ikke bør stå alene som et kerneprincip, fordi det gør teamet reaktivt frem for pro-aktivt. Så jeg mener ikke vi skal tænke, at vi skal lave en metodik der favoriserer agilitet for enhver pris, men som er inklusiv over for andre aktiviteter og værdier, der spiller en afgørende rolle i softwareudvikling.

Der er ikke nogen modsætning mellem agilitet og handlen, undren, skabelse, beskrivelse og fokusering, som du skriver: det som jeg ser det grundlæggende fundamenter i softwareudvikling som kan leve sammen med såvel agilitet som andre indgangsvinkler.

  • 0
  • 0
#11 Joachim Lykke Andersen

@Thomas Watts

"Der er noget i vejen med, at man tror, udviklingsmetoden er bestemmende for, om et projekt lykkes i en forretning."

Det du skriver er rigtigt, for det jeg oplever er at succesfulde teams netop ikke abonnerer komplet på nogen eksisterende metodik. Simpelt hen fordi der ikke er nogen enkeltstående metodik der er god nok til at favne et projekt i den virkelige verden.

Men det er også en falliterklæring. For hvis ikke sigtet med en metode er, at hjælpe udvikleren med at få succes med projektet, så kan vi jo lige så godt droppe metodikken.

Så det jeg mener vi har brug for er, at vi kan trække os et niveau op, få sat ord på de værdisæt/dikotomier der er i et projekt, og parre dem op med en række aktiviteter og praksisser som vi kan tilpasse organisationen og projektet, således at vi kan få en model der i praksis tjener os til at blive bedre til at afvikle projekter. Det skal være et redskab, og ikke et abonnement på et buzzword.

Så kan man sige, ok lad os droppe metodikken, når succesfulde teams alligevel finder ud af det. Det har bare den ulempe, at det er rigtigt svært for teams der ikke er succesfulde, at lære fra mere velfungerende teams. Hvis vi kan tage de ting, som gør et team succesfuldt i en given kontekst, og sætte ord og proces på det, så kan andre i samme kontekst måske lære noget. Derudover er det også rigtigt svært at tale om det vi gør, og lave nogle af de mere finkornede forbedringer. Vi kan heller ikke formidle det vi gør til ledelse og kunder, med henblik på at opnå tillid.

  • 0
  • 1
#12 Jens Rasmussen

Hvad er din definition af agilitet?

De ting, som goer (agile) teams mere succesfulde er netop agile teknikker, men det er ikke nok at sige 'Vi er agile/forandringsparate'. Der er faktiske teknikker der kan goere et team bedre, de er bare noget mere specifikke, men hoerer under paraplyen agilitet. Her mener jeg fx. XP teknikker som pair programming, code review, unit testing/test-first, iterativ udvikling osv. At folk saa ofte ikke maa/kan/gider bruge flere af disse teknikker betyder ikke at agile teknikker ikke virker.

  • 0
  • 0
#13 Thomas Watts

@Joachim Lykke Andersen

Nu skal jeg passe gevaldigt på med, hvordan jeg formulerer det her... det er VIRKELIG ikke ment fornærmende eller som et forsøg på at slå på tromme for mit fag, men som et seriøst bud på, hvad jeg ser som kernen i "problemet" - så prøv at se det som et forsøg på et konstruktivt indspark, for jeg kommer nok til at træde på nogle tæer nu :D

(med "problemet" mener jeg temaet her i blog post'en om, at udviklingsmetode er god/dårlig til at sikre succes ift. forretningen.)

Problemet er ikke metoderne. De er lavet til at styre et projekt. Det kan de gøre ganske glimrende.

Problemet er projektteams bestående af en projektleder og et udviklingsteam, der tror, at de kan forstå forretningen. (Det hjælper sandelig heller ikke, at forretningen ofte ikke aner, hvad den vil).

Et projekt bestående af folk, der har til opgave at lave en bestilt løsning inden for deres felt.

Det er forbandet svært at udføre det arbejde, et sådant projektteam udfører. Det kræver alle ens ressourcer at levere et godt produkt og styre (eller samarbejde med - afhængig af modenhed) en kunde. Jeg har rasende respekt for dygtige udviklere og dygtige projektledere - har arbejdet sammen med masser af folk, jeg har næsegrus beundring for på det område.

MEN hvis man har taget hele sin uddannelse i dette, har sin erfaring hér, og lægger al sin tid i det i projektet, hvem er det så, der leverer de forretningsmæssige rammer?

Disse er (i min optik) i langt de fleste tilfælde udslagsgivende. Hvis forretningen og projektet er på lavt kompleksitetsniveau, er dette ikke det store problem. Men det er jo ikke dén slags projekter, vi taler om, når vi diskuterer en metodes fallit eller ej - det er de højkomplekse projekter der sætter tingene på spidsen.

Så for denne type projekter... hvad er rammerne? Hvad styrer man efter ift. forretningens strategi koblet op på teknologier i markedet nu og kommende, samt den totale it-portefølje og forretningsprocesser, der berører projektet nu og i de kommende måneder/år?

Jeg vil vove den påstand, at hvis disse rammer leveres, så kan et godt projektteam i LANGT højere grad navigere forretningens usikkerhed. Og så er det langt mindre vigtigt, hvilken metode man benytter til udvikling/styring internt i projektet - bare man kan den, og kan tilpasse den.

Pointen er, (relativt) kort sagt, at udviklere og projektledere ofte er blinde for, at de faktisk ikke er uddannet til at finde, sætte og navigere disse forretningsmæssige rammer. De er pissedygtige til at arbejde med materien INDE i rammerne, men uden andre kompetencer til at sætte rammerne, er der høj risiko for problemer, når der opstår ændringer i kundens organisation, behov, eller bare ved at projektets fremdrift får det til at gå op for kunden, hvad de egentlig har bestilt, og hvad det betyder for deres forretning.

Og nej det er ikke elfensbenstårnsrapporter. Det er ikke nogget der tager svimlende med tid at lave. Men det er svært at sætte kroner og ører på for en kunde, og derfor efterspørges det sjældent. Jeg ved godt, at der har været tilfælde med idiotisk verdensfjern arkitektur, og at det er et yndet skudsmål for min "art" :) Men ligeledes har der været masser af verdensfjerne udviklingsprojekter - så lad os holde os til at se potentialer, og ikke enkeltsager og "sådan er det", ok? ;)

Gav det mening? Jeg prøver på min egen forkvaklede måde at sige, at man ud fra sin profession prøver at slå større brød op, end man kan bage. At diskussionen har forkert afsæt. Udviklingsmetode er til udviklingsprojektet. Dette projekt styres i en STØRRE ramme, og sorry, men den er hverken udviklere eller projektledere generelt set uddannet til at sætte. Men de tror, at udviklingsmetoden ER denne ramme. Og når det så går galt, kigger de kritisk på metoden, for det er dertil, deres verden går (og INTET forgjort i det. Men man ser jo verden ud fra det ståsted, man har).

Puha... håber, det tages som et positivt ment indlæg...

  • 2
  • 0
#14 Thomas Watts

Måske er det i virkeligheden problemet med agil udvikling.

At det tidligere netop udstilles, at man ikke har styr på rammerne? Og så søger man (som du siger) at reagere på denne forståelse, som et vandfaldsprojekt først opnår senere... men stadig uden at have de rette rammebetingelser til at gøre noget reelt ved det.

  • 0
  • 0
#15 Marc de Oliveira

Thomas, du har fuldstændig ret i, at det er et kærneproblem at få rammen på plads, og at det sandsynligvis er vigtigere end hvilken udviklingsmetode man vælger.

Men artiklen handler nu engang om valget af udviklingsmetode, og hvad dette valg (Agile) gør ved projektforløbet, så din argumentation er lidt fejlplaceret i denne sammenhæng. Jeg er i al fald uenig med dig, hvis din holdning er, at valget af metode er ligegyldig. Den metode og virksomhedskultur, som du underlægger et projekt, har meget at sige i forhold til, hvilket system du ender med at få lavet.

  • 0
  • 0
#16 Deleted User

Jeg har særdeles vanskeligt ved at genkende det billede du beskriver Joachim. Og jeg anerkender ikke at der er en sammenhæng mellem agile udviklingsmetoder og manglende udvikling af domænet i samarbejde mellem kunde og udviklere. Hvor kommer dette blik fra? Det er ikke foreskrevet af principperne som agile udviklingsmetoder baseres på.

I de 12 principper bag det agile manifest (http://agilemanifesto.org/principles.html) angiver forfatterne tydeligt, at: "Business people and developers must work together daily throughout the project" og "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation". Dette mere end antyder, at nært samarbejde og direkte kommunikation mellem kunde og udviklere er en nødvendighed.

  • 1
  • 0
#17 Thomas Watts

Jeg har ikke formuleret mig helt klart, kan jeg se... nej det er ikke det, jeg mener, Marc.

Ja artiklen handler om udviklingsmetoder ift. at styre i en usikker kontekst. Og det er også det, jeg prøver at addressere :)

Min pointe er i forhold til artiklen, at man imho prøver at opløfte udviklingsmetoden til noget, den ikke er eller skal.

Man sætter udviklingsmetode op som noget, der kan kompensere for manglende rammer, hvis bare det er den rette metode.

Surprise - det kan man ikke :)

Og så retter folk skytset på det eneste, der var synligt i projektet (i mangel af rammer) - udviklingsmetoden.

Så når artiklen handler om valg af udviklingsmetode, er det min påstand, at dens afsæt er forkert. For man skal ikke tage sin metode til indtægt for, at forretningen ikke er med. At diskutere, hvad man skal gøre med agil metode eller andet, for at rette op på hele verdens manglende evne til at sætte rammer, er ikke "fair" mod udviklingsmetoden :)

  • 0
  • 0
#18 Marc de Oliveira

Men Thomas, når man sammenligner Agile-metoder med Vandfaldsmetoder, så må du da være enig i at Vandfald har væsentlig mere fokus på at forstå domænet end Agile, idet de første to faser handler om hhv Strategi og Analyse. Ergo må man gå ud fra, at man ved at vælge vandfaldsmetoden, alt andet lige, vil ende med en bedre forståelse af domænet, inden man kaster sig ud i programmeringen. Argumentet for at vælge Agile frem for Vandfald angives ofte at være, at forretningen ikke selv ved, hvad den vil, og derfor er man nødt til at programmere nogle prototyper så tidligt som muligt, i den forventning, at disse er nemmere for forretningen at forholde sig til. Jeg er stor tilhænger af iterativ programmering (det var jeg også inden man kaldte det Agile), men, som du, mener jeg også, at en grundig analyse af problemdomænet er nødvendig inden man begynder at programmere. Jeg er derfor begyndt at agitere for hvad jeg kalder "Agile Waterfall" (eller "Structured Agile"), hvor man arbejder efter Vandfaldsmetoden under strategi-, analyse- og designfaserne, men programmerer efter Agile principper med korte leverencer.

  • 0
  • 0
#19 Deleted User

Undskyld at jeg er kommet lidt sent til festen, det kan godt være den allerede er slut. Men jeg har lige læst Joachims blog og alle kommentarerene i rap, og det slår mig at der er da et eller andet i hele præmissen for denne blog som halter:

Det agile som dominant praksis er resignation, det er softwareudviklingsselvmord, og det er stærkt reaktivt.

Det skinner tydeligt nok igennem at @Joachim ikke har haft så meget held med sine agile projekter, men der er vel egentlig ikke emperisk belæg for at gøre den subjektive betragtning til grundlag for den slutning, at kundens vidensdomæne bliver ladt i stikken når man arbejder agilt?

...Altså, vi har fine erfaringer med agile metoder.

Der er nogle åbenlyse forudsætninger, som bør være på plads før man kaster sig ud i agile metoder. Men at skyde efter det forhold at noget ikke lykkes når man bruger en given metode, afslører måske blot at forudsætningerne ikke er på plads - at der er noget man har misforstået simpelthen.

@Martin beskriver det sådan set meget godt i sit svar.

DSDM, som er én af mange agile metoder arbejder f.eks. med et suitability filter, i en vis udstrækning kan man vel også vælge at læse agile manifesto som et sådan filter: "hvis ikke du bekender dig til pricipperne, så vil du ikke lykkes med agil udvikling ...prøv noget andet i stedet".

Når jeg læsr den her blog kommer jeg til at tænke på udtrykket:

"Hvis det eneste værktøj du ejer er en hammer, så ligner alle problemer et søm".

For lige at tage den metafor lidt længere (end den måske kan bære), så er det da klart at man får en dårligt oplevelse hvis man kæmper med at save et bræt over ...med en hammer.

Men det er jo ikke hammeren der er problemet i den ligning.

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