Mange produkter er utviklet for et spesifikt behov, eller er bygget for å teste om en ide fungerer, eller det er en "build it and they will come" -tilnærming. Den første gangen et MVP (Minimum Viable Product) blir bygget, har man ikke tid til å tenke på skala eller hvordan man skal håndtere mer komplekse funksjoner og funksjonalitet. I alle tilfeller er det en god ide å følge en standardisert og transparent agil Produktutviklingsprosess for å få forutsigbare resultater.
For å vedlikeholde og kontinuerlig forbedre et produkt, vil det hjelpe å ha en prosess for å håndtere forespørsler samt feilretting.
Vår Produktutviklingsprosess starter i idéfasen.
Denne fasen fanger alle ideer fra alle i selskapet. Disse kan være korte ideer eller store ideer som kan diskuteres på en idé- eller brainstorming-møte. Siden alle kan skape disse ideene, er det også en måte å holde produktutviklingen åpen. Hvordan ting overføres fra denne fasen avhenger, kanskje det er ved å stemme opp eller bare kvalifiseres av Produktansvarlig.
Normalt lander alle forespørsler her; bugs, endringer, nye funksjoner. Det er fangstbanen for alt som ansatte eller ledere vil ha gjort. En godt fanget sak inneholder en skjermdump, en kort beskrivelse og en url. Personen bak forespørslene kalles Reporter, og står i spissen for saken gjennom hele prosessen.
Kun saker som er gjennomgått, godt forstått og sjekket kan komme til denne fasen, og bare flyttes av Produktansvarlig, eller hvem som helst som har rollen. Når de er flyttet over, prioriteres de fra topp til bunn. Utviklere velger fra toppen så langt de kan, men de velger selv hva de vil jobbe med (en stor motivasjonsfaktor). Ingen andre enn Produktansvarlig har lov til å omprioritere eller flytte ting til denne fasen. Det er verdt å gjenta.
Fra denne fasen er utviklerne selv ansvarlige for å flytte saken til Done. Dette hjelper hele prosessen, da utvikleren vil tilpasse og få det gjort som de vil at det skal være. Så det skjer ikke noen omfordeling. Lederutvikleren som tok saken er den som er ansvarlig. Flere utviklere kan jobbe med samme sak, men den ansvarlige endres aldri. Utviklerne deler informasjon med resten av teamet hver dag i form av en stand-up-møte og svarer på de tre scrum-spørsmålene: 1) Hva har jeg gjort i dag? 2) Hva skal jeg gjøre i morgen? 3) Har jeg noen problemer jeg trenger hjelp med.
Hvis en utvikler ikke kan komme videre, flyttes saken til Blokkert-fasen. Det kan være mangel på innhold, behov for å vente på en Reporter eller løsningen er ikke funnet. Å sette noe i Blokkert-fasen i et Kanban-prosjekt betyr at det er svært synlig at noe ikke beveger seg som det skal, og bør tas hånd om.
Når en sak er fusjonert til et staging- eller testmiljø, inviteres Reporteren til å hjelpe med testing. Det er naturligvis forhåndstestet av utvikleren før, noe som bør være standard atferd for enhver utvikler. Personlig vil jeg ikke flytte ansvaret fra utvikler til en QA-team, noe som tar lengre tid. Men for noen større og mer komplekse tester kan det være nødvendig og raskere. Automatisert testing utføres også.
Når noe er fusjonert til hovedgrenen og dermed utgitt til produksjon, settes det til Done. Dette er en klar definisjon av Done.
Wow, du har bare beskrevet et gammeldags prosjekt! Vent litt, hva vi har her tillater individuelle ideer/saker å bevege seg gjennom prosessen uavhengig av de andre. Det er hovedforskjellen. Også kan vi bevege oss tilbake og frem når som helst for en gyldig grunn. Dette kan ikke sammenlignes med et vannfallsprosjekt med alle sine avhengigheter og testingproblemer.
Vi hjelper selskaper med deres teknologi, ved å tilby CTO-tjenester og produktledelse. Vi er kjent for våre CTO-tjenester og samarbeider med både startups og etablerte bedrifter i Norden, Sveits og USA.
Vi er et sveitsisk selskap (LLC) basert i 
Sveits.