Che software usi per aiutare a pianificare il lavoro di squadra e perché?

OmniPlan

Strumento di pianificazione di Mac OS X.

Pivotal Tracker

Utile anche se non stai facendo uno sviluppo "agile".

FogBugz

Rilevamento di problemi incredibilmente utile e in primo piano.

Li uso insieme. OmniPlan è ottimo per disporre tutti i compiti che devono essere completati e dividerli tra la tua squadra. Puoi configurare percorsi critici (cose che devono accadere per il completamento) e ripartizione dello sforzo complessivo. Ottimo anche visivamente per la gestione.

Pivotal è eccellente per mantenere il ritmo di sviluppo. Se ti iscrivi completamente alla metodologia agile, è eccellente, ma comunque molto utile per tenere traccia delle funzionalità, dei componenti dipendenti e dello stato attivo corrente.

FogBugz fornisce un'interfaccia facile da usare per i non programmatori per inviare bug o richieste di funzionalità e monitorare i progressi. I problemi che arrivano vengono valutati e registrati in modo pivotal. Quindi vengono spostati in OmniPlan se diventa un'attività più grande con più componenti.

Usiamo Redmine - > link

Registriamo tutti i nostri sviluppatori e le chiamate di supporto in modo da poter vedere quanto tempo abbiamo libero di assegnare a uno sprint sul nostro ultimo sviluppo. È utile perché si integra perfettamente con il nostro sistema di posta elettronica e il nostro sistema di controllo delle versioni (Git nel nostro caso, ma funziona con altri).

Facile da utilizzare (scritto in Ruby, verrà eseguito sulla maggior parte dei piccoli server) e con alcuni componenti aggiuntivi abbastanza potenti che sono facili da installare e utilizzare.

Va bene rispondere nessuno ?

Sembra che implichi che sono necessari strumenti software per una pianificazione agile di successo. Non sono d'accordo Se la tua squadra sta usando correttamente scrum o XP ("dal libro"), non dovresti utilizzare alcun software per la pianificazione.

In molti casi, l'aggiunta di strumenti software a un processo agile è solo un modo per evitare di dover affrontare l'effettivo problema sottostante relativo a una scarsa comunicazione o fiducia. Tali problemi possono essere risolti meglio con altri mezzi.

La mia raccomandazione è di iniziare senza strumenti digitali e aggiungerli in un secondo momento quando veramente capisci perché ne hai bisogno.

(I team distribuiti sono un caso speciale)

Ho utilizzato entrambi Rally e JIRA con Greenhopper .

Inizierò con JIRA. JIRA è un eccellente strumento per il tracciamento dei bug. Greenhopper è un componente aggiuntivo che consente ai team di iniziare a lavorare con agilità. Poiché non è stato concepito come uno strumento agile da zero, alcuni processi sembrano imbarazzanti. Lo strumento richiede anche tempo e è difficile da usare. Tuttavia, è estremamente personalizzabile. In generale, sembra uno strumento in cui devi inserire processi agili.

Rally è stato progettato da zero per essere uno strumento agile e mostra. Segue molto bene i processi agili e completa il processo. Ho utilizzato questo strumento in un'organizzazione estremamente agile e ci ha permesso di tenere traccia delle dipendenze tra team e di progetti complicati che coinvolgono diversi team agili. Il coordinamento tra team è qualcosa con cui altri strumenti sono in difficoltà, ma Rally lo ha fatto bene. Inoltre, Rally ha un'eccellente API basata sui servizi Web. Permetteva al mio team di scrivere software personalizzato usando Rally come nostro backend e di generare report personalizzati.

Utilizziamo TFS per il controllo del codice sorgente e il monitoraggio degli oggetti di lavoro (sfortunatamente), e io uso Telerik work item manager per aiutarmi a registrare piani di sprint e mantenere sincronizzata la bacheca. Se sei costretto a usare TFS, telerik lo rende meno doloroso.

Usiamo un tracker di problemi chiamato FIT (lavoro per questa azienda come appaltatore esterno, quindi è stata una mia scelta su cosa usare). Fogbugz era costoso in confronto. Ha un ingombro ridotto, basato sul web, economico e fa le solite cose. Ho esaminato Redmine che è un pacchetto meraviglioso ma la gestione era a disagio per un pacchetto open source che era ancora all'avanguardia.
  Per uno strumento come un tracker dei problemi, non volevo mantenerlo o aggiornarlo o personalizzarlo: volevo solo che funzionasse immediatamente e rimanesse tale.