Jira contra el caos en desarrollo: cómo no perder tareas

En un artículo anterior , le dije qué complementos para Jira hicimos para que el flujo de trabajo sea lo más conveniente posible y el ticket sea exhaustivamente informativo. En el artículo de hoy, resolveremos otro problema.

Dado:

• Desarrolla y respalda un producto de software complejo que se ejecuta en varios clientes.
  
• Tiene varios equipos de ingeniería (backend, IT Ops, iOS, Android, web, etc.) que trabajan de forma independiente entre sí con registros atrasados ​​separados;
  
• tiene varias líneas de productos, es decir, en términos generales, un gerente de producto dirige varios proyectos en su propia dirección, otro gerente, a su manera;
  
• sus equipos de ingeniería son funcionales, es decir, no están asignados a áreas de productos separadas, sino que resuelven las tareas de todas las unidades a la vez, sirviendo una cierta parte de la pila tecnológica;
  
• y por supuesto usas a Jira!
  

Los problemas:

• los participantes del proceso no entienden en qué piezas de ingeniería consiste la característica y qué más se necesita hacer en el proyecto en este momento;
  
• los equipos de ingeniería trabajan en el mismo proyecto de forma asincrónica: un equipo puede terminar su parte hace un mes, y el segundo ni siquiera puede comenzar el suyo, porque olvidaron su pieza en el flujo de tareas más importantes.
  

Hay un problema obvio con la transparencia del proceso de desarrollo. Cuando hay muchos proyectos y direcciones, la necesidad de algún tipo de instrumento mágico que elimine el caos y proporcione una imagen clara es especialmente aguda. Desafortunadamente, nuestra experiencia muestra que las características estándar de Jira no son completamente compatibles con esto.

¿Eso es familiar? Pensemos en lo que podemos hacer al respecto.

Estructura del proyecto

Analizaré el problema usando el ejemplo de desarrollo en Badoo. Entonces, ¿cómo funciona el proyecto? ¿Qué etapas atraviesa el proyecto? ¿En qué piezas consiste una característica nueva típica que requiere la participación de varios equipos?

Idea y diseño

El gerente de producto (PM), después de haber ideado lo que se puede mejorar en el producto, crea un ticket PROD con el tipo Proyecto en Jira. La descripción de este ticket consiste en un solo enlace a una página en Confluence (un análogo de la Wiki de Atlassian que se integra con Jira). A esta página la llamamos PRD (Documento de requisitos del producto). Es un elemento clave del desarrollo. De hecho, esta es una descripción detallada de lo que queda por hacer en el marco del proyecto.


Al crear este documento, PM trabaja en estrecha colaboración con el diseñador. Para esto, se crea otro ticket PROD con el tipo de diseño. En él, el diseñador coloca diseños, conjuntos de iconos, etc. Estos elementos luego se insertan en el PRD para mayor claridad, y también son utilizados por los equipos de ingeniería en el desarrollo.

Habiendo escrito el documento, PM lo presenta para discusión pública. Por lo general, otros PM y líderes de equipos de ingeniería participan en la conversación. La discusión está directamente en los comentarios sobre PRD. Esto es conveniente porque el historial de correspondencia permanece y todos los participantes interesados ​​reciben notificaciones cuando aparecen nuevos comentarios. Con base en la discusión, se realizan cambios acordados en el PRD original.

Cuando se aclaran todos los matices, el ticket PROD inicial se traduce en la acumulación de desarrollo pendiente. Después de eso, una vez a la semana, el equipo de producto clasifica esta cartera de pedidos de acuerdo con la prioridad de acuerdo con los objetivos de la empresa, el escape estimado y la complejidad de la implementación. Los proyectos reconocidos como los más prometedores, pasan a la siguiente etapa: la descomposición. Para esto, se crea un ticket MAPI especial (API móvil) para el equipo de arquitectos de sistemas.

Es importante señalar aquí que para crear más rápidamente tickets relacionados con el proyecto, así como para eliminar el factor humano (olvidaron algo, lo vincularon o marcaron incorrectamente), automatizamos este proceso. Entonces, por ejemplo, el ticket raíz del proyecto en el encabezado tiene dos botones adicionales.



