Qual è il ruolo del tradizionale tracker di problemi quando viene utilizzata la lavagna Scrum / Kanban?

Question

Qual è il ruolo del tradizionale tracker di problemi quando viene utilizzata la lavagna Scrum / Kanban?

#1 da (33 voti)
#2 da (13 voti)
#3 da (5 voti)
#4 da (3 voti)
#5 da (2 voti)
#6 da (1 voti)
#7 da (0 voti)

33

Da una visualizzazione di livello molto elevato, per me sembra che ci siano generalmente 2 tipi di strumenti per la gestione dei progetti:

Tracciatori di problemi tradizionali come Fogbugz, JIRA, BugZilla, Trac, Redmine ecc.
Schede schede virtuali / strumenti di gestione del progetto agili come Pivotal Tracker, GreenHopper, AgileZen, Trello ecc.

Certo, si sovrappongono in un modo o nell'altro, ad es. Le attività di Pivotal Tracker possono essere importate in JIRA, GreenHopper stesso è implementato sulla base del problema di JIRA ecc., Ma penso che si possa ancora vedere la differenza di orientamento tra questi due tipi di strumenti.

Il tracker di problemi tradizionali sembra essere utilizzato anche in aziende che altrimenti gestiscono in modo agile il progetto. La mia domanda è, perché lo fanno? Ritengo inoltre che dovremmo utilizzare un tracker dei problemi nella mia azienda, ma quando ci penso, non sono sicuro del perché dovremmo averne bisogno.

Ad esempio, lo sviluppo di Trello sembra essere gestito utilizzando Trello stesso (vedi questo muro virtuale ) anche se hanno accesso a Fogbugz, uno dei migliori tracker di problemi in circolazione. Quindi forse non abbiamo bisogno del tradizionale tracker dei problemi quando faremo il 100% del nostro lavoro in modo agile usando uno degli agili strumenti PM?

project-management issue-tracking kanban

posta Borek Bernard 31.12.2011 - 21:19

fonte

7 risposte

Leggi altre domande sui tag project-management issue-tracking kanban

Come eseguire il debug del codice più efficacemente? [chiuso] Qual è il significato di "does not compose"?

score 33 · Answer 1

Ci sono (almeno) tre modi diversi in cui una squadra potrebbe lavorare. Scegli quello che funziona per la tua squadra.

1. Dettaglio e panoramica di alto livello

Utilizza il tracker dei problemi per tenere traccia delle singole attività. Usa il cartoncino per mantenere una grande immagine delle principali caratteristiche, come riassunto delle attività nel tracker dei problemi.

2. Bugs vs. Features

Utilizza il tracker dei problemi per tenere traccia dei singoli bug e delle richieste di assistenza clienti. Usa il cartoncino per tenere traccia delle nuove funzionalità in fase di sviluppo.

3. Consegna del software Milestone vs. consegna del software continuo

Utilizza un tracker dei problemi se fornisci grandi blocchi di nuove funzionalità in modo irregolare (ad esempio, se sei il team di Windows e c'è una nuova versione ogni pochi anni). È ideale per un processo di sviluppo in cui i progetti completi e di grandi dimensioni vengono consegnati ai clienti tutti in una volta (inclusi giochi, software incorporato e software tradizionale basato su versioni annuali o semestrali).

Utilizza un cartoncino se stai offrendo continuamente nuove funzionalità ai clienti man mano che vengono sviluppati, ad esempio, in un team Web che ha una consegna di valore continua o molto frequente ai clienti. In questo scenario il tuo processo di sviluppo del software è quasi come una catena di montaggio e meno come un progetto con un inizio e una fine.

score 13 · Answer 2

Penso che la semplice risposta sia che il tradizionale software di tracciamento dei problemi ti aiuta a gestire il backlog, mentre la mischia ti aiuta a tenere traccia dello sprint corrente e del rilascio.

Ovviamente è possibile utilizzare entrambi i tipi di strumenti per fare entrambe le cose, ma si finisce per dover scendere a compromessi.

score 5 · Answer 3

Full disclosure: sono un po 'prevenuto perché sono il product manager di GreenHopper in Atlassian, ma sono stato coinvolto per molto tempo anche nello sviluppo di Agile al di fuori di Atlassian

Avere uno strumento di pianificazione Agile o semplicemente un tracker di problemi è sicuramente fattibile. Il problema è che è sub ottimale. Nella mia esperienza è sub ottimale perché:

La pianificazione del prodotto di solito avviene a livello di Epic e Story in un backlog. Strumenti di pianificazione agili sono fantastici qui
Tuttavia, come dice un vecchio proverbio, nessun piano sopravvive al primo contatto con il nemico. In questo caso, dopo le prime uscite, sei associato a finire con bug (e altri feedback) registrati da QA, clienti, supporto, ecc. Questi devono tornare alla tua pianificazione ma non travolgerlo

Pertanto, disporre di uno strumento di pianificazione Agile è ottimo, ma con la maturazione del prodotto e l'acquisizione di più input esterni diventa sempre più difficile gestire in modo efficace tale input. Alcuni di questi contributori esterni semplicemente non possono contribuire in un tipo di "backlog Agile gestito", vogliono semplicemente inviare il loro problema e andare avanti. È qui che avere un tracker di problemi consente di coinvolgere questi contributori e gestire con successo il business in corso per mantenere attivo lo sviluppo del prodotto.

Direi che hai bisogno di entrambi gli strumenti. Hai anche bisogno che siano integrati, altrimenti passerai tutto il tempo a cercare di mantenere i due sincronizzati.

score 3 · Answer 4

Alcuni prodotti sono un po 'più ottimizzati per storie e attività rispetto a difetti, ma in realtà non c'è una grande differenza. Qualsiasi strumento PM agile e buono che non imponga un sovraccarico eccessivo in termini di struttura forzata o campi obbligatori, può essere facilmente utilizzato per il rilevamento dei difetti. Il mio progetto attuale utilizza un singolo strumento per compiti e difetti e funziona bene a parte il fatto che il prodotto sia un POS:)

