Scrum può utilizzare le specifiche tecniche nel Product Backlog piuttosto che nelle user story?

TL; DR

Scrum non impone l'uso di storie utente; sono semplicemente una pratica agile utile. Sebbene il Product Owner possa certamente utilizzare le specifiche tecniche invece degli user story per creare il Product Backlog, la maggior parte degli altri problemi di processo derivano dal mancato rispetto di pratiche Scrum e agili efficaci.

Vari problemi con il tuo processo

Il tuo Scrum sembra essere rotto in una varietà di modi, tra cui:

1. Le tue specifiche mancano di un punto di vista esplicito o di una proposta di valore.
2. Gli elementi del tuo backlog non sono legati agli obiettivi di Sprint.
3. Il tuo processo di gestione del backlog manca completamente o non riesce a creare picchi di storia per il Product Backlog.
4. Il processo di Sprint Planning non sta adeguatamente scomposendo gli articoli del Product Backlog in Sprint Backlog items.
5. Il tuo team non include correttamente l'incertezza sugli elementi del backlog nelle sue stime di Sprint Planning.
6. Il tuo team non rispetta i fondamenti del time-boxing o dell'integrità dello Sprint.

Mentre Scrum è non sempre adatto per ogni progetto, in questo caso sarebbe più accurato dire che Scrum non funziona perché il team non sta facendo davvero Scrum. La tua domanda relativa alle storie degli utenti è solo una piccola parte dei problemi di processo più importanti per il tuo team.

Perché i programmatori agili abbracciano le storie degli utenti

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

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

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

Non dovresti usare storie utente perché ritieni che sia un requisito di struttura o perché è una pratica agile ampiamente accettata. Invece, dovresti lavorare sulla creazione e sul loro utilizzo efficace perché rende più semplici le attività di programmazione e la professione di programmazione più divertente. Il tuo chilometraggio può variare, naturalmente.

Non penso che il problema qui sia Scrum in quanto tale, penso che il problema sia che non esiste un progetto chiaramente definito e (ho avuto esperienze diverse) una direzione chiara.

Penso che i tuoi compiti tecnici vadano bene, forse dal lato grande, ma misurabili e definibili quindi assolutamente perfetti per una storia.

I compiti di ricerca sono una grande bandiera rossa per me in Scrum perché offrono scarso beneficio visibile e possono creare un enorme slittamento della portata. Io sostengo di limitare questi anticipi in uno sprint, non dovrebbero essere aggiunti e certamente non dovrebbero essere aggiunti a spese degli obiettivi impegnati. Se sono necessari per completare un compito di sprint concordato, quella dipendenza dovrebbe essere stata chiara nella pianificazione (altrimenti, cosa stavano stimando?).

In base alla mia esperienza, i progetti con molti "picchi investigativi" sono una copertura per gli sviluppatori che in realtà non stanno facendo molto e desiderano trascorrere del tempo a trovare informazioni sulla nuova brillante idea piuttosto che creare valore per il business. Non sto suggerendo che la tua squadra stia facendo questo, ma un progetto ha bisogno di obiettivi chiari e se agli sviluppatori viene data la libertà di "ricercare", allora lo faranno e continueranno a farlo, finché lo permetteranno.

Scrum dice che è meglio avere un prodotto consegnabile al cliente. Tuttavia, il punto qui è che, non specifica il prodotto e il cliente .

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

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

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

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

Tuttavia, per quanto riguarda le attività di R & D di cui hai parlato, ti consiglio di leggere su picchi in Scrum. Sono essenzialmente mini-task in time-box che ti aiutano a determinare il tempo necessario per eseguire attività non familiari più grandi.

Come Scrum Master, potresti prendere in considerazione gli sprint più lunghi a causa della natura del lavoro. Questo ti darà un po 'più di un buffer per i compiti di "ricerca". Tuttavia, penso che sia necessario assicurarsi che le attività producano una sorta di prodotto di lavoro / prova di concetto nel codice. Che cosa ti aspetti da un programmatore? Chiedete loro di ottenere qualcosa da lavorare e utilizzare queste informazioni per determinare se A: fa ciò che vogliamo B: funziona meglio C: Quanto ci vorrà per ottenere più up-to-speed e iniziare a farsi un'idea di quanto tempo sarà prendere per fare qualcosa.

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

Stai facendo i conti con le esigenze dei tuoi sviluppatori e in questo caso stai riscrivendo l'applicazione. Immagino che ci siano Product Owner che desiderano che questo progetto venga completato prima piuttosto che dopo e non accetteranno la necessità di una "ricerca" come scusa a lungo termine.

Alcune delle seguenti strategie possono aiutare,

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

   Come in una storia di un utente, anche questo dovrebbe essere Storie tecniche, che si concentrano sui vantaggi che porteranno all'utente finale. Ecco alcuni suggerimenti per scriverlo. Queste sono storie che porteranno un valore intrinseco al prodotto come se si desidera passare a un back-end migliore ecc.

2. Per attività di ricerca (ricerca) Usa Spike

   Un picco è un esperimento che consente agli sviluppatori di apprendere quanto basta su qualcosa di sconosciuto in una storia utente, ad es. una nuova tecnologia, per essere in grado di stimare quella storia utente. Un picco deve essere time-boxed. Questo definisce il tempo massimo che verrà speso per l'apprendimento e corregge la stima per lo spike.