¿Qué software utiliza para ayudar a planificar el trabajo de su equipo y por qué?

La planificación es muy difícil. No somos naturalmente buenos para estimar nuestro propio futuro, y muchos sesgos cognitivos exacerban el problema. La planificación grupal es aún más difícil. La información incompleta, las vistas inconsistentes de una situación y los problemas de comunicación agravan la dificultad.

Los métodos ágiles proporcionan un marco para organizar la planificación grupal: hacer que la planificación sea visible para todos (historias de usuarios), dividirla en trozos más pequeños (sprints) y proporcionar un análisis retrospectivo para que pueda mejorar la planificación. Pero encontrar buenas herramientas para apoyar estas prácticas está resultando complicado.

¿Qué herramientas de software utilizas para lograr estos objetivos? ¿Por qué estás usando esa herramienta? ¿Qué éxitos has tenido con una herramienta en particular?

OmniPlan

Herramienta de planificación de Mac OS X

Rastreador Pivotal

Útil incluso si no está haciendo un desarrollo "ágil".

FogBugz

Increíblemente útil y destacado seguimiento de problemas.

Los uso en conjunto. OmniPlan es excelente para diseñar todas las tareas que deben completarse y dividirlas entre su equipo. Puede configurar rutas críticas (cosas que deben suceder para completar) y desglosar el esfuerzo general. También excelente visualmente para la administración.

Pivotal es excelente para mantener su ritmo de desarrollo. Si se suscribe completamente a la metodología ágil, es excelente, pero sigue siendo muy útil para rastrear características, componentes dependientes y el estado actualmente activo.

FogBugz proporciona una interfaz fácil de usar para que los no programadores envíen errores o soliciten funciones y supervisen el progreso. Los problemas que se presentan se evalúan y se registran en Pivotal. Luego se trasladan a OmniPlan si se convierte en una tarea más grande con múltiples componentes.

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

Registramos todos nuestros desarrolladores allí junto con las llamadas de soporte para que podamos ver cuánto tiempo tenemos libre para asignar a un sprint en nuestro último desarrollo. Es útil porque se vincula muy bien con nuestro sistema de correo electrónico y nuestro Sistema de control de versiones (Git en nuestro caso, pero funciona con otros).

Fácil de sacar de la caja (escrito en Ruby, se ejecutará en la mayoría de los servidores pequeños) y con algunos complementos bastante potentes que son fáciles de instalar y usar.

¿Está bien responder a ninguno ?

Parece implicar que se requieren herramientas de software para una planificación ágil exitosa. No estoy de acuerdo Si su equipo está usando scrum o XP correctamente ("según el libro"), no debería tener que usar ninguna herramienta de software para planificar.

En muchos casos, agregar herramientas de software a un proceso ágil es solo una forma de evitar tener que lidiar con el problema subyacente real relacionado con una mala comunicación o confianza. Tales problemas se resuelven mejor por otros medios.

Mi recomendación es comenzar sin herramientas digitales y solo agregarlas más tarde cuando realmente comprenda por qué las necesita.

(Los equipos distribuidos son un caso especial)

He usado tanto Rally como JIRA con Greenhopper .

Comenzaré con JIRA. JIRA es una excelente herramienta de seguimiento de errores. Greenhopper es un complemento que permite a los equipos comenzar a trabajar con Agile. Debido a que no fue diseñado como una herramienta ágil desde cero, algunos de los procesos se sienten incómodos. La herramienta también consume mucho tiempo y es difícil de usar. Sin embargo, es extremadamente personalizable. En general, se siente como una herramienta en la que tiene que meter sus procesos ágiles.

Rally fue diseñado desde cero para ser una herramienta ágil y se nota. Sigue muchos de los procesos ágiles extremadamente bien y complementa el proceso. Utilicé esta herramienta en una organización extremadamente ágil y nos permitió hacer un seguimiento de las dependencias entre equipos y proyectos complicados que involucran a varios equipos ágiles. La coordinación entre equipos es algo con lo que luchan otras herramientas, pero Rally lo ha hecho bien. Además, Rally tiene una excelente API basada en servicios web. Le permitió a mi equipo escribir un software personalizado usando Rally como nuestro back-end, así como generar algunos informes personalizados.

Usamos TFS para control de origen y seguimiento de elementos de trabajo (desafortunadamente), y uso el administrador de elementos de trabajo de Telerik para ayudarme a registrar planes de sprint y mantener el tablero de tareas sincronizado. Si se ve obligado a usar TFS, entonces telerik lo hace menos doloroso.

Utilizamos un rastreador de problemas llamado FIT (trabajo para esta empresa como contratista externo, así que fue mi elección qué usar). Fogbugz era caro en comparación. Tiene un tamaño reducido, basado en la web, es económico y hace las cosas habituales. Miré a Redmine, que es un paquete maravilloso, pero la administración estaba incómoda con respecto a un paquete de código abierto que todavía era de avanzada.
Para una herramienta como un rastreador de problemas, no quería mantenerlo, actualizarlo o personalizarlo: solo quería que funcionara de inmediato y se mantuviera así.