Agil min bare ...

Vi sad for snart et års tid siden til et bloggermøde inde på v2 og Tine annoncerede at denne her "agil-minikonference" skulle løbe af stablen.

Min reaktion var et dybt suk med obligat "åh nej..."

Som advarsel til alle der måtte løbe ind i Tine, betød det at jeg pludselig var taler på den her agil-konference, som "devils advocate" og det blev til 10 slides, med fem hovedpunkter som Bent Jensen ikke har meget til overs for ovre på sin blog.

Bent ender med at fyre konvertitternes argument nummer 1 af: "Du ved ikke hvad det er, før du har prøvet det."

Gå en tur forbi den lokale katolske kirke eller Scientologys pengemaskine og de vil bruge det præcist samme argument af samme årsager: Forandring forandrer.

Alt hvad der er nyt føles bedre, det kaldes "retail therapy" af psykologer og i mere end 50% af tilfældene afløses det af "buyers remorse" depressionen, når det viser sig at forandring ikke er det samme som forbedring.

Men Bent tager fejl: Jeg har ikke brug for at prøve agil igen.

Jeg lavede agil udvikling sammen med Anna-Lena og Petur for 24 år siden og det fik Q8 et IDS system ud af.

Jeg lavede pair-programming for 21 år siden sammen med Jon i Italien, det fik Europa Parlamentet 200kB RAM ud af.

FreeBSD projektets første 5-7 år var Extreeme Programming, eller Scrum, afhængig af hvordan man vælger at se på det.

Og jeg var ansat i Dilberts firma i 1994.

Jeg har med andre ord været til koncert med alle de hippe indie bands, længe inden de blev berømte og lang tid før de begyndte at sælge T-shirts og authoriserede biografier.

En af grundene til at der er så mange atheister i IT branchen, er at den konstant overløbes af den ene nye religion efter den anden og folk hopper med på bølgen i håbet om evig frelse, seks nitaller og ro i helpdesken.

At Bent ikke kan finde en af dem jeg nævnte, "Evidence based Programming," på nettet, kunne skyldes at alle involverede skammer sig nok over ideens tomhed, til ikke at have importeret den i hyperspace.

Hvis jeg samlede et team på 7-8 mand, forklarede dem at nu skal vi prøve noget helt nyt, vi kunne f.eks kalde det "Virkelighedstro Programmering," ville jeg et á to år senere kunne udgive en bog om denne nye mirakelmetode, tage på konferenceturne, få et interview i et par aviser og stille mig op i rækken af mindre IT-profeter.

Faktum er nemlig, at en hvilken som helst metode, inklusive "vi bruger ikke metoder" virker for et lille motiveret team. Farven på hattene og forfatteren på den hellige bog er inderligt ligegyldigt.

En stensikker opskrift på success i software udvikling er en kompetent og inspirerende leder, med op til et dusin motiverede medarbejdere.

En lige så stensikker opskrift på fiasko, er at skalere en sådan success til en gros.

Jeg ville ønske at vi kunne koncentrere os om denne tilsyneladende eviggyldige sandhed og droppe alle de religiøse hatte.

Hvis vi havde samlet 12 kompetente programmører og en god leder og sagt til dem: I har et år til at gøre alle billetter i offentlig transport elektroniske, så havde vi været færdige for flere mia kroner siden.

Men når man skriver en kæmpe kravspecifikation og sætter hundredevis af folk på opgaven, så kan intet redde projektet, heller ikke T-shirts hvor der står "BEL if your are Agile."

phk

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

Jeg vil ikke gå dybere ind i denne diskussion, men det virkelige 'problem' er manglende evne til at omsætte (optimerede) foretningsgange til brugbar EDB.

Det har været det fundamentale problem de sidste 30+ år.

Når man hører 'salgstaler' om agil udvikling, tænker jeg først og fremmest på disse amatører, der ikke evner at sætte sig ind i forretningsgangene.

Man kan:
a) Sætte sig ind i forretningsgangene (aka foranalyse/detailanalyse)
b) kaste sig ræbende ud i uvisheden og prøve sig frem (agil/iterativ).

Skal man opnå en god performance (aka ROI) i et projekt, nytter det ikke, ikke at sætte sig ind i problemstillingen inden man kaster sig ud på det 'dybe vand'.

Alle disse discipliner var gammelkendt, og indarbejdet i 'det forsvundne atlantis', men det virkelige Y2K problem var, at ingen gad at fortsætte inden for EDB, da alle faldt for det latterlige Y2K-trick.

Jeg er blevet kaldt 'dinusaur fra fortiden' oma, og jeg tror squ jeg er den eneste 'overlevende' efterhånden.

Men fred være med det, vi overlader det trygt til 'prøv det selv folket'.

  • 0
  • 0
Poul-Henning Kamp Blogger

Stig,

Jeg er enig et langt stykke hen ad vejen, men der er tilfælde hvor det man har brug for er at smide hele den gamle tankemåde over skulderen og hvor en frisk start vil være meget billigere, end at gennemanalysere hvordan man nyimplementerer alle fortidens fejltagelser.

