Come gestite un backlog di prodotti di grandi dimensioni? [chiuso]

Question

Abbiamo un ampio arretrato di cose che dovremmo fare nel nostro software, in molte categorie diverse, ad esempio:

• Nuove aree problematiche che i nostri prodotti possono risolvere
• Nuove funzionalità a supporto delle aree problematiche esistenti
• Nuove funzionalità richieste dai nostri utenti esistenti
• Usabilità e " aspetto " Miglioramenti
• Aggiornamenti architetturali al back-end
• Correzioni di bug

Gestire tutti questi in modo ragionevole è un lavoro che rientra nella gestione dei prodotti, ma è complicato per molte ragioni. In primo luogo, abbiamo diversi sistemi che contengono le diverse cose (documento sui requisiti di mercato in file, bug in un database di bug, requisiti dei clienti nel nostro sistema di help desk, lista dei desideri di enginering sulla nostra intranet, ecc.). In secondo luogo, molti degli articoli hanno dimensioni, portata, complessità e ovviamente valore decisamente diversi, il che significa che scegliere non è semplice come ordinare un elenco in base alla priorità.

Poiché ora siamo abbastanza grandi, abbiamo un prodotto complesso e molti clienti, le soluzioni di base (un foglio di calcolo, un documento di Google, un elenco di cose da fare di base) non sono sufficienti per far fronte a questo. Abbiamo bisogno di un modo per raggruppare le cose in vari modi, stabilire le priorità su base continuativa, chiarire cosa stiamo facendo e cosa sta arrivando, senza che sia necessario tutto il tempo di qualcuno per gestire solo alcuni strumenti.

Come gestirlo in un modo che consenta all'azienda di fare sempre ciò che è più prezioso per i clienti esistenti, aiuta a ottenerne di nuovi e mantiene sani i software interni?

Nota che questo è diverso dal punto di vista dello sviluppo, che penso che abbiamo perso abbastanza bene. Sviluppiamo tutto in modo iterativo e agile e, una volta scelto qualcosa per la progettazione e l'implementazione, possiamo farlo. È la parte in cui dobbiamo capire cosa fare dopo è la cosa più difficile!

Hai trovato un metodo o uno strumento che funziona? Se è così, per favore condividi! (E se desideri conoscere anche la risposta, dai un voto alla domanda in modo che rimanga visibile :)

Addendum: Naturalmente è bello correggere prima tutti i bug, ma in un sistema reale che è effettivamente installato sui computer dei clienti, non è sempre pratico. Ad esempio, potremmo avere un bug che si verifica solo molto raramente e che per risolvere il problema ci vorrebbe molto tempo e sconvolgimenti architettonici - potremmo lasciarlo per un po '. Oppure potremmo avere un bug in cui qualcuno pensa che qualcosa sia difficile da usare, e pensiamo che risolverlo dovrebbe aspettare un rinnovamento più grande di quell'area. Quindi, ci sono molti motivi per cui non li risolviamo tutti immediatamente, ma li teniamo aperti in modo da non dimenticare. Inoltre, è la definizione delle priorità dei non-bug ad essere la più difficile; immagina di non averne :)

Answer 1

Gestire un backlog di grandi dimensioni in modo aggressivo è quasi sempre dispendioso. Quando arrivi al centro di una pila prioritaria, le cose sono cambiate molto spesso. Consiglio di adottare qualcosa di simile a quello che Corey Ladas definisce un filtro prioritario:

http://leansoftwareengineering.com/2008/08/19/priority-filter /

In sostanza, hai alcuni secchi di dimensioni crescenti e priorità decrescenti. Consenti agli stakeholder di riempirli, ma li costringi a ignorare il resto delle storie fino a quando non ci sono aperture nei secchi. Molto semplice ma molto efficace.

Modifica: Allan ha chiesto cosa fare se le attività hanno dimensioni diverse. Fondamentalmente, una grande parte del fare questo lavoro è il dimensionamento corretto dei tuoi compiti. Applichiamo questa priorità solo alle storie degli utenti. Le storie degli utenti sono in genere significativamente più piccole di "creare un sito della community". Considererei il sito della comunità un po 'epico o addirittura un progetto. Dovrebbe essere suddiviso in bit significativamente più piccoli per poter stabilire le priorità.

Detto questo, può ancora essere difficile creare storie di dimensioni simili. A volte non puoi, quindi lo comunichi durante le tue decisioni di pianificazione.

Per quanto riguarda lo spostamento dei wibble di due pixel, molte di queste cose che sono facili possono essere fatte per "libero". Devi solo stare attento a bilanciarli e farlo solo se sono davvero vicini alla libera e in realtà sono in qualche modo importanti.

