Kanplan: donde el backlog y kanban unen sus fuerzas

kanban trata de dar a los miembros del equipo trabajo suficiente para que trabajen de forma constante según su capacidad. Los equipos que utilizan kanban se benefician de una planificación flexible, un enfoque más claro y una transparencia total porque, sea lo que sea lo que haya en el tablero, esa es la máxima prioridad. Eso es en lo que trabajan los desarrolladores. kanban es la solución perfecta para los equipos operativos centrados en la entrega continua con prioridades variables.

En cambio, scrum divide el trabajo en una serie de iteraciones de duración determinada llamadas sprints; sea lo que sea lo que se programe para un sprint esa es la máxima prioridad del equipo (por ejemplo, una funcionalidad concreta o un grupo de funcionalidades). Los equipos de productos con una hoja de ruta clara y pequeños trabajos ordenados por prioridades se benefician más de scrum.

Pero ¿no podría tu equipo beneficiarse más de una combinación de scrum y kanban? ¿O prefiere realizar la transición de scrum a kanban? Si crees que esto es lo mejor para tu equipo, la solución es scrumban. Esta metodología mixta se manifiesta de diferentes maneras, pero las tendencias más habituales entre los equipos de scrumban implican el uso de sprints con un backlog de scrum, y límites de trabajo en curso y duraciones de ciclo de kanban. (Nota: La duración del es la cantidad de tiempo que tarda una tarea en pasar por el workflow del equipo).

¿Qué ocurre con los equipos que no quieren trabajar de forma iterativa, pero siguen queriendo la capacidad de limpiar el backlog? En Jira, la respuesta puede estar en kanplan (o activar la función de backlog de kanban).

Kanplan es una metodología mixta para practicar el desarrollo de software ágil. Al igual que scrumban, combina funciones tanto de scrum como de kanban. Kanplan es ideal para equipos que quieren la capacidad de limpieza del backlog, pero no quieren trabajar en sprints. 

Por qué kanban es una base y no un marco estricto

El equipo de ingeniería de compilación de Atlassian está a cargo de una plataforma utilizada para compilar, probar y entregar software de Atlassian. Los desarrolladores dependen de una infraestructura fiable y una rápida integración continua (IC). Hace cuatro años esto se traducía en 21 000 builds al mes. Hoy, esta cifra supera las 150 000 builds al mes.

Esta capacidad para ampliar puede atribuirse al crecimiento del equipo, que ha pasado de Subversion a Git, a las pruebas automatizadas y a algo menos obvio: la decisión de pasar de scrum a kanban. La naturaleza del trabajo de ingeniería de compilación (piensa en las solicitudes ad hoc, las incidencias y el trabajo de innovación, por ejemplo) no encajaba bien en un marco de scrum. Por ese motivo, el equipo decidió introducir scrumban, que pronto se convirtió en kanban porque al equipo no le gustaba trabajar con sprints. Pero, resulta que, kanban tampoco resultó ser el elixir que esperaban. Como muchos otros equipos, trataron de que funcionara. Pasaron de un tablero a varios (un tablero de ingeniería de soporte, un tablero de trabajo de proyectos, etc.), todos ellos con workflows diferentes. ¿Que cuál fue su mayor punto problemático en todos los tableros? El "terreno baldío", como lo denominó un miembro del equipo, de tiques no probados que debían pasarse al modo de "listo para el trabajo". Una vez en la columna de "en curso", el equipo estaba listo para continuar, pero su columna de "por hacer" —la columna de terreno baldío— era justamente eso: una tierra yerma.

Nuestro equipo de ingeniería de compilación trató de combatir su extensa y desorganizada lista de tareas pendientes con reuniones rápidas diarias y reuniones programadas semanalmente. Sin embargo, en lugar de más reuniones, lo que de verdad necesitaba era un backlog.

Dado que, normalmente, los tableros de kanban no cuentan con la funcionalidad de backlog, los gestores de productos, los jefes de desarrollo y los líderes de equipo han utilizado los tiques de la primera columna para planificar. Pero conforme esta lista aumenta, cuesta más ver y priorizar los tiques. Entonces, el equipo de ingeniería de compilación dividió sus tableros basándose en áreas de trabajo diferentes; sin embargo, el tablero combinado de equipos seguía siendo abrumador (se requería demasiado desplazamiento por la lista).

Así que, en lugar de intentar encontrar diferentes formas de reorganizar el equipo y los tableros o reinventar la rueda, el equipo de Jira decidió llevar el backlog al kanban. La función kanplan introduce un amplio backlog de columnas con incidencias en una vista de lista. Esto divide la pizarra kanban en dos pantallas diferentes: el backlog para hacer limpieza y el tablero de kanban para que el equipo de ingeniería seleccione y mueva las tareas a lo largo del flujo de trabajo.

Esta funcionalidad no es diferente a la del backlog de un tablero de scrum en Jira. Por ejemplo, al hacer clic en el icono de backlog de la barra lateral, accederás a una amplia columna de incidencias de backlog. Después de limpiar el backlog, puedes arrastrar y soltar incidencias en el siguiente paso de tu flujo de trabajo.

Esta combinación de la pantalla de backlog de scrum y el tablero de kanban en un único tablero ágil funciona como un backlog de tablero de scrum. Si haces clic en un tique, se muestra la vista de detalles de dicho tique. Las vistas concretas, como la de detalles de tiques, permiten que cada miembro del equipo pueda llevar a cabo tareas de forma más rápida y con menos distracciones.

Por último, aquellos equipos que no son de scrum y que usan epics y versiones preasignadas para organizar sus lanzamientos pueden beneficiarse de las herramientas que se encuentran en los tableros de scrum, por ejemplo, para visualizar tiques o realizar ediciones rápidas. Esta edición simple y rápida ofrece a los gestores de productos, a los jefes de desarrollo y a cualquiera que esté trabajando en modo de planificación, la capacidad para gestionar de forma eficiente los epics y las versiones.

Kanplan pretende, como dijo un cliente, ofrecerte "lo mejor de ambos mundos". Puedes mover las cartas sin tener un sprint en progreso e introducir las tareas en un backlog para ayudarte a planificar mejor. Elimina el páramo que experimentó el equipo de ingeniería de construcción de Atlassian y da a los equipos de kanban un modo de planificación que no existía antes en un mundo de kanban. También guía una nueva forma de trabajar para equipos que no creen que el kanban, el scrum o el scrumban les den la base que necesitan para hacer el trabajo que quieren.

Al abrir el modo plan en un tablero de kanban, los equipos nuevos y antiguos que utilizan kanban pueden encontrar formas de hacer que este marco ágil funcione en lugar de tratar de seguir las prácticas recomendadas que tal vez no se apliquen a su equipo. Recuerda: el desarrollo ágil consiste en mejorar continuamente más que en las prácticas recomendadas.