Rejsekortet f.eks.

Poul-Henning

  • 0
  • 0
Ole Østergaard

Men når man skriver en kæmpe kravspecifikation og sætter hundredevis af folk på opgaven, så kan intet redde projektet

Ja, dét lyder også virkelig som noget der kører efter Scrum-bogen...

  • 0
  • 0
Jesper Louis Andersen

Er håbet ikke igen at man har fundet den magiske silver bullet i softwareudvikling? Man har fundet den metode som tager middelmådige programmører, der er billige, og får dem til at, på magisk vis, kunne arbejde som de kompetente.

Håbet er så at du til stadighed kan holde status quo og ikke tage IT seriøst, for nu har du jo meto-DEN der sikrer effektiv udvikling; det på trods af at IT i moderne virksomheder til stadighed ikke er på lige fod med økonomi.

Agil softwareudvikling er helt sikkert velmenende. Men jeg bider mærke i at stort set ingen successfulde open-source softwareprojekter benytter sig af metoden eller skriver lange blogposts om hvordan deres softwareudviklingsmetode bragte dem på fronten. Det er formentlig fordi folk arbejder af egen lyst og har et professionelt syn på tilstandene. Dermed gælder PHKs regel: Kompetente folk kan altid tilvejebringe noget nyttigt. Og kompetente folk er ofte selvorganiserende langt hen af vejen.

Jeg har iøvrigt samme holdning til Test-Driven-Design, hvor Testmiljøet tages som gidsel så nogen kan tjene penge på deres silver bullet.

Jeg tror derfor at vi som IT folk, hvis vi vil opføre os professionelt, bliver nødt til at forholde os til at der til stadighed vil være religion i vores branche på den ene eller anden måde. Indtil basen i IT modnes tilstrækkeligt. Og det kan vist sagtens vare 50 år endnu!

  • 0
  • 0
Lars Lundin

"En stensikker opskrift på success i software udvikling er en kompetent og inspirerende leder, med op til et dusin motiverede medarbejdere."

Med den lille antagelse af lederen selv deltager i udviklingen, lyder det som "The surgical team" i den 35 årige klassiker, "The Mythical Man-Month".

Nye læsere kan starte her:

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

  • 0
  • 0
Palle Raabjerg

En af grundene til at der er så mange atheister i IT branchen, er at den konstant overløbes af den ene nye religion efter den anden og folk hopper med på bølgen i håbet om evig frelse, seks nitaller og ro i helpdesken.

I sandhed. Jeg kommer faktisk til at tænke lidt på det vi kalder programmeringsparadigmer (OOP, funktionel, imperativ, logisk, etc.), og hvordan der findes guruer inden for hvert paradigme der sværger til én type programmering frem for alt andet, som mener at "det er sådan verden bør se ud!!!".
Og det kan da virke overbevisende i nogen tid. Men når man så har brugt tid med forskellige typer programmeringssprog, finder man efterhånden ud af at også her fungerer verden i gråtoner. Programmeringssprog og de tilhørende paradigmer (af hvilke mange programmeringssprog trækker på mere end én) er som at have forskellige værktøjer der passer godt til forskellige problemer.
Og så kan man jo græde en stille tåre over at mange aldrig helt lader til at komme ud af den boks de har brugt alt deres tid på at indrette sig efter. Man burde vel i det mindste gøre et forsøg på et se nuancerne uden for boksen hvor man er ekspert.

Og så kan man jo stille spørgsmålet: Er vi ikke igen ved at lave en begrænsende boks der hedder 'agil udvikling' hvor vi stopper gammelkendte ting ind, og sætter det i system med fancy navne? Og skaber det indtryk at ting som ligger uden for boksen ikke er 'af det gode'.
'Agil' virker sikkert for mange firmaer. Men hvordan virker det? Trækker man pr. definition sine udviklingsmetoder mod 'noget godt'? Eller er det der i virkeligheden sker (der hvor det virker) at man trækker udviklingsmetoderne væk fra 'noget rigtig skidt'?
Er 'agil' i virkeligheden bare en undskyldning mange steder for at komme væk fra noget møg? :)

  • 0
  • 0
Poul-Henning Kamp Blogger

[...]lyder det som "The surgical team" i den 35 årige klassiker, "The Mythical Man-Month".

Ikke enig.

"The surgical team" er bare en måde at organisere en lille gruppe programmører på og den forudsætter en af dem er meget bedre end de andre.

Min påstand er at ethvert lille team kan bringes til at virke, stort set uanset hvorledes du organiserer det.

Poul-Henning

  • 0
  • 0
Jakob Simon-Gaarde

