Nel mio precedente articolo, ho iniziato la discussione sulle abitudini poco sviluppate all’interno di un team di mischia che alla fine porteranno (prima o poi) a un fallimento nella consegna. In questo articolo, vorrei espandere ancora una volta questo argomento e concentrarmi ora sui processi funzionali all’interno del team.
Quelli sono altrettanto importanti quanto l’eccellenza tecnica della squadra. Anche se le persone all’interno sono super qualificate per il lavoro che stanno per svolgere, ci sono ancora aree che possono rovinare i loro sforzi per la perfezione. E non sarà tanto colpa loro quanto sarà responsabilità diretta delle decisioni di gestione del progetto e della loro capacità di servire il team con processi adatti allo scopo per supportare il team con intenti chiari e attività prevedibili.
Sommario:
Team altamente segregato con competenze distinte
Immagina che il team abbia sviluppatori esperti, perfettamente indipendenti e con la capacità di mantenere le loro promesse e consegnare il contenuto dello sprint concordato giusto in tempo prima della fine dello sprint. Anche in uno scenario così perfetto (che è altamente improbabile che accada comunque), il team avrà problemi a tenere il passo con le funzionalità del backlog (in continua crescita) se le competenze sono rigorosamente separate tra i membri del team.
Pochi esempi
- Il team ha 1 o 2 ingegneri DevOps in grado di apportare modifiche alle pipeline automatizzate o di occuparsi dei servizi all’interno della piattaforma, ma il resto del team non ha idea di queste cose. Quindi discutere di quelle storie durante le cerimonie di mischia come i perfezionamenti porterà alla perdita di tempo per la maggior parte del team rimanendo sospeso alla riunione senza alcuna partecipazione e viceversa: lo sviluppatore DevOps non avrà alcun interesse per il resto delle storie orientate alla funzionalità e anche il tempo della riunione sarà per lo più sprecato.
- C’è un unico esperto di database per l’intero team. A seconda della complessità e dell’utilizzo delle soluzioni di dati nel sistema che il team sta sviluppando, questa persona potrebbe essere costantemente sovraccarica di storie che non ha la possibilità di completare abbastanza presto, soprattutto se si tiene conto delle proprie priorità. Ancora peggio, anche altre storie dovranno aspettare, poiché dipendono dall’origine dati fornita dalle storie del database.
- Quando un particolare prodotto è principalmente orientato allo sviluppo back-end, l’unico sviluppatore front-end è lì per ogni evenienza (perché di tanto in tanto, è comunque necessario qualche piccolo cambiamento anche nell’applicazione UI). In tal caso, ancora una volta, la maggior parte delle cerimonie di mischia sono una perdita di tempo per questo membro del team, poiché la loro conoscenza è limitata solo al front-end e nient’altro ha importanza.
Dove si conclude
In ognuno dei casi di cui sopra, il risultato è che le persone stanno sprecando il loro tempo o, in alternativa, non sono in grado di recuperare il ritardo con la domanda arretrata. Stanno impedendo al resto del team di iniziare a lavorare sulle storie successive, o stanno effettivamente diminuendo l’efficacia complessiva del team di mischia perché c’è troppo tempo che non viene utilizzato all’interno dello sprint.
Il team, tuttavia, ha ancora questo numero di sviluppatori. Dall’esterno non è visibile (anche non volendo essere esposti) che le persone all’interno del team non siano in grado di affrontare alcune storie solo perché sono troppo orientate a qualche specifico set di abilità. Quindi non possono aiutare gli altri membri del team con le storie, anche se la loro capacità lo permetterebbe, e anche le priorità per le storie lo favorirebbero.
È persino difficile per il product owner comporre alcuni contenuti di sprint significativi per il team, poiché il product owner deve sempre tenere presente quante persone possono lavorare su ogni singola storia e se più storie simili vengono portate allo sprint contemporaneamente , alla fine la capacità del team è stata superata, anche se in effetti ci sono persone che potrebbero lavorare su quelle storie, ma non hanno le capacità per iniziare con quelle.
Risolvere il dilemma
È un dilemma da risolvere e i project manager devono essere consapevoli della strada da scegliere. In particolare, una scelta tra:
- Avere molti sviluppatori full-stack in grado di lavorare su contenuti più ampi, ma non proprio esperti in molti argomenti. Quindi possono andare in largo ma non in profondità. Quindi la consegna può progredire rapidamente, ma la qualità potrebbe risentirne.
- Avere esperti dedicati per ogni tecnologia, ma poi accettare la limitazione e lavorare di più su contenuti di stampa più adatti. Quindi le persone possono andare in profondità e costruire grandi storie, ma le storie dovranno essere affrontate in sequenza, richiedendo così più tempo per essere consegnate.
Proprietario di prodotto debole
Questo non è necessariamente un “problema di processo” per definizione, ma lo tratto così solo perché la creazione di storie solide può essere intesa come un processo che il team dovrebbe voler avere solido e compatibile con il team di sviluppo.
Ciò che intendo per debole non deve necessariamente riferirsi alla proprietà di conoscenza di una persona, ma piuttosto alla capacità del proprietario del prodotto di servire le storie del team che gli sviluppatori possono comprendere e che hanno un senso chiaro dal punto di vista della roadmap del prodotto. Entrambi sono molto importanti per un team di mischia di successo.
Se le storie mancano di dettagli affinché gli sviluppatori siano in grado di comprendere chiaramente lo scopo, il valore funzionale o le aspettative tecniche, possono verificarsi fondamentalmente due scenari:
- Gli sviluppatori costruiranno qualcosa di diverso da ciò che il proprietario del prodotto voleva effettivamente. È persino difficile da cogliere durante lo sprint stesso perché per lo più il proprietario del prodotto non ha avuto la capacità di tenere traccia dell’avanzamento delle storie a un livello così dettagliato, e per lo più PO si aspetterà solo che la cosa accada (magicamente).
- Gli sviluppatori passeranno troppo tempo a chiarire le storie e discuterne più e più volte piuttosto che iniziare a costruirle. Ciò comporta molte chiamate aggiuntive, accordi ripetuti e il rinvio del lavoro alla fase finale dello sprint. Raggiunge un punto in cui le stime originali per le storie non possono più essere considerate accurate e le storie non possono essere chiuse all’interno dello sprint e passano agli sprint successivi. Nel peggiore dei casi, la situazione si ripete poi negli sprint successivi.
Tempo per l’auto-riflessione
Di solito è difficile da ammettere, ma il proprietario del prodotto dovrebbe trovare il tempo per riflettere, guardare le storie arretrate create ed eventualmente confrontarle con la visione della roadmap del prodotto se esiste ancora un legame ragionevole tra questi due, se esiste una tabella di marcia affatto. In caso contrario, questa è la prima cosa da risolvere. A volte, la soluzione è ammettere che il product owner è troppo lontano dal team e troppo lontano dal proprio target.
In tal caso, la parte del team del proprietario del prodotto deve essere risolta. Se non altro, inserire nel team un solido business analyst orientato più ai contenuti del team piuttosto che ai contenuti di business (per questo, in questo caso abbiamo già un product owner) potrebbe essere una valida opzione da percorrere, anche al prezzo di aumento dei costi totali della squadra.
Processi di test senza tempistica fissa
Cosa succede se le attività di test non sono strettamente legate a un programma concreto all’interno di uno sprint di mischia?
A prima vista, questo potrebbe sembrare qualcosa di buono che vogliamo per un team agile / di mischia. La flessibilità è sempre benvenuta e suona bene se presentata all’esterno.
La mia esperienza mostra che il risultato di questa libertà è più caos che flessibilità. Ciò non significa che la soluzione a questo dovrebbe essere la creazione di “cascate all’interno dello sprint” con fasi di test dedicate seguite subito dopo il completamento dello sviluppo. Questo non è affatto l’approccio giusto in questo caso. Puoi leggere di più su questo nei miei post sulla strategia di scrum testing e sul ciclo di vita del test agile.
Possiamo ancora consentire una certa flessibilità e scegliere il programma di test in quanto sembra più appropriato per l’attuale team di sviluppo e le proprietà del prodotto fornite dal team. Ci sono, tuttavia, due obiettivi principali che dovrebbero essere raggiunti da questa scelta:
Se tali condizioni saranno soddisfatte, il team si adatterà naturalmente al processo di adattamento e il programma di consegna non sarà influenzato da attività di test prolungate non pianificate.
Alla fine, ciò che conta di più è uno sprint release affidabile e prevedibile, che mi porta all’ultimo punto di questo blog.
Processo di rilascio non definito
Ora, questa è una cosa così ovvia per ogni squadra di mischia. Tuttavia, curiosamente, di solito è anche uno dei processi più sottovalutati.
Molto spesso, un team di mischia dirà semplicemente che il rilascio avverrà dopo ogni sprint, ma non è supportato da un processo solido. Quello che succede allora, in realtà, è che durante il periodo di rilascio sorgeranno molte attività caotiche e imprevedibili. All’improvviso tutte le persone sono occupate da “attività di rilascio” e nessuno è in grado di concentrarsi sul continuare a sviluppare nuove storie di sprint. Le metriche dello sprint sono disattivate e il rilascio sembra un’attività casuale e imprevedibile dal punto di vista della terza persona (di solito il cliente).
Le persone sono così concentrate sul backlog, sul contenuto dello sprint, sullo sviluppo, sui test e infine sulla presentazione dei risultati che dimenticano che una volta terminato tutto questo, lo sprint successivo è già in corso e stanno già perdendo tempo.
Alla ricerca di un buon momento per rilasciare
Quindi, quando esattamente il team dovrebbe eseguire l’effettivo rilascio in produzione? L’unica cosa importante che conta alla fine.
La risposta a questa domanda si trova nel processo, supponendo che tu ne abbia uno. A seconda di:
- la complessità dei contenuti che il team sta producendo negli sprint,
- durata di uno sprint,
- numero di componenti interessati nel sistema
- il numero di persone che utilizzano e richiedono le modifiche,
un processo di rilascio ripetuto dovrebbe essere stabilito e seguito in futuro. Le regole esatte del processo possono essere nuovamente flessibili nella definizione. Ma come accade con le attività di test, renderlo un’abitudine solida come una roccia prevedibile e programmata per giorni concreti nel futuro lo rende qualcosa su cui fare affidamento e a cui fare riferimento.
Scelte da scegliere
Le possibili forme di tale processo potrebbero essere una delle seguenti o altre:
- Completare il test delle funzionalità dello sprint corrente durante lo sprint successivo e rilasciare il contenuto alla fine di tale sprint (una volta completato il test). Ciò significa che ogni versione non avrà alcun contenuto dall’ultimo sprint ma conterrà storie dei 2 sprint precedenti.
- L’ultimo sprint prima del rilascio è sempre dedicato al test del contenuto dei due sprint precedenti.
- Ciò non significa che lo sviluppo durante lo “sprint di test” verrà interrotto; dice solo che il contenuto sviluppato in quello sprint di test non sarà ancora incluso nella prossima versione.
- Se sono già in atto abbastanza attività di test automatizzate, sforzati di eseguire il rilascio dopo la fine di ogni sprint. Quindi questo deve essere un processo molto rigoroso con persone dedicate che si concentrano su quei pochi giorni per il 100%. Non dovrebbe comunque influenzare in alcun modo il resto del team di sviluppo.
- Puoi anche scegliere di rilasciare una volta al mese o una volta ogni N mesi, soprattutto se va bene dal punto di vista degli utenti finali. Ciò aumenterà lo sforzo sul lato test per ogni sprint (poiché il contenuto sarà più grande per ogni versione). Ma d’altra parte, significherà una minore quantità di attività ripetute nel tempo, che in questo caso possono avere benefici per il team. Di conseguenza, può consentire al team di creare più nuove funzionalità tra le versioni, nonostante il fatto che le funzionalità arriveranno effettivamente alla produzione con una cadenza più lenta.
Ma come già affermato alcune volte prima, non è così importante quale di questi processi verrà scelto. È molto più importante quanto bene la squadra si atterrà a quel processo e lo renderà un’abitudine duratura.
Puoi anche leggere questa guida al processo e alle pratiche di gestione dei rilasci.