El primero crea un ticket para diseñadores, el segundo para arquitectos de sistemas. En este caso, los nuevos tickets se llenan automáticamente con los atributos necesarios: las etiquetas correctas, un enlace a PRD, una plantilla de descripción y, lo más importante, están vinculados entre sí.

Esta optimización de flujo se implementa en función del complemento Jira ScriptRunner , sobre el que escribí en un artículo anterior .

Descomposición

Habiendo recibido un nuevo boleto MAPI con un PRD adjunto, los arquitectos del sistema deciden:

• qué parte de la lógica debe implementarse en el lado del servidor y qué parte en el lado del cliente;
  
• qué comandos debe enviar el cliente y qué respuestas debe recibir del servidor;
  
• qué tokens deben estar "conectados" al cliente y cuáles deben venir del lado del servidor.
  

Muy a menudo, en esta etapa, se produce un cambio en el PRD. Los arquitectos profundizan más en los detalles de implementación que cuando discutían sobre PRD. Por lo tanto, puede resultar que para lograr los objetivos comerciales del proyecto, es posible, al abandonar parte de los requisitos iniciales, simplificar significativamente el desarrollo. Realmente apreciamos esta iniciativa.

Puede obtener más información sobre cómo funciona nuestro equipo de arquitectos y ver nuestra descripción API del informe .

Los resultados del trabajo de los arquitectos de sistemas son:

1. La aparición de documentación técnica completa para el proyecto (una descripción del protocolo de interacción cliente-servidor con referencia a los casos de lógica de negocios descritos en PRD).
   
   
   Captura de pantalla de parte de la documentación de una de nuestras funciones actualmente inactivas

   
   
   
   
2. Protocolo modificado (archivo en formato Google Protocol Buffers) en los repositorios. Si se necesitan nuevas funciones o cambios a las antiguas para implementar funciones, estarán disponibles para los desarrolladores de todos los equipos.
   
3. Entradas para equipos de desarrollo y localización. Para esto, tenemos una interfaz especial que le permite crear las entradas necesarias para todos los equipos involucrados a la vez. Se abre por un enlace desde un boleto MAPI.
   
   
   
   Al hacer clic en él, se abre la siguiente interfaz creada por nosotros:
   
   
   
   Al hacer clic en el botón en la parte inferior del formulario (no está visible en la captura de pantalla), aparecerán los tickets necesarios, que se vincularán automáticamente al ticket MAPI original. Vale la pena señalar que todos los equipos de desarrollo trabajan en nuestro propio espacio (proyecto) Jira: el equipo de back-end está en SRV, el equipo de Android está en AND, el equipo web está en la Web, etc.
   
   La interfaz se basa en la API REST de Jira.
   

Por lo tanto, la estructura del proyecto se puede representar como el siguiente diagrama:

Desarrollo y lanzamiento

En el caso general, todos los equipos pueden trabajar en un proyecto en paralelo, tocando solo en la etapa final de integración, es decir, los equipos clientes no tienen que esperar a que un servidor terminado haga su parte. Dado que el protocolo de interacción se describe en detalle, durante el desarrollo, puede emular de forma segura la respuesta esperada del servidor y la lógica del cliente de depuración. Además, el servidor no necesita un cliente durante el desarrollo: el programador del servidor simplemente implementa el protocolo y lo cubre con pruebas, emulando las solicitudes del cliente.

Por lo general, se inicia una función en el siguiente escenario:

1. El servidor es el primero en diseñar su parte de la funcionalidad, cubierta por el indicador de característica, en producción. Por lo tanto, esta lógica permanece inactiva hasta que uno de los clientes comienza a enviar este indicador de función.
   
2. Los equipos de clientes antes del lanzamiento en producción prueban su parte de la funcionalidad que ya está en el servidor de "batalla".
   
3. Tan pronto como esté listo, se lanzan diferentes clientes, comience a enviar el indicador de función deseado y reciba una nueva respuesta del servidor.
   

