Scrum può utilizzare le specifiche tecniche nel Product Backlog anziché le storie degli utenti?

Presso l'azienda per cui lavoro attualmente, abbiamo iniziato a realizzare progetti Scrum. Non è stato così difficile convincere i gestori a passare dalla cascata a Scrum. Stiamo realizzando un progetto in cui ricostruiamo la nostra piattaforma da zero. Quindi la maggior parte delle funzionalità è nota e la maggior parte dei miglioramenti sono piuttosto tecnici.

In questo potrebbe essere giustificato avere compiti tecnici piuttosto che storie utente. Il nostro backlog ha tutti i tipi di compiti tecnici come:

• Riscrivi la classe DB da MySQL a PostgreSQL.
• Implementare la registrazione del sistema.
• Riscrivi la cache degli oggetti.

Le cose che emergono durante gli stand-up includono che sono richiesti lunghi "compiti di ricerca", ma non vengono mai fatti. Inoltre, i membri del team sostengono nel mezzo dello sprint che è necessario aggiungere attività non pianificate.

Come dovrebbe uno Scrum Master occuparsene? Potrebbe essere che per questo tipo di progetto, Scrum NON sia la strada da percorrere?

TL; DR

Scrum non impone l'uso di user story; sono semplicemente una pratica agile utile. Mentre il Product Owner potrebbe certamente utilizzare le specifiche tecniche anziché le storie degli utenti per costruire il Product Backlog, la maggior parte degli altri problemi di processo derivano da un fallimento nell'accettare Scrum efficaci e pratiche agili.

Vari problemi con il tuo processo

La tua Scrum sembra essere rotta in molti modi, tra cui:

1. Le tue specifiche mancano di un punto di vista esplicito o di una proposta di valore.
2. I tuoi articoli arretrati non vengono collegati agli obiettivi di Sprint.
3. Il processo di toelettatura del backlog manca del tutto o non riesce a creare picchi di trama per il backlog del prodotto.
4. Il processo di pianificazione Sprint non sta decomposendo adeguatamente gli elementi Backlog prodotto in elementi Backlog Sprint.
5. Il tuo team non include correttamente l'incertezza sugli articoli arretrati nelle sue stime di Sprint Planning.
6. La tua squadra non rispetta i fondamenti del time-boxing o dell'integrità dello Sprint.

Mentre Scrum non è sempre la soluzione giusta per ogni progetto, in questo caso sarebbe più preciso affermare che Scrum non funziona perché il team non sta davvero facendo Scrum. La tua domanda sulle storie degli utenti è solo una piccola parte dei maggiori problemi di processo che il tuo team deve affrontare.

Perché i programmatori Agili comprendono le storie degli utenti

Le specifiche tecniche sono un modo fondamentalmente rotto per comunicare i requisiti. I requisiti non fissati da un punto di vista non forniscono alcuna guida utile per gli sviluppatori. Utilizzando i tuoi esempi pubblicati:

• Riscrivi la cache degli oggetti. Perché? Qual è l'obiettivo? Chi riceve il vantaggio? Chi può fornire chiarimenti sull'attività? Se questo è legato a un requisito non funzionale, quale obiettivo del progetto viene affrontato?
• Implementare la registrazione del sistema. Perché? Chi leggerà i registri? Quali informazioni devono contenere i registri? Come saprai se il formato del registro o i dati del registro sono utili?

Dal punto di vista di uno sviluppatore, non essere in grado di rispondere a questo tipo di domande porta esattamente al tipo di problemi di processo che descrivi. Ecco cosa fanno le storie degli utenti: forniscono il contesto tanto necessario e fungono da segnaposto per ulteriori conversazioni con le parti interessate o gli utenti finali su funzioni specifiche.

Non dovresti usare le storie degli utenti perché pensi che sia un requisito quadro o perché è una pratica agile ampiamente accettata. Invece, dovresti lavorare per crearli e utilizzarli in modo efficace perché semplifica le attività di programmazione e rende più divertente la professione di programmatore. Il tuo chilometraggio può variare, ovviamente.

Non penso che il problema qui sia Scrum in quanto tale, penso che il problema sia che non esiste un progetto chiaramente definito da consegnare e (ho sperimentato molte volte) nessuna direzione chiara.

Penso che i tuoi compiti tecnici vadano bene, possibilmente su vasta scala ma misurabili e definibili, quindi assolutamente perfetti per una storia.

