Mange produkter udvikles til et specifikt behov eller bygges for at teste, om en idé virker, eller det er bare en "build it and they will come" -tilgang. Når det mindst mulige levedygtige produkt (MVP) bygges første gang, har man ikke tid til at tænke over skalaen eller, hvordan man håndterer mere komplekse funktioner og funktionalitet. I alle tilfælde er en standardiseret og gennemsigtig agil produktudviklingsproces en god idé at følge, for at opnå forudsigelige resultater.
For at vedligeholde og løbende forbedre et produkt, hjælper det med at have en proces til at håndtere anmodninger samt fejlrettelser, for at ting bliver gjort og frigivet.
Vores produktudviklingsproces starter i idéfasen.
I denne fase fanges alle idéer fra alle i virksomheden. Det kan være korte idéer eller store idéer, som diskuteres under en idé- eller brainstorming-møde. Da alle kan skabe disse idéer, er det også en måde at holde produktudviklingen åben på. Hvordan ting overgår fra denne fase afhænger, måske er det gennem opstemning eller kvalificeret af produktansvarlig.
Normalt lander alle anmodninger her; fejl, ændringer, nye funktioner. Det er fangstbane for alt, som medarbejdere eller ledere ønsker at få gjort. En godt opfanget problematik indeholder en skærmbillede, en kort beskrivelse og en URL. Den person, der står bag anmodninger, kaldes Rapporteren, og er den, der følger op på billetten gennem hele processen.
Kun gennemgåede, velforståede og kontrollerede billetter kan komme til denne fase, og kun flyttes af produktansvarlig, eller den, der har rollen. Når de er flyttet over, prioriteres de fra toppen og ned. Udviklere vælger fra toppen, så længe de kan, men de vælger selv, hvordan de vil arbejde på dem (en stor motivationsfaktor). Ingen ud over produktansvarlig må omprioritere eller flytte ting i denne fase. Det er værd at gentage.
Fra denne fase er udviklerne selv ansvarlige for at flytte billetten til 'Færdigt'. Det hjælper hele processen, da udvikleren tilpasser sig og får det gennemført, som de ønsker. Derfor sker der ingen genopgavning. Den ansvarlige udvikler, der tog billetten op, er den, der fortsat arbejder med den. Flere udviklere kan arbejde på samme billet, men den ansvarlige ændres aldrig. Udviklerne deler oplysninger med resten af teamet hver dag i form af et stand-up-møde og svarer på de tre scrum-spørgsmål: 1) Hvad har jeg gjort indtil i dag? 2) Hvad vil jeg gøre indtil i morgen og 3) Har jeg nogle problemer, som jeg har brug for hjælp med.
Hvis en udvikler ikke kan komme videre, flyttes billetten til Blokeret-fasen. Der kan være manglende indhold, behov for at vente på en Rapporter eller løsningen findes ikke. At placere noget i Blokeret-fasen i et Kanban-projekt betyder, at det er meget synligt, at noget ikke bevæger sig, som det skal, og skal tages hånd om.
Når en billet er slået sammen med en staging- eller testmiljø, inviteres Rapporteren til at hjælpe med testningen. Det er selvfølgelig prøvet af udvikleren før, som det burde være standardadfærd for enhver udvikler. Personligt ønsker jeg ikke at fjerne ansvaret fra udvikleren til et QA-team, hvilket tager længere tid. Men for nogle større og mere komplekse test kan det være nødvendigt og hurtigere. Automatiseret testning udføres også.
Når noget er slået sammen med hovedgrenen og dermed frigivet til produktion, sættes det til 'Færdigt'. Det er en klar definition af 'Færdigt'.
Wow, du har netop beskrevet et gammeldags projekt! Vent lige lidt, det vi har her gør det muligt for individuelle idéer/billetter at bevæge sig gennem processen uafhængigt af de andre. Det er det største forskel. Vi kan også bevæge os frem og tilbage når som helst, af gyldige årsager. Det kan ikke sammenlignes med et vandfaldsprojekt med alle dets afhængigheder og testningsproblemer.
Vi hjælper virksomheder med deres teknologi, ved at levere CTO-tjenester og produktledelse. Vi er kendt for vores CTO-tjenester og arbejder med både startups og etablerede virksomheder i Norden, Schweiz og USA.
Vi er et schweizisk selskab (LLC) baseret i 
Schweiz.