Kanban/Scrum Boards

Question

Tengo curiosidad sobre lo que otras personas usan para las tablas físicas de Kanban/Scrum en sus empresas. Agradezco que debido a la información comercial delicada, es posible que no pueda proporcionar una foto de la junta. I "m mirando para averiguar lo que hace su consejo parece, y cómo organizar las historias de usuario y tareas medida que se mueven a través de una carrera de velocidad típica/iteración?

Normalmente He trabajado en unos lugares que organizar la tabla 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 curso por un miembro del equipo (Bob) una lista de tareas para otras personas. parte superior ick up están esperando en la columna Todo, pero este puede ser recogido por otro miembro del equipo que se coordina con Bob para realizar el trabajo.
• Para UC-002 se completó la tarea de servicio de pago y se completó un arnés de prueba automatizado para control de calidad que les permite probar el servicio sin una IU. Si la prueba falla, se genera un error y se mueve junto con la tarea del servicio de pago a la fase de control de calidad
• Todas las tareas para UC-003 se completaron y se movieron a Listo para QA.
• Todas las tareas para Uc-004 y UC-005 estaban completas, por lo que la historia del usuario se movió 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 las críticas son bienvenidos:)

Answer 1

Utilizamos algo inspirado en el famoso Scrum and XP from the Trenches de Henrik Kniberg, las columnas que se adaptan en función del contexto (a menudo: TODO, EN EL IR, para ser probado, hecho):

alt text http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

Los elementos del inventario de productos (PBI) se imprimen como "tarjetas físicas" (formato A5) para la reunión de planificación de Sprint (al menos las más importantes). Una vez que el equipo ha recogido las PBI para la próxima iteración, los elementos se dividen en tareas/actividades (en notas adhesivas). Después de la reunión, todo va en la Junta de Scrum y sugiero usar cinta adhesiva o chinchetas o imanes. Los PBI se ordenan por importancia, lo más importante en la parte superior del tablero, menos importante en la parte inferior. El equipo debe trabajar en el elemento más importante primero hasta que se haga. Primero, la actividad post-its se mueve de izquierda a derecha. Luego, el PBI salta a Listo. Las tareas inesperadas se agregan a una zona de "Elementos no planificados" (para tenerlos en cuenta en el gráfico de burndown). Los PBI futuros permanecen visibles en la zona "Siguiente" (si todos los elementos se completan durante la iteración, elegimos uno nuevo de allí). Bastante simple.

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

• tareas stucked (es decir,tareas que no están en movimiento) que muestran un posible impedimento
• equipo de hacer las cosas en el orden equivocado y no se centran en artículos de alta prioridad, al igual que en su muestra :)
• demasiado trabajo en curso, no se hace nada
• elementos no planificados que están matando un sprint

Funciona muy bien.

Si usted está buscando más "Kanban orientado" cosas, tal vez echar un vistazo a Kanban vs Scrum, One day in Kanban Land y Kanban and Scrum - a practical guide de la misma Henrik Kniberg. Genial también.

Y, para más fotos, darle una oportunidad Google con scrum+board, kanban, scrumban, scrum+kanban.

Answer 2

En la práctica, la mejor manera de determinar la organización del tablero de trabajo en progreso depende de las circunstancias y el entorno. (. == ágil autogestión)

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

Tuvimos dos tableros - uno con fichas para las próximas historias para que pudiéramos ver lo que estaba por venir, y uno con el trabajo del sprint actual. Nuestras columnas en el tablero de sprint actual eran simplemente

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

y una caja en la esquina de Blocked.

Una nota post-it representa cada historia.

Los desarrolladores tenían cada uno 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), así que esto realmente ayudó a descubrir quién estaba emparejado con quién.

No nos molestamos con una versión electrónica (no tiene sentido), aunque nuestro Product Owner tenía un sistema Scrumworks que necesitaba para estar al día. ¡Nos mantuvimos lo más lejos posible de eso!

Answer 3

La nuestra se ve bastante similar. Cada desarrollador tiene una columna y tenemos filas para 'Hecho', 'En prueba', 'Trabajo en progreso', 'Atrasos'.

Y utilizamos notas de estilo de post-it reales que nos movemos físicamente a medida que atraviesa cada fase.

Personalmente, me parece que el sistema sea deficiente ...

