Abbattere una storia complessa all'avvio del progetto

Se hai bisogno che le tue storie siano da 1 a 2 giorni di lavoro degli sviluppatori, forse dovresti suddividere ciascuna storia in compiti utente specifici che sono da 1 a 2 giorni di lavoro dello sviluppatore.

Considera la seguente "user story:"

A user should be able to receive an invoice from a purchased product.

Pensa a ciò che è coinvolto solo nella progettazione del database, nel dare all'utente questa capacità. Hai bisogno di una tabella clienti, una tabella dell'intestazione della fattura e una tabella degli elementi pubblicitari della fattura e non abbiamo ancora parlato dell'accettazione dei pagamenti.

In realtà, le storie degli utenti non sono così semplici. Le storie utente complete comprendono una procedura dettagliata dei passaggi dell'utente coinvolti:

• User puts product in cart
• User specifies quantity
• User specifies shipping type

e così via. In breve, devi abbattere le tue storie utente in dettagli più precisi.

Le storie non dovrebbero essere, "1-2 giorni di lavoro". Le storie di Scrum sono normalmente stimate usando Story Points, un sistema di dimensionamento relativo. Se usi pianificazione del poker ai racconti viene assegnato un valore in punti: il tempo che la storia impiega per implementare dipende dalla velocità che la tua squadra ha stabilito.

Se ritieni che la storia stia nascondendo la complessità (puoi chiamarla Epic storia) , dovresti suddividerlo in storie più piccole. Assicurati che le nuove storie seguano i criteri INVEST .

Ma potresti essere troppo impegnativo; il principio XP di YAGNI si applica qui. Per essere espliciti non dovresti implementare un "sistema di tagging polimorfico sotto il cofano", a meno che tu non ne abbia davvero bisogno. Anche allora, dovrebbe essere progettato migliorando il sistema esistente, che hai sviluppato con una buona serie di test.

Se sei sicuro di aver bisogno di questo complesso sistema di codifica, dovresti richiamare la complessità in storie separate. Mike Cohn descrive l'approccio al design come " Intenzionale, ancora emergente "

Sembra che tu stia confondendo storie e attività.

User Story

Una User story è una "feature" completa, qualcosa che quando aggiunta al prodotto fornisce più valore al prodotto.

Una User story non dovrebbe essere più grande di quanto possa essere implementata durante uno sprint . Durante la prima parte della pianificazione sprint, decidi quali storie utente vuoi lavorare durante lo sprint. L'obiettivo dello sprint è completare queste storie utente, aggiungendo così più valore al prodotto.

attività

Durante la seconda parte della fase di pianificazione dello sprint, gli sviluppatori dividono la storia in attività . Le attività sono attività di sviluppo. Potrebbero essere cose come "Aggiungi colonna al database", "Estendi servizio x", ecc. Un'attività non deve essere più grande di quanto possa essere completata in un giorno.

Durante la mischia giornaliera, valuti lo stato di avanzamento di queste attività. Se un'attività è in corso da più di una mischia giornaliera, ci vuole troppo tempo e tu, come squadra, hai la responsabilità di risolvere quella situazione.

Ricorda che le storie degli utenti rappresentano un valore aziendale per gli stakeholder. I portatori di interesse dovrebbero essere interessati al completamento delle storie degli utenti, non delle attività.

La divisione attività è uno strumento per il team di sviluppo per gestire lo sprint, monitorare i progressi delle storie degli utenti durante uno sprint e visualizzare potenziali problemi.

I soggetti interessati non dovrebbero preoccuparsi di questi compiti di sviluppo. Sfortunatamente, è la mia esperienza che spesso fanno, in particolare per le organizzazioni nuove allo sviluppo agile. Affrontare questa situazione è una questione diversa però.

Epica

Se una user story è più grande di quanto pensi di poter completare in uno sprint, si chiama epico. Deve essere diviso in diverse storie di utenti più piccole prima che tu possa iniziare a lavorare su di esso.

Ricorda che una storia utente aggiunge valore all'utente finale, quindi suddividere un'epica in una trama "front-end" e una "back-end" non è la strada giusta. L'aggiunta del back-end per una nuova funzione non fornisce di per sé valore agli utenti finali.

La divisione di un'epica in storie utente gestibili nel tempo di uno sprint non è sempre facile quando non si ha esperienza nel farlo.

Utilizzo di Pivotal Tracker

Penso che Pivotal Tracker sia un ottimo strumento per tracciare le storie degli utenti. Ma non è uno strumento di miseria in quanto tale, e il modo in cui scrum insegna a dividere le storie in compiti non è facilmente gestibile da tracker chiave. Puoi abilitare la possibilità di aggiungere compiti alle storie degli utenti. Ma se stai eseguendo un progetto usando scrum, ti suggerirei di usare una lavagna bianca e delle note adesive per tenere traccia dell'avanzamento delle attività durante uno sprint.

Avere un obiettivo progettuale di implementare un sistema di codifica polimorfico va bene, ma è comunque necessario concentrarsi sull'implementazione delle funzionalità desiderate dal cliente. Ciò potrebbe significare che, una storia utente a grana fine con una storia a grana fine, il tuo sistema si evolve in un sistema di tagging polimorfico nel tempo. In qualsiasi punto del viaggio, tuttavia, dovresti disporre di un sistema costituito da numerose funzionalità piccole e testabili, descritte da una raccolta di User Story che hai implementato.