Trattiamo i bug in modo simile. I bug ottengono una delle tre categorie, Ora, Presto o Alla fine. Risolviamo i bug Now e Soon il più rapidamente possibile, con la sola differenza di pubblicare le correzioni. Alla fine i bug non vengono corretti a meno che gli sviluppatori non si annoino e non abbiano nulla da fare o in qualche modo diventino una priorità più alta.

Answer 2

La chiave è la categorizzazione aggressiva e la definizione delle priorità.

Risolvi i problemi che allontanano rapidamente i clienti e aggiungi altre funzionalità per farli venire. Respingere i problemi che riguardano solo un piccolo numero di persone a meno che non siano molto facili da risolvere.

Answer 3

Una tecnica semplice consiste nell'utilizzare una matrice di priorità.

Esempi:

• http://erc.msh.org/quality/pstools/ psprior2.cfm

• http: // it. toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Utili anche i quadranti delle priorità (due dimensioni: Importanza, Urgenza) che Covey propone: http : //www.dkeener.com/keenstuff/priority.html . Concentrati su Importante e Urgente, quindi su Importante e Non urgente. Le cose non importanti ... beh ... se qualcuno vuole farlo nelle ore fuori orario :-). Una variante dei quadranti di Covey che ho usato è con le dimensioni di Importanza e Facilità. Facilità è un buon modo per dare priorità alle attività all'interno di un quadrante di Covey.

Answer 4

Penso che devi metterli tutti in un unico posto in modo da poter dare la priorità. Dover raccogliere diverse fonti diverse rende ciò praticamente impossibile. Una volta che lo hai, qualcuno / un gruppo deve classificare ogni bug, funzionalità richiesta e sviluppo desiderato.

Le cose a cui potresti dare la priorità sono:

• Valore aggiunto al prodotto
• Importanza per i clienti, sia esistenti che potenziali
• Scala dell'attività

Answer 5

Dovresti prima correggere tutti i bug e solo successivamente pensare ad aggiungere nuove funzioni ad esso.

Answer 6

Tutte queste cose potrebbero essere monitorate da un buon sistema di tracciamento dei bug che ha le seguenti caratteristiche:

• Possibilità di contrassegnare gli oggetti di lavoro come bug o richieste di miglioramento
• Campo categoria per la regione di responsabilità in cui l'oggetto di lavoro rientra (UI, back-end, ecc.)
• Campo versione n. per quando è pianificata la correzione o la funzionalità
• Campo di stato (in corso, completato, verificato, ecc.)
• Campo prioritario

Answer 7

Dato che stai già facendo le cose in modo agile, potresti prendere in prestito alcune idee da XP:

• metti tutti le tue storie in una grande pila di schede (o alcuni di questi strumenti)
• ora gli sviluppatori dovrebbero stimare quanto siano grandi o piccole quelle storie (qui gli sviluppatori hanno l'ultima parola)
• e consenti al cliente (o al suo product manager simile al proxy) di ordinare tali storie in base al loro valore commerciale (qui il cliente ha la parola finale)
• e se gli sviluppatori pensano che ci sia qualcosa di tecnico che è più importante (come correggere quei fastidiosi bug), devono comunicarlo al cliente (uomo d'affari) e fare in modo che il cliente aumenti tale priorità (il cliente ha ancora l'ultima parola)
• seleziona tutte le storie per la prossima iterazione che la velocità del tuo team consente

In questo modo:

• esiste un'unica coda di attività, ordinata per esigenze aziendali
• i clienti ottengono il miglior ritorno per il loro investimento
• il valore aziendale favorisce lo sviluppo, non la tecnologia o i geek
• gli sviluppatori possono dire quanto sono difficili da implementare
• se non c'è ROI , l'attività rimane vicino al fondo di quella pila

Per ulteriori informazioni, vedere Pianificazione della programmazione estrema di Kent Bech e Martin Fowler . Lo dicono molto meglio di quanto io possa mai fare.

Answer 8

Non sono sicuro che lo strumento sia critico quanto il processo. Ho visto i team avere molto successo usando qualcosa di semplice come le schede e le lavagne bianche per gestire progetti abbastanza grandi. Una cosa che consiglierei di stabilire le priorità è assicurarti di avere un elenco completo di questi elementi insieme. In questo modo puoi valutare la priorità della risoluzione di un problema rispetto a una nuova funzionalità, ecc.

Answer 9

Al di là di qualsiasi strumento e processo, ci dovrebbero essere ... alcune persone;)

Nel nostro negozio, viene chiamato Release Manager e determina il prossimo perimetro funzionale da spedire in produzione.
Poi c'è un Freeze Manager che in realtà conosce codice, file e bug (di solito è uno dei programmatori) e imporrà le scelte del gestore delle versioni e monitorerà le fusioni necessarie per avere qualcosa da testare e quindi rilasciare.

Tra loro due, è possibile stabilire una priorità, sia ad alto livello (richieste funzionali) che a basso livello (bug e problemi tecnici)