come suddividere le richieste di funzioni in unità di lavoro [chiuso]

Ciò cambierà da persona a persona e da impresa a impresa, il modello che vedo più spesso suddivide la richiesta in unità consegnabili (una o più in base all'ambito della richiesta) Quelle unità diventano i biglietti e i biglietti avrà un elenco di attività generalizzato creato da un analista. Tale ticket verrà assegnato a uno sviluppatore che esaminerà quindi le attività, sospirando un po 'e quindi suddividendole in un elenco di attività dettagliato dell'unità di codifica.

A questo sviluppatore verrà quindi chiesto di assegnare un numero arbitrario% completo al ticket e aggiornare quel numero arbitrario con una stima arbitraria ogni X giorni arbitrari o Project Manager arbitrario li infastidirà o, peggio ancora ... li trascinerà in una riunione di status

Request (from Customer)
   |
   |-- Deliverable Unit 1(Ticket Item -from analyst - distinct publishable item) 
   |-- Deliverable Unit 2 
   |-- Deliverable Unit 3
            |
            |---Generalized Task Item 1(from analyst - generic to-do list item needed to complete Deliverable Unit)
            |---Generalized Task Item 2
            |---Generalized Task Item 3
            |---Generalized Task Item 4 
                              |
                              |-- Detailed Coding Task 1(developer created - breaking down problem into small testable tasks)
                              |-- Detailed Coding Task 2
                              |-- Detailed Coding Task 3
                              |-- Detailed Coding Task 4
                              |-- Detailed Coding Task 5

In un progetto molto grande - si può mantenere un blocco Big Functional come un ticket e così tante attività (sviluppo e testing) continuano ad evolversi fino alla chiusura definitiva del ticket.

Nel tuo scopo una cosa del genere non avrà alcun fine utile. Nella configurazione, è necessario concentrarsi su un passaggio alla volta (a.k.a. lavoro incrementale) che può essere testato e utile dopo ogni passaggio.

La dimensione del ticket dovrebbe essere la più piccola unità di lavoro implementabile / verificabile e utile. Questo dovrebbe essere tanto piccolo quanto un'attività in modo da non dover gestire realmente le attività separatamente. Inoltre, dopo ciascuna attività atomica (funzionalità / attività) la build torna a essere stabile prima di procedere con qualsiasi altra attività.

Parlando da una prospettiva Agile, in genere si desidera creare ticket che descrivano storie / caratteristiche che richiedono tra 1-3 settimane di tempo per essere completate. Questo naturalmente può variare dalla metodologia alla metodologia, tuttavia si desidera essere in grado di completare i ticket abbastanza rapidamente al fine di fornire dati reali, segnalabili e tracciabili per un'analisi successiva.

Se il ticket è troppo complesso o troppo grande, non vi è nulla di male nel generare due o più nuovi ticket e chiudere il ticket originale. Se il tuo tracker di problemi ha la possibilità di creare collegamenti tra gli elementi del ticket, allora hai le opzioni per riferire i nuovi biglietti spawn al loro problema di origine.

In generale, vorrei iniziare con le mie caratteristiche / storie e elencare tutti i compiti necessari per implementare ogni storia. Fornirei stime basate su ogni singola attività, che collettivamente determinerebbero la stima di un'intera storia / funzione.

Una funzionalità può essere abbastanza grande. Comincio a formulare ciò che mi aspetterei di vedere se tale funzionalità fosse completa; criteri di accettazione.

Ciò rende le funzionalità più attuabili perché il risultato è espresso in termini concreti. Solitamente in questo processo risulta che la funzione è in realtà una composizione di più funzioni secondarie.

Da lì in genere posso scegliere una sub-funzione che è davvero il core o qualcosa su cui tutto il resto dipende. Inizio lì e fino a quando non ho finito, mi dimentico del resto.

Quando ho un morso di lavoro, comprendo che l'ulteriore guasto che faccio è davvero low tech, schizzi, punti elenco sulla carta da lettere e molti sticky gialli.

Gli stickies gialli sono la mia memoria esterna principale e "interruzione del lavoro" mentre si lavora su una (sotto) funzione. Le faccio e le scarto progressivamente, non creo una pila in anticipo.

Se a causa di limiti di tempo devo tagliare l'ambito di una funzione, di solito converto i miei sticky gialli annullati in nuovi "problemi" o "storie" per la possibile implementazione di funzionalità.

Non mi piace il tipo "Crea GUI", "Costruisci DB storage". Queste cose sono troppo ovvie.