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

Da un punto di vista di altissimo livello, a me sembra che ci siano generalmente 2 tipi di strumenti di Project Management:

1. Tracker di problemi tradizionali come Fogbugz, JIRA, BugZilla, Trac, Redmine ecc.
2. Schede a schede virtuali / strumenti di gestione dei progetti agili come Pivotal Tracker, GreenHopper, AgileZen, Trello ecc.

Certo, si sovrappongono in un modo o nell'altro, ad esempio le attività Pivotal Tracker possono essere importate in JIRA, GreenHopper stesso è implementato in cima alla base di problemi 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 agilmente la gestione dei progetti. La mia domanda è: perché lo fanno? Sento anche che dovremmo usare un tracker di problemi nella mia azienda, ma quando ci sto pensando, non sono sicuro del perché dovremmo averne bisogno.

Ad esempio, lo sviluppo di Trello sembra essere gestito usando 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 eseguiremo il 100% del nostro lavoro in modo agile utilizzando uno degli strumenti PM agili?

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

1. Dettagli e panoramica di alto livello

Utilizzare il tracker dei problemi per tenere traccia delle singole attività. Usa il cartoncino per conservare una visione d'insieme delle principali funzionalità, come riepilogo delle attività nel tracker dei problemi.

2. Bugs vs. Features

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

3. Consegna del software fondamentale rispetto alla consegna continua del software

Utilizzare un tracker di problemi se si forniscono blocchi di nuove funzionalità in modo irregolare (ad esempio, se si è il team di Windows e c'è una nuova versione ogni pochi anni). È ideale per un processo di sviluppo in cui i progetti di grandi dimensioni e completati vengono consegnati ai clienti contemporaneamente (che include giochi, software incorporato e software tradizionale basato su versioni annuali o semestrali).

Utilizzare un cartoncino se si forniscono continuamente nuove funzionalità ai clienti mentre vengono sviluppate, ad esempio, in un team Web che ha consegne continue o molto frequenti di valore ai clienti. In questo scenario il processo di sviluppo del software è quasi come una catena di montaggio e meno come un progetto con un inizio e una fine.

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

Ovviamente è possibile utilizzare entrambi i tipi di strumento per fare entrambe le cose, ma alla fine devi scendere a compromessi.

Informativa completa: sono un po 'di parte perché sono il responsabile del prodotto GreenHopper di Atlassian, ma sono stato anche coinvolto nello sviluppo Agile al di fuori di Atlassian per molto tempo

Avere solo uno strumento di pianificazione Agile o solo un tracker di problemi è sicuramente praticabile. Il problema è che non è ottimale. Nella mia esperienza è subottimale perché:

• La pianificazione del prodotto di solito avviene a livello di Epica e Storia in un arretrato. Gli strumenti di pianificazione agili sono fantastici qui
• Eppure, come dice il vecchio proverbio, nessun piano sopravvive al primo contatto con il nemico. In questo caso, dopo le prime versioni rilasciate, sarete costretti a finire con bug (e altri feedback) registrati da QA, clienti, supporto, ecc. Questi devono rispondere alla vostra pianificazione ma non sopraffarli

In quanto tale, avere solo uno strumento di pianificazione Agile è fantastico, ma man mano che il tuo prodotto matura e ottieni più input esterni diventa sempre più difficile gestire in modo efficace quell'input. Alcuni di questi collaboratori esterni semplicemente non possono contribuire in un modo di "backlog Agile gestito", vogliono solo inviare il loro problema e andare avanti. Ecco dove avere un tracker di problemi ti consente di coinvolgere questi collaboratori e gestire con successo l'attività in corso per continuare lo sviluppo del prodotto.

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

Alcuni prodotti sono un po 'più ottimizzati per storie e compiti rispetto a difetti, ma in realtà non c'è una grande differenza. Qualsiasi buon strumento PM agile 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 sta usando un unico strumento sia per compiti che per difetti e funziona bene a parte il fatto che il prodotto è un POS :)

Eseguiamo un tracker di problemi chiamato DoneDone che si adatta al n. 3 nella risposta di Joel, il ruolo più tradizionale di un bug tracker. In effetti, l'abbiamo costruito perché la nostra consulenza storicamente fornisce un sacco di codice (sotto forma di siti Web) a intervalli non regolari.

Un mese fa abbiamo fatto un po 'di sensibilizzazione alla nostra base di utenti DoneDone e molti di loro hanno richiesto un front-end simile a Trello e Sprint.ly per i loro cicli di codice / rilascio più continui. Un altro utile spunto è che molte di queste persone usano DoneDone prima che inizi il loro QA, quindi vorrebbero tutti quei dati in un posto mentre i loro progetti (o funzionalità) 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 il modo in cui accoglie il team e qualsiasi metodologia e / o fase del progetto in cui si trovano al momento.

Il monitoraggio dei problemi non è la gestione dei progetti, anche se molti degli strumenti sono progettati per consentire di fare entrambi, quindi un sistema non sostituisce realmente l'altro,

Una scheda Kanban ti offre una bella panoramica del lavoro che hai che è attuale e eccezionale e ti informiamo a colpo d'occhio quali sono le priorità, mentre un tracker di problemi ti consente 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 ulteriori dettagli che altrimenti renderebbero la tua scheda Kanban un vero casino da leggere.

Il fatto è che i due concetti funzionano bene insieme e si sostengono a vicenda. Ovviamente, se hai un sistema che può darti il ​​meglio di entrambi i mondi all'interno di una semplice applicazione, allora può offuscare un po 'le linee, tuttavia i concetti rimangono ragionevolmente separati.

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. Tuttavia, di recente ho preso un lavoro in cui siamo Agili (essendo veramente agili, non solo facendo Agile). Non abbiamo lunghi elenchi storici di bug o oggetti interessanti.

Non serve proprio a questo strumento. Tutto ciò che è importante arriviamo abbastanza velocemente. Qualcosa di non così importante, beh, qual è il punto?

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