Método Ágil, Kanban y Trello: ¡así es como se lleva al siguiente nivel!
Cuando se implementan los métodos ágiles Scrum o Kanban de gestión de proyectos, no importa qué herramienta se utilice. Lo que importa es la calidad de la colaboración del equipo y, sobre todo, la creación de valor para sus clientes.
Dicho esto, una buena herramienta ayuda a los miembros del equipo a visualizar fácilmente todos los detalles del desarrollo de un producto, para que todos puedan concentrarse en resolver problemas complejos en cada sprint.
Trello es una herramienta Kanban ideal para manejar los sprints porque permite a los equipos estar constantemente actualizados. Y las características de trello no obstaculizan la colaboración del equipo como podrían hacerlo con herramientas más complejas.
Aunque puede usar Trello como le parezca, puede ser necesario probar diferentes enfoques para encontrar lo que funciona mejor para su equipo.
He conocido a cientos de equipos que usaban Trello para sus métodos ágiles de Scrum y Kanban al crear los cuadros de mando ágiles de Corrello. A partir de mis conversaciones con estos equipos (que eran pequeños pero crecientes o grandes y muy bien estructurados), pude descubrir algunas prácticas comunes.
Echemos un vistazo a cómo los equipos ágiles usan Trello.
Repasemos lo básico: la configuración de su matriz
Asegurémonos de que estamos en la misma longitud de onda en los fundamentos antes de mirar problemas más complejos:
La pintura Scrum / Kanban
Los elementos clave de un simple gráfico Scrum para los equipos de desarrollo de software son los siguientes:
- Una lista de atrasos para el Sprint. Este está lleno al principio del sprint y vacío (¡esperemos!) al final de sprint .
- Una o más listas de «Proyectos Actuales» . En la captura de pantalla de arriba, tenemos «Desarrollo», «Revisión de código» y «Prueba», pero tienes que hacer coincidir estas listas con tu proceso específico. Más allá de la lista «En curso», es útil dividir su proceso de desarrollo en varias listas para acompañar mejor la evolución de las tareas del proyecto.
- Una lista de «Hecho» que contiene todo el trabajo ya realizado (¡un pequeño recordatorio de todo lo que has hecho!).
Un ejemplo de una simple tabla de Kanban Trello se parecería a la tabla de Sprint de arriba, pero en lugar de la tabla de Sprint Backlog simplemente tienes una lista de «Listo para el desarrollo» en el extremo izquierdo.
Las tareas a realizar se colocan en la lista «Listo para el desarrollo» cuando la programación puede comenzar, y las tarjetas se priorizan de arriba a abajo.
Cuando el equipo puede asumir la responsabilidad de nuevas tareas, las tarjetas se pasan de la lista de «Listo para el desarrollo» a las siguientes listas hasta que se finalizan.
Listo para… ¡más listas!
El ejemplo anterior del tablero de Kanban Trello permite a los turnos rastrear los mapas pendientes, que difieren de las tareas en las que los turnos están trabajando activamente.
¡Esto permite a sus equipos ser aún más ágiles! Porque si te lleva cinco días completar un mapa, ¿significa que has estado trabajando cinco días sin interrupción en la tarea? ¿O hay tiempos muertos entre las diferentes etapas del proceso? Así que… ¡Si pudieras reducir los tiempos de espera, el trabajo podría hacerse más rápido y nadie tendría que trabajar más! (¿Perdón?) Tomemos nuestro ejemplo de una tabla de Kanban Trello de nuevo:
Aquí podemos ver tres cartas en la lista de «Desarrollo» y sólo una carta en la lista de «Prueba». También hay dos tarjetas en la lista de «Listo para la revisión del código». Cuando revise la tabla con su equipo, puede discutir por qué nadie ha procesado aún una de las cartas de la lista «Listo para la revisión del código» antes de abordar una carta de la lista «Desarrollo».
Las listas de «Listo para…» te ayudan a saber si las tarjetas están esperando y, más importante aún, muestran al equipo que las tarjetas están disponibles para el siguiente paso del proceso, pero no están siendo procesadas. De esta manera, el equipo puede actuar y completar las tareas más rápido (sin trabajar más). Estas listas de «Listo para…» también pueden ayudar a mostrar las lagunas.
En la tabla de kanban arriba, una vez que la tarjeta de la lista «Test» se procese, no habrá más pruebas en marcha, por ejemplo. Si la tabla fuera más simple (con menos listas), tal vez no se daría cuenta de las deficiencias porque algunas cartas se estancaban en la lista de «Revisión de códigos» sin que se revisara realmente ninguna línea de código.
No olvides que la lista de «Listo para…» lista casi el doble de las listas de tu tabla kanban. Tal vez no quiera establecer tantos pasos, pero si cree que puede ser útil, nada más fácil que probar este método y archivar las listas que no quiera usar más tarde. La estructura flexible de la lista de Trello lo hace todo muy simple. También puedes crear listas de «Listo para…» para los pasos de tu proceso que creas que más lo necesitan (en mi experiencia, esto es siempre la «revisión de código» ).
Archivar las tareas completadas
Los dos cuadros anteriores tienen una única lista de «Hecho», que sugiere algunas formas ágiles de decidir si se archivan o no los elementos:
- No archive o borre las tarjetas de la lista de «Hecho»; ¡siempre las necesitaremos algún día! ❌
- Archívalos regularmente tan pronto como alguien «se canse de verlos». (Las listas largas suelen ser poco prácticas.)
- Archiva las listas de «Terminados» cada semana (pero recuerda: puedes perder la pista de lo que acaba de ser terminado).
Algunos de los hábitos más comunes de los turnos de trabajo incluyen lo siguiente:
- Una lista de «Terminados» para cada sprint / semana / mes según las preferencias del equipo. Con esta plantilla, se crea una nueva lista de «Terminados» cada semana y se cambia el nombre de la anterior por «Terminados – Semana del 08 al 14 de octubre». Estas listas se desplazan gradualmente hacia la derecha y pueden ser archivadas tan pronto como ya no sean necesarias.
- Una tabla completa dedicada a los mapas archivados que quieres conservar. La tabla se construye alrededor de listas para cada sprint o cada semana. Los mapas de la lista de «Hecho» se mueven regularmente a la tabla de archivos. Esto hace que la mesa principal esté un poco más organizada y mantiene una historia completa de lo que se hizo y cuándo.
Cualquiera de estos métodos ágiles es una excelente manera de mantener una historia fácilmente consultable de lo que se ha hecho anteriormente, a la vez que se mantiene bien organizada la junta principal de kanban del equipo.
La descripción de los mapas
Descubrí que muchos equipos prefieren detallar la información directamente en la descripción del mapa en lugar de añadir un Google Docs como un archivo adjunto. El uso del sistema Markdown ofrece muchas opciones para formatear su descripción. Por regla general, si la descripción se hace demasiado grande, significa que es mejor dividir la información en dos mapas separados.
Los enlaces se utilizan para proporcionar explicaciones adicionales en forma de cuadros de cables, maquetas de la interfaz de usuario y otros detalles que no pueden documentarse por escrito.
Plantillas de la lista de control
La revisión del código se gestiona a menudo mediante listas de comprobación. Los equipos ágiles crean una plantilla de lista de control que puede ser replicada para cada uso. Esta lista de verificación se copia en los mapas deseados utilizando la función «Copiar de» cuando se añade la lista de verificación.
Si quiere que se incluyan sistemáticamente ciertas listas de verificación en ciertos mapas, el uso de plantillas de listas de verificación es una buena solución. Asegúrate de que todos los miembros del equipo estén usando la versión más reciente de la lista de verificación cuando la añadan a su mapa.
Usando imágenes de portada para una tabla macro «Proyecto/Objetivos»
Puede ser necesario que algunos equipos proporcionen una visión general de un proyecto con personas ajenas al equipo. Mientras que una mesa bien llena puede sufrir rápidamente una sobrecarga visual si todos los mapas tienen una imagen de portada, es en cambio una excelente manera de hacer que su mesa sea visual cuando contiene pocos mapas.
Algunos equipos van más allá y también utilizan este tipo de enfoque en las tablas para gestionar los próximos proyectos de su equipo. Si quieres saber más sobre esto, encuentra un ejemplo aquí y una explicación de cómo usar esta tabla allí.
Usar etiquetas sin perder la cabeza
Es común que las etiquetas se usen indiscriminadamente, como si cada tarjeta tuviera que ir acompañada de un montón de etiquetas. ¿Esto es una «mancha»? ¿Una «subtarea»? ¿Una «tarea de interfaz de usuario»? ¿Una «mejora de la interfaz de usuario»? ¿Una «mejora del fondo»? O qué-ya-sabes-qué más? ¡Como sea!
A veces se requiere un nivel de detalle significativo, pero esta no es la mejor manera de hacer el primer movimiento. Y en las palabras de John Gall :
«Se encuentra invariablemente que un sistema complejo que funciona proviene de un sistema simple que ha funcionado. Un sistema complejo diseñado desde cero nunca funciona y no puedes arreglarlo para que funcione».
Así que vamos a empezar con un simple sistema que consiste en una a tres etiquetas:
- Bug
- Bloqueado
- Urgente (si lo necesita)
La etiqueta «Bug» es roja para asegurarse de que se destaca en el tablero. Si no formas parte de un equipo de desarrollo, probablemente haya una clasificación similar que puedas adaptar y adoptar para etiquetar tus mapas.
«Bloqueado» significa que el equipo no puede pasar a la siguiente etapa. El uso de una etiqueta naranja en este tipo de situaciones en lugar de poner todos los mapas bloqueados «en cuarentena» en una lista separada permite ver a qué listas pertenecen los mapas bloqueados. De esta manera, se puede ver si los mapas bloqueados están asociados a un cuello de botella en alguna parte de su proceso para optimizarlo. Esta es una de las razones por las que tiene sentido no limitarse a una sola lista de «Proyectos Actuales», sino subdividirla en varias listas para un nivel más fino de supervisión del progreso de las tareas.
La etiqueta «Urgente» puede ser útil si el equipo tiene que ocuparse de tareas o proyectos urgentes. La etiqueta es un buen recordatorio visual que permite a su equipo estar atento a las prioridades.
Consejo : puedes añadir rápidamente etiquetas a las cartas pasando el ratón por encima de ellas y pulsando la tecla asociada al número de la etiqueta. Por ejemplo, la etiqueta roja del bicho de arriba corresponde al número «4».
Creando tareas simples
Cuando se trata de dividir los mapas en tareas más simples, dos enfoques parecen funcionar a largo plazo:
Usando listas de control
Este es el lugar ideal para enumerar las tareas de un proyecto.
El uso de Markdown hace que estas listas sean muy claras, con encabezados y subtareas en negrita. Si es necesario, puede agregar varias listas de verificación para organizar mejor las tareas. Sin embargo, si este es el caso, podría ser el momento de…
Crear varias tarjetas si es necesario
Si una carta es demasiado grande, divide el trabajo en dos o más cartas separadas. Con el tiempo, su equipo probablemente se hará una idea de lo que hace que un mapa sea «demasiado grande» y podrá crear varios mapas en lugar de uno solo para el desarrollo de un gran proyecto.
Los equipos de Scrum a menudo usan la medida de velocidad, que proporciona un promedio del número de Story Points por Sprint. Una regla que los equipos ágiles comúnmente adoptan es no crear mapas más grandes que la mitad de su velocidad en un solo Sprint. Esto puede ser una medida útil cuando un mapa necesita ser dividido. Y si tienes problemas para definir claramente lo que hay que hacer con un solo mapa, probablemente significa que la tarea debe ser dividida en varias tareas.
Preparando su equipo para las épicas (Epics)
Al igual que las tareas sencillas, las épicas (o misiones, como las llames) se utilizan para agrupar mapas con un alto nivel de visión. He observado tres enfoques que funcionan bien:
1. Usar etiquetas
Este es probablemente el enfoque más utilizado. Se crean etiquetas para cada epopeya y se asignan a los mapas. Las etiquetas se mueven con los mapas a medida que se copian o se mueven de un cuadro a otro. De esta manera, es fácil ver qué cartas forman parte de una epopeya y cuánto trabajo se ha hecho en comparación con lo que queda por hacer.
Vemos este enfoque aquí con todas las etiquetas épicas en negro, pero por supuesto puede elegir el código de color que convient .
2. Listas de uso
Otro enfoque es hacer una lista para cada una de las próximas épocas. El problema es que pierdes la relación con la Epopeya una vez que la tarjeta ha salido de la lista. Si estás trabajando en sólo uno o un pequeño número de Epis a la vez, esto no es necesariamente un problema porque todo el mundo sabe qué Epis están siendo procesados. Sin embargo, si es confuso, puede ser mejor pegarse a las etiquetas, o …
3. Usa el potenciador de Hello Epics
El potenciador de Epics más popular con el que me he encontrado es Hello Epics, que permite configurar tarjetas como Epics y adjuntar otras tarjetas a ellas. Vale la pena probar este Power-Up si buscas una solución para manejar tus épicas!
Plantillas de gestión de versiones / productos para tu cartera de pedidos
Hay diferentes enfoques para organizar su atraso. El mejor enfoque para su equipo suele estar dictado por el tamaño del equipo en sí y el número de productos en los que está trabajando. Estos son algunos de los métodos más utilizados.
Lista única de atrasos
Este enfoque es generalmente utilizado por pequeños equipos que trabajan en una sola matriz Trello .
A menudo, así es como los equipos ágiles empiezan a manejar su atraso de Kanban en Trello. Una sola lista de «atrasos» se encuentra en el lado izquierdo de su mesa. Las tarjetas se enumeran en orden de prioridad descendente. Esta lista puede complementarse con una segunda lista de «A evaluar» para que cualquiera pueda añadir una sugerencia o un informe de errores, que el administrador puede (o no) priorizar moviéndolo sabiamente a la lista de atrasos.
Listas de versiones o pasos
Este método es utilizado generalmente por equipos que trabajan en una sola tabla Trello Kanban con un producto en desarrollo .
Esto suele consistir en añadir listas que representan los siguientes pasos o versiones :
Aquí tenemos dos listas de atrasos para los próximos dos pasos: «v1» y «v2». Aquí, cuando todas las cartas de la v1 están terminadas, este paso (o versión si lo prefieres) está terminado. Esta puede ser una buena manera de ayudar a los equipos a manejar el alcance del trabajo a medida que los proyectos crecen. Pero, ¿cómo se define lo que pertenece a V1 y lo que se relaciona con V2?
Aunque puede ser conveniente tener todo a su alcance en una sola mesa, en algún momento puede ser necesario…
Tabla de gestión de productos
Este tipo de tablero es más bien utilizado por grandes equipos que trabajan en varios tableros Trello Kanban o por equipos que manejan productos de tamaño complejo .
El método utilizado es similar a las listas de pasos que se han visto anteriormente, pero cada lista tiene su propia tabla. Dado que esta tabla es utilizada principalmente por los dueños o administradores de productos, puede ser manejada con menos atención. Esto permite añadir listas de comentarios, ideas, sugerencias épicas sin molestar a los equipos, que a su vez pueden conservar su mesa principal.
Las listas completas o los mapas individuales pueden ser enviados a los tableros de los equipos pertinentes cuando estén listos. Esto permite una clara planificación de tareas a nivel de la lista de cada equipo. Además, su consejo de administración de productos le permite gestionar la distribución de tareas para todos sus equipos.
Potenciadores que facilitan la implementación de su método ágil de Kanban
Corrello de potencia en acción
Ahora hay más de 100 Power-Ups para Trello! Si aún no los has mirado, hazlo, vale la pena el desvío. Aquí hay algunos ejemplos de Power-Ups para equipos que usan el método ágil Kanban en Trello:
- Herramientas del método ágil: Story Points, límites WIP (Work In Progress) y mucho más (gratis)
- Corrello: tableros para equipos Scrum y Kanban con Burndowns (gráficos de progreso), CFD (Diagrama de Flujo Acumulativo), Cycle Time y mucho más
- Hello Epics: mencionado arriba, relación padre/hijo para sus tarjetas de Trello
Avanza tu equipo ágil
¡Eso lo dice todo!
