Mejores prácticas de PivotalTracker [cerrado]

Question

(Para aquellos que no han oído hablar de él, Pivotal Tracker " es un Herramienta simple de planificación de proyectos basada en la historia que permite a los equipos colaborar y reaccionar instantáneamente a los cambios del mundo real. Se basa en métodos de desarrollo de software ágiles, pero se puede utilizar en una variedad de tipos de proyectos. ""

Estamos a punto de desarrollar un flujo de trabajo basado en este esbozo de Rein Henrichs y tenía curiosidad por saber cómo dividir los componentes del producto en proyectos.

Hemos experimentado algunos con el etiquetado, pero parece que si hay muchos componentes en un sistema (un visor de fotos, un visor de video, un servicio de noticias, un servicio de notificación) un solo proyecto puede estar bastante lleno.

Al mismo tiempo, para el control de versiones, etc., parece tener más sentido tenerlo todo en un proyecto, independientemente del desorden.

¿Alguna idea? Opiniones? Comentarios? Gracias.

Answer 1

Recuerde que Tracker es una herramienta de planificación basada en historias, no una herramienta de planificación basada en tareas. Desde el punto de vista del cliente, no importa si la historia impacta al visor de fotos, al servicio de notificaciones o a ambos. El cliente tiene algunas historias (requisitos de alto nivel) que le gustaría haber implementado, tiene estimaciones sobre el costo de las historias y tiene la capacidad de priorizar las historias. Romper cosas en componentes es un problema de nivel de tarea.

Más importante aún, dividir historias para el mismo producto en múltiples proyectos de seguimiento dificultaría que el cliente comunique cómo priorizan las historias u obtenga una buena estimación de cuándo podrían completarse las historias.

Usamos Rastreador para rastrear nuestras historias, y tenemos nuestro propio tablero donde rastreamos las tareas. Personalmente, creo que sería útil rastrear historias y tareas en Tracker, pero la herramienta no lo admite.

Answer 2

Probablemente sea mejor tener un solo proyecto para contener todas sus historias. De esa manera, tiene un lugar único para que todo el equipo vea qué está pasando con el proyecto y cuáles son los elementos prioritarios actuales. Si tiene sus historias desglosadas lo suficiente como para que puedan ser las características del proceso de Rein, ¡está en buena forma! Al final del día, tener una lista de características priorizadas es todo lo que cualquier equipo de desarrollo realmente necesita. Use las etiquetas en Tracker para filtrar. Funcionan bien En mi opinión, dividir un solo producto en múltiples proyectos dependientes en realidad oscurece la información y dificulta la visibilidad del verdadero estado del proyecto.