Kanban no es un registro de trabajo

Kanban es un sistema de cola de extracción que visualiza las puertas de proceso y las transiciones de estado de trabajo. Eso significa que los ejecutantes de la tarea extraen cada elemento de trabajo de una cola anterior cuando sus límites WIP lo permiten. Cada tablero debe representar una vista lógica de un solo proceso unificado. Puede tener varios tableros para poner en cola el trabajo entre procesos independientes o secuenciales, así como tableros complementarios para proporcionar una mayor visibilidad de los cambios de estado dentro de cada columna.

Kanban no es un sistema de emisión de boletos, y la inclusión de flujos de trabajo dispares o altamente variables va en contra del marco. La inclusión de colas y estados de trabajo sin flujo dentro de un solo tablero crea ruido porque muchas de las colas no serán aplicables a un volumen significativo de los elementos de trabajo que se visualizan. ¡No hagas eso!

Múltiples equipos necesitan trabajos pendientes en ciclo separados

Parte del problema que está tratando de expresar es que las personas de UX y software no están realmente en el mismo equipo. Múltiples equipos deberían estar trabajando cada uno desde una cola separada, en lugar de intentar meter el flujo de trabajo de cada equipo en una vista consolidada.

Si bien tener una única cartera de productos de nivel superior suele ser lo correcto, cada equipo generalmente necesita tener su propio tablero Kanban y su propio proceso visualizado para rastrear las transiciones de estado. En las implementaciones de Scrum a escala, esto se hace distinguiendo entre el Product Backlog y el Sprint Backlog para cada equipo. Kanban es menos prescriptivo, pero debería aplicarse el mismo modelo.

Ideas para explorar

JIRA es, en el fondo, un sistema de venta de entradas. Si bien ciertamente se puede usar para proporcionar la funcionalidad Kanban, es importante no distorsionar su proceso para que se ajuste a JIRA. En su lugar, debe definir su proceso y luego aprovechar las capacidades de JIRA para mapear su flujo de trabajo lo más cerca posible.

Colas menos granulares

Si mantiene pequeños los elementos de trabajo, entonces es perfectamente aceptable en un contexto ágil tratar las columnas como colas de granularidad gruesa. Específicamente, podría tener un tablero unificado que simplemente diga:

1. Listo
2. En curso
   • experiencia de usuario
   • Codificación
   • Pruebas
3. Hecho

y luego deje que cada equipo implemente las colas y los procesos que deseen para realizar un seguimiento del trabajo internamente en un tablero JIRA separado.

Cuentas de equipo/rol para la asignación de tickets

Otra alternativa es dejar de dejar que las limitaciones de JIRA como sistema de emisión de boletos lo limiten. Mantenga un tablero consolidado, pero use cuentas de equipo o función como el único asignado para los tickets y listas de distribución de correo electrónico para asegurarse de que todos en los equipos relevantes aún puedan recibir notificaciones por correo electrónico y demás.

El enfoque de equipo/rol tiene el beneficio adicional de mantener a todos informados sobre los cambios de estado. Si descubre que la relación señal-ruido para mantener a todos informados sobre cada transición de estado es demasiado baja, entonces debe preguntar:

• ¿Por qué todos necesitan ver la misma representación visual del sistema, en lugar de vistas personalizadas de los procesos en los que están directamente involucrados?
• ¿Por qué la UX y el desarrollo de software necesitan ver las mismas columnas, en lugar de extraer/poner en cola el trabajo en los límites del proceso de cada equipo?
• ¿Por qué tenemos flujos de trabajo distintos, donde las personas de UX no están integradas directamente en un equipo de desarrollo multifuncional?

Si el ruido de mantener todo consolidado es demasiado alto, entonces desacoplar o secuenciar sus tableros simplemente tiene más sentido. Si tiene equipos no integrados, entonces su visualización debería modelarlo con precisión. Un tablero Kanban estrechamente acoplado implica un nivel de coherencia en el flujo de trabajo que en realidad puede no existir en su organización y que debe ser completamente visible para todos los involucrados.

Asignar procesos existentes a JIRA

Los flujos de trabajo separados frente a los integrados representan un conjunto de compensaciones comerciales y operativas. Considere volver a evaluar la X en este escenario X/Y y asegúrese de no permitir que las limitaciones de JIRA controlen sus procesos.

Actualmente, parece que tiene equipos desacoplados con procesos separados y algunas dependencias entre procesos. Esa debería ser la base sobre la que modele sus tableros Kanban, en lugar de crear un tablero de administración sucedáneo con un valor limitado para los ejecutores del proceso. Naturalmente, la gerencia quiere ver una descripción general, pero un modelo visual que no se corresponde con precisión con los procesos existentes tiene un valor extremadamente limitado para cualquiera.

Desacople los paneles/métricas de gestión de la visualización del flujo de trabajo

Si es necesario, considere desarrollar un tablero o informe separado que extraiga datos de cada flujo de trabajo relevante. Sin embargo, no contamine el flujo de trabajo con esto. Los tableros Kanban reales son para hacer que un proceso sea transparente, no para sustituir otras formas de análisis e informes.

Los tableros de JIRA son efectivamente puntos de vista sobre los proyectos. Eso significa que es posible tener muchos tableros diferentes que contengan los mismos datos (o un subconjunto de los mismos datos).

Por ejemplo, podría tener un tablero de desarrollador, un tablero de UX y un tablero combinado, todos apuntando al mismo proyecto. Todo lo que JIRA necesita es una forma de determinar qué tareas mostrar en qué tableros. Por ejemplo, podría usar un campo personalizado o una etiqueta y usar eso en JQL en un filtro para definir los tableros.

Valdría la pena reunir al equipo para pensar sobre los propósitos para los que desea usar los tableros, ya que esto determinará las columnas en cada tablero y el JQL para los filtros.

Por experiencia, sugeriría que es poco probable que lo haga bien la primera vez. Recomendaría crear varios tableros y luego inspeccionar los resultados después de algunas semanas para determinar qué tableros funcionan bien y qué tableros deben modificarse.

INVERTIR

Algunas de las historias en las que trabajan los diseñadores se incorporan directamente a las historias de los desarrolladores.

Aquí está tu problema.

Echa un vistazo a la regla nemotécnica INVEST .

I - Independiente - El PBI debe ser autónomo, de manera que no exista una dependencia inherente de otro PBI.

Está tomando una sola historia ("Hacer que el widget alfa sea confuso") y dividirla en dos historias no independientes ("Hacer que el widget alfa parezca confuso" y "Hacer que el widget alfa actúe confuso").

En cambio, lo que debe hacer es tener una sola historia que contenga subtareas.

Sin embargo, a veces hay trabajo de diseño que no conducirá directamente a una historia de desarrollo; básicamente, las historias de diseño se saltarán pasos en el flujo.

¿Está bien? Simplemente permita que los problemas hagan la transición como lo desee el usuario.

Si desea una funcionalidad más estricta/más bonita

Lo anterior funcionará , pero tiene algunas torpezas.

Una mejora que sugeriría sería agregar diferentes tipos de subtareas. Entonces tú puedes:

• Asígnelos a diferentes flujos de trabajo (por ejemplo, Design-Sub-Tasks no tiene Code Review).
• Tenga tres tableros: uno que muestre todo, uno para desarrollo y otro para diseño.
• Agregue filtros rápidos a la placa principal.