Get best of the week

Planificación horaria y otra optimización de eventos scrum

imagen
Pure Scrum es como un unicornio en un festival de música: parece existir, todos hablan de eso, solo que nadie puede mostrárselo. También sucedió en nuestro equipo, hablaremos de esto. Y más específicamente, sobre cómo redujimos el tiempo para las reuniones y no perdimos el beneficio de ellas.

Por supuesto, Internet está lleno de artículos sobre quién y cómo este scrum se cultivó en sí mismo, qué sucedió y qué no. No pretendo ser único y no he leído todo, porque hay muchos más escritores de tales artículos que tengo tiempo libre. Sin embargo, quiero decir cómo en el equipo de desarrollo de Android construimos (y todavía estamos construyendo) el proceso, prácticamente sin perder tiempo en reuniones y discusiones. Resultó solo porque mi tiempo (soy PO) y el tiempo del equipo son muy limitados, y me esfuerzo por hacer todo lo posible para no participar en los procesos por el bien de los procesos y al mismo tiempo mantener un alto rendimiento y transparencia.

Daré una pequeña idea de mí mismo, para que el lector comience a desarrollar un retrato de la persona de cuya persona se narra la historia.

Soy el gerente de producto del equipo de Android en Wrike. Además de esto, tuve el honorable papel de un maestro scrum.

Somos una aplicación satelital, y la mayoría de nuestros clientes trabajan en la oficina y usan la versión web del producto. Tenemos alrededor de 3 lanzamientos clave por trimestre, pero se debe dedicar mucho tiempo a apoyar las mejoras de la versión web. Debido al desarrollo activo de la web, seremos lanzados una vez cada dos semanas. La función de la aplicación es no perder contacto con el equipo y monitorear los procesos de trabajo. Puede configurar el entorno solo en la versión web. La estrategia de desarrollo de productos es aumentar la audiencia y su actividad en dispositivos móviles. Nuestro equipo consta de cinco desarrolladores de Android, dos de control de calidad, un diseñador de experiencia de usuario, un gerente de producto. Todos los muchachos son muy hábiles.

Ahora que el lector tiene una idea del equipo, pasaré a la esencia del artículo: los procesos. Hoy hablaremos sobre elementos de scrum como: PBR, Retro, Planning, Daily. Mi objetivo principal como scrum master es utilizar el valor de estas reuniones y, al mismo tiempo, dedicar un mínimo de tiempo a ellas. Además del hecho de que es lógico en términos de optimización de recursos, tenemos una limitación más: nuestro equipo debe admitir los cambios de veinte equipos de productos. No admitimos todos los cambios, pero aquellos que afectan la funcionalidad existente requieren nuestra participación. En el artículo, le contaré más sobre cuánto tiempo dedicamos a cada uno de estos cuatro rituales y qué beneficios trae ese marco de tiempo.

PBR


Busqué en Internet esa definición : "PBR (Refinamiento de la cartera de productos) es el proceso de agregar piezas, clasificaciones y pedidos a los elementos de la lista de las acumulaciones". Por mi propia experiencia, sé que en un evento así, todo el equipo a menudo está presente para ver la tarea por adelantado, resaltar momentos no obvios. Pero una reunión de este tipo requiere mucho tiempo, pero nuestro equipo no la tiene, porque muchos cambios provienen de la versión web. Por lo tanto, cambiamos el formato de la reunión.

Como ha demostrado la práctica, a primera vista, hay una lista de tareas que pueden ser muy complejas o poco características para el producto. Antes de investigar tales problemas, reúno a todos y les cuento la esencia de lo que está sucediendo: esto se llama Foro. Esto ocurre extremadamente raramente, sin embargo, une al equipo decentemente y alimenta el interés en la tarea, y la participación en el producto es adictiva. Y esta participación está creciendo precisamente debido a su irregularidad. Tal reunión se convierte en algo especial, no rutinario y, por lo tanto, significativo.

