Quale software utilizzi per pianificare il lavoro del tuo team e perché?

La pianificazione è molto difficile. Non siamo naturalmente bravi a stimare il nostro futuro e molti pregiudizi cognitivi esacerbano il problema. La pianificazione di gruppo è ancora più difficile. Informazioni incomplete, opinioni incoerenti di una situazione e problemi di comunicazione aggravano la difficoltà.

I metodi agili forniscono un framework per l'organizzazione della pianificazione di gruppo: rendere la pianificazione visibile a tutti (user story), suddividerla in blocchi più piccoli (sprint) e fornire analisi retrospettive per migliorare la pianificazione. Ma trovare buoni strumenti per supportare queste pratiche si sta rivelando difficile.

Quali strumenti software utilizzate per raggiungere questi obiettivi? Perché stai usando quello strumento? Quali successi hai avuto con un particolare strumento?

OmniPlan

Strumento di pianificazione per Mac OS X.

Pivotal Tracker

Utile anche se non stai sviluppando "agile".

FogBugz

Monitoraggio dei problemi incredibilmente utile e in primo piano.

Li uso insieme. OmniPlan è ottimo per disporre tutte le attività che devono essere completate e dividerle tra il team. È possibile impostare percorsi critici (cose che devono accadere per il completamento) e interrompere lo sforzo complessivo. Ottimo anche visivamente per la gestione.

Pivotal è eccellente per tenere il passo del tuo sviluppo. Se ti abboni completamente alla metodologia agile, è eccellente, ma comunque molto utile per tenere traccia delle funzionalità, dei componenti dipendenti e dello stato attualmente attivo.

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 si presentano vengono valutati e registrati in Pivotal. Quindi vengono spostati in OmniPlan se diventa un'attività più grande con più componenti.

Usiamo Redmine -> http://www.redmine.org/

Registriamo tutti i nostri sviluppatori insieme a chiamate di supporto in modo da poter vedere quanto tempo abbiamo libero di allocare a uno sprint sul nostro ultimo bit di sviluppo. È utile perché si adatta perfettamente al nostro sistema di posta elettronica e al nostro sistema di controllo della versione (Git nel nostro caso, ma funziona con altri).

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

Va bene rispondere a nessuno ?

Sembra che tu implichi la necessità di strumenti software per una pianificazione agile di successo. Non sono d'accordo Se il tuo team sta usando correttamente Scrum o XP ("dal libro"), non dovresti usare alcun software per pianificare.

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

La mia raccomandazione è di iniziare senza strumenti digitali e di aggiungerli in seguito solo quando capisci davvero perché ne hai bisogno.

(I team distribuiti sono un caso speciale)

Ho usato sia Rally che JIRA con Greenhopper .

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

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

Utilizziamo TFS per il controllo del codice sorgente e il monitoraggio degli oggetti di lavoro (purtroppo) e utilizzo il gestore degli oggetti di lavoro di Telerik per aiutarmi a registrare i piani di sprint e mantenere sincronizzata la taskboard. Se sei costretto a usare TFS, Telerik lo rende meno doloroso.

Usiamo un tracker di problemi chiamato FIT (lavoro per questa azienda come appaltatore in outsourcing, quindi è stata la mia scelta cosa usare). Fogbugz era costoso in confronto. Ha un ingombro ridotto, basato sul web, economico e fa le solite cose. Ho guardato 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 di problemi non volevo mantenerlo o aggiornarlo o personalizzarlo: volevo solo che funzionasse immediatamente e rimanesse così.