I en agile verden er definisjonen av ferdig interessant. Noen ganger blir en funksjon betraktet som ferdig, fra en utviklers eller utviklingsprosessperspektiv, når den er flyttet til kolonnen 'ferdig'. Nå 'bare' trenger den å bli testet og utgitt. Lettvint. Ikke så raskt.
La oss dele denne setningen i små deler og gå gjennom dem en etter en – bare da kan vi forstå og danne en mening om hvorfor. Tro meg, det finnes mange små konsepter skjult her.
I scrum lager teamet (i beste tilfeller) opp en Definisjon av Ferdig. Dette er en 'kontrakt' mellom teammedlemmene. Det er viktig å definere dette fordi ellers vet vi ikke når vi er ferdige. Når en brukerhistorie (eller billett) er 'ferdig' og den er Pull Requestet til utgivelsesgrenen (en forespørsel om å legge til koden i den neste utgivelsen), kan den betraktes som ferdig. Dette er bare et eksempel. Jeg skal fortelle deg hva problemet er med denne tilnærmingen.
De fleste utviklere jeg har jobbet med misliker sterkt å bli inkludert sent i tenkeprosessen av en brukerhistorie (eller billett). De fleste vil forstå problemet og komme med en løsning selv, heller enn bare å implementere løsningen gitt av en arkitekt eller Produktansvarlig (eller billettrapportør). Så langt bra. Så hvorfor gjør utviklere noen ganger det samme? Det vil si å kaste ting over gjerdet i den forstand at de vil være ferdige med sin billett en gang den er inkludert i utgivelsesgrenen? Hva med testing? Hva med å informere rapportøren? Hva med å se det i handling? Hva med integrasjon?
Det verste vi kan gjøre som teammedlemmer, teamledere eller ledere er å fjerne vårt kompetente arbeidsmiljø fra beslutningsprosessen, samt utgivelsesprosessen. Det jeg mener er denne situasjonen: Pat arbeider med en billett og en gang hun er 'ferdig', blir den testet av QA-teamet. De finner massevis av bugs og oppdager scenarier for kodebrudd (sammen med andre relaterte ting) som ingen utvikler noen gang ville tenkt på. De legger til så mye verdi... eller suger de bare energien ut av Pat? Ved å gi testansvaret til noen andre fjerner vi ansvaret fra utviklerne. De er da bare en liten del av prosessen, et hjul i maskineriet. De ser aldri hele prosessen. I min erfaring føler de seg mindre involvert og kan til og med skrive underoptimal kode fordi de vet at den blir testet senere uansett, og de må rette opp problemene. Selvfølgelig bør utviklere teste sine egne funksjoner.
De er da bare en liten del av prosessen, et hjul i maskineriet.
Et alternativ til alt dette er å sette opp en annen utviklingsprosess. En som gir utviklerne muligheter. Den er enkel likevel kompleks. Og den holder utvikleren ansvarlig til det virkelige Ferdig.
Et eksempel på en Kanban-utviklingsprosess:
Det ovenfor beskriver prosessen hvor utvikleren er fullt ansvarlig fra “In Progress” til “Ferdig” uten vagt områder som “Done-Done”, “Released” eller “Done-Done-Done”. Ferdig er når det er ferdig, når det er lansert og i produksjon og det skaper verdi. Som med alle lean-flows, alt vi bruker tid på er et fullstendig sløsing før det er levert. Ingen verdi i det hele tatt. Bare søppel. Det er først når det er i produksjon, på nettstedet, i full funksjon at det skaper (potensielt) noen verdi. Men det er et annet innlegg…
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.