El análisis del trabajo es el siguiente: cada tarea (historia) está planificada para una persona (llamémosle "campeón"), y él realiza un estudio de lo que debe hacerse exactamente al respecto. Agrega una descripción, aclara con el diseñador de UX cómo deberían funcionar algunos puntos si esto no es suficiente en el dock, consulta el backend y escribe un plan detallado. De hecho, resulta algo así como Spike .

Este enfoque se ha demostrado por las siguientes razones:

  • Trabajar mucho tiempo en una tarea nos permite comprender mejor su esencia. Una comprensión profunda del problema lleva al hecho de que el campeón puede encontrar los errores cometidos durante el diseño. Y ahora no solo me refiero al código, sino también a la idea misma. Una especie de verificación de la decisión de organicidad.
  • Por mi parte, noté que la motivación del equipo está creciendo (no hay gráficos de crecimiento de felicidad, lo siento) y el deseo de llevar la tarea a producción.
  • Si la motivación del campeón es alta y comprende la esencia del problema, entonces ofrece sugerencias que pueden reducir el costo de desarrollo, se llena con una acumulación de tareas técnicas y aparecen ofertas para UX. Este último puede ahorrar mucho tiempo de programador.

Quiero prestar especial atención al tiempo dedicado a dicha investigación. Los desafíos requieren una inmersión profunda, especialmente en el caso del legado. Aquí, en mi opinión, hay 3 estrategias principales:

  1. "Lo resolveremos en el acto": por lo general, el final de una tarea de este tipo no es visible hasta que está casi completa.
  2. « » — : « , ». , .
  3. « » — , , .

En caso de que las tareas no sean triviales, la investigación a menudo va en paralelo con el desarrollo. El descubrimiento de código normal no lleva más de un día y le permite crear un plan de desarrollo completamente preciso. Yo diría que de todas las tareas, alrededor del 10% están sujetas a investigación, el resto se puede llevar a cabo sin este proceso. Nuestra receta para el rendimiento son los desarrolladores fuertes y la regla es que el 20% de los recursos se asignan a tareas técnicas. El equipo sabe mejor cómo y dónde dirigir los esfuerzos para mantener el código en un estado saludable. Para mí, esta es exactamente la herramienta que le permite moverse rápidamente con las tareas del producto, mantener contentos a los desarrolladores, planificar con claridad y llegar a tiempo. Desarrolla una cultura de ingeniería y apoya la motivación de los muchachos del equipo.

Retro


Aquí no voy a presumir, solo digo que el equipo tiene una regla: junto con el problema, ofrecer una solución. Los chicos del equipo son responsables, quieren trabajar bien y no distraerse con cosas desagradables, por lo que están interesados ​​en que los procesos sean claros y confiables.

Permítanme dar un ejemplo del problema que nos enfrentó en Retro: olvidamos agregar análisis. Puede parecer que se trata de PM en lugar de desarrolladores, pero, como dije, los muchachos del equipo están motivados y quieren hacer bien su trabajo. Debido a los recursos analíticos limitados, este proceso es idealmente imposible de llevar a cabo, porque justo en retro construimos un proceso específico y compartimos responsabilidades entre los miembros del equipo para que todos traigan sus beneficios en una determinada etapa. También una nota importante: si en una hora no tuvimos tiempo para descubrir cómo resolver el problema, acordamos probar las ideas propuestas y ajustarlas en el camino.

Pero también hay casos límite en los que los objetivos profesionales difieren un poco, y pueden aparecer puntos difíciles entre los miembros del equipo, en otras palabras, los ingenieros están más centrados en la parte técnica, PM en el producto y el diseñador en la conveniencia y los gráficos. Pero dado que nuestro principal objetivo común es crear un buen producto, no tenemos reparos en discutir temas en la intersección de intereses de los miembros del equipo. Y aquí vale la pena decir que es costumbre para nosotros ser abiertos y honestos. Sin embargo, si alguien en el equipo se avergüenza de expresar su punto de vista, entonces hay una alta probabilidad de que haya una desigualdad en el equipo o que haya conflictos ocultos. Solo la igualdad en el sistema te permite ser abierto. Si está interesado en cómo logramos hacer esto, hágamelo saber en los comentarios, pero por ahora, vamos más allá.

