Come gestire l'accettazione di più build all'interno di uno sprint agile

Altri qui hanno già sollevato la preoccupazione che la tua domanda porta alla mente: Come si può usare un processo agile con una sola build ogni sprint? Se questo è davvero il caso (e quelle build sono considerate troppo frequenti da qualcuno nella vostra organizzazione), allora sarò più schietto degli altri: probabilmente non siete davvero agili.

Un primo principio di scrum è che il team produce codice funzionante (o codice pronto per la produzione se siete dei puristi) ogni singolo sprint. Se il vostro team non sta costruendo e testando durante lo sprint, allora non sta consegnando codice funzionante alla fine, e non sta "facendo" scrum.

In effetti, nella vostra domanda avete detto che considerate uno sprint come un modo per gestire una settimana di lavoro. Questo suggerisce che state semplicemente usando le scadenze settimanali per controllare i progressi del team, con codice funzionante da vedere dopo un certo numero di settimane.

Se ho capito male, allora ignorate quanto detto sopra e concentratevi su ciò che hanno detto gli altri qui: Qualunque sistema usiate per gestire il vostro codice (ne usate uno, giusto?) dovrebbe tenere traccia di ciò che è incluso in ogni build. Certo, questo non è comodo da capire per gli esterni, che è il motivo per cui uno dei pezzi di documentazione veramente importanti che viene fuori da un team scrum sono le note di rilascio. Se stai gestendo gli elementi di lavoro in uno strumento dovresti essere in grado di ottenere una lista molto chiara di ciò che è stato completato in uno sprint. Se la tua infrastruttura è davvero matura dovresti essere in grado di includere anche i link ai casi di test e ai risultati.

Una gran parte dell'avanzamento di un processo agile dipende dall'automatizzare il più possibile. Anche se stai gestendo gli elementi di lavoro con PostIt Notes, il tuo codice dovrebbe essere un sistema di gestione del controllo dei sorgenti e le tue compilazioni e deploy nel tuo ambiente di test dovrebbero essere automatizzate. Finché non avete questo, il vostro team è troppo appesantito dal farlo a mano per essere veramente agile. E una volta che avete questo, nessuno dovrebbe avere un problema con il team che fa tutte le build di cui ha bisogno per consegnare i suoi sprint.