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?

Derfor holder budgetterne ikke, når projekter skal realiseres

"Mennesket ser for lyst på fremtiden – bevidst og ubevist - og derfor holder budgetterne ikke, når store byggeprojekter skal realiseres." Oprindelig artikel fra Ingeniøren af Bjørn Kock Sørensen

Jeg faldt over dette citat i denne artikel og selv om den går på byggeprojekter, og uden at have nærmere på Bent Flyvbjergs arbejde, eller på Daniel Kahnemans for den sags skyld, mener stadig jeg det holder på de projekter jeg har været tæt på.

Skal man budgettere ud fra hvad man ud fra hvad man ved, det vil sige ikke se spøgelser?
Skal man være pessimistisk?
Skal man gøre det nedefra-op eller oppefra-ned?
Eller hvad med Planning Game?

---

Kender du Bent Flyvbjerg og Daniel Kahnemans arbejde? Er du enig med deres perspektiv?

Hvordan estimere i arbejdet ved jer?

Estimering

Vi er inden for de sidste par måneder begyndt at drive estimeringen ved hjælp af poker planning (se tidligere indlæg her).

Jeg er stødt på en meget god artikel ang. emnet. Den indeholder forskellige tilgange til estimering og deres fordele og ulemper:

http://leadinganswers.typepad.com/leading_answers/2007/11/agile-estimatin.html

Når jeg skal forklare, hvorfor man ikke skal og kan bruge meget tid up-front på estimering, så tegner jeg altid en graf som nedenstående hentet fra artiklen:

Estimering - Grafisk Design vs. Programmering

Det er min erfaring, at det er lettere for interessenter at acceptere at grafiske designere ikke kan give estimater, end det er for de samme interessenter at acceptere en udvikler har svært ved at give estimater.

Personligt kan jeg ikke se nogen forskel.

Givet at andre har samme erfaring - hvorfor er det tilfældet?

Definition of done...

Jeg er meget opmærksom på at kunne tracke projektets fremskridt målt som mængden af færdig funktionalitet. Hvorfor? Jo, hvis man nu antager, at projektet skulle stoppes lige nu, hvad nytte havde man så af, at eks. 66% af alle opgaver var løst, hvis denne mængde rent faktisk kun svarede til 2% færdig funktionalitet?

Dette er vist en meget almindelig antagelse for alle agile projekt-process modeller. Der hvor det bliver lidt sjovt er, når talen kommer ind på, hvad færdig egentlig betyder - the definition of done? Der findes mange bud, bl.a. læste jeg et godt et i dag her, men faktisk har jeg selv svært ved at komme frem til en entydig og universel gyldig liste. Efter min opfattelse skal definitionen af færdig forhandles med produktejere og udviklere som en del af opstarten på et projekt, og definitionen skal afstemmes med krav til deadline, kvalitet, genbrugelighed, testabillity osv.

Hvordan ser jeres liste ud?

Reflektion, estimering og vision

Stødte på en sjov betragtning på lifebeyondcode vedrørende finansverdens evige og ukuelige vækstfokus: "I think the financial people have got it. They say "past performance is not an indicator of future results" along with every report"...

Det fik mig til at tænke på, hvordan vi på den blå taler meget om at skulle tage ved lære af vores estimater og tracke tidligere projekters estimater, sådan at disse kan indgå i vores fælles erfaringspool og igen forbedre nye estimater... hvordan hænger det lige sammen med ovenstående citat?

Hvis vi vender tilbage til the planning game - er der nogen som har prøvet spillet jeg refererede til i min sidste post? - så handler spillet lige netop om at skabe en verden, hvor motivation og selvorganisering vil drive estimeringen og eksekveringen af estimerede opgaver op i et hurtigere og hurtigere tempo. Her lærer man af sidste iterations resultat, og planlægger næste ud fra det, men oftest sker der det, at man tilføjer mere til den næste iteration, som så danner grundlag for planlægningen af den næste igen. Samtidig med så ændrer estimaterne hele tiden karakter, da de ikke er baseret på tid, men på kompleksitet. Kompleksiteten fungerer relativt på den måde, at den kommer til at afspejle, hvad man kan nå i en given iteration, og hvad man kan nå ændrer jo sig lige netop... langhåret? hmm, måske lidt. Jeg ser nogle klare fordele i hele tiden at fokusere på estimater som noget relativt, så man lige netop ikke bliver hængende i et bestemt tempo, men konstant tilpasser sig... og nogle gange tror jeg estimater givet i timer, spænder lidt ben for det pga. estimatets direkte relation til noget kendt og meget målbart... en time er en time er en time... eller er det? Hos os taler vi faktisk om estimat-timer og timeforbrug...

Hvad er din holdning til denne estimeringsvirak? Og hvordan lærer din organisation af tidligere estimeringer uden at hænge fast i samme tempo derved?

Planning game - fortsættelse...

I forlængelse af Daniels tidligere post vil jeg godt gøre lidt reklame:

Der findes et færdigt kit man kan anvende til planning game (baseret på XPs principper). Jeg var igennem en øvelse i forbindelse med Scrum Master certificeringen, som anvendte dette kit, og det var en meget lærerig oplevelse... jeg kan på det varmeste anbefale alle projektledere at "lege" denne leg som intro på agile projekter, for ligesom at få folk i denne rette stemning og ånd.. På ganske kort tid lærer man om koncepter som velocity/fart, kompleksitet og story estimering.

Hent kittet her: http://www.xp.be/html/xpgame.zip

Planning Game

Jeg faldt over denne artikel, omkring planning game.

På Den Blå Avis har vi også erfaring med lignende principper. Jeg følger op med et indlæg senere.