Jeg har det sådan med diverse procestunge "metoder" at det ejner sig godt nok til studiebrug, fordi det kan være en metode til at lære de studerende udviklingstankegange. Men når det kommer til den rigtige verden og når man har at gøre med mennesker som har programmeringserfaring, så er jeg klart tilhænger af mere effektive konsensusfremkaldende discipliner så som mockup, teknologidiagrammer og ikke mindst prototyper.

Firmaer kan alt for nemt drukne sig selv i processer, man bør forholde sig til hvad der er nødvendigt at dokumentere.

  • 0
  • 0
Slet Mig nu

Det minder mig on en analyse jeg læste om på et tidspunkt. Et antal slagteriarbejdere arbejder ved et bånd. Test 1 satte lystyrken op med 25% i forhold til normalen med bedre performance som resultat. Test 2 man satte lysstyrken ned med 25% i forhold til normalen med bedre performance som resultat. Moralen var at det afgørende for god performance var at management interesserede sig for arbejderene. Et lille team med gode folk kan lave mange gode ting uanset om du bruger processmodel 1 (hæver lysstyrken) eller 2 (sænker lysstyrken), sålænge den er relevant for teammedlemmerne.

Hvis du skyder dig selv i foden med at kræve store komplette kravspecifikationer m.m. så har du gjort det svært for teamet, men jeg har nu hellere ikke set en agil procesmodel som kræver det.

  • 0
  • 0
Ole Laursen

Problemet som jeg ser det, er at der stadig nogen der ikke har forstået at vandfaldsmodellen er en dårlig model. Jeg læste Design of Design af Fred Brooks (til dem der ikke har læst den, så er det bare at komme i gang) for ikke så længe siden, og en af hans pointer er at det ikke kan gå hurtigt nok med at få taget livet af vandfaldsmodellen. Den modellerer ikke hvordan de gode designere arbejder.

Hvis alle hypezombierne kan hjælpe med til at lægge vandfaldsmodellen i graven, så er det da med at gi' dem et klap på skulderen. Det var da virkeligt et af de steder hvor man kunne forestille sig det offentlige kunne spare nogle klejner.

  • 0
  • 1
Thomas Søndergaard

PHK, du argumenterer i det her blog-indlæg overhovedet ikke mod agile. Du argumenterer blot for at et mindre hold af kompetente mennesker er det der virker bedst. Det er der ikke nogen inden for agile-kirken der vil modsige.

Desværre er det ikke specielt relevant at et mindre hold af meget kompetente mennesker er det der virker bedst, hvis man ikke kan skaffe et mindre hold af meget kompetente udviklere. Hvad kan man så? Tjo, men kan prøve at skaffe dig bedst mulige folk og så støtte sig op af erfaringerne fra meget dygtige og erfarne folk - det er vel det som alle metoder handler om?

  • 0
  • 0
Poul-Henning Kamp Blogger

Helt klart: Hvis ikke vi kan finde nogen der kompetente til at bygge den her bro, må vi bare nøjes med nogen der ikke er kompetente og så give dem en flot T-shirt og håbe at det gør broen solid nok til at den ikke falder sammen.

Not.

Forstå mig ret: Folk er mere end velkomne til at deltage i DHL-stafetten, firmafodbold eller kalde sig agile, hvis det hjælper på team-spirit.

De skal bare ikke komme og påstå at det forbedrer IT udviklingen i forhold til Dart, Billiard eller Prototyping.

Poul-Henning

PS: @Ken: http://improbable.com/airchives/paperair/volume5/v5i2/placebos-5-2.html

  • 0
  • 0
Lars Vange

Det er præcis 4 stk. mere eller mindre luftige værdier.

At hævde pair programming, iterativ udvikling, hyppig feedback, standups eller andet er agile er direkte i modstrid med den første værdi, i alt fald hvis det er uden kontekst.

Og jeg tror såmænd heller ikke, at det hjælper sønderligt på successen i udvikling af software, at bekende sig til disse værdier.

Når det er sagt, er det samtidig lidt slående at 12 kompetente programmører og en god leder ofte ender med at ligne agile disciple, uden de behøver være det.

  • 0
  • 0
Morten Korsaa

Vi har set mange silver bullets. Virkede de som forventet? Nej! Skal vi så gøre nar af dem? Pas på!

Lad mig vove en påstand. Alle de enkelte silver bullets/ideer/teknikker har bevist at de var nyttige - i en bestemt kontekst!

De naive( godt hjulpet af markedsføringsfolkene) blæser ideen op til at skulle løse alle vores problemer, uden skelen til konteksten. Herefter bliver ideens success målt efter om den faktisk levede op til de latterlige forventninger.
Det gør den så sjovt nok ikke, hvorefter den næste række af naive melder sig på banen med "hvad sagde jeg" sangene. Og så blev den ide/teknik lagt skamfuldt i graven.

Det er ikke de naive der skal redde vores verden, men de skrappe pragmatikkere, der kan gennemskue hvornår og hvordan, de kan udnytte de enkelte teknikker til egen fordel.

