Tableros Kanban / Scrum [cerrado]

Question

Tengo curiosidad por saber qué otras personas usan para los tableros Kanban / Scrum físicos en sus empresas. Aprecio que, debido a la información comercial confidencial, es posible que no pueda proporcionar una foto de la pizarra. Estoy mirando para saber cómo se ve tu tablero , y cómo organizas las historias y tareas de los usuarios a medida que avanzan a través de un sprint / iteración típico.

Típicamente, he trabajado en lugares que organizan la pizarra de la siguiente manera con cada

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

Para resumir:

• Una tarea para UC-001 está en progreso por un miembro del equipo (Bob). Una lista de tareas para que otras personas retengan está esperando en la columna Todo, pero otro miembro del equipo puede coordinar esta tarea para coordinar con Bob y hacer el trabajo.
• Para UC-002, se completó la tarea del servicio de pago y se completó un arnés de prueba automático para el control de calidad que les permite probar el servicio sin una interfaz de usuario. Si la prueba falla, se genera un error y se mueve junto con la tarea de Servicio de pago a la fase de control de calidad
• Todas las tareas para UC-003 se completaron y se movieron a Ready for QA.
• Todas las tareas para Uc-004 y UC-005 se completaron, por lo que la historia del usuario se trasladó a Hecho.

Esto funciona como una pizarra blanca tangible que involucra a las personas que interactúan con cada una de las tareas / historias de usuario (representadas como notas post-it). Se crea una versión electrónica antes del sprint / iteración y solo se actualiza al final del sprint / iteración correspondiente a la situación actual. Los comentarios y críticas son bienvenidos:)

Answer 1

Usamos algo inspirado en el famoso Scrum y XP de Trenches de Henrik Kniberg, las columnas se adaptan en función del contexto (a menudo: TODO, EN EL CAMINO, PARA SER PROBADO, HECHO):

texto alternativo http://blog.realcoderscoding.com/ wp-content / uploads / 2008/09 / hk.png

Los elementos del Backlog del producto (PBI) se imprimen como " tarjetas físicas " (Formato A5) para la reunión de planificación de Sprint (al menos la más importante). Una vez que el equipo ha recogido los PBI para la siguiente iteración, los elementos se dividen en tareas / actividades (en notas adhesivas). Después de la reunión, todo va en el Scrum Board y le sugiero que use cinta, chinchetas o imanes. Los PBI están ordenados por importancia, los más importantes en la parte superior del tablero y menos importantes en la parte inferior. El equipo debe trabajar en el elemento más importante primero hasta que se haga. Primero, la actividad post-it se mueve de izquierda a derecha. Entonces, el PBI salta a Hecho. Las tareas inesperadas se agregan a un " Elementos no planificados " zona (para tenerlos en cuenta en el gráfico de burndown). Los PBI futuros permanecen visibles en un " Siguiente " zona (si todos los elementos se completan durante la iteración, seleccionamos uno nuevo desde allí). Bastante simple.

Estas prácticas permiten detectar olores visualmente, por ejemplo:

• tareas atascadas (es decir, tareas que no se están moviendo) que muestran un impedimento potencial
• el equipo hace las cosas en el orden incorrecto y no se centra en los elementos de mayor prioridad, como en su muestra :)
• demasiado trabajo en progreso, nada hecho
• elementos no planificados que están matando a un sprint

Funciona muy bien.

Si está buscando más " kanban orientado " tal vez, eche un vistazo a Scrum Kanban vs Scrum , Un día en Kanban Land y Kanban y Scrum: una guía práctica del mismo Henrik Kniberg. Grandes cosas también.

Y, para obtener más fotos, pruebe Google Images con scrum + board , kanban , scrumban , scrum + kanban .

Answer 2

Aquí está nuestro Tablero Kanban que usamos en TargetProcess . No trabajamos en el nivel de Tareas, solo en el nivel de Historias de Usuario y Errores. A veces creamos tareas, pero no se rastrean explícitamente en el tablero.

No estimamos las Historias de Usuario ni los Errores, pero intentamos dividir las Historias en más pequeñas (con éxito mixto). Las columnas son autoexplicativas. Acumulamos elementos en la columna Probado , luego creamos una rama, probamos humo y lanzamos una nueva versión. Por lo general, lanzamos nuevas versiones cada dos semanas.

