A veces los equipos de desarrollo jóvenes se meten en un lío.
Esto sucede en un momento en que aún no han entendido completamente qué es una ventaja; El proyecto y el producto discuten cuál de ellos es quién, y cada uno realiza tareas por su cuenta. O todo el mundo ya lo sabe todo, pero los sprints no pueden planificarse: las tareas no se resuelven, las demostraciones y el retro no son regulares.
También tuvimos una historia similar, pero encontramos nuestro camino.
Esta es una historia del equipo de cuentas personales de Yandex.Kassa, y una instrucción detallada para aquellos que desean mejorar su planificación.
Como fue
El equipo de cuentas personales de Yandex.Kassa es responsable de la conveniencia de conectar nuevos comerciantes al Cajero y ofrece un servicio de facturación. Según los estándares de Yandex, el equipo es joven: 4 de cada 6 desarrolladores trabajan seis meses o menos, y yo, el gerente del proyecto, me uní al equipo hace 3 meses.
El primer día del nuevo sprint, el equipo se reunió con el propietario del producto (en adelante, PO) y planeó el sprint durante aproximadamente dos horas. Este enfoque tiene desventajas obvias:
- Baja elaboración de requisitos. PO no tuvo tiempo suficiente para responder todas las preguntas. Tomamos tales tareas en el sprint o pedimos a los analistas que evaluaran la tarea y pospusimos su implementación hasta el comienzo del próximo sprint.
- Hubo situaciones en las que las partes interesadas fueron recordadas cuando el sprint estaba en pleno apogeo y necesitábamos urgentemente algunas mejoras o soluciones de los equipos relacionados.
- Falta de gestión de riesgos.
Con su consideración, aparecieron los requisitos para un nuevo proceso:
- Los requisitos para las tareas deben ser elaborados tanto por el propietario del producto como por todas las partes interesadas.
- DOD implementado (la definición de done es un conjunto de criterios que le permiten comprender si se realizó el propósito del desarrollo) para cada actividad. Comenzaron a identificar a los interesados para que una semana antes del comienzo de un nuevo sprint les informaran sobre el progreso del trabajo y recogieran comentarios.
- Reuniones mínimas para centrarse en el sprint actual. Limitado a dos reuniones en dos semanas durante una hora cada una.
- Comenzaron a llevar a cabo regularmente una capacitación interna del producto en equipo, ya que hoy uno de los riesgos clave es la falta de conocimiento sobre el producto.
Nuevos conceptos
Introdujimos nuevos contenedores (listas) de comandos:

La prioridad de las tareas en todas las listas, excepto la primera, está determinada por PO.
Si las tareas se completan en el sprint, un miembro del equipo puede asumir las tareas de Estimado y comprenderá que están completamente listas para el trabajo: tómelo y hágalo.
Primera semana

Por clic - versión completa.
Lunes
El propietario del producto mueve las actividades del contenedor Lista de tareas a Preparación, prioriza y describe la Definición de hecho de la forma más clara posible.
PM verifica la actividad en el contenedor de aseo contra la lista de verificación:
- ¿Se necesitan diseños para nuevas actividades y, en caso afirmativo, lo son?
- ¿Se han incluido todas las actividades para el proyecto más importante?
- ¿Están indicados los enlaces entre tareas?
Si algo está mal, PM se comunica con el PO para aclarar los detalles y notifica al equipo que la lista de Grooming está actualizada.
Un ejemplo:
- Tome la tarea "Las cartas sobre las facturas emitidas por la noche se envían con retraso". Fue agregado por el probador al final de la lista de aseo.
- PO planteó esta tarea en la lista.
- PM verificó que la actividad de trabajar con el contenedor por parte de PO se llevó a cabo, y notificó al equipo al respecto.
Martes
El equipo se familiariza con nuevas actividades y escribe comentarios, preguntas y hace sugerencias. PO recibe automáticamente todos los comentarios nuevos (usamos Jira, por lo que es fácil de hacer), y tiene tiempo para preparar las respuestas para mañana.

Un miembro del equipo especificó si la tarea es relevante. Resultó que la tarea es relevante, el probador encontró la causa del problema y lo informó. Sin embargo, desde el punto de vista de la lógica empresarial, la pregunta permaneció abierta.
Miercoles
Tenemos una reunión con el PO que responde las preguntas del equipo. El propósito de la reunión: arreglar DoD. Después de la reunión, parte de las actividades irán al contenedor "Definido", y parte - inmediatamente a "Estimado", si es inmediatamente obvio cuánto tiempo llevará esta actividad. Definir dependencias y partes interesadas.