Debatten er da meget underholdende, men ikke særlig værdig. Glem den naive tro på at noget er enten godt eller skidt, og skab en mere nuanceret debat, så vi andre kan lære af, hvordan du udnyttede en given teknik på en fed måde. Eller hvorfor den ikke virker når bla bla bla..
Det tror jeg gør os rigere.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Hvis du spørger en dygtig kok, hvilket redskab, der er det vigtigste i et køkken, svarer han (måske): Kniven.

Der, hvor det går galt, er, når kokkeelever tror, at med den rette kniv, kan de alt. Der knækker filmen.

Agile metoder forudsætter nogenlunde det samme som spørgsmålet til kokken: Det er underforstået, at man kan skrive en proper kode, at man forstår jævnt dansk/engelsk og kan kommunikere med folk omkring sig, at man ikke lyver, at man er indstillet på at lave et godt stykke arbejde og en helt masse andre ting.

Agile metoder er ikke et vidundermiddel, som man kan gnubbe et ind i overfladen på et projekt og så få det til at skinne.

Men der er en masse grøfter, som projekter bliver ved med at falde i, fordi udviklere ikke holder løbende kontakt med kunden, fordi software først bliver testet, når der er 3 uger til endelig aflevering, fordi der ikke er klare måder at vurdere fremdriften, fordi der ikke er mulighed for at korrigere målet, fordi ... etc.

Men agile projekter kan også fejle! Især hvis man tror, at bare man er agil, så kommer resten af sig selv. Det gør det ikke! Og det er her misforståelsen opstår.

Jeg tror, at PHK er langt mere agil end de fleste. Men PHK er bare træt af værktøjsfetishisme og vidundermiddelsælgere med julelys i øjnene. Den slags har travle programmører ikke tid til.

Thomas

  • 0
  • 0
Jasper Arildslund

Så man må gerne bruge agile praktikker, og de er nærmest uundværlige i nogle sammenhænge, men man må ikke kalde det agil?
Jeg synes netop det sproget, hvor Scrum har haft sin største succes. Scrum har givet os* et fælles sprog, så vi er i stand til at kommunikere om iterativ forretningsværdi-fokuseret it-udvikling. Så kan vi diskutere kvaliteten af sproget, men jeg synes stadig det er godt nok.
*Og 'os' er ikke bare nørderne i maskinrummet, men også slipsedyrene i forretningen.

  • 0
  • 0
Torben Rahbek Koch

Selv bryder jeg generelt ikke synderligt om Poul-Hennings lettere unuancerede måde at udtrykke sig på, men den har den store fordel, at den får folk op ad stolene og i den grad indbyder til diskussion.

Når man selv føler, at man besidder en stor kompetence på et område kan det være utroligt svært at håndtere andres mangel på kompetence, ligeså vel som det kan være svært at håndtere manglende dedikation til en opgave. Man kan jo vælge at forsøge at skubbe folk lidt i den rigtige retning eller man kan blive lidt mavesur. Min egen strategi afhænger i høj grad af hvilket ben, jeg får først ud af sengen den pågældende dag ;-)

PHK har naturligvis ret i, at et hold bestående af dygtige, kompetente og dedikerede mennesker oftest vil være i stand til at opnå noget rigtigt godt. Det er der næppe nogen, der kan være uenig i. Desværre er verden indrettet sådan, at de fleste opgaver - både indenfor og udenfor softwareudvikling - udføres af ganske almindelige mennesker. De er ikke nødvendigvis inkompetente og mangler ikke nødvendigvis dedikation, men de er ikke ekvilibrister. Og eftersom det meste software jo netop udvikles af den type mennesker er der en desperat jagt på metoder, der kan løfte det samlede niveau af sådan et hold.

Metoder er et forsøg på at få udnyttet middelmådighed eller gennemsnitlighed, så man alt i alt får noget, der er større end summen af enkeltdelene. Og her ser det ud til, at de agile metoder har det lidt nemmere.

Men det betyder jo ikke, at det er en af de berømte sølvkugler. Ligesåvel som vandfaldsmodellen så tydeligt heller ikke er det. Den rette - dvs. dygtige - (projekt)leder vil være i stand til at løfte et vilkårligt hold uanset metoden.

Pointen – både min (og PHKs formodentligt) - er naturligvis, at det i høj grad er menneskene og ikke metoden, der er afgørende for resultatet. Og de agile metoder bryster sig netop af at sætte mennesker fremfor metoder i centrum, hvilket nok i høj grad (gætter jeg på) er medvirkende til deres success.

  • 0
  • 0
Anonym

PHK

Jeg er enig et langt stykke hen ad vejen, men der er tilfælde hvor det man har brug for er at smide hele den gamle tankemåde over skulderen og hvor en frisk start vil være meget billigere, end at gennemanalysere hvordan man nyimplementerer alle fortidens fejltagelser.

Det er lidt belastende når du skriver f.eks. "den gamle tankemåde" - hvad skal man lægge i det?

Der bliver ævlet lidt om 'sort og hvidt', men i den virkelige verden er det ikke særligt svært.

