IT 
EN 
JA 
ES 
La semplificazione dello stato
Sto facendo una grande ipotesi qui, ma immagino che i tuoi team utilizzino Jira per soddisfare i requisiti del prodotto? Non è nemmeno un grande presupposto, oltre 65.000 aziende lo usano a livello globale, quindi sto solo giocando le probabilità. Jira è fantastico... ma nonostante tutte le sue straordinarie funzionalità, il flusso di lavoro personalizzabile è quello di cui parlerò... perché mi infastidisce.
Ogni PBI nel tuo Product Backlog ha un ciclo di vita. Viene creato, probabilmente lavorato e quindi completato. Semplice, vero? Ogni team con cui ho lavorato utilizza i flussi di lavoro Jira per modellare il proprio ciclo di vita PBI ed è molto efficace. Ecco un esempio:
Il team di sviluppo sposta ogni PBI attraverso gli stati finché il lavoro non è terminato. Ma hai mai notato che c'è sempre quel membro del team il cui lavoro è seduto in "Open" e poi annuncia nel Daily Scrum "oh sì, scusa, è quasi finito, non ho cambiato lo stato". È colpa loro se non mantengono aggiornato lo stato? O il processo è solo troppo complicato?
Ne vale davvero la pena per la complessità del flusso di lavoro?
Per rispondere a questa domanda, dobbiamo considerare lo scopo dello Sprint Backlog. È un artefatto che mostra il piano previsto dal Team di sviluppo per raggiungere lo Sprint Goal. Viene ispezionato (e adattato se necessario) quotidianamente. È importante sottolineare che è trasparente. Nella mia esperienza, quando i team di sviluppo ispezionano il loro Sprint Backlog, parlano di cose come "Sì, sto per integrare quel lavoro" o "No, ha bisogno di altri test manuali prima del rilascio"... se lo stanno dando livello di dettaglio, considera per chi sono gli stati complessi del flusso di lavoro di Jira? Chiedi ai tuoi team! Dopo tutto, è il loro processo.
Ho chiesto questo al mio Scrum Team e la risposta è stata... *alza le spalle*. Dopo alcuni Five Whys, abbiamo rotto questo *alza le spalle* fino a tre cose:
- Il team di sviluppo non ha bisogno di stati complessi. Conoscono lo stato approfondito dei loro PBI.
- Nemmeno il Product Owner ha utilizzato gli stati. Tutto quello che volevano sapere era se lo Sprint Goal sarebbe stato raggiunto.
- I vantaggi degli stati complessi erano esterni (i ruoli "complementari" di Project e Release Manager).
Gli appassionati di Scrum sapranno che la guida non fa riferimento esplicito a nessuno "stato" attraverso cui un PBI dovrebbe passare (bene, perché è un framework, non una metodologia 😊). Ma alcuni sono impliciti? Nella mia mente, SÌ!
In primo luogo, 'Fatto' – un PBI che soddisfa la definizione di Fatto è 'Fatto'. In secondo luogo, un PBI appena creato è "Da fare" o un termine simile. E in terzo luogo, solo per estensione, un PBI che non è né 'Da fare' né 'Fatto' è….Fare? In corso? Qualunque cosa tu voglia chiamarli, il nostro flusso di lavoro Jira potrebbe essere semplicemente "Da fare", "In corso" e "Fatto"? Certamente non spetta a me, in qualità di Scrum Master, deciderlo. Il processo è di proprietà dello Scrum Team. Ma penso che questa semplificazione sia utile perché fornisce un linguaggio più semplice e comune a cui il team può fare riferimento.
Se stai pensando, il mio team utilizza un flusso di lavoro più complesso e questo funziona per noi... è geniale! Se il tuo processo funziona, cracking! Ma chiediti chi aiuta la complessità: le persone che hanno bisogno di conoscere i progressi dei PBI lo sanno già? Stai cercando di sostituire la comunicazione con stati complessi? C'è valore nella complessità? In caso contrario, lascia che i tuoi team lo considerino e vedano come vogliono auto-organizzarsi attorno a una soluzione.
Pensa, quanto potrebbe essere semplice tutto:
Ci sono alcuni aspetti negativi con questo semplice flusso di lavoro? Ecco le domande che il mio team mi ha posto e le mie risposte parafrasate:
Cosa succede se un PBI viene bloccato da fattori esterni?
Domanda giusta. Potremmo aggiungere uno stato per bloccato. Ma se il PBI è bloccato da un'altra squadra, ci sono ancora progressi? Sei ancora coinvolto nel suo progresso? Quindi, potrebbe semplicemente rimanere "In Progress"?
Cosa succede se dobbiamo consegnare un PBI per il test?
Scrum è un framework utilizzato da team interfunzionali. Il team di sviluppo è responsabile di tutto il lavoro per trasformare un PBI in Fatto. Trasferiamo regolarmente il lavoro ad altri team? Perché?
Come posso mostrare i progressi compiuti su un PBI più grande se è solo "In corso" da anni?
Comunicazione con il proprietario del prodotto. Se l'OP sa che si stanno compiendo progressi, è sua responsabilità tenere aggiornati i suoi stakeholder. Se ti senti sotto pressione perché non stai dimostrando progressi, come si sente il team che modelliamo la fiducia? Oppure potremmo imparare da questo e scomporre i nostri PBI in blocchi più piccoli?
Lascio questo post lì. So che questa semplificazione non sarà la tazza di tè di tutti, ma se togli una cosa da questo, ricorda che un flusso di lavoro Jira complesso non dovrebbe sostituire la buona comunicazione verbale e la trasparenza.