Sviluppo del Prodotto

Molti prodotti sono sviluppati per soddisfare una specifica esigenza o sono costruiti per testare se un'idea funziona, oppure seguono l'approccio "costruisci e verranno". La prima volta che viene sviluppato un MVP (Minimum Viable Product), non si ha tempo per pensare alla scalabilità o a come gestire funzionalità e caratteristiche più complesse. In ogni caso, un processo standardizzato e trasparente di sviluppo di prodotti Agile è una buona idea da seguire per ottenere risultati prevedibili.
Per mantenere e migliorare continuamente un prodotto, avere un processo per gestire le richieste nonché i bug fix aiuterà a portare a termine le cose e a rilasciarle.

Il nostro processo di sviluppo di prodotti inizia nella fase delle idee.

Fase delle idee

In questa fase vengono raccolte tutte le idee di chiunque nella società. Queste possono essere idee brevi o grandi idee che possono essere discusse in un incontro per idee o di brainstorming. Poiché chiunque può creare queste idee, è anche un modo per mantenere aperta lo sviluppo del prodotto. Come vengono passate da questa fase dipende, forse attraverso il voto o semplicemente valutate dal Product Owner.

Fase delle richieste

Normalmente tutte le richieste arrivano qui; bug, cambiamenti, nuove funzionalità. È la corsia di cattura per tutto ciò che gli impiegati o i leader vogliono venga fatto. Un problema ben catturato contiene uno screenshot, una breve descrizione e un URL. La persona dietro alle richieste è chiamata Reporter, e sostiene il ticket durante tutto il processo. 

Fase del backlog

Solo i ticket che sono stati esaminati, ben compresi e controllati possono arrivare a questa fase, e solo possono essere spostati dal Product Owner, o da chiunque abbia il ruolo. Una volta spostati, vengono priorizzati dall'alto verso il basso. Gli sviluppatori sceglieranno dall'alto in basso in quanto possono, tuttavia sceglieranno come lavorare su di esso (un grande motivatore). Nessuno, tranne il Product Owner, è autorizzato a riorganizzare o spostare le cose in questa fase. Vale la pena ripeterlo.

Fase in corso

Da questa fase, gli sviluppatori stessi sono responsabili di spostare il ticket a "Fatto". Questo aiuta l'intero processo, poiché lo sviluppatore lo adatterà e lo farà procedere come desidera. Quindi non ci sono riassegnazioni. Il lead developer responsabile del ticket è colui che lo ha preso. Più sviluppatori possono lavorare sullo stesso ticket, ma l'assignee non viene mai cambiato. Gli sviluppatori condividono informazioni con il resto del team ogni giorno sotto forma di riunione stand-up e rispondono alle tre domande di Scrum: 1) Cosa ho fatto fino ad oggi? 2) Cosa farò fino a domani e 3) Ho problemi di cui ho bisogno di aiuto?

Fase bloccata

Se uno sviluppatore non può procedere, il ticket viene spostato nella fase bloccata. Potrebbe esserci contenuto mancante, potrebbe essere necessario aspettare un Reporter o la soluzione non è stata trovata. Mettere qualcosa nella fase bloccata in un progetto Kanban significa che è altamente visibile che qualcosa non si muove come dovrebbe e dovrebbe essere curato.

Fase di test

Una volta che un ticket è stato fuso in un ambiente di staging o di test, il Reporter viene invitato a contribuire al test. Ovviamente è stato pre-testato dallo sviluppatore prima, come dovrebbe essere il comportamento predefinito di qualsiasi sviluppatore. Personalmente non voglio allontanare la responsabilità dallo sviluppatore a un team di QA, il che richiede più tempo. Ma per test più grandi e complessi potrebbe essere necessario e più veloce. I test automatizzati sono anche eseguiti.

Fase "Fatto"

Una volta che qualcosa è stato fuso nel ramo principale e quindi rilasciato in produzione, viene impostato come "Fatto". Questa è una chiara definizione di "Fatto".

Wow, hai appena descritto un progetto vecchio stile! Aspetta un attimo, quello che abbiamo qui permette a idee/ticket singole di muoversi attraverso il processo indipendentemente dalle altre. Questa è la principale differenza. Inoltre, possiamo spostarci avanti e indietro in qualsiasi momento per qualsiasi motivo valido. Questo non può essere confrontato con il progetto a cascata con tutte le sue dipendenze e problemi di test.