La posibilidad de trabajo sincrónico en el proyecto es una gran ventaja, que puede aumentar significativamente la eficiencia del desarrollo. Pero aquí radica el riesgo: algunos equipos pueden "escribir en la mesa", es decir, hacer su parte del trabajo, que nunca será demandada por otros participantes del proyecto. Puede haber varias razones:

• diferentes prioridades para los equipos de desarrollo; Los problemas generalmente no surgen cuando se trabaja en proyectos que son súper importantes para la empresa (todos son conocidos y difíciles de olvidar), pero los menos importantes se pueden colocar en la cartera local de un equipo separado en los últimos lugares;
  
• error de gestión del proyecto: el gerente simplemente puede olvidarse de priorizar correctamente las tareas del equipo de desarrollo, es decir, sus participantes ni siquiera sabrán que el boleto debe implementarse lo antes posible.
  

¿Cómo nivelar estos problemas? ¿Cómo asegurarse de que las piezas del proyecto no se pierdan y que los equipos presten la debida atención a los proyectos prioritarios?

Características estándar de Jira

¿Qué puede ofrecer la funcionalidad estándar de Jira al gerente de proyecto para resolver estos problemas? No tanto

• Filtros
  
• tableros kanban.
  

Filtros

El filtro le permite ver una lista lineal de tickets recibidos para una consulta JQL arbitraria. Esta herramienta es muy conveniente para atender el trabajo atrasado de un equipo, pero no sé cómo usarla para la gestión de proyectos de alta calidad, distribuida en diferentes equipos. Lo máximo que puede hacer un gerente es mostrar una lista priorizada de tickets PROD raíz, y luego debe ir a cada uno, mirando los tickets vinculados. Pero esto es extremadamente inconveniente y largo, especialmente considerando que la jerarquía de enlaces puede ser de varios pisos. Además, el equipo de desarrollo puede crear varios tickets adicionales para resolver la tarea inicial, y su estado también debe ser monitoreado.

Tableros Kanban

Para aquellos que no saben cómo funciona esto en Jira, lo explicaré. En general, esta es una lista de tareas basadas en un filtro específico, agrupadas en tres columnas: "Backlog", "Tareas en desarrollo", "Tareas completadas". La interfaz le permite aumentar la prioridad de las tareas simplemente arrastrando un ticket en la lista con el mouse. Al mismo tiempo, cambia la propiedad Clasificación , por la cual puede ordenar los tickets en sus filtros.

Aquí ya tenemos mucho más espacio para usar la herramienta en el contexto de la tarea en cuestión. PM puede crear un filtro que seleccione todas las tareas de todos los departamentos en la dirección deseada. Esto se puede hacer, por ejemplo, colocando tickets automáticamente con las etiquetas correspondientes. Les recuerdo que todos los tickets clave del proyecto para nuestro proyecto se crean utilizando las herramientas apropiadas. Por lo tanto, copiar automáticamente las etiquetas necesarias del ticket PROD raíz a todos los tickets derivados es una tarea técnica trivial.

Utilizamos tableros kanban para formar y controlar los retrasos de los equipos de ingeniería. Usando la herramienta Swimlanes, un tablero puede agruparse en proyectos que corresponden a equipos de ingeniería. Por lo tanto, utilizando esta herramienta, PM puede monitorear el progreso de sus proyectos en el contexto de diferentes equipos, así como priorizar las entradas de los equipos.


Esquema de un tablero de productos kanban en el que los tickets de proyectos PM se agrupan por equipos

El problema es que la herramienta no proporciona una manera fácil de agrupar tickets por tickets PROD de origen, es decir, por características: quiero monitorear el progreso de cada proyecto individualmente en todos los equipos de ingeniería.

Excel

La solución más obvia es usar hojas de cálculo. Después de todo, puede hacer todo lo que quiera: conveniente, hermoso, informativo. Algo como esto:



Puede ver el alcance general del trabajo para cada proyecto en un solo lugar. Puede hacer varias notas, tachar tickets completados, etc. Aquí todo es bueno, excepto uno en negrita, pero: mantener la relevancia de tales tablas es extremadamente difícil. Los estados de los tickets cambian constantemente, se crean nuevos. ¿Hacer todos los cambios manualmente? Puedes pasarlo todo el día. Pero estamos por la eficiencia, ¿verdad?

"¡Y crucemos!"

¿Por qué no utilizamos la conveniencia y la claridad de las hojas de cálculo agregando sincronización automática con Jira? ¡Tenemos todas las posibilidades para esto! Así que decidimos crear una herramienta adicional basada en la API REST de Jira, que mantiene automáticamente el estado actual de la información y tiene una interfaz conveniente para nosotros.

Los requisitos de la herramienta fueron los siguientes:

• la capacidad de crear listas de proyectos y tickets derivados de ellos de acuerdo con consultas JQL arbitrarias (esto es necesario para que cualquier PM pueda crear su propio espacio (unidad) en el que solo verá sus proyectos y los gestionará);
  
• nuevos proyectos en Jira deberían aparecer automáticamente en la interfaz;
  
• los nuevos tickets en el proyecto deberían aparecer automáticamente en la interfaz (es decir, si el equipo de desarrollo decide que se necesitan más tickets para implementar la función, el primer ministro lo verá inmediatamente en la interfaz);
  
• dependiendo del estado de los tickets, los colores de las celdas de la tabla deberían cambiar (para que los participantes comprendan rápidamente el estado del proyecto);
  
• la capacidad de ordenar proyectos (priorizarlos adecuadamente);
  
• ocultamiento automático de proyectos completados dos semanas después de la finalización.
  

PM comienza a trabajar con la herramienta, creando su propio espacio (unidad), indicando su nombre y consulta JQL:



A continuación, se realiza una solicitud a Jira para obtener una lista de proyectos para la consulta JQL especificada. También usando enlaces en Jira están todos los tickets derivados de los equipos de ingeniería. El resultado es algo así como esta tabla:



Arriba están los enlaces para cambiar entre unidades.

Las filas de la tabla son los tickets PROD raíz de la unidad. En las celdas vemos las tareas del proyecto para departamentos de ingeniería específicos. El llenado se realiza automáticamente sujeto a las reglas para vincular los tickets del proyecto entre sí. Las etapas completadas están marcadas en verde, no iniciadas en rojo y actual en amarillo.

Los enlaces conducen a entradas para Jira. También puede obtener información breve sobre el boleto al pasar el mouse sobre el enlace:



Con una frecuencia de una vez cada pocos minutos, se realiza una solicitud a la API de Jira para obtener una lista actualizada de proyectos para todas las unidades, para sincronizar la lista de tickets derivados, así como sus estados actuales.

La ordenación se realiza simplemente arrastrando y soltando el proyecto deseado en la ubicación deseada en la lista:



Es importante tener en cuenta que con esta herramienta en Badoo no solo trabajan los gerentes de producto, sino también los líderes de los equipos de ingeniería. Después de todo, es importante que todos entiendan lo que está sucediendo en las áreas de productos, qué equipos han avanzado en la implementación de proyectos importantes para la empresa más que otros, y cuáles están detrás.

Conclusiones

Jira "fuera de la caja" proporciona una potente funcionalidad para gestionar la estructura del proyecto y la relación entre tickets. También hay complementos que amplían significativamente las capacidades de JQL (por ejemplo, le permiten usar enlaces entre tickets y sus tipos para filtrar tickets). En nuestro caso, solo carecíamos de la capacidad de visualizar todo lo que necesitábamos.

Afortunadamente, Jira permite crear herramientas convenientes adicionales basadas en su API, adaptadas a los procesos comerciales de la compañía. Entonces, por ejemplo, pudimos resolver el problema que surgió con la transparencia de llevar a cabo proyectos en una docena de áreas de productos, con un poco de esfuerzo y utilizando características adicionales de este rastreador de tareas. Sería interesante leer los comentarios si intentara hacer tales complementos en su lugar o encontrara otras soluciones para sus tareas.

¡Gracias a todos por su atención!