Afhængig af projektets kompleksitet, foretager man en foranalyse.

Hensigten er at kortlægge forretningsgange, og evt. allerede dér komme med en systemforslag, som naturligvis understøtter forretningsgangene.

NB: 'Forretningsgange' er et abstrakt begreb, og indbefatter også f.eks. optimering af lager/materiale/produktionsstyring - m.v.

Kigger man ned i materien, er der typisk en masse (åbenlyse) stamfunktioner, som ikke kræver den store intelligens - nærmest lige ud ad landevejen.

Nu ved jeg godt jeg er lidt en outsider fordi jeg har arbejdet med højstrategisk 'forretnings EDB', men disse åbenlyse og lavpraktiske 'stamfunktioner' kan man sagtens udlicitere til 3. part.

Kommer vi over i den egentlige transaktionshåndtering, kræver det en symbiose mellem forretningsforståelse og systemdesign ('programmering'), og det er typisk hér det halter.

Domæneeksperterne forstår ikke EDB, og EDB-folket forstår ikke domæneeksperterne.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det er lidt belastende når du skriver f.eks. "den gamle tankemåde" - hvad skal man lægge i det?

Vores måde at administrere virkeligheden på forandrer sig ofte når man begynder at bruge IT.

Tag rejsekortet som eksempel:

Med manuel håndtering er rejsehjemmel er det økonomisk urealistisk a lave en betalingsmodel baseret fugleflugtsafstanden.

Med computere er det muligvis de billigste måde at gøre det på.

Men hvis beslutningstagerne ikke kan tage det mentale spring, høster man ikke den økonomiske fordel ved IT, men spilder istedet tid & penge på at få IT-løsningen til at emuluere manuel håndtering af rejsehjemmel.

Poul-Henning

  • 0
  • 0
Martin Bøgelund

PHK:

Med manuel håndtering er rejsehjemmel er det økonomisk urealistisk a lave en betalingsmodel baseret fugleflugtsafstanden.

Med computere er det muligvis de billigste måde at gøre det på.

Bare fordi DSB minimerer omkostningerne, betyder det ikke at DSB maksimerer profitten; i profitmaksimering hører indtægterne selvsagt også med.

Hvis nu
- Du skal fra A til B
- Skinnerne fører fra A over C til B
- Fugleflugtslinien fra A til B er mindre end fugleflugtslinien fra A til C
så vil alle der skal fra A til C købe billet fra A til B til en lavere pris (pga kortere fugleflugtslinie), og så bare stige af på C.

Når man så sidder og laver "Business Intelligence" på data fra billetsalget, vil man tro at det er nødvendigt med mere kapacitet mellem C og B end det rent faktisk er tilfældet.

I dette eksempel vil du så risikere at have højere omkostninger til overkapaciteten mellem C og B, og iøvrigt have lavere indtjening end du burde, fordi din forretningsmodel bliver omgået.

Du mister desuden goodwill, fordi det bliver åbenlyst at den lange køretur er billigere end den korte.

  • 0
  • 0
Carsten Pedersen

Med manuel håndtering er rejsehjemmel er det økonomisk urealistisk a lave en betalingsmodel baseret fugleflugtsafstanden.

Med computere er det muligvis de billigste måde at gøre det på.

Her ignorerer vi så at "billigst" vil medføre at samtlige aktører (DSB, privatbaner, regioner, kommuner, med mange flere) foruden at investere i Rejsekortet samtidigt skal ændre på mange års politikker, lokalplaner, tankegange osv.

Måske kunne det tænkes at de, der lever uden for den snævre IT-vinkel, syntes det var en lidt for stor mundfuld på én gang?

Foruden de politiske spil, som givetvis ville tage flere år, ville det medføre betydelige omkostninger i implementering, administration og efteruddannelse.

Fugleflugt-beregningen vil helt sikkert være smartere i mange aspekter. Men, set i et samfundsmæssigt perspektiv, tvivler jeg på at hverken tid- eller pengeforbruget ville være væsentligt mindre end hvis et kompetent firma var blevet sat til at implementere rejsekortet med de restriktioner der nu ligger.

  • 0
  • 0
Carsten Sonne

Jeg ville ønske at vi kunne koncentrere os om denne tilsyneladende eviggyldige sandhed og droppe alle de religiøse hatte.

Når IT projekter går galt, fokuseres ofte på alle mulige andre områder end det virklige problem. Det er tilsyneladende ikke så nemt at vurdere hvilke parameter, der er forudsætning for andre og i hvor stor grad de forskellige parametre er årsag til et mindre succesfuld projekt (eller direkte fiasko).

Mange forskellige kaniner bliver trukket op af hatten når ting gå galt. En ting er dog sikkert, tingene går sin gang hvad enten man vil det eller ej. Hvis vi ikke selv formår at identificere kilden i årsag/virkningskæden, vil den baske virklighed automatisk diktere en løsning. Prisen er ikke til disktution, den må vi bare betale.