También la placa muestra a los desarrolladores y evaluadores la carga y las clases de servicios a través de códigos de colores.

UPD. Ahora tenemos varios equipos pequeños y utilizamos una sola placa para rastrear el progreso de todos los equipos en http: //www.targetprocess. com / 3

Answer 3

Guión gráfico de programación Scrum / Extreme.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

El trabajo aparece en la segunda columna de la izquierda y avanza a través del tablero a través de diferentes etapas de integridad.

Nombres de columnas: No iniciada, recién iniciada, a mitad de camino, casi terminada, lista para exhibición (aprobada QA)

La primera fila está especialmente reservada para la corrección de errores, como una prioridad fija para eliminar errores.

Los personajes de los Simpson representan a cada miembro del equipo. Se mueven para que podamos ver quién está trabajando en qué.

Answer 4

Le sugiero que eche un vistazo a la pizarra Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_samp= = geffort Puede adaptarse a todas sus necesidades debido a su interfaz intuitiva, estadísticas, panel de control. También se adapta a cualquier proceso y lo más importante es que es muy fácil de usar. Este tablero le permite representar varios proyectos en un tablero utilizando filas. Todas las filas pueden estar visibles al mismo tiempo o puede eliminar las seleccionadas del ámbito. Otra solución puede ser agrupar y filtrar las tareas por categorías, luego todas las tareas pueden representarse en una placa y fila, pero vinculadas a diferentes categorías.

Answer 5

En la práctica, la organización de la junta de trabajo en progreso es mejor dejar que el equipo la determine según sus circunstancias y entorno. (Agile == autogestión.)

Dicho esto, esto es lo que hicimos en mi equipo anterior, parte de un esfuerzo de más de 300 desarrolladores que era relativamente nuevo para Agile y Scum:

Tuvimos dos tablas - una con fichas para las próximas historias para que pudiéramos decir lo que se avecinaba, y otra con el trabajo del sprint actual. Nuestras columnas en el tablero actual de sprint eran simplemente

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

y un cuadro en la esquina para Blocked .

Una nota post-it representaba cada historia.

Cada uno de los desarrolladores tenía un pequeño imán que usaban en el standup cada mañana para indicar quién estaba trabajando en qué. Nuestro equipo era bastante grande (~ 12 en un punto), por lo que esto realmente ayudó a determinar quién fue emparejado con quién.

No nos molestamos con una versión electrónica (sin punto), aunque nuestro Product Product sí tenía un sistema Scrumworks que necesitaba para mantenerse actualizado. Nos mantuvimos tan lejos de eso como pudimos!

Answer 6

Estoy muy interesado en Lean / Kanban y hemos estado iterando en nuestro proceso por un tiempo, inicialmente a través de un flujo de trabajo personalizado en JIRA, pero eso no es exactamente sin fricción dada la complejidad del administrador en la versión empresarial. Ahora hemos ampliado nuestro uso de una pizarra y hemos decidido iterar nuestro proceso utilizando la pizarra durante un tiempo antes de recodificarla en JIRA. Aquí hay un ejemplo de nuestro diseño:

• Somos 6 desarrolladores
• Cuando una historia está en dev, está en el escritorio de un dev. Del mismo modo, con la revisión, el control de calidad, etc. Esto significa que cada tarjeta en la pizarra representa un elemento accionable, y también proporciona una instantánea bastante precisa del progreso de la iteración. La regla es que solo en circunstancias excepcionales tiene más de una tarjeta en su escritorio.
• Hemos acordado no tener más de dos tarjetas " amontonar " en la columna En espera de revisión. Esto mantiene un grado de " flujo " ;.

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

Esto está bastante cerca de mapeo de la corriente de valor , excepto la parte de despliegue que espera, que es un truco para solucionar el problema en el que el control de calidad no puede realizar el control de calidad de un elemento hasta que lo implementamos en su servidor; implementamos 3/4 veces durante una iteración de 2 semanas.

Una cosa que he notado al mapear el flujo de valor en una " information radiador " es que hace que las personas se centren mágicamente en el trabajo de valor agregado real que se debe hacer, y eso parece aumentar el ritmo de desarrollo del valor empresarial y mantener el impulso.