Un diálogo entre PM y PO, después del cual quedó claro lo que hay que hacer. Por lo general, este diálogo no es fijo, pero fue debido a esta actividad que el PO no estuvo disponible durante la reunión, por lo tanto, la comunicación se registró por escrito.
Jueves
PM envía una lista de actividades cercanas de la lista Estimada y Definida a las partes interesadas con una solicitud para ver y comentar.

Viernes
El PM responde las preguntas de las partes interesadas, involucrando a un equipo o PO si es necesario.
No se recibieron comentarios sobre la tarea, que mostramos como ejemplo, pero en general se ve así:

La retroalimentación puede venir a través del mensajero.
El resultado de la primera semana es la actividad, según la cual está claro lo que hay que hacer (se determina dod), teniendo en cuenta los deseos de las partes interesadas.
Segunda semana

Lunes
El equipo evalúa de forma independiente las actividades en la lista "Definida" y la descomposición de las actividades en la lista "Estimada". PO no está involucrado aquí, porque él es responsable de establecer tareas por parte de la empresa y no es su responsabilidad evaluar cómo se realiza alguno de los planes.

Martes
Hay una segunda reunión con PO, en la que el equipo puede aclarar los detalles y comunicar sus calificaciones. PO puede informarle sobre nuevos eventos introductorios que pueden haber ocurrido durante la semana pasada, así como aclarar por qué la actividad es precisamente tales estimaciones, y no menos.
Miercoles
Hay una demostración sobre el sprint actual. Como resultado de la demostración, generalmente se forman nuevas actividades, algunas de las cuales deben completarse antes del final de la semana, y el resto en el próximo sprint. El propósito de la demostración es recopilar comentarios. El equipo presenta el resultado de su trabajo y recibe retroalimentación temprana sobre el trabajo de la nueva funcionalidad.
La demostración es interna y externa .
La demostración interna es para PO, donde evalúa si el equipo logró el resultado como esperaba o si se necesitan mejoras. Lo realiza un probador en un entorno de prueba.
La demostración externa está destinada a las partes interesadas. Ocurre después del cálculo de la nueva funcionalidad "a la batalla", lo lleva PO.
Después de la demostración, se agregan nuevas actividades a la cartera de pedidos y, según su prioridad y calificación, se pueden agregar al sprint actual. Realizamos una demostración específica a mediados de la segunda semana para tener tiempo de mejoras hasta el final del sprint.
Jueves
PO prioriza las listas Definidas (si durante el sprint las actividades se completan antes de la fecha esperada, entonces se pueden tomar nuevas actividades de esta lista) y Estimadas (las actividades de esta lista se transfieren al nuevo sprint).
Viernes
Se lleva a cabo la planificación de Sprint, en la que participa el equipo de desarrollo de PM y PO.
Hay un retro en el que discutimos cómo trabajamos en el sprint actual y si nos preparamos bien para el próximo: intercambiamos opiniones, está todo claro para el próximo sprint, ¿todavía tenemos suficientes recursos en el recurso para corregir errores inesperados?
Se está llevando a cabo una reunión de gestión de riesgos. En este momento, estamos dedicando este tiempo al estudio del producto, ya que su excelente comprensión reduce significativamente los riesgos. PM junto con los evaluadores durante la semana asigna tiempo para estudiar el producto y comparte el resultado con el equipo. Los representantes de las unidades están invitados a la reunión para complementar la imagen.
Cada segundo viernes es el final no solo de la semana laboral, sino también del sprint. Este es un día de comunicación y comentarios. Así, el lunes de la nueva semana laboral comienza con tareas claras y apreciadas, lo que también es lógico y cómodo para el equipo.
Conclusiones y próximos pasos.
Utilizando este proceso, fue posible establecer una interacción de alta calidad entre la OP y el equipo, los conflictos y malentendidos se produjeron en el pasado. El clima en el equipo mejoró y apareció una sensación de trabajo rítmico armonioso. Por supuesto, todavía hay muchos problemas, pero hubo muchas menos situaciones de emergencia e imprevistas en las que el equipo o el primer ministro tuvieron que salvar el proyecto.
Como todos los seres vivos, nuestro proceso de vez en cuando requiere actualización. Ahora vemos que vale la pena finalizar en las siguientes áreas:
- Errores El trabajo con errores también debe planificarse. No podemos llevar a cabo los errores emergentes en el proceso de planificación del sprint, aquí se necesita más trabajo operativo. Estamos pensando en cómo hacerlo.
- Queremos hacer una tabla de riesgos típicos para tenerlos en cuenta y reducir la probabilidad de errores en la implementación del sprint.
- Cuando planificamos un sprint, queremos aprovechar el objetivo del sprint para mantener el enfoque del trabajo. El equipo es joven, por lo que hay dificultades con esto.
Esperamos que nuestra experiencia ayude a su equipo. Estamos listos para discutir nuestro enfoque en los comentarios, responder preguntas o dar consejos.