Hola Habr! Mi nombre es Maxim Lutzau, en Promsvyazbank trabajo como propietario de un producto. Durante casi un año, el desarrollo del nuevo banco de Internet My Business ha continuado con el marco Scrum, y en este sentido, ya he logrado llenar los baches. En esta publicación, me gustaría hablar sobre los más dolorosos, así como sobre las herramientas que finalmente nos ayudaron. Para que pueda evitar tales problemas.
Algunos empleados se oponen fundamentalmente al cambio.
El marco Scrum se adoptó en nuestro banco para acelerar el desarrollo y reducir la TTM. Cuando comenzó la implementación, resultó que algunos empleados no estaban preparados para esto. No entendían por qué esto era necesario y qué daría.
"Solíamos trabajar bien, ¿por qué necesitamos esto?", "¿Por qué no lo hacemos de manera diferente?", "¿Quién vino a enseñarme esto, cómo sabe que es mejor?" - Preguntas similares llovieron constantemente por su parte. E incluso cuando estos empleados recibieron respuestas, después de un tiempo, todo se repitió nuevamente.
La solución más razonable en este caso es transferir personas a otros proyectos. Esto debe hacerse necesariamente, ya que una persona que irradia un negativo puede influir en todos. En nuestra historia, esto es precisamente lo que ha sanado nuestro colectivo: la tensión general ha desaparecido y todos están sintonizados con la percepción de nueva información.
Una reacción negativa a los cambios no depende de la edad. Los desarrolladores de los que hablamos anteriormente tenían poco más de 30 años. Al mismo tiempo, una persona que ya tiene más de 50 años está trabajando perfectamente en nuestro equipo: no tuvo ningún problema con Scrum.
Es difícil interactuar con personas que no viven con Scrum.
Cualquier organización tiene que colaborar con personas que simplemente no trabajan en Scrum. En nuestro caso, se trata de equipos de otros proyectos y departamentos. Por lo general, tienen etapas mucho más largas de implementación del proyecto. Honestamente, hasta ahora solo los desarrolladores de RBS trabajan para nosotros en Scrum.
Decidimos no hacer nada con este problema, no meternos en el trabajo de otras personas con nuestro scrum. Simplemente les pedimos que hagan lo que necesitamos. Cuando regresan con una solución, comenzamos a vincular sus tareas. No complique la interacción si la cultura corporativa aún no está madura por sí misma. Por supuesto, después de los entrenamientos de scrum existe el deseo de cambiar absolutamente todo, pero es mejor detenerse a tiempo.
Aunque no apresuramos a otras unidades, en cooperación con nosotros comienzan a trabajar más rápido. Invitamos a los guardias de seguridad a nuestras reuniones y demostraciones, y ahora llegar a un acuerdo sobre una versión completamente completa solo lleva un día. Antes de eso, tomó de una semana a dos.
"¡No llegaremos a tiempo para el sprint!"
Después de implementar Scrum, cambiamos de los períodos de informes mensuales a sprints de dos semanas. Al principio, debido a la escala de las tareas, no querían comprimir los plazos. Pero ajustar el tamaño del sprint a lo que hay que hacer es un gran error. Por el contrario, debe ajustar los planes para la duración del sprint. Hacer esto es bastante simple: simplemente descomponga las tareas. Cuando disminuyen de tamaño, son más fáciles de organizar según el plan, para darles prioridad. Los lotes de código más pequeños son más rápidos de probar, verificar y negociar con los guardias de seguridad. En general, incluso recomendaría reducir la duración del sprint, si es posible, de dos semanas a una.
Cuando alguien del equipo no tiene tiempo para hacer todo lo planeado para el final del sprint, existe un deseo natural de posponer la demostración, de llegar a ella completamente armado. Pero en este caso, aún debe cumplir con el cronograma. En cualquier caso, vale la pena hablar sobre los resultados del trabajo: qué hicieron, qué y por qué no lo hicieron, qué hicieron para llegar a tiempo. Por lo tanto, no huimos de los problemas, sino que nos enfrentamos a ellos y luego podemos encontrar soluciones juntos.
Este enfoque aumenta la motivación, después de demostraciones planificadas sin éxito, crece la responsabilidad por el trabajo. Si antes los desarrolladores preparaban el stand para la demostración en cinco minutos, ahora lo hacen el día antes de la demostración, y luego pulen los golpes restantes para hacer que todo sea súper.
"¿Por qué necesitamos stand-ups diarios?"
Al principio, los colegas eran escépticos acerca de distraerse de su trabajo habitual en las reuniones de pie todos los días. Incluso si se llevan a cabo en línea y requieren solo 10 minutos.
Al resolver este problema, el estímulo simbólico de una persona que encuentra un lenguaje común con el equipo ayuda. Una vez, por diversión, dije que marcaría en el calendario a los que se ponen de pie y comencé a poner ventajas. El resultado fue inesperado, y el efecto fue notable después de un sprint. No queriendo ser bombardeados, los propios desarrolladores se pusieron de pie. Incluso se convirtió en nuestra broma común: ahora amenazan con ponerme un menos cuando no puedo asistir a ninguna reunión.
Muchas personas piensan que las reuniones de scrum toman mucho tiempo. Es suficiente calcular aquí si esto es realmente así. Tenemos dos horas a la semana de 40. Esto no es tanto para organizar el trabajo y estar al día con todas las cosas.
Si todo el equipo no quiere ir a las reuniones de pie, y las reuniones en sí mismas no son muy activas, esto es una señal de que el trabajo va mal. Como si la reunión se retrasara más de 15-20 minutos. Una historia sobre sus actividades y planes en una persona no debería tomar más de uno o dos minutos.
Una regla más está relacionada con la gestión del tiempo. Si la discusión de la tarea lleva más de 30 minutos, la detenemos. Esto significa que no tuvimos tiempo para desarrollar la tarea, que está mal descompuesta y aún requiere tiempo. Vale la pena prestarle atención. Establecemos un límite de 30 minutos para nosotros: cada empresa necesita establecer su propia barrera.
Retraso incomprensible
El éxito de Scrum depende principalmente de una planificación clara. Es necesario determinar cuántas tareas se deben evaluar y describir, y cuáles se pueden posponer simplemente por ahora. No intentes cubrir todo de una vez. El desarrollador necesita entender lo que hará en los próximos dos sprints. Para períodos más largos, una idea aproximada es suficiente: cuanto más tarde, menos detalles.
Micromanagement inapropiado
¿Qué están haciendo los desarrolladores hoy? ¿Qué pasará mañana? Sucede que los gerentes hacen tales preguntas regularmente. Pudimos explicarle a nuestra gerencia que todos los puntos de interés se pueden encontrar en nuestro tablero de scrum o acudiendo al stand-up diario. No hay informes especiales con tablas y monitoreo de tareas en Jira. Logramos exprimir esta microgestión a reuniones semanales con la gerencia, donde informo sobre las tareas específicas realizadas por el equipo.
Algo casi nunca escrito sobre
Finalmente, hay un problema claro, cuya mención casi nunca encontré. No es necesario intentar combinar el scrum master y el propietario del producto. Este último está construyendo una unidad de negocios, trabajando en una cartera de pedidos y realizando KPI. Está interesado en el éxito del producto y trata de profundizar en todo; por lo tanto, comienza a hacer citas y discutir algunos detalles. En general, se carga con un montón de funciones, por lo que simplemente no queda tiempo para la acumulación.
Esto me paso a mi. Organicé reuniones, stand-ups, resolví los problemas de los miembros del equipo. Debido a esto, el trabajo atrasado no se resolvió, es decir, simplemente no había tiempo para la actividad principal. Ahora hemos encontrado un gerente de desarrollo que tiene autoridad sobre el equipo y también comenzó a realizar las funciones de un scrum master, ya que tiene más experiencia trabajando en este marco. Ahora podía alejarme de Scrum y concentrarme completamente en las tareas del propietario del producto, quien, a su vez, debería pensar en los requisitos. Sin buenos requisitos, no habrá buen producto. Como resultado, la cartera de pedidos comenzó a mejorar, los colegas llegaron a comprender cómo avanzaremos.
A primera vista, Scrum parece muy simple, pero aún tiene muchas dificultades. Hemos estado trabajando en este marco durante casi un año, pero solo ahora hemos comenzado a evaluar más o menos claramente nuestras habilidades, hemos comenzado a aumentar la velocidad de desarrollo.