En dag når prisen er blevet høj nok, så lære vi det; Med mindre vi er gået bankerot inde da.

  • 0
  • 0
Poul-Henning Kamp Blogger

En dag når prisen er blevet høj nok, så lære vi det; Med mindre vi er gået bankerot inde da.

Taget i betragtning at vi ikke foretager post-mortems på katastroferne og heller ikke på andenvis har etableret en feed-back mekanisme, ser jeg igen grund til at antage at katastroferne ikke skulle fortsætte uantastet...

Poul-Henning

  • 0
  • 0
Carsten Sonne

[..] ser jeg igen grund til at antage at katastroferne ikke skulle fortsætte uantastet...

Det er et gradsspørgsmål hvor slemt det skal være før det er en katastrofe. Vi taler næppe om katastrofer af apokalyptisk karakter.

Jeg tror det kommer til at gøre så ondt på nogle mennesker at de til sidst finder andre veje; Eller måske gør nogle andre det for dem.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det er et gradsspørgsmål hvor slemt det skal være før det er en katastrofe. Vi taler næppe om katastrofer af apokalyptisk karakter.

Taget i betragtning at vi ved der er et problem, burde det så være nødvendigt med en katastrofe af "apokalyptisk karakter" inden vi gør noget ved det ?

Hvorfor har vi ikke for længst fået en havarikommision for offentlige IT-investeringer ?

Poul-Henning

  • 0
  • 0
Carsten Sonne

Hvorfor har vi ikke for længst fået en havarikommision for offentlige IT-investeringer ?

Med den politisk korrekthed der hersker i samfundet i dag, den handlinglammelse der er i det politiske system, den nul-fejls kultur der dominerer i den offentlige forvaltning og en verden hvor TV er alvidende i hvordan den virkelige verden fungerer, så er det vel ikke så mærkeligt.

En havarikommision vil betyde at inkompetence vil skulle frem i lyset, også ganske højt i rækkerne. Uforholdsmæssigt mange ville få inkompetencens stempel idet der ikke er plads til fejl. Det er ganske enkelt ikke muligt under de nuværende omstændigheder.

  • 0
  • 0
Jesper Louis Andersen

Hvis nu
- Du skal fra A til B
- Skinnerne fører fra A over C til B
- Fugleflugtslinien fra A til B er mindre end fugleflugtslinien fra A til C
så vil alle der skal fra A til C købe billet fra A til B til en lavere pris (pga kortere fugleflugtslinie), og så bare stige af på C.

Heldigvis har vi Floyd-Warshalls All-Pairs-Shortest-Path algoritme. Skinnenettets simplicitet taget i betragtning, trods alt, så er det klart muligt at beregne en fornuftig pris ved opslag i en matrixtabel af størrelse NxN hvor N er antallet af stationer. En Ikke-FW algoritme, men een som kører O(N^3 lg n) fylder omkring 20-30 liniers ML, alt inklusive og jeg kan skrive den på en eftermiddag uden problemer.

Som udgangspunkt er det formentlig ikke nogen dårlig start hvis man ønsker at implementere løsningen. Man kan også uden videre tilføje zonekonstruktionen i den nuværende model, hvis man vel at mærke accepterer at der skal laves visse ændringer i den. Dermed undgår man at implementationen kompliceres yderligere.

Men blindt at basere løsningen på zonekonstruktionen er en fejl.

  • 0
  • 0
Ole Østergaard

Jeg tror, at PHK er langt mere agil end de fleste. Men PHK er bare træt af værktøjsfetishisme og vidundermiddelsælgere med julelys i øjnene. Den slags har travle programmører ikke tid til.

Det jeg forstår af PHK's indlæg, er dybest set at hvis bare han har en flok "kompetente programmører og en god leder", så skal han nok klare opgaven - uanset hvilket værktøj han så får lov at bruge, og uanset hvordan kunden undervejs i projektet ændrer verden omkring ham.

Selv travle programmører bør reflektere over hvad de bruger tiden på, og så prøve at optimere hverdagen og lære nye teknikker. Ellers ender de travle programmører pludselig en dag som gamle, højtråbende enspændere der stadig tror at man pr. automatik skal gøre som man gjorde for 30 år siden.

  • 0
  • 0
Ole Østergaard

Der er ikke noget nyt i agil udvikling, det er gammel vin på nye flasker.

Og hvad så?

Mange af "de erfarne i branchen" kan godt lide at minde folk om at alle nye idéer er gamle. Ruby er Smalltalk, bare med en anden syntaks. TDD blev opfundet da man havde hulkort og sparsomme ressourcer på mainframen. Osv. osv.

Men konteksten skifter konstant, så hvad der kan have været en rigtig dårlig idé i gamle dage, kan være lige den ingrediens der får nye projekter til at lykkes.

  • 0
  • 0
Poul-Henning Kamp Blogger

Og hvad så?

Så mister man den kontext og viden der allerede findes om de pågælende metoder.