score 2 · Answer 5

Gestiamo un tracker dei problemi chiamato DoneDone che si adatta al # 3 in La risposta di Joel - il ruolo più tradizionale di un bug tracker. Infatti, l'abbiamo costruita perché la nostra società di consulenza fornisce storicamente un sacco di codice (sotto forma di siti Web) a intervalli non regolari.

Abbiamo fatto un po 'di attenzione alla nostra base utenti DoneDone un mese fa e alcuni di loro hanno richiesto un front-end simile a Trello e Sprint.ly per i loro cicli di rilascio / rilascio più continui. Un altro utile punto di vista è che molte di queste persone stanno usando DoneDone prima che il loro QA abbia inizio, quindi vorrebbero tutti quei dati in un unico posto mentre i loro progetti (o caratteristiche) si spostano tra i cicli.

I miei due centesimi sono tutti i dati con un po 'di flusso di lavoro applicato. La distinzione è in realtà l'interfaccia utente e come si adatta al team e qualsiasi metodologia e / o fase di progetto in cui si trovino al momento.

score 1 · Answer 6

Non so se c'è una risposta chiara, quindi sto solo riportando la mia esperienza ...

Per anni sono stato completamente venduto su veri sistemi di tracciamento dei bug, come FogBugz, Jira, Trac, ecc. Comunque, recentemente ho preso un lavoro dove siamo Agile (veramente agile, non solo fare Agile). Non abbiamo elenchi di bug lunghi o storici o elementi carini.

Non c'è proprio alcun uso per uno strumento del genere. Tutto ciò che è importante ci arriva in fretta. Qualcosa non così importante, beh, qual è il punto?

È abbastanza liberatorio non avere un enorme arretrato di cose che sappiamo non avremo tempo di fare, mentre allo stesso tempo sappiamo che stiamo offrendo il miglior valore ogni giorno.

score 0 · Answer 7

Il rilevamento dei problemi non è la gestione dei progetti, anche se molti degli strumenti sono progettati per consentire di eseguire entrambe le operazioni, quindi un sistema non sostituisce l'altro,

Una scheda Kanban ti offre una bella panoramica del tuo lavoro che è attuale ed eccezionale, e ti fa sapere a colpo d'occhio quali sono le priorità, mentre un tracker dei problemi ti permette di legare i tuoi problemi al tuo sistema di controllo delle versioni, e funziona meglio come mezzo per registrare tutto ciò che dovrebbe essere nel tuo backlog Kanban, ma con dettagli aggiuntivi che altrimenti renderebbero la tua Kanban un vero casino da leggere.

Il fatto è che i due concetti funzionano bene insieme e si supportano a vicenda. Ovviamente, se si dispone di un sistema in grado di fornire il meglio di entrambi i mondi all'interno di un'unica applicazione, è possibile che le linee risultino leggermente sfocate, tuttavia i concetti rimangono comunque ragionevolmente separati.