2010-09-23 15 views
9

Sono l'unico sviluppatore che lavora su un paio di siti webapp. Li ho in sovversione, ma non sto usando uno strumento di gestione del progetto.organizzazione di progetti Redmine?

Recentemente ho preso il redmine su e giù, e voglio mettere in piedi i progetti. Quello che sto cercando è una raccomandazione su come strutturare questi due progetti in Redmine. Da quello che posso dedurre, la struttura è Project-> subproject. Quindi sto cercando di mappare questo alla mia lista di cose da fare. Dalla mia lista di cose da fare, ci sono tre tipi di compiti: nuove funzionalità, correzioni di bug e manutenzione (non abbastanza correzioni di bug ma cose che hanno davvero bisogno di pulizia).

Devo fare a ogni applicazione Web un progetto di livello superiore, con funzionalità, bug e manutenzione come sottoprogetti? Quali altri modi di organizzare i progetti ci sono? Ad esempio, nel manuale di sovversione, si consiglia di avere project/trunk, project/branches, project/testing, project/releases, ecc. Esistono linee guida simili per lavorare in Redmine?

+0

Alla luce dell'età della domanda, questo potrebbe avvantaggiare gli altri utenti .. Ma dovresti prendere nota qui: i sottoprogetti di Redmine non elencano i genitori nei loro URI, ognuno usa semplicemente 'server: port//projects/ 'per l'accesso diretto alla pagina del progetto. Credo che ciò sia valido sia per l'interfaccia utente web sia per il back-end RESTful. – ZaLiTHkA

risposta

12

Come al solito, quando si configura un sistema è necessario personalizzarlo il più possibile per cercare di soddisfare le proprie esigenze. Personalmente non conosco linee guida o raccomandazioni per Redmine, tuttavia posso riferire quello che facciamo qui e spero che vi possa aiutare! :-)

Caratteristiche/Bug/Manutenzione sono solo modi per etichettare le attività in modo da poterle filtrare. Queste sono un'etichetta specifica conosciuta come "tracker" in Redmine. È possibile definire i propri tracker per ulteriori tipi di attività.

Il progetto e il sottoprogetto sono anche un modo efficace per etichettare i compiti, ma raggrupparli in una categoria di ombrello più ampia. Quando crei "progetti", assegni ai tracker di cui avrai bisogno. Nel nostro caso, creiamo un'API e abbiamo distinti tracker per identificare bug, funzioni & modifiche con nomi di tracker (effettivamente) duplicati in modo che possiamo identificare se le attività sono per programmatori desktop o dsp. I sottoprogetti vengono utilizzati per identificare le linee di prodotto o le personalizzazioni a cui i nostri clienti richiedono un supporto specifico. Utilizziamo inoltre le etichette delle versioni per identificare versioni specifiche in ciascun sottoprogetto, in modo da ottenere una buona visualizzazione della roadmap di tutte le attività che stiamo monitorando. Abbiamo diversi progetti nel nostro sistema Redmine, ciascuno configurato in modo simile, con alcune attività di progetto collegate a progetti come problemi "correlati" in modo da poter identificare le dipendenze.

Questo è solo un modo per configurare Redmine, ma è il più semplice che possiamo gestire viste le complesse relazioni tra alcuni dei nostri progetti. È la seconda configurazione che abbiamo provato e troviamo che funziona bene. Cordiali saluti, la prima configurazione era su un sistema di test per permetterci di capire cosa avevamo bisogno dal sistema dopo la migrazione da Trac, un paio di anni fa. L'attuale configurazione è in uso da circa 2 anni e sembra adattarsi perfettamente alle nostre esigenze.

Come ho detto prima, è necessario decidere cosa occorre dal sistema, ma l'approccio più semplice è pensare a come si visualizza un progetto dall'alto verso il basso, configurare il sistema in modo che corrisponda ai processi e non modificare il proprio processi per abbinare lo strumento - sempre l'opzione più "disastrosa" IMHO. Non consiglierei di rintracciare bug e funzionalità ecc in progetti separati, in quanto ottenere le tabelle di marcia insieme è solitamente più difficile, e rende anche più difficile visualizzare il carico di attività totale per un determinato progetto. Anche dividere i tipi di attività in sottoprogetti potrebbe essere problematico, in quanto complica le cose se si scopre che è necessario supportare più cicli di rilascio del prodotto, aggiungendo al carico di lavoro in termini di gestione del sistema Redmine.

Questo è tutto ciò a cui riesco a pensare per ora.Spero che ti possa aiutare. :-)

+0

Questo aiuta molto. Solo il tipo di risposta informativa che stavo cercando :) – user151841

2

Il tipo di attività che hai citato sembra essere quello che Redmine chiama tracker. Puoi definire i tuoi tracker. Secondo me, non dovresti avere bisogno di un sottoprogetto per ogni "tipo di compito", ma un tracker.