Eller som enhver ved: "Den der ikke vil lære af historien er dømt til at gentage den."

Vi bliver ikke bedre til at udvikle IT systemer hvis hver generation selv skal opdage "at jeg har kun en lille hjerne og må leve med den."

Poul-Henning

  • 0
  • 0
Ole Østergaard

Så mister man den kontext og viden der allerede findes om de pågælende metoder.

Som sagt: Hvis konteksten er ny, så kan jeg ikke se at historien nødvendigvis vil gentage sig.

Jeg læser blot dit blog-indlæg som en vrissen af alt der kaldes "agilt", uden nogen gode argumenter for eller imod de enkelte praksisser. En generel "agil min bare..." kan jeg ikke bruge til en dyt. Hvis du ville uddybe og forklare hvorfor parprogrammering ikke lige fungerede for dig dengang for 21 år siden, hvorfor du mener det er forkert at stille krav til kunden (du har jo prøvet Scrum/XP, siger du), hvorfor du mener at FreeBSD var en skandale de første 5-7 år osv., så kan jeg bruge historien til noget. I hvert fald kan jeg så tage stilling til om konteksten passer på min hverdag og derfor er relevant.

Med andre ord: Jeg er ikke nødvendigvis uenig med dig. Jeg ved bare ikke hvad det er du vrisser af og hvorfor. Jeg tror der kunne komme et interessant og debatskabende blog-indlæg ud af at du rent faktisk tager stilling til de agile praksisser i stedet for bare at kalde det hele noget bras.

  • 0
  • 0
Ole Østergaard

Jeg tror lige du bør følge med i den anden debattråd.

Jeg vrisser ikke af agil, jeg vrisser af at det bliver solgt som en ny løsning på alverdens problemer.

Ah, der er kommet nye blogs fra dig og Bent mens jeg har været gravet ned i denne. Så vil jeg da skynde mig videre. Hvis jeg gider.

En af idéerne ved at have noget som "Version2 Live" eller andre agile konferencer er netop at udveksle erfaringer med brug af processer. Succeser og nederlag. For det er almindelig kendt at der ikke findes "silver bullets". At du så opfatter sådanne konferencer som salgsboder, er en anden sag. Det er nok konferencearrangørernes skyld.

  • 0
  • 0
Poul-Henning Kamp Blogger

For det er almindelig kendt at der ikke findes "silver bullets".

Jep, der findes endda et par klassiske papers hvor nogle af de største i branchen diskuterer netop den overskrift.

Gid dem der har travlt med at sælge agile metoder gad læse dem.

Poul-Henning

  • 0
  • 0
Rasmus Pedersen

"Gid dem der har travlt med at sælge agile metoder gad læse dem."

Kan du ikke kaste lidt links til papers du synes om, jeg læste for længe siden mythical man month og personligt så gav den mig mere end det jeg fik i posen fra universitetet, det var nærmest ved et tilfælde jeg opdagede mythical man month og de her klassiske gems bliver der desvære ikke agiteret ret meget for.

  • 0
  • 0
Rasmus Kaae

Efter min mening er det virkelig problem ikke hvorvidt agiludvikling, rup, tdd, osv. virker eller ej. I teorien vil en vilkårlig udviklingsproces resultere i det perfekte produkt. I praksis kommer det, som du nævner, an på de personer som skal løse problemet.

Hvis nu alverdens IT-chefer og deres ledergrupper kunne indse at der ikke findes en entydig definition på en proces der konstant leder projekter til succes - så er vi nået langt.

Jeg er sikker på at de agile udviklingsmetoder, for de fleste, kan være vejen ud af skolebogs-eksemplet med iterativ udvikling via RUP.

Hvis man nu kunne definere en overordnet proces, f.eks. "the umbrella method" som kunne definere en række målepunkter for ledelsen - hvor hver enkelt projekt så kunne instantiere den konkrete udviklingsmetode de finder passende (rup, tdd, xp, osv). Se, det vil være smart! :-)

  • 0
  • 0
Morten Korsaa

Den findes da! Det er nøjagtig det der har været målet for de tusindvis af experter der har været involveret i CMMI og SPICE / ISO 15504.

Disse modeller består simpelthen af karakteristika for gode processer. Altså det som kendetegner en proces der erfaringsmæssigt fører til succes!
Med dem i hånden kan ledelsen sammenligne med egne processer, og se om det giver anledning til bekymring.

De er store og tunge, ja, men det er også en meget kompleks branche vi arbejder i. Hvis der var en nem løsning, så var den vist fundet nu.

Hvis man er i tvivl om modellernes værdi, så prøv at tage en tilfældig side i proces områderne. Læs den igennem, og tænk: "vil disse aktiviteter minimere risici for projektet?" eller "vil et projekt som har gjort dette være på mere sikker grund?"

