Best practice di Redmine [chiuso]

Quali suggerimenti e "standard" usi nel tuo processo di gestione del progetto Redmine?

Hai un modello di inserimento wiki standard che potresti condividere o un modo standard per lavorare un progetto utilizzando bug, funzionalità, attività e problemi di supporto?

Consenti che problemi e aggiornamenti vengano inviati via email in Redmine? Usi i forum? Usi il repository SVN? Usi Mylyn in eclipse per lavorare sugli elenchi di attività?

Sto cercando di trascinare il nostro reparto. in qualche PM basato sul Web invece di documenti Word inviati via e-mail di requisiti vaghi seguiti da documenti Word che spiegano come eseguire il QA e distribuire che si perdono in una pila di aggiornamenti e progetti concorrenti in modo che nel momento in cui devo aggiustare qualcosa, nessuno può trovare tutta la documentazione su come funziona.

Sviluppo e mantengo applicazioni interne per una famiglia di aziende manifatturiere. Al momento di questo commento, sono l'unico sviluppatore / analista del team IT. Durante la peggiore della recessione, le richieste del mio progetto sono esplose. In quanto tale, il mio progetto e il mio arretrato di problemi sono piuttosto ingombranti. Attualmente siamo in fase di ristrutturazione per espandere il team.

Ecco come utilizzo Redmine per tenere la testa dritta (per quanto possibile), i miei utenti a bada e, si spera, evitare che in futuro si tenga troppo per mano il nuovo personale.

• Uso Subversion per il controllo del codice sorgente, con TortoiseSVN e il plugin Tortoise-Redmine dal nome appropriato . L'aggiornamento del repository sul progetto Redmine dopo un commit collega il problema, che mostra la revisione sul problema e aggiorna i miei stakeholder tramite notifica e-mail.
• Tratto la descrizione del progetto come un mezzo per comunicare lo scopo, l'ambito e la fase del ciclo di vita del progetto a coloro che non sono coinvolti. In questo modo i miei utenti sanno cosa ho nel piatto e cosa c'è ancora sul buffet che sto osservando da lontano.
• Uso nomi di ruoli specifici per i miei set di autorizzazioni che indicano più di un set di autorizzazioni, ancora una volta, come mezzo di documentazione. I miei ruoli includono i seguenti: Project Manager, membro del team di progetto, proprietario, utente principale, utente secondario, osservatore, Overlord (per i miei capi ... entrambi divertenti e innegabilmente corretti).
• Uso Wiki e Documents per la documentazione, a seconda di ciò che ritengo appropriato.
• Le versioni sono praticamente inutili per me, quindi invece di usarle per i rilasci pianificati, la uso per raggruppare i problemi correlati in sprint.
• Uso il favoloso plug-in Stuff-To-Do di Eric Davis per organizzare / riorganizzare i summenzionati sprint prima di modificare in massa le versioni target sui miei problemi. Ciò consente inoltre ai miei stakeholder di sapere su cosa sto lavorando e come ho dato la priorità ai loro interessi (nel bene e nel male).
• Per incoraggiare l'interazione con l'utente, ho aggiunto collegamenti al progetto Redmine nei menu della Guida delle mie applicazioni. La casella "Informazioni" contiene anche un collegamento al progetto Redmine.

Progetti futuri

• Spero a un certo punto di completare la mia estensione di Visual Studio per l'integrazione di Redmine.
• Costruisci una libreria di codice per accoppiare liberamente la mia applicazione con il suo progetto Redmine: automatizza l'invio di bug, avvisa gli stakeholder di sottoscrizione dalla barra delle applicazioni, menu di aiuto interattivo riutilizzabile guidato dall'API REST di Redmine, ecc. (Forse automatizzare parti di documentazione con Wiki?)

Sono uno sviluppatore web freelance Ruby e Redmine che gestisce un'attività di sviluppo di uno (me). Quindi il mio Redmine è configurato per essere piuttosto leggero e focalizzato sul cliente. Il mio Redmine ha anche il doppio compito di ospitare i miei progetti Open Source.

