¿Cuál es la mejor manera de hacer un Desarrollo ágil con Trac? [cerrado]

Así es como usamos Trac para nuestro scrum como sprints:

• Utilizamos los hitos en Trac para identificar sprints.
• Hay un hito predeterminado de Backlog donde reunimos todos los tickets nuevos.
• Antes de cada sprint movemos tickets del backlog de la versión actual.
• En la página de hitos, podemos agregar retrospectivas y otra información sobre sprint usando la sintaxis wiki.

Así que solo la funcionalidad Trac predeterminada sin ningún complemento por ahora para mantenerla ligero. A medida que mejoramos podemos agregar características como gráficos de burndown o tal vez cambiar a otra herramienta, pero queremos obtener los procesos en su lugar primero.

Responder tarde, pero esto más de compartir mi experiencia con Trac+Agilo hasta ahora.

Para responder rápidamente a su pregunta, quizás Agilo sea la mejor opción disponible para el desarrollo ágil con Trac.

Ahora viene a instalar y usar la instalación fue muy fácil. Hemos utilizado su última versión 0.7.3.3. Se instala sin defectos en Trac 0.11 y Python 2.5. No olvide instalar libjpeg y python imaging library. Sería útil tener en cuenta que utilizamos virtualenv que tomó un hecho las cosas son más fáciles.

El uso posterior es muy simple. Para wiki prefiero la vieja mirada limpia de Trac sobre la personalización de Agilo. Aparte de eso, todas las cosas funcionan.

En su lista de correo he notado que están planeando ofrecer soporte multi-proyecto en el futuro. En todo recomiendo Agilo plugin para Trac.

Sí, instalé Agilo en nuestra instalación Trac.

Parece muy genial, incluye buenos gráficos de burndown.

Desafortunadamente dejé la compañía donde lo instalé antes de que pudiera obtener un uso serio de ella.

La instalación fue un dolor (Ubuntu Ibex) - Documenté pasos precisos en el Agilo Google Group.

El problema (como siempre) es la integración en el negocio de las cosas que PMs y CEOs les gusta ver (por ejemplo, horas estimadas vs reales). Hay (como se ha mencionado) hay otros productos que cubren esto (FogBugz cubre esto creo), pero a mí (y al equipo) me encanta Trac, así que trabajamos alrededor de esto.

Oh, una cosa más; parece que introduce una gran cantidad de gastos generales (es decir, tienes que pasar más tiempo en trac para sacarle el máximo provecho), pero como digo no tuve la oportunidad de usarlo realmente con ira.

Usamos Trac antes con un plugin de burndown y luego fuimos a Redmine. Hemos encontrado que Redmine es miserable para la visualización del repositorio y la interfaz de problemas. En realidad estamos buscando volver a Trac de nuevo.

Bitten es un complemento de Trac para la integración continua que se puede aprovechar para hacer compilaciones automáticas en el check-in, lo que proporciona una parte crítica del proceso Ágil (retroalimentación rápida). No he utilizado ningún otro plugin para Trac personalmente, así que no puedo comentar sobre ellos. Sin embargo, la funcionalidad Trac nativa de los hitos podría aprovecharse con bastante facilidad, sospecho, para usarse como marcadores de iteración (donde cada hito representa el final de una iteración). Dado que los hitos se pueden utilizar para marque una' fecha de vencimiento ' para las características ya, no debería necesitar mucho en el camino de modificación para usarlas como tales.

A partir de ahí, usar tickets como historias de usuario y vincularlos a hitos (estoy seguro de que esto se puede hacer manualmente en el peor de los casos) le daría un método básico de seguimiento de la velocidad y mantener al equipo al tanto del progreso (y los cambios que también deben realizarse).

Usamos el wiki de Trac para:

• Lista de requisitos para cada característica
• Lista de especificaciones técnicas (en su caso) para las características
• Lista de lanzamientos y sus características
• Entornos implementados, con enlaces a todas las instancias
  • Hay una macro para hacer solicitudes web, para que podamos enumerar qué versión, etc. cada env tiene
  • (hay un plugin GraphViz que es bastante útil para dibujos simples)

También hay un ticket en el sistema de tickets para cada "característica", para mantener un backlog bruto y el sprint actual/siguiente planificado.

Luego escribimos un montón de cartas durante la planificación del sprint para cada función.

También hay un lado más operativo de las cosas. Mantenemos una persona cada sprint en Operaciones, por lo que tenemos una persona que se dedica a ser interrumpida por personas fuera del equipo. El resto del equipo puede centrarse en la entrega de características.

Cada tarea bug / ops recibe un ticket, pero tan pronto como empezamos a trabajar en él, obtiene una carta y comienza a moverse a través del tablero. De esa manera se consigue visibilidad y no nos olvidamos de involucrar a los probadores, etc.

Scrum es bastante táctil, así que no creo que funcionaría muy bien poner demasiadas cosas fuera del entorno de trabajo físico. Pero al final tu equipo necesita encontrar un equilibrio que funcione.

Para algo completamente diferente, la mejor manera de hacer Desarrollo Ágil con Trac puede ser simplemente migrar todo a Redmine. Es compatible con las características principales de Trac con algunos extras que incluyen múltiples proyectos, gráficos de Gantt, foros, DCVS, etc. aunque parece que no está completamente ahí todavía. Algunas cosas buenas en la tubería.

Daniel Srb (en los comentarios) tiene un redmind agile plugin ha estado trabajando en que se ve prometedor. Es posible que pueda ponerse en contacto y ver si está planeando liberarlo (fue hace mucho tiempo).

Hemos tenido éxito usando dos productos en concierto en el pasado, Trac para entradas, xplanner para la planificación.

Agilo para Scrum rocks, las últimas versiones están utilizando gráficos generados por el lado del cliente, por lo que ya no hay dependencia, es mucho más fácil de instalar :-) agile42 solo lanza una versión Pro que enriquece la experiencia de Agilo con un Tablero de planificación agradable e intuitivo , screencast muy cool: -)

Recientemente comenzamos a usar Scrumban.

Básicamente un tablero Kanban, con las reuniones diarias que cubren las preguntas clásicas de Agile Scrum: ¿en qué trabajaste el día anterior? ¿en qué piensas trabajar hoy? ¿tienes algún bloqueador?

Hacemos esto alrededor de un tablero Kanban físico, es ideal para visualizar el flujo de trabajo y para la sinergia del equipo, pero también queríamos una forma digital de nuestro tablero Kanban para poder verificar el uso del trac frente al uso físico Junta.

En busca de algo que funcionara, encontré este inteligente post sobre la recreación de una versión digital del tablero Kanban en trac.

Es muy sencillo y sencillo, pude manipular fácilmente este enfoque para nuestro flujo de trabajo, y probablemente podría adaptarlo a su enfoque iterativo ágil Scrum (o si puede deshacerse del enfoque en caja de tiempo, pruebe Scrumban).