project-management - español - kanplan

Tableros Kanban/Scrum (11)

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 y los Errores, pero intentamos dividir las Historias en más pequeñas (con éxito mixto). Las columnas son autoexplicativas. Acumulamos elementos en la columna Prueba , luego creamos una rama, probamos humo y lanzamos una nueva versión. Por lo general, lanzamos nuevas versiones cada dos semanas.

Además, el tablero 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 usamos una sola tabla para rastrear el progreso de todos los equipos en http://www.targetprocess.com/3

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 qué aspecto tiene su tablero , y cómo organiza las historias y tareas de los usuarios a medida que avanzan a través de un sprint / iteración típico.

Por lo general, he trabajado en lugares que organizan la pizarra de la siguiente manera con cada uno.

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 recojan están esperando en la columna Todo, pero otro miembro del equipo puede coordinar esta tarea para coordinar con Bob a fin de realizar el trabajo.
Para UC-002, se completó la tarea del servicio de pago y se completó un arnés de prueba automatizado 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 Servicio de pago a la fase de control de calidad
Todas las tareas para UC-003 se completaron y se movieron a Listo para control de calidad.
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. Comentarios y críticas son bienvenidos:)

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

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

Personalmente, me parece que falta el sistema ...

Moviendo manualmente post-it llega a ser un dolor después de un tiempo. Nuestro equipo de control de calidad administra principalmente el movimiento de tickets, y es un esfuerzo constante para mantenerlos sincronizados con TFS.
Las publicaciones posteriores solo se pueden mover tantas veces antes de que ya no estén pegajosas. Si un ticket se devuelve de la prueba y se coloca en ''En progreso'' y luego se vuelve a la prueba, etc, etc ... no se necesita 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 manera 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 Quinto fuera de la pila y está contribuyendo rápidamente a la disminución de la adherencia que terminará con las notas en el suelo.
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 geniales, robustas, gratuitas e incluso que se interconectará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

En la práctica, lo mejor es dejar que el equipo lo determine según sus circunstancias y su 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:

Teníamos dos tablas, una con fichas para las próximas historias para poder contar 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 recuadro 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 averiguar quién estaba emparejado con quién.

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

Estamos experimentando con un par de estructuras de tablero 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 en el 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 opuesto" de la sección En progreso 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 inmanejable a medida que se llenaba la sección En progreso .

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

La sección recién agregada Ready for Test se convirtió esencialmente en una sección formal de la junta que anteriormente era el "lado opuesto" de la sección In Progress . 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 la prueba (no los aburriré con las diferentes interpretaciones aquí).

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

Esto está bastante lejos de las simples secciones de Backlog , In Progress y Done 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 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 usando 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.

Estoy bastante 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 "acumuladas" en la columna En espera de revisión. Esto mantiene un grado de "flujo".

Esto está bastante cerca de asignar el flujo de valor, excepto por la parte de implementación pendiente, que es un truco para solucionar el problema en el que el control de calidad no puede realizar un control de calidad de un elemento hasta que lo implementamos en su servidor: implementamos 3/4 veces durante una 2 semanas de iteración.

Una cosa que he notado al trazar el flujo de valor en un " radiador de información " es que hace que las personas se centren mágicamente en el trabajo de valor agregado real que se necesita hacer, y que parece aumentar el ritmo del desarrollo de valor de negocios y mantenerlo hasta el impulso.

¡Espero que ayude!

Fuimos con la siguiente estructura de tableros en nuestra empresa.

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

Los carriles están asignados 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 que deben trabajarse 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.

Utilizamos 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.

Nuestra pizarra se divide en estas columnas:

Historia, No comenzado, 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, 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 estar 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, se coloca una nueva pestaña blanca sobre la anterior 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 realizado se cuenta y se mueve hacia arriba en el tablero para hacer espacio en la parte inferior para más historias.

También tenemos fichas de colores para las historias y tareas para indicar que los bloqueos progresan (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 Hecho. Agregamos 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

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 puesto en equipo con el 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. Hace poco escribí una publicación sobre nuestro último cambio, si está interesado, eche un vistazo a 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 comprender el flujo de trabajo y no a convertirse en 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.

Te sugiero que eches un vistazo en el tablero de Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort puede satisfacer todas sus necesidades gracias 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.

Usamos algo inspirado en el famoso Scrum y XP de las trincheras de Henrik Kniberg, y las columnas se adaptan según el contexto (a menudo: TODO, EN MARCHA, 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 sugiero usar cinta o 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 una zona de "Elementos no planificados" (para tenerlos en cuenta en el gráfico de quemado). Los PBI futuros permanecen visibles en una zona "Siguiente" (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 bloqueadas (es decir, tareas que no se mueven) 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
artículos no planeados que están matando a un sprint

Funciona genial.

Si está buscando más productos "orientados a kanban", tal vez eche un vistazo a Kanban vs Scrum , One day in Kanban Land y Kanban and Scrum, una guía práctica del mismo Henrik Kniberg. Grandes cosas también.

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

Scratch / programación extrema del guión gráfico.

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 iniciados, Recién iniciados, medio camino, casi terminados, listos para exhibición (aprobado control de calidad)

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é.