Många produkter utvecklas för ett specifikt behov eller bygger för att testa om en idé fungerar, eller så är det en "bygga och de kommer"-metod. Första gången ett MVP (Minimum Viable Product) byggs har man inte tid att tänka på skalning eller hur man ska hantera mer komplexa funktioner och funktionalitet. I alla fall är en standardiserad och transparent agil produktutvecklingsprocess en bra idé att följa, för att få förutsägbara resultat.
För att underhålla och kontinuerligt förbättra en produkt hjälper en process som hanterar förfrågningar samt buggfixar till att få saker gjorda och släppta.
Vår produktutvecklingsprocess börjar i idéstadiet.
I det här stadiet fångas alla idéer från alla i företaget. Det kan vara korta idéer eller stora idéer som kan diskuteras vid ett idé- eller brainstormingmöte. Eftersom alla kan skapa dessa idéer är det också ett sätt att hålla produktutvecklingen öppen. Hur saker övergår från det här stadiet beror på, kanske det är genom att rösta upp eller bara kvalificeras av Produktägaren.
Normalt hamnar alla förfrågningar här; buggar, ändringar, nya funktioner. Det är fångstbanan för allt som anställda eller ledare vill få gjort. En väl fångad fråga innehåller en skärmdump, en kort beskrivning och en url. Den person som står bakom förfrågningar kallas Rapporterare och kämpar för biljetten under hela processen.
Endast genomgångna, väl förstådda och kontrollerade biljetter kan komma till det här stadiet, och endast flyttas av Produktägaren, eller vem som än har rollen. När de flyttas över prioriteras de från toppen och ner. Utvecklare väljer från toppen i den utsträckning de kan, men de väljer själva hur de vill arbeta (ett stort motivatoriskt inslag). Ingen utom Produktägaren får omprioritera eller flytta saker till det här stadiet. Det är värt att upprepa.
Från det här stadiet är utvecklarna själva ansvariga för att flytta biljetten till Klar. Det hjälper hela processen, eftersom utvecklaren kommer att anpassa och se till att den går igenom som de vill ha den. Så det sker ingen omtilldelning. Den ledande utvecklaren som tog biljetten är den som ansvarar. Flera utvecklare kan arbeta på samma biljett, men den som ansvarar för den ändras aldrig. Utvecklarna delar information med resten av teamet varje dag i form av ett ståuppmöte och svarar på de tre scrumfrågorna: 1) Vad har jag gjort idag? 2) Vad kommer jag att göra imorgon? 3) Har jag några problem som jag behöver hjälp med.
Om en utvecklare inte kan fortsätta framåt flyttas biljetten till Blockerat stadiet. Det kan bero på saknade innehåll, att man behöver vänta på en Rapporterare eller att lösningen inte finns. Att sätta något i Blockerat stadiet i ett Kanbanprojekt innebär att det är mycket synligt att något inte rör sig som det ska, och att det behöver tas hand om.
När en biljett har slutförts i ett test- eller stagingmiljö bjuds Rapporteraren in att hjälpa till med testningen. Det är förstås förtestat av utvecklaren innan som bör vara standardbeteende för alla utvecklare. Personligen vill jag inte ta bort ansvaret från utvecklaren till ett QA-team, vilket tar längre tid. Men för vissa större och mer komplexa tester kan det behövas och vara snabbare. Automatiserade tester utförs också.
När något har slutförts i huvudgrenen och därmed släppts till produktion sätts det till Klar. Det är en tydlig definition av Klar.
Wow du har beskrivit ett gammaldags projekt! Vänta lite, vad vi har här tillåter individuella idéer/biljetter att gå igenom processen oberoende av de andra. Det är den största skillnaden. Dessutom kan vi flytta fram och tillbaka när som helst vi vill för en giltig anledning. Det kan inte jämföras med ett vattenfallsprojekt med alla dess beroenden och testproblem.
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.