Pianificazione delle attività dipendenti in uno scrum sprint

Non segui Scrum perché i tuoi 3 PBI non sono PBI. È un PBI. Inoltre, se si divide il PBI in questo modo e si ha un ruolo speciale per ciascuna parte non si sta facendo Scrum ma ScrumFall. La tua funzionalità incrociata non funziona affatto perché hai un ruolo separato per ogni attività, quindi mentre un ruolo sta facendo la sua parte di PBI altri ruoli sono in attesa.

La funzionalità incrociata significa che quasi tutti i membri del team possono svolgere qualsiasi compito ed è uno dei requisiti fondamentali per far funzionare Scrum. Altrimenti non puoi pianificare in modo efficiente lo sprint perché devi contare la velocità per ruolo e combinare i PBI nel modo di riempire la capacità di ciascun membro - che è per lo più impossibile.

How should these 3 product backlog items be scheduled so that they all get completed by the end of the sprint?

Conversazione giornaliera. Si chiama "alzati". Tutti partecipano. Ogni giorno.

Since they are all dependent on each other and require at least 3 members of the team to work together, it seems to me like they each need deadlines in order for them to get done in time.

Non hanno bisogno di "scadenze". Hanno bisogno di una conversazione in corso. Ogni giorno. Si chiama "alzati". Tutti partecipano. Ogni giorno.

The scrum master keeps saying that they don't need deadlines because the cross-functional team will take care of it.

Una corretta.

This hasn't worked in 10+ sprints, though.

Wow. Voi gente siete ostinati. Ti odiavi attivamente l'un l'altro? O le persone si rifiutano semplicemente di partecipare allo stand-up quotidiano?

Il primo problema qui è che gli elementi nel tuo backlog non sono basati sul valore del business. L'interfaccia utente da sola non fornisce alcun valore, così come il codice backend da solo non lo è. Ti suggerisco di provare a suddividere verticalmente le funzionalità, invece di pensare in termini di componenti, prendere la prospettiva di un utente finale e ridefinire i tuoi articoli come storie degli utenti, ad es.

As a user I want to search by keyword so that I can find matches that are relevant to me.

Si noti che questa funzione può includere diverse attività: creare / modificare l'interfaccia utente, codificare la logica, recuperare i risultati dal database ... Il test non viene trattato come una funzione separata, ma inclusa in ogni storia e in base al proprio " definizione di fatto ", includerà diverse attività, come unità test, test funzionali automatizzati, test manuali del sistema, ... Lo scopo di lavorare in brevi sprint time-box è di fornire regolarmente software di lavoro pur mantenendo la capacità di adattarsi ai cambiamenti nelle priorità. Il software non testato semplicemente non può essere considerato un software funzionante.

Può succedere che una storia sia troppo grande per essere inserita in un singolo sprint. In tal caso dovrai dividerlo in storie più piccole, cercando di non cadere in una divisione meccanica per componente, quando possibile. Dividere le storie degli utenti non è facile e richiede molta pratica. Ci sono alcuni nice articoli sull'argomento.

D'altra parte, i team agili sono interfunzionali . Ciò non significa che alcune persone non saranno più abili di altre in certe aree, ma che i membri del team collaboreranno tra loro per raggiungere un obiettivo condiviso, ovvero completare le storie programmate per lo sprint. Nella pratica, questo può tradursi in, ad esempio, gli sviluppatori che assistono nelle attività di test e viceversa. La condivisione della conoscenza (rispetto ai silos esperti) è una pratica fondamentale per una squadra che può ottenere il massimo da lui.