Fantastisk citat...

Et vigtigt aspekt ved agil udvikling er at sikre en kodebase, der kører næsten uden bugs. Dette er selvfølgelig vigtigt (1)  for at kunne leve op til princippet om, at hver sprint/iteration leverer release-bar funktionalitet og (2) for at undgå en death march periode inden noget skal releases. Jeg læste fornyligt en artikel fra Mike Cohn omkring naturen af nye funktioner i et softwareprojekt (artiklen stiller et interessant spørgsmål, så læs den...) og her stødte jeg på følgende citat:

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

Tænk lige over det. Ville du nogen sinde bestige et bjerg uden at sikre hvert skridt? Overfør så det til dit daglige arbejde med softwareudvikling... Selvfølgelig kan man altid invende, at softwareudvikling ikke er en disciplin man dør af, hvis man træder forkert, men så igen, hvis man ser bjergbestigning som en disciplin hvis målsætnings success er betinget af, at man ikke træder ved siden af (uanset om man dør eller ej), så er vi jo tilbage til at muligheden for at nå trygt i mål afhænger af kvaliteten af ens arbejde undervejs.

Krav - hvordan og hvem gør hvad...

Vi har brugt en del tid på at optimere kravsprocessen her i huset, og vi blev i den forbindelse klar over, at vi med Scrum og fokus på roller og deres funktion måske var endt i en grøft, hvor forventninger til Product Owneren var for store. Vores PO skrev krav og overleverede disse til teamet under Estimeringsmødet op til en sprint. Dette er problematisk, da kravene ofte ikke var modne nok. Det er som citatet nedenfor også pointerer svært for en person alene at stå for dette arbejde.

"It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why."

Alle på teamet deltager i dette arbejde. Det er en kollaborativ proces. Man kunne spørge sig selv: hvorfor? Er det ikke spild og skal vi ikke lige netop fokusere på at eliminere spild i processen??

Jo lige netop! Ved at gøre det til en kollaborativ proces så sikrer man også den bedste vidensdeling og at udviklerne har et "godt" forhold til de krav, som står i backloggen, og som skal estimeres på et tidspunkt. Vi anvender user stories, som jo pr. natur er tænkt som værende et kommunikationsredskab, og derfor giver det endnu mere mening at samarbejde om modningen af disse, så hver user story fungerer som en effektiv placeholder for kommunikation. Ved at gøre kravsmodning til en kollaborativ proces tidligt i projektforløbet kan man opnå følgende gode fordele:

• Øget kommunikation imellem PO og team
• Bedre forståelse af user stories og deres boundaries
• Hurtigere og mere præcise estimeringssessioner (sprint planning 1)
• Bedre og mere præcise velocity-forudsigelser
• Bedre krav 
• En velfungerende backlog, som teamet stoler på
• En PO som teamet stoler på
• etc.

Hvilke erfaringer har i gjort jer på området? Hvordan faciliterer i kravsmodning?

Forretningen, domænet & udvikling

Et stort problem for agile udviklingsproces er, som jeg ser det, at sikre fremskridt og konstant levering. Mange bøger beskæftiger sig ikke rigtigt med, hvordan man sikrer, at hver iteration producerer noget færdig funktionalitet, som principielt set skulle være deployment-klar.

Crystal Clear taler om walking skeleton strategien, som går ud på at man først får et simpelt arkitekturskelet op og køre, og dernæst fylder kød på det. Scott Ambler med Agile Unified Proces (som er den processmetode der ligger til grund for projekterne her på Den Blå Avis) taler om requirements-driven architecture og modeling in small increments. Lidt samme ide igen: man opbygger arkitekturen i små bidder, dog krydret med at arkitekturen skal udspringe fra forretningens/kundens krav. Men det store spørgsmål forbliver, hvordan gør man egenligt?

Belært af tidligere projekter er jeg blevet meget påpasselig med at tage domænet for givet. Vi opererer med en arkitektur, hvor de grundlæggende forretningslogikker og -objekter afspejles i en domænemodel. For mig at se er det essentielt at få domænet på plads tidligt i projektet, før udviklingen af krav starter. Det betyder at

• Krav skal være tilpas detaljerede
• Kravstiller skal kunne stå inde for kravene
• Kravene skal mappes til domænet
• Domænet skal afspejle løsningen af kravene

