A quale livello PBI dovrei creare rami?

Question

A quale livello PBI dovrei creare rami?

#1 da (5 voti)

5

Ho commesso l'errore di creare rami a livello User Story. Vedi: User Story! = Funzioni .

Credo di averlo fatto in questo modo a causa della mia scarsa pratica nell'organizzazione di Funzionalità ed Epopee che sono sia permanenti che realmente organizzative per postare le storie sottostanti ( EG. Migliorare la home page \ Come inserzionista,. .. ).

Qual è un modo migliore per creare Epic e funzionalità?

.

Da quando uso Epics e Features per organizzare il backlog, i miei collaboratori e amp; Li ho utilizzati per determinare dove creare User Story. Il problema con questo, credo, è piuttosto che avere solo User Story orfane che io, in quanto designer, dovrei determinare in base a quali storie di caratteristiche appartengono. Questo ha creato un fenomeno in cui le User Story vengono duplicate perché il creatore non si rende conto che esiste già in una "caratteristica" diversa.

Quindi, dovrei richiedere che le User Story vengano create orfane piuttosto che in seguito, determinando in base a quale caratteristica appartengono? Piuttosto che lasciare che i proprietari dei prodotti provino a decidere in base a quale caratteristica appartiene una storia.

.

Un ulteriore timore che ho di questo cambiamento nella pianificazione, si sta sviluppando in base alle User Story spostate abbastanza velocemente, unendo il ramo Story indietro al ramo Principale una volta completato, quindi distribuendo.

Posso ancora mantenere rapide implementazioni mentre lavoro su un ramo Feature invece di un ramo Story, unendoci con Main alla 'fine' di ogni Story e poi continuando alla successiva Story nel ramo Feature?

.

Inoltre, forse un metodo più diretto e potente, un esempio in questo caso può fornire più contesto rispetto a tutte le risposte precedenti.

Fornisci un esempio reale di un ramo e di eventuali Storie, Funzionalità, Attività, Epic contenuti nei tuoi progetti di sviluppo del mondo reale.

.

Ecco un mock diagram del mio backlog

(E-#) Epic

(F-#) Feature

(S-#) Story | (B-#) BUG

(T-#) Task

(E-1) Sitewide Improvements

(F-2) CMS

(S-3) As a developer, I want to audit @inherits on cshtml pages, and see how I can better use Strongly Typing pages

(S-4) Upgrade to CMS Version 7.5.8

(T-5) backup

(T-6) Nuget upgrade

(T-7) run upgrader

(T-8) merge config files

(E-9) Improve Public facing site

(F-10) Improve Homepage

(S-11) As an advertiser, I want my ads to show on the homepage, so my ad have better visibility

(F-12) Improve Reviews

(S-13) As a traveler, I want to be able to sort reviews by # of stars, so I can look at reviews with the # I am interested in

(T-14) Create a sorting logic in a function to accomplish this

(T-15) Create the proper UX to request sorting

(S-16) As a traveler, I don't want to see old reviews, as they don't represent well

(F-17) Improve Articles Page

(S-18) As a reader, I want to articles tagged, so that I can view other articles with tags I am interested in.

(E-19) Improve Client backend portal site

(F-20) Account Management

(S-21) As a portal user, I want notification to be emailed to me, so that I know what is happening

(F-22) Ad Manager

(S-23) As an advertiser, I want to set budgets on a per advertisment basis, so that I can have greater control.

(S-24) As an advertiser, I want to be able to upload my on images, so that I can better customize my ads.

(F-25) Billing Manager

(S-26) As an portal admin, I want to be able to see past statements, so I can understand past charges.

version-control branching project-management scrum user-story

posta Devin Gleason Lambert 20.02.2017 - 20:19

fonte

1 risposta

Leggi altre domande sui tag version-control branching project-management scrum user-story

Best practice per i messaggi di commit Git per moduli specifici Come andresti a creare un algoritmo di ricerca per un CRM?

score 5 · Answer 1

Sembra che tu stia combinando diverse cose che dovrebbero rimanere separate.

Prima di tutto: la tua strategia di ramificazione e la tua struttura di suddivisione degli elementi di lavoro non devono necessariamente corrispondere. La strategia di ramificazione dovrebbe essere utilizzata per comunicare come hai ottenuto il codice sorgente che hai, ma non è stato necessario seguire pedissequamente la disaggregazione dell'oggetto di lavoro.

Secondo: le storie utente e le funzionalità non sono necessariamente la granularità con cui vengono distribuite nuove versioni. Potresti aver bisogno di un'intera epop o di più epiche implementate prima di inviare una nuova versione ai clienti. Ciò non significa che devi tenere una branca a parte per tutta la durata dell'attuazione di quell'epica; potresti volere le pubblicazioni interne molto più spesso, quindi devi integrarti regolarmente. Ciò è aiutato dall'utilizzo, ad es. funzione alterna.

Terzo: la struttura di suddivisione dell'elemento di lavoro non è il miglior repository per codificare la conoscenza di quali funzionalità sono state implementate. Sarebbe saggio ad es. mantenere un documento nell'albero dei sorgenti che descriva tutte le storie utente che sono state implementate. Mantenere quel documento leggibile e ben organizzato è parte del tuo lavoro di sviluppo e aiuta a rispondere alla domanda "come si integra questa storia utente con il resto del programma?", Con la quale sembra anche che tu lotti. Si noti che non è affatto negativo avere la stessa user story in più oggetti di lavoro; questo significa solo che vedi che quella storia utente deve funzionare per molteplici ragioni. Può anche darsi che le occorrenze della stessa user story siano separate nel tempo di mesi ... nel qual caso un documento nell'albero dei sorgenti è molto preferibile rispetto alla cronologia degli oggetti di lavoro su cui si lavora. Per i calci extra è possibile automatizzare il controllo delle storie degli utenti in modo che il documento diventi documentazione vivente.

Spero che questo chiarisca un po 'le cose.

Una cosa da notare è che sembra che si mischino i livelli di astrazione nel backlog del prodotto; cercare di mantenere il valore in mente quando si scrivono le storie degli utenti aiuta a evitare quella trappola, e un modo per farlo è far scattare la pila di motivi. Per esempio. nel caso di "Come amministratore del portale, voglio essere in grado di vedere le dichiarazioni passate, quindi posso capire le accuse del passato" si potrebbe chiedere "Perché voglio capire le spese passate?", e così via, fino al valore fornito è cristallino.