Consento l'invio di nuovi problemi e aggiornamenti e funziona alla grande per gli utenti connessi alla posta elettronica (o per coloro che sono sempre sui loro iPhone).

Ho utilizzato la visualizzazione del repository con i repository git e funziona alla grande. Ad ogni check-in faccio riferimento al problema con #nnn, quindi la pagina del problema effettivo mostrerà tutti i commit per implementare la funzione.

Ho scoperto che i forum sono sottoutilizzati. Penso che se ci fosse un'integrazione della posta elettronica, sarebbero più utili.

Abbiamo trovato utili le seguenti pratiche:

1) Nascondi il tracker "Problema" e "Supporto" e archivia tutto come bug :

• risparmio di tempo per sviluppatori, tester, gestione;
• se alcune attività devono essere fatturate come "extra" o "nuove funzionalità" o qualsiasi altra cosa, vengono organizzati rapidi incontri per valutarle.

2) pietre miliari e versioni Adoro questo, puoi facilmente rintracciare lo stato di ogni rilascio e in qualsiasi momento puoi scaricare un pacchetto precedente, cioè per testare un bug segnalato dal cliente.

3) funzione "salva" nella scheda "problemi": un altro grande risparmio di tempo, ho diverse query salvate per molte attività di reporting quotidiane e questo è tutto ciò di cui ho bisogno.

4) integrazione del controllo delle versioni, ovvero l'utilizzo di "# 123" nei commenti crea un collegamento al problema corrispondente: semplicemente intelligente!

Usiamo Redmine ampiamente sul nostro sistema. Abbiamo persino impostato un progetto "Vendite" per il nostro team di vendita da utilizzare come CRM. Abbiamo un mucchio di campi personalizzati in questo progetto e sostituisce SugarCRM che stavamo usando prima.

All'interno del nostro sistema abbiamo progetti per software Server e Client. Il progetto del server è suddiviso in sottomoduli, in base a come ho strutturato il sistema e i sotto-repository, poiché a Redmine piace un repository separato per progetto.

Usiamo, come altri notano, i codici #nnn nei messaggi di commit per fare riferimento ai ticket. La cosa interessante è che non è necessario che sia un biglietto nello stesso progetto. Pertanto, un ticket di vendita può essere bloccato da un problema di bug o da una richiesta di supporto.

Abbiamo appena iniziato a utilizzare Documents per l'agenda / i verbali delle riunioni. Usiamo le versioni per raggruppare in versioni, sia sul client che sul server.

Per provare a utilizzare il plug-in Redmine Time Tracker per tenere traccia del tempo, ma dimentico sempre di fare clic su inizio o fine. Riceviamo email quotidiane su problemi che non vengono toccati da un po '(Redmine Whining, credo) e che hanno date di scadenza nel passato o nel prossimo futuro (Promemoria avanzato).