Så overblikket er der. Der er ikke noget mystisk. Det er svært, for svært for mange. Men for dem der kan, tør og vil sætte sig ind i det, så er det da rart at vide, at utallige experter har arbejdet i snart 30 år på at skabe rammerne for dig.

  • 0
  • 0
Rasmus Kaae

Hej Morten

CMMI er ikke en proces, men men model for at måle "modenhed". CMMI udtaler sig kun noget om hvor vidt man så følger de processer som er definerede.

Det er slet ikke det jeg efterspørger. Det jeg efterspørger er en overordnet udviklingsmodel så topledelsen kan sige "vi udvikler efter the umbrella model og kan se at alt går efter planen", mellem ledelsen kan så f.eks. sige "vi udvikler efter extreme programming og alt går som det skal" og alt sammen være fanget i samme proces.

Se evt. dette hurtige diagram http://vendelbo.71nk.com/umbrellamethod.png

  • 0
  • 0
Morten Korsaa

Nej CMMI er ikke en proces, men karakteristika for gode processer. Derfor kan CMMI bl.a. bruges som reference til at måle modenhed. Modenhed er udtryk for hvor god en organisation er til produktudvikling, deriblandt at vælge og udnytte sin egen "umbrella model".

Der er ingen defineret livscyklus model (RUP, Vandfald, xp, SCRUM, ...) som dækker alle behov, det er vist bevist nu. Men der er behov for et højere abstraktionsniveau. Derfor siger CMMI at man skal vælge den der er bedst i situationen. "Situationen" skal så vurderes for mange aspekter, før den helt rigtige livscyklus model for det givne projekt er fundet. Og det valg skal guides gennem "umbrella modellen" eller det som i CMMI termer hedder "the organisations defined set of lifecycles, including tailoring guidelines".

Jeg er helt på det rene med de mange misforståelser der er omkring CMMI, men det ændre ikke ved at alt det du efterspørger vil jeg kunne vise dig guidance til i modellen. Det er ikke den evige sandhed, og der er på mange områder brug for mere guidance, men modellen kan godt holde til en prøvning for om det der står er relevant. Og den er resultatet af 28 års arbejde på at skabe et overblik.
At den så er skrækkeligt utilgængeligt i det offentliggjorte format, det er en anden sag. Men efter at have brugt et halvt liv og spidsen af en jetjager på at blive SEI autoriseret CMMI instructor må jeg bukke mig ærbødigt i støvet for den visdom der ligger gemt i den. Men det er nogle sure rønnebær :-)

  • 0
  • 0
Rasmus Kaae

Hej Morten

Rart at høre at vi er enige om hvad CMMI er. Dog er CMMI ikke værktøjet der kan løse det problem jeg beskriver.

Betragt det lidt som en OSI-stack for netværkstrafik - altså på hvert niveau har du ikke behov for detaljer fra underliggende niveauer, blot en status (f.eks. OK).

Som jeg ser de fleste udviklingsmetoder så indledes de alle med en mængde undersøgende arbejde og afsluttes altid med et release (dvs. preanalysis/analysis og release jvf. mit diagram fra før). Undervejs vil der altid blive udviklet noget og det der er udviklet vil altid blive testet (dvs. development og test jvf. mit diagram fra før).

Ledelsen har kun behov for at vide ganske få ting om projekter - dvs. status, problemer, osv. mens de operationelle beslutninger bør ligge hos projekterne.

Jeg er ikke sikker på at jeg udtrykker mig klart nok - men CMMI er i hvert fald ikke svaret (det kan dog være at visse konsulenter og ledelse mener det :-)

  • 0
  • 0
Morten Korsaa

Mjahhh, det er vi så ikke helt. Din analyse af problemet er jeg enig i, men tillad mig at svare i CMMI termer i [kommentar]:

"Betragt det lidt som en OSI-stack for netværkstrafik - altså på hvert niveau har du ikke behov for detaljer fra underliggende niveauer, blot en status (f.eks. OK)." [GP2.8 fortæller at det er smart at definere nogle målinger på de vigtigste detaljer, og GP2.10 at ledelsen skal have informationer om hvordan processen performer.]

"Som jeg ser de fleste udviklingsmetoder så indledes de alle med en mængde undersøgende arbejde [RD] og afsluttes altid med et release [PI](dvs. preanalysis/analysis og release jvf. mit diagram fra før). Undervejs vil der altid blive udviklet noget [TS] og det der er udviklet vil altid blive testet[VER / VAL] (dvs. development og test jvf. mit diagram fra før).

Ledelsen har kun behov for at vide ganske få ting om projekter - dvs. status, problemer, [PMC]
osv. mens de operationelle beslutninger bør ligge hos projekterne. [REQM SP1.3 og CM SG2]

Jeg er ikke sikker på at jeg udtrykker mig klart nok - men CMMI er i hvert fald ikke svaret [hvad (indenfor produktudvikling) mangler CMMI at svare på?] (det kan dog være at visse konsulenter [ jeg har ikke noget bedre svar] og ledelse [ak - hvis blot de gjorde] mener det :-)

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