Abbattere una storia complessa all'inizio del progetto

Sto cercando di fare i conti con la gestione agile del progetto (con Pivotal Tracker), ma continuo a ritrovarmi a sbattere contro i muri quando provo a definire le prime storie di un progetto. Prendi ad esempio questa storia molto semplice:

"Un utente dovrebbe essere in grado di taggare un prodotto"

Supponendo che abbia già definito "prodotto" altrove, questa storia implicherebbe probabilmente la scrittura di un sistema di etichettatura polimorfica sotto il cofano, al completamento di tale sistema potrei finalmente aggiungere la possibilità di taggare un prodotto.

Il mio problema è con la quantità di lavoro nascosta in questa storia. Posso definire compiti per portare a termine la storia, ma le storie nel loro insieme dovrebbero essere 1-2 giorni di lavoro? Non mi sento a mio agio sulla storia rivelando solo la punta dell'iceberg, ma questa è l'unica parte relativa all'utente.

Come si supera questo tipo di cose? Quali sono le migliori pratiche?

AGGIORNAMENTO 25/08 Grazie a tutti per la vostra guida, ho preso tutti i consigli a bordo su come definire le storie. Ora sto passando a Jira Grasshopper, che offre un migliore supporto per le attività all'interno di storie (compiti, stime, ecc.) E il monitoraggio delle attività di sviluppo una volta iniziato lo sprint.

Se hai bisogno che le tue storie durino da 1 a 2 giorni di lavoro dello sviluppatore ciascuna, forse dovresti suddividere ciascuna storia in attività specifiche per l'utente che sono da 1 a 2 giorni di lavoro dello sviluppatore.

Considera la seguente "user story:"

Un utente dovrebbe essere in grado di ricevere una fattura da un prodotto acquistato.

Pensa a ciò che è coinvolto solo nella progettazione del database, nel dare all'utente questa capacità. Hai bisogno di una tabella dei 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 includono una procedura dettagliata dei passaggi dell'utente coinvolti:

• L'utente inserisce il prodotto nel carrello
• L'utente specifica la quantità
• L'utente specifica il tipo di spedizione

e così via. In breve, è necessario suddividere le storie degli utenti in dettagli più precisi.

Le storie non dovrebbero essere "1-2 giorni di lavoro". Sotto Scrum le storie sono normalmente stimate usando Story Points, un sistema di dimensionamento relativo. Se usi la pianificazione delle storie di poker viene assegnato un valore in punti - il tempo necessario per implementare la storia dipende dalla velocità stabilita dalla tua squadra.

Se ritieni che la storia nasconda la complessità (potresti chiamarla storia epica ), dovresti spezzarla in storie più piccole. Assicurati che le nuove storie seguano i criteri di INVEST .

Ma potresti essere troppo ingegnoso; il principio XP di YAGNI si applica qui. Per essere espliciti non dovresti implementare un "sistema di marcatura polimorfica 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 tagging, dovresti richiamare la complessità in storie separate. Mike Cohn descrive l'approccio al design come " intenzionale, ma emergente "

Sembra che tu stia confondendo storie e compiti.

User Story

Una user story è una "caratteristica" completa, qualcosa che se aggiunto 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 dello sprint, decidi su quali user story vuoi lavorare durante lo sprint. L'obiettivo dello sprint è completare queste storie utente, aggiungendo così più valore al prodotto.

Compito

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 dovrebbe essere più grande di quanto possa essere completata in un giorno.

Durante la mischia quotidiana si valuta l'avanzamento di queste attività. Se un'attività è in corso da più di una mischia giornaliera, sta impiegando troppo tempo e tu, come squadra, hai la responsabilità di risolvere quella situazione.

Ricorda, le storie degli utenti rappresentano un valore commerciale per gli stakeholder. I portatori di interessi dovrebbero essere interessati al completamento delle storie degli utenti, non alle 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.

Le parti interessate non dovrebbero occuparsi di questi compiti di sviluppo. Sfortunatamente, è la mia esperienza che lo fanno spesso, in particolare per le organizzazioni nuove allo sviluppo agile. Affrontare questa situazione è una questione diversa.

Epico

Se una user story è più grande di quanto pensi di poterla completare in uno sprint, si chiama epica. Deve essere diviso in più user story prima che tu possa iniziare a lavorarci su come un team.

