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