I en agil verden er Definition of Done interessant. Nogle gange betragtes en funktion som færdig, fra en udviklers eller udviklingsperspektiv, når den flyttes til 'Done'-kolonnen. Nu 'kun' har den brug for at blive testet og frigivet. Let-peasy. Ikke så hurtigt.
Lad os bryde denne erklæring ned i små stykker og gennemgå dem én ad gang – kun så kan vi forstå og danne en mening om hvorfor. Tro mig, der er mange små begreber skjult her.
I scrum, laver teamet (i bedste tilfælde) en Definition of Done. Dette er en 'kontrakt' mellem teammedlemmerne. Det er vigtigt at definere dette, fordi ellers ved vi ikke, når vi er færdige. Når en brugerhistorie (eller billet) er 'færdig' og den bliver pull-requestet til releasegrenen (en anmodning om at tilføje koden til næste udgivelse), kan den betragtes som færdig. Dette er blot et eksempel. Jeg vil fortælle dig problemet med denne tilgang.
De fleste udviklere, jeg har arbejdet med, hader at blive inkluderet sent i tankeprocessen for en brugerhistorie (eller billet). De fleste vil gerne forstå problemet og komme med en løsning selv, snarere end blot at implementere den løsning, som en arkitekt eller Produkt Owner (eller billetrapporter) har givet. Så langt godt. Så hvorfor gør udviklere nogle gange det samme? Altså at kaste ting over hegnet i den forstand, at de gerne vil være færdige med deres billet, når den er inkluderet i releasegrenen? Hvad med testning? Hvad med at informere rapporteren? Hvad med at se det i handling? Hvad med integration?
Det værste, vi kan gøre som teammedlemmer, teamledere eller ledere, er at fjerne vores dygtige arbejdskraft fra beslutningsprocessen, samt frigivelsesprocessen. Hvad jeg mener er dette scenario: Pat arbejder på en billet og en gang hun er 'færdig', bliver den testet af QA-teamet. De finder masser af fejl og opdager scenarier af kodebrud (sammen med andre, urelaterede ting), som ingen udvikler nogensinde ville have tænkt på. De tilføjer så meget værdi... eller suger de bare energi ud af Pat? Ved at give testansvaret til en anden fjerner vi ansvaret fra udviklerne. De er så kun en lille del af processen, en tandhjul i maskineriet. De ser aldrig hele processen. I min erfaring føler de sig mindre involveret og kan endda skrive under-optimal kode, fordi de ved, at den bliver testet senere alligevel, og de skal rette problemerne. Selvfølgelig skal udviklere teste deres egne funktioner.
De er så kun en lille del af processen, en tandhjul i maskineriet.
Et alternativ til alt dette er at opsætte en anden udviklingsproces. En der giver mulighed for udviklerne. Det er enkelt, men alligevel komplekst. Og det holder udvikleren ansvarlig, indtil den virkelige 'færdig'.
Et eksempel på en Kanban-udviklingsproces:
Det ovenstående beskriver processen, hvor udvikleren er fuldt ansvarlig fra “I gang” til “Færdigt” uden uklare områder som “Færdigt-Færdigt”, “Udgivet” eller “Færdigt-Færdigt-Færdigt”. Færdigt er, når det er færdigt, når det er udgivet og i produktion, og når det skaber værdi. Som med alle slanke flows, er alt det tid, vi bruger, fuldstændig spild, indtil det er leveret. Ingen værdi overhovedet. Kun skrot. Det er først, når det er i produktion, på hjemmesiden, i fuld funktion, at det skaber (potentiel) værdi. Men det er et andet indlæg...
We help companies with their technology, providing CTO-services and Product Management. Trusted for our CTO-services, we work with both startups and established businesses in the Nordics, Switzerland and US.
We are a Swiss Company (LLC) based in 
Switzerland.