• mover manualmente los post-it llega a ser un dolor después de un tiempo. Nuestro equipo de control de calidad maneja principalmente el movimiento del ticket, y es un esfuerzo constante mantenerlos sincronizados con TFS.
• Los mensajes solo se pueden mover tantas veces antes de que ya no queden pegajosos. Si un ticket se envía de vuelta desde la prueba y se coloca en 'En progreso' y luego vuelve a las pruebas, etc., no tarda demasiado en terminar en el suelo.
• A veces, el gran volumen de notas es abrumador. Las notas deben apilarse para que sean visibles de forma remota: las superponemos de modo que podamos ver el identificador único de cada nota (lo mejor que podamos) ... pero luego tiene una pila de 10 notas y necesita obtener el Quinto de la pila y estás contribuyendo rápidamente a la disminución de la pegajosidad que terminará con las notas en el suelo.
• Cuando las entradas terminan en el piso, es bastante molesto averiguar a dónde deben ir. ¿Era ese boleto del Desarrollador A? O B? ¿Y fue en Testing? ¿O fue hecho? Regresemos a TFS, busquemos esos tickets y luego movámoslos según corresponda.

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 sea completamente libre de problemas. Usamos Team Foundation Server, y he visto algunas herramientas realmente geniales, robustas, gratuitas e incluso de código abierto que interactuarán con Team Foundation Server y administrarán todo eso en tiempo real.

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

Answer 4

Scrum/Extreme guión gráfico de programación. aparece

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

trabajo en la segunda de Colum la izquierda, y progresa a través del tablero a través de diferentes etapas de la integridad.

Los nombres de columna: no se ha iniciado, Acaba de comenzar, a mitad de camino, casi hecho, listo para escaparate (QA pasado)

La primera fila está especialmente reservado para la corrección de errores - como un fijo, la prioridad para la limpieza loco.

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

Answer 5

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 administrativa en la versión empresarial. Ahora hemos ampliado nuestro uso de una pizarra y hemos decidido repetir nuestro proceso utilizando la pizarra durante un tiempo antes de volver a codificarla en JIRA. He aquí un ejemplo de nuestro diseño:

• Estamos a 6 desarrolladores
• Cuando una historia se encuentra en dev, que está en el escritorio de un prog. Del mismo modo que se revisa, se hace QA, etc. Esto significa que cada carta en el tablero representa un elemento procesable, y también proporciona una instantánea decentemente 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 "acumuladas" 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 es bastante cercano a mapping the value stream excepto por la parte de implementación en espera, que es un truco para solucionar el problema en el control de calidad no puede control de calidad a un tema hasta que hemos desplegado en su servidor - desplegamos 3/4 veces durante una iteración de 2 semanas.

Una cosa que he notado al mapear el flujo de valores en un "information radiator" es que enfoca mágicamente a las personas en el trabajo real de valor agregado que necesita hacerse, y eso parece aumentar el ritmo del valor comercial desarrollo y mantener el impulso.

Espero que ayude!

Answer 6

Estamos experimentando con un par de estructuras de placa diferentes en algunos proyectos diferentes que estamos ejecutando. Uno de los proyectos tiene la estructura más básica que podemos utilizar:

| (Sprint) Backlog | In Progress | Done | 

medida de lo posible, tratamos de tener una sola para representar tanto las actividades que los post-dev y de control de calidad para una historia.

La estructura anterior parece funcionar bien para los desarrolladores del proyecto, pero los miembros de QA han tenido problemas para saber cuándo se completó el trabajo de desarrollo de una historia, de modo que pudieran ejecutar sus pruebas para esa historia. Nos encontramos moviendo las historias al "otro lado" de la sección En progreso para indicar que el trabajo de revelado estaba hecho y que QA podría retomar esa historia. Esto rápidamente se volvió bastante inmanejable ya que se completó la sección En progreso.

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

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

El recién agregado sección listo para la prueba esencialmente se convirtió en una sección formal de la junta que antes era la "cara oculta "de la sección En progreso. En la superficie, esto debería haber aclarado las cosas para los miembros de QA, pero esto todavía causaba cierta confusión ya que las personas tenían diferentes interpretaciones de lo que significaba Ready for Test (no te aburriré con las diferentes interpretaciones aquí).

Esto ha conducido a continuación a la última iteración de la estructura directiva que estamos utilizando en otro proyecto:

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