Espero que ayude!

Answer 7

Estamos experimentando con un par de estructuras de placa diferentes en varios proyectos diferentes que estamos ejecutando. Un proyecto tiene la estructura más básica que podemos usar:

| (Sprint) Backlog | In Progress | Done |

En la medida de lo posible, tratamos de tener un solo post-it para representar las actividades de desarrollo y control de calidad de una historia.

La estructura anterior parece funcionar bien para los desarrolladores del proyecto, pero los miembros de control de calidad han tenido dificultades para saber cuándo una historia completó el trabajo de desarrollo de manera que pudieran ejecutar sus pruebas para esa historia. Nos encontramos moviendo las historias al "lado lejano" de la sección En curso para indicar que se realizó el trabajo de desarrollo y que el control de calidad podría recoger esa historia. Esto se convirtió rápidamente en algo muy difícil de manejar cuando se llenó la sección En curso .

Esto llevó a la segunda iteración de la estructura del tablero para otro proyecto que es:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

La sección recién agregada Listo para prueba se convirtió esencialmente en una sección formal de la placa que anteriormente era la " cara opuesta " de la sección En curso . En la superficie, esto debería haber aclarado las cosas para los miembros del control de calidad, pero esto aún causó cierta confusión, ya que las personas tenían diferentes interpretaciones de lo que significaba Listo para el examen (no los aburriré con el diferentes interpretaciones aquí).

Esto llevó a la última iteración de la estructura de la placa que estamos usando en otro proyecto:

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

Esto está bastante lejos de las secciones simples Backlog , In Progress y Done de la primera iteración, pero esto parece estar trabajando bien para el equipo. Tienen una comprensión clara de lo que significa mover una historia a través de varias secciones de la pizarra y para cualquier historia, da una idea clara de dónde se encuentra esa historia en particular en el ciclo de vida. Solo hemos estado utilizando esta estructura desde el inicio del sprint actual (estamos 9 días en un sprint de 10 días), por lo que exploraremos esta estructura con más detalle en nuestra retrospectiva de mañana. No es perfecto, estoy seguro, pero si continúa funcionando para el equipo que lo está piloteando, intentaremos implementarlo en otros equipos de nuestra organización.

Answer 8

Nuestra pizarra se divide en estas columnas:

Story, Not Started, Req / Des / Dev *, Peer Review, QA, Done

Las historias de mayor prioridad van de arriba a abajo. Cada historia puede tener múltiples tareas, así que usamos una gran publicación para la historia y otras más pequeñas para las tareas. Las tareas se mueven de izquierda a derecha. Todos los días nos aseguramos de que estemos trabajando en las historias de mayor prioridad.

Usamos una pestaña blanca pegajosa en cada tarea donde la persona que trabaja pone sus iniciales. Cuando hayan terminado y muévalo a lo largo de una nueva pestaña blanca, se coloca sobre la antigua para mostrar que está disponible para que cualquiera la pueda recoger. Cuando se realizan todas las tareas, la historia se mueve también a la columna Hecho y, en el standup, todo el trabajo Hecho se cuenta y se mueve hacia arriba en el tablero para hacer espacio en la parte inferior para más historias.

También tenemos pestañas de colores para las historias y tareas para indicar los bloqueos que deben progresar (el azul indica un bloqueo de otro equipo, el rojo solicitando asistencia de scrum master) Hablamos de los obstáculos en cada standup.

Podemos ver cuando hay demasiadas tareas en una columna en particular y cambiar el énfasis para hacer más en Listo. Hemos agregado deliberadamente la columna de revisión para enfatizar que el trabajo necesario fue revisado por otra persona que no sea la persona que lo realiza antes de que llegue al control de calidad.

* Requisitos / Diseño / Desarrollo

Answer 9

El nuestro se ve bastante similar. Cada desarrollador tiene una columna y nosotros tenemos filas para 'Hecho', 'En prueba', 'Trabajo en progreso', 'Trabajo acumulado'.

Y usamos notas de estilo de post-it reales que movemos físicamente a medida que avanza en cada fase.

Personalmente, encuentro que falta el sistema ...

