Come funziona Bugzilla per la gestione dei progetti Scrum? [chiuso]

Question

Abbiamo MS Sharepoint, che non è affatto male per la gestione di un elenco di attività. I dati sono pubblicamente disponibili, le persone vengono informate di modifiche e incarichi.

Penso che Bugzilla potrebbe essere un po 'più facile per scopi di gestione e reportistica. Mentre ci sono alcuni buoni strumenti di gestione di Scrum Open Source, ho usato molto del mio capitale politico e non posso chiedere molto di più di quello che abbiamo ora. Il denaro non è l'oggetto - ovviamente - è l'idea che il mio team abbia troppi strumenti specializzati.

Bugzilla funzionerà come uno strumento di gestione del progetto più generale - al di fuori dei casi d'uso di correzione dei bug?

Sarò amaramente deluso e vorrei aver scaricato qualcos'altro e fatto valere la mia richiesta di un migliore strumento di gestione del progetto?

Answer 1

Bugzilla È un ottimo sistema di tracciamento dei bug. Abbiamo provato a usarlo per altre attività di gestione del progetto e i risultati sono meno che stellari. Consiglierei di trovare qualcosa progettato pensando ai tuoi obiettivi.

Answer 2

Provalo tu stesso.

Ottieni un account di $ 15 al mese su wush.net e usalo per un po 'di tempo (nessun rapporto commerciale oltre al cliente soddisfatto).

Bugzilla è potente e ha molte opzioni di configurazione, che possono essere fonte di confusione.

L'ho usato personalmente tre anni fa su un progetto a cui stavo lavorando. Non avevo project manager ed ero lo sviluppatore, quindi avevo bisogno di un sistema molto leggero. Bugzilla mi ha dato questo. Ho messo il mio obiettivo principale come un miglioramento "sistema di produzione" e poi ho fatto dipendenze per raggiungere quel punto. Ho finito per avere 160 nodi tutti dipendenti l'uno dall'altro. Questa era essenzialmente una struttura di suddivisione del lavoro. Non mi sono preoccupato delle stime dei tempi e non mi sono preoccupato di creare nessun altro tipo di documentazione di progetto.

Un grande vantaggio era che mentre scrivevo il codice, se avessi notato qualcosa che doveva essere fatto, l'avrei semplicemente inserito in bugzilla (processo di 20 secondi dopo averlo impostato), legandolo come dipendenza e tornando a ciò che ho stava facendo.

Ogni volta che ho completato un'attività, guardavo il diagramma delle dipendenze e trovavo le foglie più esterne (bug che bloccavano altre ma non erano esse stesse bloccate), e ci lavoravo.

Il vantaggio di questo metodo per me è che se un'attività fosse sembrata semplice e avesse un nodo associato ad essa, ma quando facevo la cosa in sé mi rendevo conto che era più complessa, l'avrei divisa in diverse attività secondarie. Ciò ha richiesto solo un minuto e non ha comportato assolutamente un incontro con un project manager.

Altre persone nel team hanno potuto monitorare i miei progressi guardando bug aperti, bug chiusi ordinati per data, ecc. Hanno visto l'azione, mi hanno lasciato solo. Quando avevo dipendenze esterne, creavo un bug, dettagliavo il lavoro e inviavo a quella persona un link via e-mail. Potevano quindi capire perché ciò fosse necessario osservando il diagramma delle dipendenze.

Nota che se non preventivamente concordato, non ho assegnato loro il bug.

Funzionava davvero bene e il sistema era pronto con un mese di anticipo.

Come funzionerà con SCRUM? Avendo dato solo un'occhiata superficiale alla mischia, non posso dirtelo. Ma questa è stata la mia esperienza.

L'uso di un host dedicato ti consentirà tre cose:

• Supporto
• facili aggiornamenti (a meno che tu non abbia dei guru interni, la gestione dei bugzilla non è facile - almeno per me)
• utenti oltre i confini dell'organizzazione.

Nota che bugzilla ha ogni sorta di funzionalità di sicurezza, quindi è facile bloccare gli utenti su ciò che devono vedere.

Answer 3

Abbiamo usato Trac e Subversion con successo per diversi progetti.

Il vantaggio principale qui è la possibilità di personalizzare i report, alcuni molto specifici di Scrum, per fornire informazioni alla direzione.

Answer 4

La mia soluzione indipendente è DokuWiki + MantisBT + Subversion + Review Board, che può essere integrato con relativa facilità. L'alternativa ospitata è Bitbucket.org. La logica è che scrivi storie utente su Wiki e puoi fare riferimento a compiti specifici. Bug più grandi possono essere progettati in modo collaborativo e il " wiki " il collegamento è fornito sulla segnalazione di bug di Mantis. La scheda di revisione consente di eseguire revisioni del codice peer contro svn diff prima che venga apportata la modifica.