Le e-mail di supporto entrano direttamente nel nostro progetto di supporto e se l'importazione delle e-mail fosse un po 'più robusta (a volte non crea nuovi ticket correttamente se la riga Progetto: è inclusa nell'e-mail), avremmo le richieste del sito Web che generano automaticamente i biglietti di vendita . Così com'è, dobbiamo solo monitorare i ticket di supporto e spostarli nelle vendite, se applicabile.

Cose che vorrei poter fare:

• Avere relazioni tra il nostro sistema e redmine, in modo che i biglietti possano essere associati a un utente o un'azienda nel nostro sistema. Inoltre, in modo da poter generare una nuova azienda da un ticket di vendita nel punto pertinente. Questo richiede solo che io faccia un po 'di lavoro.
• Avere una relazione tra il nostro software di tracciamento degli errori (sentry) e redmine, in modo che gli errori del server generino un ticket redmine. Ancora una volta, risolvibile con la tecnologia attuale.
• Avere un client desktop da ripristinare. Il server è all'interno della nostra LAN, ma essere in grado di avere un modo più flessibile per accedere ai dati diversi dalla pagina web sarebbe fantastico. Non è che ci sia qualcosa che non posso davvero fare nell'interfaccia web Redmine, ma qualcosa di simile Things.app è così molto più bello di lavorare in.
• Avere la nostra documentazione di supporto tutta all'interno di redmine e quindi generata su un server rivolto al pubblico. In questo modo, il nostro personale di supporto può mantenere la documentazione, modificarla in modo piacevole e distribuire le modifiche al doc-server.

Redmine è stato fantastico per noi finora. Lo usiamo come coda multi-tenant per ticketing / prioritizzazione agile e l'abbiamo collegato anche a SVN. In particolare:

• Installare / mantenere tramite SVN è stato un gioco da ragazzi (ci ho migrato da 1.1 a 1.2 a 1.3 a 1.4 tramite l'uso di svn switch https//.../branches/1.3-stable .comandi seguiti dalrake migrate comandi con solo occasionali installazioni gem necessarie nel mezzo).
• I backup del database e dei file memorizzati sono un'esecuzione di script su una riga
• Adoriamo i plugin Time Tracker e Spent Time . Ucciderei per un Mac OS X che monitora il fat client per alcuni dei nostri utenti in ufficio, ma non è questo il punto :)
• Non usiamo molto i forum, ma usiamo pesantemente Activity e Roadmap. Legare i problemi a versioni specifiche è una manna dal cielo.
• Abbiamo anche distinzioni client / server, ma usiamo la versione di destinazione per legare i ticket per specificare quale va dove (e avere NEXT CLIENT RELEASE / NEXT SERVER RELEASE) in modo da distinguere tra mentre si sta lavorando.
• Mescoliamo metafore per gli stati: usiamo prima i nostri elenchi raggruppati per questi ("Immediate", "Rejected", "Blocked", "Working", "On Deck" "The List", "Waiting For Build", "Published To Test "," Verificato "," Rilasciato in produzione "," Chiuso "," Annullato).
• Quindi, all'interno di ciascun gruppo sopra, abbiamo questo elenco ordinato di priorità: ("Immediate", "Prioritize Me", "Design And Size Me", "P1" ... "P5", "P-Watch List"). Questo, oltre a quanto sopra, consente un facile flusso di lavoro dall'area dei problemi.
• Per l'elenco dei problemi di base, ordiniamo per "Priorità", "Attività principale", quindi "Data aggiornata": è necessario quello centrale in modo che Redmine rientri bene nel caso in cui ci sia un'attività figlio nello stesso raggruppamento.
• Usiamo i commit di checkin per collegare i commit ai problemi (ad es. svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - e facciamo in modo che il problema venga spostato in "Waiting For Build" (che era "Risoluto", ma mi sono stancato di spiegare che "Risolto" non significa aspettiamo di vederlo ancora rilasciato).

Penso che dovrò andare a indagare sul plug-in Redmine-stuff-to-do. +1 Domanda.

La mia azienda lavora con sviluppatori software e hardware di origine internazionale. Prima di entrare in azienda, la posta elettronica veniva utilizzata con i documenti MS Word per trasmettere i nostri problemi e bug con software o hardware per richiedere una correzione. Questo processo era impossibile da monitorare e mantenere qualsiasi tipo di processo. Ho implementato RedMine come mezzo per tenere traccia dei bug software e hardware e da allora ha funzionato molto bene. C'è una grande barriera linguistica nella mia situazione. Per fortuna RedMine può essere visualizzato in lingua cinese semplificata e il feedback ha dimostrato che questo è OK finora dai miei sviluppatori.

Stato - Quando trovo un problema software o hardware, lo stato è "Nuovo" - Quando i miei sviluppatori software / hardware hanno riscontrato questo problema e ci stanno lavorando, cambiano lo stato in "In corso". Possono usare% done se lo desiderano da 0 a 50. Ho impostato% Done su 50 quando sentono di aver risolto il problema. - Determino se il problema è stato risolto e cambio lo stato in "Risolto" e la% completata in 100%. Ciò mi consente di filtrare i problemi <o uguali al 50% per trovare problemi ancora aperti.

Priorità: bassa, normale, alta, urgente, immediata si traduce bene in cinese.

Data di scadenza: lo uso per dirmi quando la correzione è stata originariamente caricata dai miei sviluppatori di software. Potrei impiegare 4-6 giorni per testare qualcosa e chiudere il problema. Mi piace che il mio diagramma di Gannt rifletta la reattività del mio team di software, non quanto tempo mi ci è voluto per approvare la correzione.

Categoria: riflette sempre la versione del software o dell'hardware in cui ho riscontrato il problema. Lo uso per vedere quale versione del software ha il maggior numero di bug e per assicurarmi che le versioni più recenti del software non soffrano di regressione.

Ho tutti inclusi nella lista degli osservatori di RedMine per tutti i bug. L'e-mail si presenta come (Nuovo), (Risolto) o (In corso) in modo che i miei supervisori e i supervisori e gli ingegneri capo dei team coinvolti possano vedere l'email e leggere rapidamente i progressi attualmente in corso. La maggior parte delle altre persone coinvolte non accede mai a RedMine, in genere sono l'unico. Le e-mail servono perfettamente per fornire aggiornamenti istantanei a tutti coloro la cui unica preoccupazione è se si stanno compiendo progressi o meno.

Come hai accennato a inviare documenti di Word avanti e indietro con il tuo QA - Conosco questa sensazione, ci sono stato, l'ho fatto. Il problema principale per me era: alle persone QA non piace aggiungere problemi in nessun bug tracker, li annotano in un editor accanto a loro durante i test.

Stiamo usando Redmine ora con un bel addon - Usersnap (Dichiarazione di non responsabilità: abbiamo creato lo strumento per risolvere questo problema da soli.

Usersnap è ottimo per gli sviluppatori web: aggiungilo al tuo progetto web e otterrai screenshot direttamente allegati ai ticket Redmine, incluse le meta informazioni sul browser utilizzato, il sistema operativo e così via.

I nostri QA / clienti possono ora inserire i bug direttamente nell'applicazione web e gli sviluppatori possono riprodurre più facilmente le segnalazioni di bug in Redmine.

Stiamo usando la sezione Roadmap come un modo chiaro per visualizzare:

• insetti
• caratteristiche (che sarebbero riferimenti al tuo documento word o link a pagine dei requisiti html)
• riconciliazioni (differenze tra valori di produzione e valori di prova)
• e così via...

Questo è il principale punto di consolidamento per noi. Il resto viene utilizzato in relazione a quello (ad esempio, la sezione "annuncia" viene utilizzata per definire le principali date di traguardo / rilascio utilizzate nella roadmap)

In aggiunta agli altri commenti, raccomando l'uso del plug-in "Stuff To Do" (scritto da Eric Davis credo :) L'uso di quel plugin ti consente di trascinare e rilasciare l'ordine dei problemi su più progetti.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Usiamo le versioni come un modo per definire gli sprint, quindi ogni versione è uno sprint con la visualizzazione Roadmap che fornisce una chiara illustrazione del progresso. I problemi negli sprint vengono contrassegnati come "pronti per la revisione" una volta completati e quindi chiusi quando il QA è stato verificato.

Usiamo una versione come backlog per eventuali problemi che non rientrano nell'ambito o perdono la loro priorità, ecc.

Utilizziamo Redmine da circa un anno ormai e si è evoluto da solo in molti modi. Usiamo le versioni per raggruppare i problemi insieme per un rilascio e le categorie per raggruppare i problemi per disciplina.

Ogni problema passa attraverso un flusso di lavoro di nuovo> in corso> risolto. Quindi il tester chiuderà il problema quando sarà soddisfatto.

Ci piacerebbe aggiornare il modo in cui utilizziamo Redmine, sembra che ci siano così tanti ottimi plugin, ma scopriamo che molti di loro sono rotti o non verranno installati.

Usiamo il wiki in modo completo per la documentazione degli sviluppatori.