project-management scrum fogbugz

project management - Scrum y Fogbugz



project-management (11)

¿Alguien por ahí usando Fogbugz y Scrum juntos?

Usamos Fogbugz extensivamente, y estoy buscando ideas de cualquier persona que pueda estar usándolo como parte de Scrum. Encontré estos dos elementos, pero están archivados y no están disponibles para una discusión posterior. Estoy específicamente interesado en ideas para mapear conceptos de Scrum en Fogbugz.

Algunas cosas son bastante obvias. Las versiones y los sprints se correlacionan bien entre sí. Pero otras partes de Scrum no encajan realmente.

http://support.fogcreek.com/default.asp?fogbugz.4.12143.4
http://support.fogcreek.com/default.asp?fogbugz.4.19971.3

También estoy pensando que puede que no sea demasiado difícil crear algo ligero y personalizado para envolver a Fogbugz para que no tengamos que abandonar una de nuestras herramientas favoritas para mejorar la integración de nuestros procesos de software.

Editar:

Estoy agregando algunas preguntas más específicas que han surgido. Cualquier sugerencia sobre estos elementos sería útil:

  • ¿Cómo priorizamos un gran retraso acumulado con solo los 7 niveles de prioridad proporcionados por Fogbugz? Podemos modificar las tablas de la base de datos para agregar más niveles, pero ¿es eso apropiado en el modelo de Fogbugz actual / previsto?
  • ¿Cómo / dónde documentamos un objetivo de sprint?
  • ¿Cómo documentamos un sprint cancelado?
  • ¿Cómo documentamos la revisión de sprint?
  • ¿Cómo rastreamos los sprints completados o cancelados?

Editar # 2:

La respuesta de Chris a continuación me recordó que, de hecho, nos hemos actualizado a Fogbugz v7. Tiene muchas características excelentes que lo alinean más de cerca con Agile, Scrum y Lean, incluyendo:

  • Proyecto Backlog (a través del plugin)
  • Flujo de trabajo personalizado
  • Burn Down Charts
  • Kanban Board (a través de un plugin)

Vea los siguientes enlaces para más información:
http://www.fogcreek.com/FogBugz/WhatsNew.html
http://www.fogcreek.com/FogBugz/Plugins/default.aspx?ixCategory=-3

Editar # 3 Agregando el enlace que Perhentian mencionó en su respuesta, así como otro que encontré:

http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

En icanhascheezburger.com, usamos FogBugz y hemos encontrado que FogBugz es genial en muchas cosas, pero no funciona tan bien para un desarrollo ágil al instante. Aquí hay dos cosas que hacemos:

Usamos los paneles de discusión para los informes de scrum diarios, aunque una página wiki podría ser más adecuada para eso, ya que puede suscribirse.

También utilizamos la prioridad 7 para la acumulación. Para encontrar todos los casos pendientes, solo busque:

priority:7 project:"project name"

La API haría que escribir un pequeño cliente de scrum fuera bastante fácil.

Complemento de Kanban para FogBugz

Actualmente estamos en el proceso de probar FogBugz en un proyecto basado en SCRUM.

Todavía estamos encontrando nuestros pies con SCRUM (y FogBugz) así que lo que estamos haciendo puede no ser SCRUM ''puro''.

En primer lugar, estamos utilizando Excel para el retraso en la publicación, por ejemplo, lo que entregaremos en la versión x.xx

De hecho, había escrito una publicación en un blog sobre el uso de FogBugz como una acumulación, pero terminé yendo con Excel, ya que lo que proponía era un poco complicado en retrospectiva y no creo que realmente estuviera ganando nada.

En la hoja de cálculo de retraso acumulado, guardamos el nombre del elemento de registro retroactivo, estimaciones de tamaño, para que podamos calcular la velocidad y otra información, como por ejemplo en qué sprint entregaremos cada elemento.

Mantenemos las especificaciones de nuestros productos en la wiki de FogBugz y agregamos enlaces a esta de cada entrada en la lista de espera.

En Fogbugz mapeamos lanzamientos a sprints y usamos elementos de cronograma para rastrear nuestras tareas para cada ítem atrasado.

Antes de comenzar un sprint, elegimos los elementos de backlog que vamos a entregar en este sprint. En FogBugz creo una nueva versión y establezco la fecha de finalización en dos semanas en la línea. A continuación, dividimos los elementos pendientes de registro en tareas y los agregamos a la publicación como ''elementos de programación''.

Todos estiman sus propias tareas y registran el tiempo en contra de ellas usando el menú "trabajando" como lo haría normalmente. Todos los días, los miembros del equipo revisan sus estimaciones y luego podemos usar los diversos informes para ver cómo están progresando las cosas. La tabla de confianza de fecha de envío te da una especie de burndown inverso.

Cada miembro del equipo también tiene un ítem del cronograma de "estado" que editan todos los días para registrar el informe de estado de la reunión diaria de pié, por ejemplo, ¿qué hice ayer? , ¿Qué estoy haciendo hoy? ¿Qué obstáculos hay en mi camino?

Como puede ver, realmente usamos FogBugz para la administración de tareas.

Lo elegimos más para EBS y Wiki.

Hasta ahora está funcionando bastante bien, pero el proyecto que estoy usando es un proyecto de 3 personas de 6 semanas.

Espero que algo de esto ayude. Avísame si necesitas alguna aclaración.

