Cualquier idea para mezclar un kanban con tableros de tareas

Soy el PM de un pequeño equipo de 6 programadores, recientemente estamos tratando de volvernos más ágiles al incluir en nuestro flujo de trabajo algunos principios o técnicas de XP, scrum, scrumban y lean.

Una herramienta muy importante es nuestro kanban, actualmente estamos usando github+zenhub para eso. Zenhub proporciona un kanban simple y personalizable (similar a trello) totalmente integrado en los problemas de github.

Nuestra configuración actual se ve así.ingrese la descripción de la imagen aquí

Es una especie de combinación de Taskboard Kanban y User story Kanban. Pero aún así, la columna 2,3 es administrada por el PO y el PM, mientras que las últimas 3 columnas son administradas por el equipo.

El problema es que tenemos esta mezcla de historias de usuarios y tareas, y me pregunto cuál es el enfoque típico para organizarlas. Algunas tareas son parte de las historias de usuario, mientras que otras (características no funcionales, tareas y refactores) no lo son. ¿Deberían ser parte del backlog? ¿Cómo mejorarías este kanban?

Respuestas (4)

Por lo general, descompondría sus historias de usuario en subtareas. Las tareas deben usarse para necesidades técnicas, no para la descomposición de una historia de usuario. No sé zenhub, pero en Trello podría crear una lista de verificación para las subtareas de EE. UU. debe sentir es que tiene una jerarquía de elementos y tal vez necesite un tablero para cada nivel, tal vez no necesite un tablero para las subtareas. En cualquier caso parece difícil representar dos niveles en un mismo tablero

Siempre estuve confundido acerca de esos dos conceptos (tareas e historias de usuario). Hoy, Zenhub lanzó problemas de temas épicos (esta es una jerarquía de un nivel, que se adapta perfectamente a la dependencia entre las subtareas de tareas y las subtareas de EE. UU.). Después de su publicación, agregué tareas y EE. UU. a la cartera de productos y a la cartera de pedidos de Sprint, y dejé ToDo/On Progress para la cartera de subtareas.
Otra cosa es que necesitamos tener un canal (kanban) para las subtareas, la razón es que como no estamos físicamente en el mismo lugar todo el tiempo, es importante saber quién está haciendo qué. Zenhub no proporciona varias placas, así que se me ocurrió esta solución para solucionarlo.
Me pregunto por qué la ubicación de los compañeros de equipo implica un tablero para subtareas.
Tal vez esté enfrentando un problema de tamaño para sus EE. UU. y tareas
La idea de tener un tablero de subtareas es saber quién está trabajando en qué subtarea y saber cuándo han terminado. Sobre el problema del tamaño, ¿quiere decir que mis historias/tareas pueden ser demasiado amplias?
Sí. En mi experiencia, las subtareas son solo para la persona (o la pareja) que realiza la implementación. Los EE. UU. y las tareas siguen un flujo de trabajo para que el equipo sepa qué hacer / en progreso / hecho
Ya veo, entonces, ¿recomienda no usar un tablero kanban de subtareas? Pero creo que estamos abordando la situación de manera diferente, en mi equipo, las historias de usuario generalmente las implementa más de una persona, por lo que trabajan en equipo creando las subtareas y asignándoles aquellas con las que están familiarizados o les apetece. Sin embargo, esas subtareas suelen depender unas de otras, por lo que necesitan una tabla visual para ver cuáles se han realizado y poder pasar a la siguiente subtarea.
Veo el problema. Para mí, sí, no deberías tener un flujo de trabajo debajo de las historias en la mayoría de los casos. Quizás la solución a tu problema esté en una herramienta de comunicación como slack o hipchat. Proporcionará un tablero para EE. UU. y tareas, y una sincronización de comunicación con una herramienta de sala de chat. Espero que pueda conectarse con zenhub. Y espero que ayude también
Tengo tu idea. esa fue una discusión muy valiosa, en realidad podría ser mejor lo que sugirió ya que nuestro tablero se ve muy desordenado y la microgestión de las subtareas a veces es un poco exagerada.

Comenzaría por pasar a un tablero de tareas físicas. Las herramientas pueden ser grandes multiplicadores de fuerza. Sin embargo, si comienza en una herramienta, a menudo se verá influenciado por la herramienta y terminará haciendo proceso por herramienta. Esto le está sucediendo a mis equipos en AOL ahora y tengo equipos que experimentan con tableros de tareas físicas para el día a día y Jira solo para documentar el trabajo para los registros oficiales.

Averigüe qué funciona bien para usted, con un tablero físico, luego descubra cómo hacer que la herramienta funcione.

Ese es un buen enfoque, lamentablemente, aunque tenemos una oficina, este es un proyecto de medio tiempo y, en ocasiones, es difícil encontrar a todos en la oficina (los miembros del equipo tienen otras funciones y viajan con frecuencia). Por lo tanto, confiamos mucho en las herramientas en línea.

Si mezcla historias con tareas, supongo que tendrá dificultades para obtener métricas razonables de su tablero.

Una de las cosas clave al hacer Kanban es medir el tiempo del ciclo y asegurarse de que cumpla con sus requisitos. También debe pensar en los tipos (clases de trabajo) para los que mide el tiempo de ciclo.

Recomendaría tener carriles de natación horizontales para diferentes clases de trabajo (errores, características, deuda técnica) y solo historias de usuarios. Así es como podría decir que, en promedio, las historias con tamaño X tardan Y días en completarse.

Mis 2 centavos.

Pondría los dos en tableros kanban separados, pero trataría de mantener intactos los vínculos entre las tarjetas. Eso solucionará muchos de los problemas y la confusión.

Anime a todos a mirar regularmente ambos tableros para no perder esa integración.

Cualquier idea para mezclar un kanban con tableros de tareas
RespuestasAquíPolítica de privacidad1y, 1v