• Los post-it que se mueven manualmente se convierten en un dolor después de un tiempo. Nuestro equipo de control de calidad administra principalmente la transferencia de tickets, y es un esfuerzo constante para mantenerlos sincronizados con TFS.
• El post-it realmente solo se puede mover tantas veces antes de que ya no estén pegajosos. Si un boleto se devuelve de la prueba y se coloca en 'En progreso' y luego se regresa a la prueba, etc, etc ... no toma mucho para que termine en el piso.
• A veces, el volumen total de notas es abrumador. Las notas deben apilarse para ser visibles de forma remota; las colocamos en capas de tal forma que podamos ver cada identificador único de las notas (lo mejor que podamos) ... pero luego tiene una pila de 10 notas y necesita obtener la Queda fuera de la pila y está contribuyendo rápidamente a la disminución de la adherencia que terminará con las notas en el piso.
• Cuando las entradas terminan en el piso, es bastante molesto averiguar a dónde deben ir. ¿Fue ese boleto del Desarrollador A? O B? ¿Y fue en Pruebas? ¿O fue hecho? Regresemos a TFS, busquemos esos tickets y luego movamos los post-it en consecuencia.

Personalmente, no creo que las notas post-it sean la herramienta adecuada aquí. Hay un puñado de herramientas digitales que hacen que este tipo de cosas estén completamente libres de problemas. Utilizamos el servidor de Team Foundation, y he visto un par de herramientas de código abierto realmente excelentes, robustas, e incluso abiertas que se conectarán con el servidor de Team Foundation y administrarán todo eso por usted, en tiempo real.

http: / /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Answer 10

Nuestros tableros tienden a evolucionar a lo largo del tiempo a medida que avanzamos como equipo. Tiendo a favorecer los tableros de tarjetas físicas si tiene un equipo asignado al equipo, ya que fomenta una mejor comunicación cara a cara, en general, desde mi experiencia. Obviamente, hay más gastos generales, pero vale la pena hacer que el equipo trabaje en conjunto. Otra ventaja que he visto con los tableros físicos es que ayuda con el compromiso empresarial. Las partes interesadas remotas no pueden simplemente iniciar sesión y ver el progreso dentro del sprint actual y sacar las cosas fuera de contexto, ya que a veces las cartas no cuentan la historia completa. Deben tener una conversación y llegar a la junta, lo que puede ser beneficioso ya que las cosas se pueden explicar y también significa que se les puede alentar a ayudar a resolver los impedimentos. Sin embargo, esto no es exclusivo de los tableros físicos, pero ayuda.

Como se mencionó, nuestros tableros evolucionan con el tiempo y las necesidades de los equipos. A menudo comenzamos con scrum de libros de texto, pero alentamos la mejora continua y generalmente terminamos con una solución de scrumban. Estos cambios se reflejan al visualizar el nuevo flujo de trabajo a través de los tableros. Recientemente escribí una publicación sobre nuestro último cambio si le interesa ver nuestro scrum de reloj de arena / tablero Kanban

Creo que el equipo debería involucrarse en hacer los tableros, ya que ayuda al equipo a entender el flujo de trabajo y no a convertirse en un silo. Además, si el equipo ha contribuido a hacer que la junta directiva controle mejor sus propios procesos, lo que ayuda con la auto organización, ya que es un producto al que han contribuido.

Answer 11

Fuimos con la siguiente estructura de placa en nuestra empresa.

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

Los carriles se asignan a miembros específicos. Cada miembro tiene un trabajo diferente en nuestra oficina, por lo que las tareas varían. Añadimos lo que tenemos que trabajar a nuestro Backlog, luego lo movemos a Next Sprint si se aproxima a la fecha límite. Las tareas verdes bloqueadas se utilizan para tareas continuas en las que se debe trabajar diariamente. Las tarjetas rojas indican la importancia de la tarea y deben terminarse lo antes posible. Nuestra junta nos permite colaborar libremente y agregar tareas a los demás nadadores si necesitamos que un departamento diferente haga algo.

Usamos KanbanTool (Kanbantool.com) para visualizar nuestro flujo de trabajo y administrar proyectos. Es realmente intuitivo y fácil de usar. La comunicación de nuestro equipo ha mejorado enormemente.