Attività di sviluppo condivise per storie utente agili

Naviga le tue risposte
9

Il mio team utilizzerà Visual Studio Team Services per un progetto imminente. Gli strumenti Agile consentono di organizzare gerarchicamente User Story e attività in questo modo:

Epic > Funzionalità > User Story > Attività / Bug

Diciamo che sto progettando un sistema di gestione Student Org (club) per studenti e consulenti delle scuole superiori. Studenti e consulenti possono iscriversi ai club, essere ufficiali, organizzare eventi, inviare annunci, ecc.

Prendiamo come esempio la funzione Annunci:

User Story:

  • Come studente, voglio leggere gli annunci per i club di cui faccio parte di modo che io sappia delle modifiche di programma.
  • In qualità di consigliere, desidero leggere gli annunci per i club di cui faccio parte in modo che conosca i cambiamenti di programma.
  • In qualità di consigliere, desidero inviare annunci per i club di cui faccio parte affinché i miei studenti siano a conoscenza dei cambiamenti di programma
  • In qualità di amministratore, desidero inviare annunci a TUTTI i club scolastici in modo che io possa renderli consapevoli dei conflitti di programmazione.
  • etc

Se assumiamo che queste siano User Story ben scritte (che potrebbero non essere), mi confondo quando il mio team di sviluppo e io ci sediamo per suddividere questi elementi in attività di sviluppo. Possiamo coprire parti di diverse User Story con singole attività di sviluppo. Ad esempio, abbiamo uno strumento che genera azioni CRUD per tutti i livelli dall'interfaccia utente al DB semplicemente definendo le proprietà di un annuncio. Pertanto, le parti di diverse "User story" di "invio" e "lettura" vengono completate in un unico passaggio di sviluppo.

Da quello che ho letto, ogni User Story dovrebbe essere indipendente dalle altre e questo ha senso. Ma ciascuna delle nostre User Story condivide l'attività "Genera UI e DB" perché è così che creiamo la nostra interfaccia utente di livello base (prima di personalizzarla). Non dovrei scrivere un'attività "Genera UI e DB" per ogni User Story. È troppo ridondante. Ma non so come scrivere un'attività "Genera UI e DB" che deve essere completata prima di poter avviare una delle User Story.

Ho una simile confusione con il nostro sistema di autorizzazione. Abbiamo diversi tipi di account come Studente, Consulente e Amministratore che hanno tutti accesso alla pagina degli Annunci, ma hanno diverse funzionalità all'interno della pagina (ho catturato questa idea con le User Story sopra). Possiamo scrivere il sistema dei permessi per essere modulari in modo che possa essere utilizzato per altre funzionalità, ma non so dove scrivere l'attività per creare un "sistema di autorizzazione modulare".

Credo che tutta questa storia User Story mi abbia confuso. Sì, è ottimo per catturare la funzionalità di un sistema, ma quando si tratta di pensare allo sviluppo di Task, non riesco a spiegarmelo. Qualsiasi consiglio sarebbe fantastico.

TL; DR: Alcuni dei programmi che faccio per una User Story possono essere utilizzati altrove nel nostro progetto per altre User Story (sistema di autorizzazione, ecc.). Come posso scrivere / organizzare attività per le User Story per illustrare questa possibilità?

    
posta Schmidty15 19.07.2018 - 17:48
fonte

2 risposte

11

I shouldn't write a "Generate UI and DB" Task for each User Story. That's too much redundancy. But I don't know how to write a "Generate UI and DB" task that must be completed before any of the User Stories can be started.

Non .

Scrivi le tue storie degli utenti in base alle esigenze dell'utente di alto livello: sei arrivato così lontano.

Quindi scegli la storia utente (funzionalità) che dovrai affrontare per prima. A questo punto, dato lo stato attuale del prodotto, decidi il modo migliore per implementare questa funzione. Quindi esegui il lavoro tecnico minimo richiesto per implementare la funzione. Poi passerai alla prossima user story.

Potrebbe funzionare come segue:

  • Ci sediamo per fare la storia utente 1 e identificare che richiede un database. Quindi implementiamo il database e quindi la funzione.
  • Ci sediamo per fare la user story 2 e identifichiamo che - hey - abbiamo già il database, quindi ora abbiamo solo bisogno di estendere l'interfaccia.

O nel tuo esempio potrebbe anche funzionare come segue:

  • Ci sediamo per implementare l'invio di un annuncio. Costruiamo un'interfaccia utente con una casella di testo e un pulsante di invio che rende un messaggio di posta. Back-end, non succede nulla. Freddo. User story complete.
  • Ora ci sediamo per implementare gli annunci di ricezione ... indovina che è ora di iniziare a fare qualcosa con loro quando vengono inviati.

L'intero scopo di questo processo è quello di impedirti di progettare tutto in anticipo e di prendere decisioni informate su come implementare la prossima cosa data la corrente stato del software. Questo è direttamente incompatibile con il tentativo di suddividere tutte le storie in compiti tecnici prima di iniziare qualsiasi di esse.

Quindi puoi solo progettare la soluzione una volta che raccogli la storia e evolvi il tuo progetto una funzione alla volta. Come (e anche se) documenterai il tuo disegno tecnico quando decidi di iniziare a lavorare su una storia.

Se due sviluppatori raccolgono due storie contemporaneamente e condividono entrambi i requisiti tecnici, ciò ti sta dicendo che non puoi eseguire questi lavori in parallelo, quindi sceglierne uno e fare l'altro dev fare qualcos'altro.

Lo scopo qui è di implementare soluzioni semplici e rivedere il tuo design quando emergono nuovi requisiti.

E, soprattutto, ricorda: questa non è una scienza .

    
risposta data 19.07.2018 - 18:24
fonte
2

Dato che stai partecipando a ogni sprint con un elenco di storie con priorità, e ogni storia è suddivisa in attività tecniche separate, tutti gli sviluppatori dovrebbero lavorare su attività per la storia con la priorità più alta prima di iniziare a lavorare sulla seconda storia con la priorità più alta . Per questo motivo, quando inizi a lavorare sulla seconda priorità, l'attività "Genera UI e DB" dovrebbe essere già stata completata come parte della prima storia. Pertanto, se durante la pianificazione dello sprint trovi che un'attività tecnica viene duplicata su più storie, attribuisci tale attività alla storia con priorità più alta in modo che venga completata per prima.

Se la tua squadra ha l'abitudine di riorganizzare le priorità della storia una volta iniziato lo sprint, potresti vedere dei vantaggi nell'includere attività tecniche duplicate su ogni storia e prendere nota del compito di cui altre storie lo utilizzano.

Potrebbe essere utile entrare nella mentalità di lavorare da un elenco di attività tecniche anziché da un elenco di storie.

    
risposta data 25.07.2018 - 10:56
fonte

Leggi altre domande sui tag

Qual è il modo di capire il codice spaghetti gigante non commentato di qualcun altro? [duplicare] Perché GCC utilizza la sintassi AT & T per impostazione predefinita?