Ricorda che una user story aggiunge valore all'utente finale, quindi dividere un'epopea in una "front-end" e una "back-end" non è la strada giusta. L'aggiunta del back-end per una nuova funzionalità non fornisce di per sé valore agli utenti finali.

Dividere un'epopea in storie utente gestibili nel periodo di 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 mischia in quanto tale, e il modo in cui la mischia insegna a dividere le storie in compiti non è facilmente gestibile dal tracker cardine. È possibile abilitare la possibilità di aggiungere attività alle storie utente. Ma se stai gestendo un progetto usando Scrum, suggerirei di usare una lavagna bianca e note adesive per tenere traccia dell'avanzamento delle attività durante uno sprint.

Avere un obiettivo di progettazione nell'implementazione di un sistema di marcatura polimorfica va bene, ma dovresti comunque concentrarti sull'implementazione delle funzionalità che il cliente desidera. Ciò potrebbe significare che, User-Story-grained fine User-grained-User-Story, il sistema si evolve nel tempo con un sistema di marcatura polimorfica. In qualsiasi momento di quel viaggio, tuttavia, dovresti avere un sistema composto da molte 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'epica, ovvero qualcosa che è molto più grande di una singola User Story e può essere suddivisa 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 desidero eseguire il seeding del sistema con alcuni tag validi in modo che gli utenti abbiano alcuni valori tra cui scegliere al primo utilizzo della funzione di tagging.
• Come utente del sistema voglio essere in grado di cercare un prodotto per nome in modo da poterlo taggare in seguito.
• Come utente del sistema voglio poter leggere la descrizione di un prodotto in modo da poter decidere quali tag dovrebbe avere.
• Come utente del sistema voglio poter vedere un'immagine del prodotto in modo da poter decidere quali tag dovrebbe avere.
• Come utente del sistema, voglio essere in grado di allegare un singolo tag a un singolo prodotto.
• Come utente del sistema voglio poter rimuovere un singolo tag da un singolo prodotto.
• Come utente del sistema, voglio essere in grado di allegare un singolo tag a più prodotti.
• Come utente del sistema, voglio essere in grado di allegare più tag a un singolo prodotto.
• Come amministratore di sistema voglio vedere un elenco distinto di tag in uso nel sistema in modo da poter decidere se uno di essi è duplicato.
• Come amministratore di sistema voglio consolidare i tag duplicati.

... e potrei continuare.

Dubito che uno qualsiasi di questi sarà così realistico che li userete, ma spero che illustrino il tipo di dettagli a cui potete andare con le vostre User Story.

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

Prendendo ancora più licenza artistica, potrei dividere "Come utente del sistema voglio essere in grado di collegare 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 da poter decidere quale applicare.
• Come utente del sistema che guarda un singolo prodotto, avendo deciso un tag da applicare a quel prodotto, voglio essere in grado di applicarlo.
• 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 di per sé.

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

Spesso trovo team di sviluppo che cercano soluzioni complesse invece di quelle più semplici. Ciò potrebbe essere dovuto alla storia stessa o perché il team vuole cercare una soluzione troppo complessa che non solo risolva questa storia, ma getta le basi anche per le storie x, ye z. Questa è una buona intenzione, ma gonfia l'ambito in cui lo stesso lavoro può essere fatto con meno lavoro. È sempre difficile giudicare la quantità di design che deve andare in una storia per non rovinare le storie future rovinando il design. Questa decisione spetta al team.

In quanto proprietario del prodotto, puoi influenzarlo solo suddividendo le storie in pezzi più piccoli. Dovresti chiederti: la storia è la soluzione più piccola a cui possiamo pensare in questo momento? Possiamo scomporlo in set di funzionalità ridotte che un giorno diventeranno il "grande sistema di tagging flessibile che ho sempre desiderato". È possibile iniziare con un sistema di tag per un solo tag, quindi estenderlo per includere un elenco di tag preselezionati e quindi consentire all'utente di definire tag, ecc.

Per il team di sviluppo si riduce a: possiamo trovare un approccio più semplice per realizzare la storia, ma avere ancora una solida architettura che compie il lavoro oggi 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, probabilmente troverai il punto debole in cui la dimensione delle storie che vuoi fare è giusta (più piccola è, 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 pezzi più piccoli.