Esta es sin duda una manera muy sencilla lejos de la Cartera , en curso y Hecho secciones de la primera iteración, pero esto parece estar funcionando bien para el equipo. Tienen una comprensión clara de lo que significa mover una historia a través de varias secciones del tablero y, para cualquier historia, da una idea clara de en qué parte del ciclo de vida se encuentra esa historia en particular. Solo hemos usado esta estructura desde el inicio del sprint actual (estamos a 9 días de 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á pilotando, intentaremos implementarlo en otros equipos de nuestra organización.

Answer 7

Nuestra pizarra se divide en las siguientes columnas:

historia, no iniciada, Req/Des/Dev *, revisión por pares, control de calidad, Hecho

Las historias de mayor prioridad van de arriba a abajo. Cada historia puede tener múltiples tareas, por lo que usamos un postit grande para la historia y otros más pequeños para las tareas. Las tareas se mueven de izquierda a derecha. Todos los días nos aseguramos de que trabajemos en las historias de mayor prioridad.

Utilizamos una pestaña blanca adhesiva en cada tarea donde la persona que trabaja en ella pone sus iniciales. Cuando hayan terminado y lo muevan, se colocará una nueva pestaña blanca sobre la anterior para mostrar que está disponible para que cualquiera la recoja. Cuando se realizan todas las tareas, la historia se traslada a la columna Listo también y, al inicio, todo el trabajo Realizado se suma y se mueve hacia arriba para dejar espacio en la parte inferior para obtener más historias.

También tenemos fichas de colores para las historias y tareas que indican bloqueos para el progreso (azul que indica un bloqueo de otro equipo, rojo solicitando asistencia de maestro de melé). Hablamos de los bloqueos en cada standup.

Podemos ver cuando hay demasiadas tareas en una columna en particular y cambiar el énfasis para hacer más en Hecho. Deliberadamente agregamos la columna de revisión para enfatizar que el trabajo necesitaba ser revisado por alguien que no sea la persona que lo estaba haciendo antes de llegar a la garantía de calidad.

* Requisitos/diseño/desarrollo

Answer 8

Aquí está nuestra Junta Kanban que utilizamos en TargetProcess. No trabajamos en el nivel de tareas, solo en el nivel de Historias de usuarios y errores. A veces creamos tareas, pero no se rastrean explícitamente en el tablero.

No calculamos las Historias de usuarios y errores, pero tratamos de dividir las historias en más pequeñas (con éxito mixto). Las columnas son autoexplicativas. Acumulamos artículos en Columna probada, luego creamos una rama, probamos y lanzamos nueva construcción. Por lo general, lanzamos nuevas versiones cada dos semanas.

Además, la placa muestra la carga y la clase de servicios de los desarrolladores y evaluadores a través de la codificación por colores.

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

Answer 9

Nuestros tableros tienden a evolucionar horas extras a medida que avanzamos en equipo. Tiendo a favor de los tableros físicos de tarjetas si tiene un equipo compartido para el equipo, ya que alienta una mejor comunicación cara a cara en general, según 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 registrarse y ver el progreso dentro del sprint actual y sacar las cosas de su contexto ya que a veces las cartas no cuentan la historia completa. Deben mantener una conversación y acudir a la junta, lo que puede ser beneficioso, ya que las cosas pueden explicarse y también significa que se las puede alentar para ayudar a resolver los obstáculos. Sin embargo, esto no es exclusivo de las placas físicas, pero ayuda.

Como hemos mencionado, nuestros tableros evolucionan con las necesidades del equipo. A menudo, comenzamos con el scrum de libros de texto, pero fomentamos la mejora continua y generalmente terminamos con una solución scrumban. Estos cambios se reflejan visualizando el nuevo flujo de trabajo a través de las placas. Recientemente escribí una publicación sobre nuestro último cambio, si está interesado, eche un vistazo a nuestro hourglass scrum/Kanban board

Creo que el equipo debería involucrarse en la creación de las juntas, ya que ayuda al equipo a entender el flujo de trabajo y no convertirse en silo. Además, si el equipo ha participado en la creación de la junta, controlan mejor sus propios procesos, lo que ayuda a la autoorganización, ya que es un producto al que han contribuido.

Answer 10

Fuimos con la siguiente estructura de la junta 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. Agregamos lo que tenemos que trabajar en nuestro Backlog, luego lo movemos a Next Sprint si se acerca la fecha límite. Las tareas verdes bloqueadas se usan para tareas continuas que se deben trabajar diariamente. Las tarjetas rojas indican la importancia de la tarea y deben terminarse lo antes posible. Nuestro tablero nos permite colaborar libremente y agregar tareas a los demás carriles si necesitamos que un departamento diferente haga algo.

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

Answer 11

Le sugiero que eche un vistazo a la placa Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort puede satisfacer todas sus necesidades gracias a la interfaz intuitiva, estadísticas, tablero de instrumentos. También se adapta a cualquier proceso y lo más importante es que es muy fácil de usar. Esta placa te permite representar varios proyectos en una tabla utilizando filas. Todas las filas pueden estar visibles a la vez o puede eliminar las seleccionadas del alcance. Otra solución puede ser agrupar tareas y filtrar por categorías; luego, todas las tareas se pueden representar en una placa y fila, pero se pueden adjuntar a diferentes categorías.