Edición: tampoco estoy tratando de poner en funcionamiento el sistema perfecto por primera vez. Estoy tomando el enfoque de probar algo y si no está funcionando, entonces cámbielo. Hasta ahora todo bien con FogBugz.

Usamos Scrumworks y JIRA.

SCRUM realmente no cubre cómo se implementan los procedimientos de QA / QC, parte de ágil es poder definir, mejorar e iterar procesos.

Buenos comentarios hasta ahora. Echaré un vistazo a Scrumworks. Realmente nos gusta Fogbugz y el equipo se siente cómodo con eso, así que es por eso que estoy tratando de ver si es factible.

@Stefan, una de las sugerencias de acumulación de productos en los artículos vinculados es que el retraso acumulado del proyecto se puede implementar en Fogbugz creando una publicación asignable del mismo nombre sin fecha, una fecha al final del contrato formal o una fecha lejana en el futuro. ¿Has probado eso o tienes alguna idea sobre por qué tu método podría ser mejor?

FogBugz y Scrum trabajan juntos de manera adecuada. Creo que tus preguntas son buenas, así que me limitaré a responder estas ...

¿Cómo priorizamos un gran retraso acumulado con solo los 7 niveles de prioridad proporcionados por Fogbugz? Podemos modificar las tablas de la base de datos para agregar más niveles, pero ¿es eso apropiado en el modelo de Fogbugz actual / previsto?

IMHO 7 es demasiado para administrar, me parece que los primeros 3-4 son manejables y más allá de eso, podría agrupar todo en un solo backlog "posterior". Sin embargo, la documentación de FogBugz o los artículos de KB de vez en cuando brindan orientación a las personas que han agregado niveles de prioridad adicionales, por lo que si FogBugz no tiene la intención de que usted lo use, parecen estar conscientes de ello y básicamente respaldan a las personas que lo hacen.

¿Cómo / dónde documentamos un objetivo de sprint? Tenemos una página de "revisión de sprint" en la wiki para cada proyecto. Documentamos el sprint más reciente en la parte superior y lo convertimos en una gran página (aunque me imagino que eventualmente guardaremos solo el año más reciente o algo así, ya que esas páginas se están poniendo ENORMES). La revisión de sprint que utilizamos es simple y tiene un conjunto de campos que debe completar el equipo y el PM. Antes del sprint documentamos un objetivo y el SBL, después de que agregamos los campos para la revisión.

¿Cómo documentamos un sprint cancelado?

En la página de revisión de sprint mencionada anteriormente.

¿Cómo documentamos la revisión de sprint? ¿Cómo rastreamos los sprints completados o cancelados?

Me imagino que ya puedes adivinar cómo lidiamos con esos dos :)

Espero que sea útil para ti y para otros que leen. Tenemos un par de errores relacionados con las estimaciones de FB que no he mencionado, pero si quieres hablar más, estaré encantado de hacerlo. Quizás tengas algunas experiencias para compartir de las que pueda aprender?

-scott

Después de usar FOGBUGZ y JIRA para ágil, he decidido que ninguna herramienta es realmente ideal para soportar el modelo. ¿Puedes ir a trabajar? Sí. JIRA es en realidad un poco mejor debido a la capacidad de personalizar más (Crear historias de usuario, etc.) Pero si realmente quieres que tu equipo esté en modo SCRUM, necesitas que todos miren un gráfico de burndown y que todos miren un retraso y creo deberías mirar herramientas como SCRUMWORKS. La versión básica es gratuita y te dará lo que quieras. Utilice JIRA y Fogbugz para lo que deberían hacer, realice un seguimiento de errores y solicitudes, pero no sea una herramienta de administración SCRUM completa.

Actualización: puede usar el complemento Greenhopper para JIRA, que es un poco mejor para admitir proyectos ágiles.

Hemos estado utilizando FB durante mucho tiempo, pero recientemente comenzamos a formalizar nuestro uso de Scrum.

Encontré las siguientes cosas BONITAS útiles:

  1. Usó una etiqueta para cada Sprint de Scrum.
  2. La etiqueta de sprint se ingresa en cada caso de FB en ese sprint.
  3. Tenemos un Wiki llamado "Scrum Sprint Reports"
  4. Dentro de esa Wiki, agregamos un artículo para cada nuevo sprint (los tenemos por semanas). Ese artículo tiene la misma etiqueta que la del sprint.

Entonces, las siguientes cosas ayudan:

En primer lugar, si simplemente busca por la etiqueta, encontrará: todos los casos y el artículo específico de Wiki (que incluso en la vista general le mostrará los objetivos)

En segundo lugar, creamos dos filtros: un filtro para mostrar los casos de ese scrum en una vista de lista, y un segundo filtro para mostrar los casos abiertos / cerrados en un gráfico circular. A medida que avance la semana, espera haber comido más del pastel.

Lo único que no me gusta de esto es que tengo que modificar mis dos filtros todos los viernes, pero al menos TGIF.

PD: Solo tengo ganas de mencionar que FB Wiki Editor es mejor que uno en 7.0, pero realmente debería tener una versión 0.8. Está al menos 2 ediciones lejos de ser algo estable.

Usamos FogBugz para scrum usando un "lanzamiento" para la acumulación de proyectos y luego creamos lanzamientos para sprints, moviendo elementos de la publicación de registro de proyectos a la versión sprint actual. Cada elemento tiene un presupuesto y, a partir de eso, podemos construir un gráfico de reducción, como se ilustra en esta pregunta anterior .

No, no es ideal pero funciona lo suficientemente bien.