I compiti di ricerca sono una grande bandiera rossa per me in Scrum perché forniscono pochi benefici visibili e possono creare enormi ostacoli. Sostengo di limitare questi in anticipo in uno sprint, non dovrebbero essere aggiunti e certamente non dovrebbero essere aggiunti a scapito degli obiettivi impegnati. Se fossero necessari per completare un'attività di sprint concordata, tale dipendenza avrebbe dovuto essere chiara in fase di pianificazione (altrimenti, cosa stavano stimando?).

Nella mia esperienza, i progetti con molti "picchi di indagine" sono una copertura per gli sviluppatori che in realtà non fanno molto e vogliono passare il tempo a scoprire le nuove cose fantastiche piuttosto che a creare valore commerciale. Non sto suggerendo che il tuo team lo stia facendo, ma un progetto ha bisogno di obiettivi chiari e se gli sviluppatori hanno la libertà di "ricercare", lo faranno e continueranno a farlo, fino a quando lo consentirai.

Scrum dice che è meglio avere un prodotto consegnabile per i tuoi clienti. Tuttavia, il punto qui è che non specifica il prodotto consegnabile e il cliente .

In altre parole, nel tuo caso specifico, potresti definire il tuo prodotto consegnabile come miglioramenti del codice, modifiche alla piattaforma, riscritture e riprogettazioni, ecc. E considerare il tuo responsabile tecnico come il tuo cliente.

Questo ha il 100% di senso per me. Crei un backlog che racconta le storie dell'utente dei tuoi prodotti e chi è l'utente? Responsabile tecnico. Quindi articoli come:

1. Come responsabile tecnico, voglio che il mio database cambi da MySQL a X, in modo da poter aumentare la scalabilità
2. Come sviluppatore, desidero un sistema di registrazione completo, in modo da poter diagnosticare in modo più efficiente

E ciò che consegni al tuo cliente (responsabile tecnico) è un sistema di registrazione.

Tuttavia, per quanto riguarda le attività di ricerca e sviluppo di cui hai parlato, ti consiglio di leggere i picchi in Scrum. Si tratta essenzialmente di mini-attività temporizzate che consentono di determinare il tempo necessario per eseguire attività non familiari più grandi.

Come Scrum Master, potresti prendere in considerazione sprint più lunghi a causa della natura del lavoro. Questo ti darà un po 'più di un buffer per le attività di "ricerca". Tuttavia, penso che sia necessario assicurarsi che le attività producano una sorta di prodotto di lavoro / prova del concetto nel codice. Che cosa ti aspetti che faccia un programmatore? Chiedi loro di far funzionare qualcosa e usa queste informazioni per determinare se A: fa quello che vogliamo B: funziona meglio C: Quanto tempo ci vorrà per essere più veloce e iniziare a farti un'idea di quanto tempo prendere per fare qualcosa.

Se scopri di non sapere quanto pensavi dell'attuale riscrittura, puoi passare a cicli di sprint più brevi. Non aver paura di adattarli mentre procedi; questo è ciò che si intende per essere agili. Dopo la tua ricerca potresti anche decidere di utilizzare la nuova tecnologia. Questo potrebbe essere un altro motivo per abbreviare gli sprint prima di andare troppo fuori controllo. Potresti scoprire nel mezzo di uno sprint che le nuove cose non funzioneranno. Ferma lo sprint e regolalo con la vecchia tecnologia. Dopotutto, i tuoi sviluppatori avrebbero dovuto essere in grado di confrontare e confrontare i vecchi e i nuovi metodi.

Stai destreggiando tra le esigenze dei tuoi sviluppatori e in questo caso stai riscrivendo l'applicazione. Immagino che ci siano proprietari di prodotti che desiderano che questo progetto venga completato prima piuttosto che dopo e non accetteranno la necessità di "ricerca" come scusa a lungo termine.

Alcune delle strategie di seguito potrebbero aiutare,

1. Sì, puoi avere un backlog con storie tecniche .

   Come una storia utente, anche queste dovrebbero essere storie tecniche, incentrate sui vantaggi che porterà all'utente finale. Ecco alcuni suggerimenti per scriverlo. Queste sono storie che porteranno valore intrinseco al prodotto come se volessi passare a un back-end migliore, ecc.

2. Per le attività di ricerca (ricerca) utilizzare Spike

   Un picco è un esperimento che consente agli sviluppatori di apprendere quanto basta su qualcosa di sconosciuto in una user story, ad esempio una nuova tecnologia, per essere in grado di stimare quella user story. Un picco deve essere time-boxed. Questo definisce il tempo massimo che verrà impiegato per l'apprendimento e fissa la stima per il picco.