Agil...hvad er det lige det er chef?

Indledning

Lad os nu være lidt realistiske og indse, at der ikke findes nogen opskrift på god softwareudvikling. Ethvert forsøg på at beskrive hvordan den rigtige måde at udvikle software på vil altid kun være god i under bestemte forhold. Hvis man forsøger at beskrive hvordan processen skal håndtere alle mulige projektsetups, så går processen hen og bliver for tung. Derudover vil dem der skal fortolke processen have problemer med at finde ud af hvordan de skal gøre i en given situation. Her fejlede CMM big time og SCRUM er lige ved at fejle lige så fælt

I stedet skulle vi måske forsøge at fokusere på nogle ting der er gode at gøre.

Tidlig brugerinvolvering

Det ved jeg ikke noget om, men mange siger at det er en god idé og jeg arbejder lige nu på et projekt hvor jeg oplever dets fordele og ulemper. Ja, det er jo egentlig lidt en løgn men jeg ved at jeg taler på kundens vegne når han også opfatter sig som bruger af produktet.

Parprogrammering

Det er efterhånden et accepteret faktum at parprogrammering giver bedre kodekvalitet. Derfor gør parprogrammering det næsten unødvendigt at gennemføre efterfølgende peer-reviews af koden.

Cross-functional teams

Jo flere forskellige interessenter der er tilknyttet samme team eller endnu bedre sidder i samme rum jo større sikkerhed er der for at de oplever en success. Successen kunne f.eks. være at projektlederen blev glad, product owneren blev glad, salgsafdelingen blev stolt over det deres firma producerede og sidst men vist nok desværre ikke mindst kunden blev glad. Glemte jeg brugeren?

Pragmatisk Test-drevet udvikling

Jeg har det med testdrevet udvikling som jeg har det med sikkerhedsseler og cykelhjelme. Det eneste problem med TDD i forhold hertil er at TDD også kræver at man gør noget og bruger nogle værdifulde tastetryk. Lad mig sige det på en anden måde når jeg er ude på dybt vand og ikke føler, at det også gælder om at være en rigtig mand, så glæder jeg over den lille smule disciplin jeg trods alt til tider har. Det gør jeg fordi TDD sikrer mig en forudsigelig vej igennem dagen som kodeko / programmør / Senior Systems Engineer / Lead Developer / menneske. (så fik I også mit nogenlunde ærlige syn på titler)

Retrospektiv processforbedring

Retrospektives er gyldne muligheder for at et team eller en organisation kan få luftet ud og forbedre sig. Jeg har selv faciliteret en del retrospektiver og jeg synes tit de giver en del. De minder lidt om CMM's milestone reviews bortset fra at man typisk havde halvårlige milestones når man var lidt fremsynet :-)

Change by evolution not revolution

Problemet med Scrum tilgangen til agil udvikling er at den er revolutionær. Enhver ændring af en organisation er nødt til at ske evolutionært fremfor revolutionært. I Scrum bruger man meget ordet *skal* og beskriver nogle roller som har meget specifikke ansvarsområder og som har et meget fast defineret interface imellem hinanden. Det minder mig om en af de jobtitler jeg har grinet længe over (og som jeg senere faktisk også stødte på i SCBCD certificeringen) "Deployment Manager". Man kunne også kalde ham mr. Hudson eller mr. Jenkins for at være lidt med på beatet og samtidig en smule Oracle ditchene.