Planificación


Mi parte favorita de scrum. Me gusta por dos razones:

  1. es divertido;
  2. Prácticamente no requiere mi participación.

El proceso se ve así: hay una lista de tareas que defino para el sprint. Cada miembro del equipo junto con otros decide en qué punto y qué es mejor comenzar a hacer, cuáles serán los criterios de aceptación para la tarea. Los propios miembros del equipo establecen las dependencias entre UX, DEV y QA. Y es divertido precisamente porque los chicos se ponen de acuerdo, planifican sus tareas prioritarias en un orden cómodo para ellos. Discuten, bromean, actúan como un equipo, están unidos en este momento. Dependiendo de sus planes / estado de ánimo, entienden qué y cuándo quieren hacer, y el tiempo y las dependencias se establecen en esto. Resulta algo así como Workload: la planificación no se basa en tareas, sino en personas.

imagen
A primera vista, puede parecer un desastre, pero debido al hecho de que el equipo mismo planifica, está bien versado en lo que está sucediendo y rápidamente realiza cambios.

Diario


En primer lugar, se trata de la sincronización, pero quiero enfatizar por separado mi papel como gerente de producto en este evento. Ya he dicho que la igualdad es importante en un equipo. El clima debe ser tal que los muchachos se sientan como un equipo, no como contribuyentes individuales. Por lo tanto, como gerente de producto, le cuento a la compañía las noticias, así como lo que estaba haciendo, lo que reconocí y lo que me esperaba. No tengo secretos frente al equipo, aunque las excepciones son extremadamente raras: se pide que se guarden algunas cosas hasta el anuncio oficial. Pero tales anuncios son simplemente algo fuera de lo común.

Total


Spike para 1 día + reuniones raras en el formato del Foro para presentar a los niños a tareas inusuales dan una buena comprensión de qué tipo de trabajo tenemos que hacer. La planificación lleva solo una hora y se realiza de forma gratuita, todas las personas están de acuerdo perfectamente en lo que deben hacer. Retro siempre tiene lugar en un formato, pero es muy productivo y las pequeñas cosas en los procesos se agudizan regularmente. Y la apertura del gerente de producto en el equipo diario forma igualdad y confianza en el equipo.

Para mí, en última instancia, solo tres indicadores tienen sentido: el nivel de satisfacción del equipo para que los chicos no se agoten, la calidad del producto y la velocidad de las tareas.

Y estos indicadores en nuestro equipo son bastante altos:

  • Calidad: 2-3 errores después del lanzamiento (y tenemos lanzamientos grandes);
  • Velocidad: nuestro equipo de cinco desarrolladores, dos de control de calidad y un UX admite los cambios que crean veinte equipos web;
  • Satisfacción: en los cinco años de mi trabajo en Wrike, un desarrollador y un QA abandonaron la empresa.

Guinda del pastel


Un poco de matemática. Para un sprint de dos semanas resulta:

  • 10 diarios por 15 minutos;
  • ± 2 foros por hora;
  • Planificación 1 hora;
  • Retro 1 hora.

Total: 4h 30min ± 2 horas de 80 horas en un sprint de dos semanas.

Está claro que este número debe multiplicarse por la cantidad de personas en el equipo para comprender cuántas horas de persona le costó el scrum del evento. Mi indicador es 5.6% ± 2.5% con un tamaño de equipo de 9 personas. Cuanto más grande sea el equipo, mayor será el valor. Pero no olvidemos que el equipo scrum tiene los tamaños recomendados, lo que significa que el indicador del tiempo dedicado a los eventos del equipo también tiene un límite razonable.

En general, por ahora. Será ideal si comparte las cifras: cuánto tiempo tiene en el scrum del evento. Bueno, para que el artículo sea más valioso, analicemos los beneficios y los daños que, en su opinión, tales optimizaciones pueden traer.

More articles:


All Articles