Dette arbejde er interessant af flere grunde. Det skaber en kontakt imellem kravstiller og udviklere som er helt nødvendig for at få kravstiller til at tage et aktivt ansvar i udviklingsprocessen og for at få udviklerne til at tage et aktivt ansvar i kravene. Med andre ord de bringer de to verdner tættere sammen. Kravstiller og udvikler kan diskutere krav på en måde, som de begge hver især forstår: Kravstiller taler ud fra forretningen, udvikleren ud fra domænemodellen. Gode eksempler kunne være:

Udvikler: Jamen skal kunden kunne få den rabat hver gang han handler?
Kravstiller: Øh, ja... Kunden får rabatten, fordi han handler for mere end 3000 kr om året hos os.
Udvikler: Ok, så man skal altså logge den samlede sum en kunde handler for?
Kravstiller: Ja det vil jeg da klart mene
Udvikler: Og hvis den samlede sum overstiger 3000 kr, så får kunden en rabatsats?
Kravstiller: Ja på 2%. Hvis kunden handler for over 10000 så stiger rabatten til 5%
Udvikler: Så det er en slags konfigurerbar trappesats? Skal i selv kunne vælge procentsatserne og beløbene?
Kravstiller: Det ville da være at foretrække, så skal vi jo ikke belemre nogen fra udviklingsafdelingen hver gang vi skal have det ændret!

Udvikler sidder her og kigger på det domæne, hun har tegnet op. Sikkert bestående af nogle ordrer, kunder og varer. Men ved at diskutere rabat med kravstiller ud fra domænet lærer udvikleren hurtigt at der skal tilføjelser til domænet for, at rabatten kan virke som forretningen ønsker det. Pointen her er, at hvis man i de tidlige faser får vendt domæment med kravstiller og de krav, der er registreret, så får man et mere stabilt udgangspunkt for udviklingsfasen. Det er min påstand, at dette arbejde i et eller andet omfang er nødvendigt for at kunne levere færdig funktionalitet efter hver iteration i udviklingsfasen, ellers skal der bruges for megen tid på undersøgelse af krav og ændring af domæne efterfølgende.

Vi arbejder med fire faser (hentet fra Agile Unified Proces & Rational Unified Proces): inception, elaboration, construction og transition. Inception er projektfødsel, hvor man definerer overordnede rammer for projektet, elaboration er der hvor man fordyber sig i projektet, construction der hvor kravene udvikles og transitition er udrulningen af projektet. Vi arbejder på Den Blå Avis med en kravsprocess, som definerer krav som værende 10% færdige efter inception og 80% færdige efter elaboration. De sidste 20% kommer i løbet af construction, når kravene udvikles (man kan ikke vide alt up-front!). På samme måde foreslår jeg egentlig at man går til både domæne og arkitektur...

Grey Scope Creep

Når man anvender agile projektledelsformer og processer, så vil der altid være et indbygget krav om, at hver iteration - hvad enten den hedder iteration, sprint eller noget andet - skal levere demonstrerbar og færdig funktionalitet. Det kan være utrolig svært at sikre dette formål. Hvis man ikke er meget påpasselig, så vil der være mange løse ender i det som leveres efter hver iteration. Dette kaldes grey scope creep og betyder, at arbejdet hober sig op på usynlig vis. For hver iteration kommer man længere og længere bagud, specielt hvis man bogfører funktionerne, som er blevet leveret, som "done". Jeg har selv været i den situation og kan derfor kun samtykke, når der tales om, at man skal operere med en meget striks version af "done". Det er langt bedre at lægge ganske lidt funktionalitet i en iteration, og så får denne funktionalitet færdig. Og færdig betyder her, at funktionerne er gennemtestede både på unit-test og brugergrænsefladeniveau, at dokumentation er udført, at alle integrationstests er foretaget osv...

Hvis udviklere/programmører på et givent projekt ikke lever efter denne devise, så skal det tages meget alvorligt. Ingen udvikler skal have lov til at cutte i koden for at komme hurtigere i mål. Heller ingen skal springe test eller review over. Samtidig skal projektlederen aldrig bogføre funktioner som "done", før de rent faktisk er det. Dette er en kunst, tro mig, men det lønner sig altsammen i form af mere stabil kode og mere stabil projektplanlægning (burn-rates der kan bruges til noget, iterationplanlægning som er realistisk osv...)