I en agil värld är definitionen av "gjord" intressant. Ibland anses en funktion vara "gjord", ur utvecklarens eller utvecklingsprocessens perspektiv, när den flyttas till "Klar"-kolumnen. Nu behöver den bara "bara" testas och släppas. Lätt som en plätt. Men inte så snabbt.
Låt oss ta isär detta uttalande i små delar och gå igenom dem en efter en – först då kan vi förstå och bilda en uppfattning om varför. Tro mig, det finns många små begrepp dolda här.
I scrum utarbetar teamet (i bästa fall) en Definition av "gjord". Detta är ett "avtal" mellan teammedlemmarna. Det är viktigt att definiera detta eftersom vi annars inte vet när vi är klara. När en användarhistoria (eller biljett) är "gjord" och den Pull Requests till utgivningsgrenen (en begäran om att lägga till koden i nästa utgåva), kan den anses vara "gjord". Detta är bara ett exempel. Jag ska berätta för dig problemet med detta tillvägagångssätt.
De flesta utvecklare jag har arbetat med ogillar starkt att bli inkluderade sent i tanken bakom en användarhistoria (eller biljett). De flesta vill förstå problemet och erbjuda en lösning själva, snarare än bara att implementera den lösning som en arkitekt eller produktägare (eller biljettrapporterare) ger. Så här långt bra. Så varför gör utvecklare ibland samma sak? Med andra ord att kasta saker över häcken i den meningen att de vill vara klara med sin biljett så snart den inkluderas i utgivningsgrenen? Vad händer med testning? Vad händer med att informera rapporteraren? Vad händer med att se det i verkligheten? Vad händer med integrationen?
Det värsta vi kan göra som teammedlemmar, teamledare eller chefer är att ta bort vår kompetenta arbetsstyrka från beslutsprocessen, samt från utgivningsprocessen. Vad jag menar är denna scen: Pat arbetar på en biljett och när hon är "gjord", testas den av QA-teamet. De hittar massor av buggar och upptäcker scenarier av att bryta koden (tillsammans med andra oberoende saker) som ingen utvecklare någonsin skulle ha tänkt på. De lägger till så mycket värde ... eller suger de bara ut energi från Pat? Genom att ge testansvaret till någon annan tar vi bort ansvaret från utvecklarna. De är då bara en liten del av processen, en kugge i maskineriet. De ser aldrig hela processen. I min erfarenhet känner de sig mindre engagerade och kan till och med skriva underoptimal kod eftersom de vet att den testas senare ändå, och de måste fixa problemen. Naturligtvis bör utvecklare testa sina egna funktioner.
De är då bara en liten del av processen, en kugge i maskineriet.
Ett alternativ till allt detta är att sätta upp en annan utvecklingsprocess. En som möjliggör utvecklarna. Det är enkelt men komplext. Och det håller utvecklaren ansvarig tills den verkliga "Klar".
Ett exempel på en Kanban-utvecklingsprocess:
Ovan beskrivs processen där utvecklaren är fullt ansvarig från “På gång” till “Klar” utan vaga områden som “Klar-Klar”, “Släppt” eller “Klar-Klar-Klar”. Klar är när det är klart, när det är släppt och i produktion och det skapar värde. Som med alla lean-flöden, allt vi lägger tid på är fullständigt avfall tills det levereras. Inget värde alls. Bara skräp. Det är först när det är i produktion, på webbplatsen, i full funktion som det skapar (potentiellt) något värde. Men det är ett annat inlägg…
Vi hjälper företag med sin teknik och erbjuder CTO-tjänster och produktledning. Kända för våra CTO-tjänster arbetar vi med både startups och etablerade företag i Norden, Schweiz och USA.
Vi är ett schweiziskt företag (LLC) baserat i 
Schweiz.