Richieste di funzionalità di tracciamento per componenti su piccola scala

Question

Richieste di funzionalità di tracciamento per componenti su piccola scala

#1 da (4 voti)

2

Sono curioso di sapere come altri team di sviluppo (in particolare quelli che lavorano in gruppi di sviluppo moderati o di grandi dimensioni) tracciano caratteristiche / elenchi di desideri "futuri" per funzionalità per framework o componenti sviluppati internamente.

So che il consiglio standard è che un team di sviluppo dovrebbe trovare uno strumento valido per tracciare bug / funzionalità e usarlo per tutto e sono d'accordo con questo se le richieste future riguardano il prodotto stesso.

Nella mia azienda abbiamo un dipartimento di ingegneria, suddiviso in più gruppi e all'interno di ciascuno ci può essere uno o più team agili. Il prodotto di tracciamento dei bug che utilizziamo è stato "un leader dal 1997" (la loro UI / usabilità sembra essere valutata anche contro quell'anno anche oggi) ma il mio team agile o addirittura gruppo non controlla realmente ciò che viene utilizzato dall'intero dipartimento .

Quello che stiamo cercando di tracciare non è necessariamente la funzionalità del prodotto, ma l'espansione / il piacere di avere funzionalità per i componenti interni che entrano nel nostro prodotto. Quindi per citarne alcuni, ad esempio ...

framework / libreria di utilità su CppUnit condivisa dai nostri sviluppatori
framework di comunicazione IPC di basso livello
SDK di sviluppo comune che io e molti altri colleghi del team abbiamo iniziato a collaborare alla condivisione di alcuni codici / strumenti comuni a livello di dipartimento (questo SDK è rilasciato come "prodotto" interno a ciascuno dei gruppi).

La pratica standard è quella di utilizzare l'unico strumento di tracciamento dei bug? O avrebbe più senso impostare qualcosa di più localizzato specificamente per i nostri bisogni e mantenerlo noi stessi? Inoltre, non è chiaro come si sentirà il management se gli sviluppatori inizieranno a svolgere ruoli "IT" di manutenzione di software e server.

Allo stesso tempo, al momento, utilizziamo i file excel, wiki interno e MS OneNote per questo tipo di cose e questo non sembra giusto.

(Ho paura di chiedere consigli sui software reali, poiché ciò potrebbe rendere questa domanda più localizzata o qualcosa del genere.Inoltre gli sviluppatori hanno bisogno in questo modo più della gestione, quindi sarebbe bello trovare qualcosa di gratuito o nient'altro che il costo di un happy hour).

development-process

posta DXM 21.10.2011 - 23:21

fonte

1 risposta

Leggi altre domande sui tag development-process

Il modo migliore per delimitare gli elementi variabili di un percorso nella documentazione del codice? Sarei in violazione della licenza gratuita di queste icone sulla mia applicazione Android?

score 4 · Accepted Answer

Per quanto riguarda il modo in cui il management può pensare di creare qualcosa di localizzato, penso che la risposta più ovvia sia semplicemente incontrarsi con la direzione e chiedere apertamente la propria opinione in merito. Meglio ancora, hai un paio di idee per presentare e vedere se puoi incoraggiare i tuoi manager a prendere in considerazione quelle idee.

Uno strumento è uno strumento. È buono solo come la persona che lo usa. Se qualcosa non ti sembra corretto, chiediti quali sono gli aspetti degli strumenti attualmente usati che ti fanno sentire in questo modo, e poi guarda le tue opzioni. Potresti personalizzare, migliorare o sostituire in base a come te e i tuoi colleghi vi sentite. Inoltre, è necessario che l'intera squadra acquisti l'idea. Se a tutti piace il sistema già installato, allora potresti combattere una battaglia persa. D'altra parte, probabilmente scoprirai che molti dei problemi che solleverai riguardo al tuo attuale sistema di tracciamento saranno probabilmente visti dai tuoi colleghi come problemi e potrebbero semplicemente avere alcune buone idee da condividere.

Per quanto riguarda cosa usare, qualsiasi buon sistema di tracciabilità dei problemi può essere personalizzato allo scopo desiderato. Ad esempio (perdonare la spina), usiamo un sistema Redmine (sì, è gratis come in gratis) dove lavoriamo, e abbiamo creato una sorta di meta-progetto che usiamo come una sorta di discarica per idee e richieste che non sembrano adattarsi bene a nessun progetto esistente. Ogni pochi mesi, passiamo attraverso la lista, rimuoviamo gli articoli che non sono più rilevanti ed espandi le idee che richiedono più discussioni. La cosa bella per noi è che Redmine ci consente di creare nuovi progetti che possiamo collegare alla funzione / problema originale nel nostro "discarica", e possiamo facilmente spostare questi problemi offline in altri progetti, se necessario. Troviamo che questo funziona per noi, e abbiamo messo a punto lo strumento per soddisfare i nostri scopi in questo senso. Quello che sto ottenendo è che con un po 'di riflessione laterale, potresti scoprire che il tuo attuale sistema di tracciamento dei problemi potrebbe essere in grado di essere adattato alle tue esigenze in questo senso. Il vantaggio di questo è che la gestione sarà felice di non aver speso soldi veri e il tuo reparto IT non dovrà preoccuparsi di provare a farli fuori dal lavoro! ; -)