In questo caso sembra che "Tagging Products" nel tuo sistema potrebbe essere un Epic, cioè qualcosa che è molto più grande di una User Story e può essere suddiviso in diverse storie più piccole con un piccolo sforzo. Prendendo una buona quantità di licenza artistica, posso pensare alle seguenti User Story che potrebbero essere approssimativamente applicabili alle tue esigenze:

• Come amministratore di sistema, voglio seminare il sistema con alcuni tag validi in modo che gli utenti abbiano alcuni valori tra cui scegliere quando si utilizza la funzione di codifica per la prima volta.
• Come utente del sistema, desidero poter cercare un prodotto per nome in modo che possa taggarlo in un secondo momento.
• Come utente del sistema voglio essere in grado di leggere la descrizione di un prodotto in modo che possa decidere quali tag dovrebbe avere.
• Come utente del sistema voglio poter vedere un'immagine del prodotto in modo che possa decidere quali tag dovrebbe avere.
• Come utente del sistema, desidero poter allegare un singolo tag a un singolo prodotto.
• Come utente del sistema, desidero poter rimuovere un singolo tag da un singolo prodotto.
• Come utente del sistema, desidero poter allegare un singolo tag a più prodotti.
• Come utente del sistema, desidero poter allegare più tag a un singolo prodotto.
• Come amministratore di sistema voglio vedere un elenco distinto di tag in uso nel sistema in modo che possa decidere se qualcuno di questi è duplicato.
• In qualità di amministratore di sistema, desidero consolidare i tag duplicati.

... e potrei andare avanti.

Dubito che qualcuno di questi sarà così realistico da poter essere usato, ma si spera che illustrino il tipo di dettagli a cui puoi accedere con le tue User Story.

Se una User Story non può essere suddivisa in storie più piccole e la consideri ancora troppo grande per tentare di implementarla in una sola volta, puoi dividerla in sezioni verticali. Questa è una tecnica che significa fornire solo parte della funzionalità in ogni User Story, ma ogni parte è una sezione testabile attraverso tutti i livelli rilevanti della tecnologia, ad es. per un sito Web questo potrebbe significare cambiare il database, l'applicazione e i livelli dell'interfaccia utente. Evita di avere una User Story per il lavoro del database, un'altra per l'applicazione e un'altra per l'interfaccia utente, in quanto non saranno testabili individualmente.

Prendendo una licenza ancora più artistica, potrei dividere "Come utente del sistema, voglio essere in grado di allegare un singolo tag a un singolo prodotto." nelle seguenti sezioni verticali:

• Come utente del sistema che guarda un singolo prodotto, voglio essere in grado di cercare un elenco di tag in modo che possa decidere quale applicare.
• Come utente del sistema che osserva un singolo prodotto, dopo aver deciso un tag da applicare a quel prodotto, voglio poterlo applicare.
• Come utente del sistema che guarda un singolo prodotto, dopo aver applicato un tag a quel prodotto, voglio un messaggio di conferma sullo schermo che mi dice che è stato salvato con successo.

Ognuno di questi è testabile, se non particolarmente prezioso per sé.

Ci sono libri scritti con il solo scopo di trovare il modo corretto di descrivere e abbattere le tue esigenze. Quindi non è un compito facile.

Spesso, a volte, i team di sviluppo cercano soluzioni complesse invece di quelle più semplici. Ciò potrebbe essere dovuto alla storia stessa o perché la squadra vuole andare per una soluzione eccessivamente complessa che non solo risolve questa storia ma pone anche le basi per le storie x, yez. Questa è una buona intenzione, ma dilata lo scopo in cui lo stesso lavoro può essere svolto con meno lavoro. È sempre difficile giudicare quanto il design debba essere inserito in una storia per non rovinare le storie future rovinando il design. Questa decisione è per la squadra.

Come proprietario del prodotto puoi influenzarlo solo suddividendo le storie in parti più piccole. Dovresti chiederti: la storia è la soluzione più piccola a cui possiamo pensare in questo momento? Possiamo suddividerlo in set di funzionalità ridotte che un giorno diventerà il "grande sistema di codifica flessibile che ho sempre desiderato". Puoi iniziare con un sistema di tag solo per un singolo tag, quindi estenderlo per includere un elenco di tag preselezionati, quindi consentire all'utente di definire i tag, ecc.

Per il team di sviluppo si riduce a: Possiamo trovare un approccio più semplice per realizzare la storia, ma avere comunque una solida architettura che oggi assolva il lavoro senza compromettere le funzionalità future.

Se sei aperto ad accettare soluzioni intermedie e il team di sviluppo cerca anche di offrire la soluzione più semplice, ma buona, allora probabilmente troverai il punto debole in cui la dimensione delle storie che vuoi fare è giusta (il più piccolo meglio è). Questo non vuol dire che hai solo piccole storie. Alcuni sono più grandi di altri, questo è solo un fatto che devi accettare, o se sono troppo grandi, quindi suddividere le storie in parti più piccole.