Pregunta

Estoy buscando la "mejor" característica ágil y software de seguimiento de defectos. Actualmente, estamos utilizando Fogbugz, pero esto no es terriblemente útil para los equipos que siguen una metodología ágil por lo que puedo decir. Hay mejores herramientas para esto, como Greenhopper para Jira. He usado JIRA antes, pero me pregunto si hay otras herramientas que sean mejores.

¿Fue útil?

Solución

Relacionaré mi experiencia, esperando que sea útil.

Comenzamos a pilotar scrum usando tarjetas en una pared. Pensamos que cambiaríamos a una herramienta una vez que comenzamos a hacerlo de verdad. Configuramos nuestro rastreador de defectos (Rojizo) con la historia del usuario y las tareas, y tener una manera de crear un quema en cada proyecto. Sin embargo, lo que encontramos es que realmente no obtienes la transparencia de un radiador de información física. La gente camina por la pared de la tarjeta y puede ver el progreso del equipo. Muy pocos verificarán el sitio web con tanta frecuencia como inspeccionen la pared de la tarjeta. Entonces, actualmente, hacemos la pared de la tarjeta para el sprint actual y Rastree el sprint en Redmine, que nos brinda información histórica.

A medida que escalamos a más equipos de los que tenemos espacio en la pared, nos dimos cuenta de que necesitaremos una herramienta que pueda funcionar como una pared de tarjetas y ser un rastreador ágil 'real'. Así que observamos varias herramientas, y nuestra lista corta incluía Versión uno, Reunión, y Mezclarse. Cualquiera de estos productos puede ser mejor para usted, pero en última instancia elegimos Mingle por varias razones.

Lo único que me preocupa es la pérdida de las paredes de la tarjeta. Es difícil explicar el valor transformador que han tenido estos radiadores de información pública. Los equipos obtienen mucha visibilidad de los propietarios de productos, así como de la gerencia y otras partes interesadas. Me preocupa que la visibilidad se pierda si cambiamos a usar únicamente la herramienta. Es posible que tenga que construir paneles que suban sobre monitores montados en la pared, actuando como una versión de alta tecnología de las paredes de las cartas. Una cosa que hicimos fue obtener algunas pizarras de pantalla táctil que permitirá a los equipos en standups mover las tarjetas virtuales de una manera familiar, utilizando la interfaz de pared de tarjetas de arrastre de la herramienta. Espero que esto nos permita retener los beneficios de comunicación e interacción del equipo que hemos visto cuando se reunimos alrededor de la pared de una tarjeta.

De todos modos, ¡buena suerte con tu búsqueda!

Otros consejos

Estamos utilizando PivotalTracker (http://pivotaltracker.com) en nuestros proyectos. Es una herramienta liviana y fácil de usar. Funciona en la nube, por lo que crear una cuenta y configurar un proyecto es cuestión de minutos. La historia del usuario y la entrada de errores es bastante fácil. La herramienta admite un flujo de trabajo estándar de tareas que consisten en estados no iniciados, iniciados, terminados, aceptados y rechazados.

Todavía no he probado Fogbugz, pero usé Jira, Greenhopper y VersionOne antes de PivotalTracker. La desventaja de todas estas herramientas contra PivotalTracker es que usarlas te brinda demasiado. Tienes que configurarlos y mantenerlos. Tienes que configurarlos. Y debido a que son más difíciles de usar, requieren más tiempo para el uso diario. He visto que los desarrolladores dudan en usar estas herramientas porque crean demasiada fricción. IMO PivotalTracker es la mejor herramienta a este respecto.

La desventaja de PivotalTracker es que solo ofrece unas pocas opciones de configuración. No le permite personalizar los flujos de trabajo. No tiene muchas opciones de autorización de usuario. Pero en nuestro caso se adapta muy bien a nuestras necesidades.

Esto podría ser una no respuesta hasta cierto punto, pero espero que siga siendo informativo y agregue valor.

He estado en varios equipos usando varias herramientas, incluidas tablas físicas y Greenhopper. Otros equipos ágiles en mi departamento han utilizado y evaluado varias otras opciones. Si está hablando de encontrar la forma más eficiente de administrar el equipo dentro de un sprint (en lugar de la planificación de liberación, el aceo de la cartera de pedidos, etc.) He llegado a la siguiente conclusión:Nada va a ser un gran ajuste a menos que escriba la herramienta usted mismo o use una hojas de rentabilidad. Sí, una hoja de cálculo. Es la opción más flexible que he encontrado. Usamos uno elegante con gráficos de quemaduras y demás, pero funciona muy bien.

Cualquier herramienta que encuentre ahora que puede ser un ajuste perfecto eventualmente terminará sin hacer algo que desee. Aquí hay un ejemplo de mi propia experiencia reciente:

Estábamos trabajando para reducir el tiempo que lleva informar el estado durante la reunión diaria de scrum. El desafío era que los desarrolladores tienden a entrar en una explicación detallada de los problemas que han encontrado mientras trabajaban en una tarea. Tratamos de posponer esas discusiones hasta después de la reunión Scrum. Fue difícil de hacer hasta que comenzamos simplemente destacando cualquier elemento en la hoja de cálculo que debemos discutir más. Esto seguimos adelante con la reunión pero no perdamos el nogro de temas que deben discutirse. Fue fácil introducir esto en nuestro proceso precisamente porque estábamos usando una herramienta flexible como una hoja de cálculo. La herramienta no se interpuso en el camino de mejorar nuestro proceso.

En cuanto a la tachuela de defectos, la mayoría de los equipos de mi departamento usan Jira.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top