En mi artículo anterior, comencé la discusión sobre hábitos mal desarrollados dentro de un equipo de scrum que eventualmente conducirán (tarde o temprano) a una falla en la entrega. En este artículo, me gustaría ampliar este tema una vez más y centrarme ahora en los procesos funcionales dentro del equipo.
Esos son tan importantes como la excelencia técnica del equipo. Incluso si las personas en el interior son súper hábiles para el trabajo que están a punto de realizar, todavía hay áreas que pueden arruinar su esfuerzo por la perfección. Y no será tanto su culpa como la responsabilidad directa de las decisiones de gestión del proyecto y su capacidad para servir al equipo con procesos adecuados para apoyar al equipo con una intención clara y actividades predecibles.
Tabla de contenido
Equipo altamente segregado con distintas habilidades
Imagine que el equipo tiene desarrolladores capacitados, perfectamente independientes y con la capacidad de cumplir sus promesas y entregar el contenido del sprint acordado justo a tiempo antes del final del sprint. Incluso en un escenario tan perfecto (que es muy poco probable que suceda de todos modos), el equipo tendrá problemas para mantenerse al día con las funciones de trabajo pendiente (en constante crecimiento) si las habilidades están estrictamente segregadas entre los miembros del equipo.
Algunos ejemplos
- El equipo tiene 1 o 2 ingenieros de DevOps capaces de realizar cualquier cambio en las canalizaciones automatizadas o cuidar los servicios dentro de la plataforma, pero el resto del equipo no tiene idea de esas cosas. Luego, discutir esas historias en las ceremonias de scrum como los refinamientos conducirá a una pérdida de tiempo para la mayoría del equipo al esperar la reunión sin ninguna participación y viceversa: el desarrollador de DevOps no tendrá interés en el resto de las historias orientadas a la funcionalidad, y el tiempo de la reunión también se desperdiciará en su mayor parte.
- Hay un único experto en bases de datos para todo el equipo. Dependiendo de la complejidad y el uso de las soluciones de datos en el sistema que el equipo está desarrollando, esta persona puede estar constantemente sobrecargada con historias que no tiene la posibilidad de completar pronto, especialmente cuando se tienen en cuenta sus prioridades. Peor aún, otras historias también tendrán que esperar, ya que dependen de la fuente de datos proporcionada por las historias de la base de datos.
- Cuando un producto en particular está orientado principalmente hacia el desarrollo de back-end, el único desarrollador de front-end está allí por si acaso (porque de vez en cuando, se necesitan algunos pequeños cambios incluso en la aplicación de interfaz de usuario de todos modos). En ese caso, nuevamente, la mayoría de las ceremonias de scrum son una pérdida de tiempo para este miembro del equipo, ya que su conocimiento se limita solo al frente y nada más importa.
donde concluye
En cualquiera de los casos anteriores, el resultado es que las personas están perdiendo el tiempo o, alternativamente, no pueden ponerse al día con la demanda acumulada. Están impidiendo que el resto del equipo comience a trabajar en las próximas historias, o están disminuyendo efectivamente la efectividad general del equipo Scrum porque hay demasiado tiempo que no se utiliza dentro del sprint.
El equipo, sin embargo, todavía tiene este número de desarrolladores. Desde el exterior, no es visible (incluso sin querer ser expuesto) que las personas dentro del equipo no pueden asumir algunas historias solo porque están demasiado orientadas a un conjunto de habilidades específicas. Por lo tanto, no pueden ayudar a los otros miembros del equipo con las historias, incluso si su capacidad lo permitiera, y las prioridades de las historias también lo favorecerían.
Incluso es difícil para el propietario del producto redactar contenido de sprint significativo para el equipo, ya que el propietario del producto siempre debe tener en cuenta cuántas personas pueden trabajar en cada historia y si se llevan más historias similares al sprint al mismo tiempo. , en última instancia, la capacidad del equipo se desborda, incluso si de hecho hay personas que posiblemente podrían trabajar en esas historias, pero no tienen el conjunto de habilidades para comenzar con ellas.
Resolviendo el dilema
Es un dilema a resolver, y los jefes de proyecto deben ser conscientes del camino a elegir. Específicamente, una elección entre:
- Tener muchos desarrolladores de pila completa capaces de trabajar en contenido más amplio, pero que no son realmente expertos en muchos temas. Entonces pueden ir anchos pero no profundos. Entonces la entrega puede progresar rápidamente, pero la calidad puede verse afectada.
- Tener expertos dedicados para cada tecnología, pero luego aceptar la limitación y trabajar más duro en contenido impreso mejor ajustado. Luego, las personas pueden profundizar y construir grandes historias, pero las historias deberán abordarse secuencialmente, por lo que llevará más tiempo entregarlas.
Propietario de producto débil
Este no es necesariamente un «problema de proceso» por definición, pero lo trato así solo porque la creación de historias sólidas puede entenderse como un proceso que el equipo debería querer tener sólido como una roca y compatible con el equipo de desarrollo.
Lo que quiero decir con débil no necesita referirse a la propiedad de conocimiento de una persona, sino más bien a la capacidad del propietario del producto para brindar al equipo historias que los desarrolladores puedan entender y que tengan un sentido claro desde la perspectiva de la hoja de ruta del producto. Ambos son muy importantes para un equipo scrum exitoso.
Si las historias carecen de detalles para que los desarrolladores puedan comprender claramente el propósito, el valor funcional o las expectativas técnicas, básicamente pueden ocurrir dos escenarios:
- Los desarrolladores crearán algo diferente de lo que realmente quería el propietario del producto. Incluso es difícil de detectar durante el sprint en sí porque, en su mayoría, el propietario del producto no ha tenido la capacidad de rastrear el progreso de las historias en un nivel tan detallado y, en su mayoría, PO esperará que las cosas sucedan (mágicamente).
- Los desarrolladores pasarán demasiado tiempo aclarando las historias y discutiéndolas una y otra vez en lugar de comenzar a construirlas. Esto implica muchas llamadas adicionales, acuerdos repetidos y posponer el trabajo hasta la última fase del sprint. Llega a un punto en el que las estimaciones originales de las historias ya no se pueden considerar precisas, y las historias no se pueden cerrar dentro del sprint y pasan a los siguientes sprints. En el peor de los casos, la situación se repite en los siguientes sprints.
Tiempo para la autorreflexión
Por lo general, es difícil de admitir, pero el propietario del producto debe encontrar el tiempo para reflexionar, mirar las historias pendientes creadas y, finalmente, compararlo con la visión de la hoja de ruta del producto si todavía hay algún vínculo sensato entre esos dos, si hay alguna hoja de ruta. en absoluto. Si no, eso es lo primero que hay que solucionar. A veces, la solución es admitir que el propietario del producto está demasiado lejos del equipo y demasiado lejos de su propio objetivo.
En tal caso, se debe resolver la parte del propietario del producto del equipo. Por lo menos, traer al equipo un analista de negocios sólido orientado más hacia el contenido del equipo que hacia el contenido comercial (para eso, ya tenemos un propietario de producto en este caso) podría ser una opción válida, incluso por el precio de aumento de los costes totales del equipo.
Procesos de prueba sin cronograma fijo
¿Qué pasa si las actividades de prueba no están ajustadas a un cronograma concreto dentro de un sprint de scrum?
A primera vista, esto podría parecer algo bueno que queremos para un equipo ágil/scrum. La flexibilidad siempre es bienvenida y suena bien cuando se presenta en el exterior.
Mi experiencia muestra que el resultado de esta libertad es más caos que flexibilidad. No significa que la solución a esto deba ser crear «cascadas dentro del sprint» con fases de prueba dedicadas seguidas justo después de que se complete el desarrollo. Este no es de ninguna manera el enfoque correcto en este caso. Puede leer más sobre esto en mis publicaciones sobre la estrategia de prueba de scrum y el ciclo de vida de prueba ágil.
Todavía podemos permitir cierta flexibilidad y elegir el programa de prueba que parezca más apropiado para el equipo de desarrollo actual y las propiedades del producto que el equipo está entregando. Sin embargo, hay dos objetivos principales que se deben lograr con esta elección:
Si se cumplen esas condiciones, el equipo se adaptará naturalmente al proceso de ajuste y el cronograma de entrega no se verá afectado por actividades de prueba prolongadas no planificadas.
Al final, lo que más importa es la liberación de sprint confiable y predecible, lo que me lleva al último punto de este blog.
Proceso de lanzamiento indefinido
Ahora, esto es algo tan obvio para cada equipo de scrum. Sin embargo, curiosamente, también suele ser uno de los procesos más subestimados.
Muy a menudo, un equipo de scrum solo dirá que el lanzamiento será después de cada sprint, pero no está respaldado por un proceso sólido. Lo que sucede entonces, en realidad, es que surgirán muchas actividades caóticas e impredecibles durante el tiempo de liberación. De repente, todas las personas están ocupadas con «tareas de lanzamiento» y nadie puede concentrarse en continuar desarrollando nuevas historias de sprint. Las métricas de Sprint están desactivadas y el lanzamiento parece una actividad aleatoria e impredecible desde la perspectiva de una tercera persona (generalmente el cliente).
Las personas están tan concentradas en la acumulación, el contenido del sprint, el desarrollo, las pruebas y, finalmente, en mostrar los resultados que se olvidan de que una vez que terminan con todo esto, el siguiente sprint ya está en curso y ya están perdiendo tiempo.
Buscando un buen momento para liberar
Entonces, ¿cuándo exactamente debería el equipo hacer el lanzamiento real a producción? Lo único importante que importa al final.
La respuesta a esa pregunta se encuentra en el proceso, suponiendo que tenga uno. Dependiendo de:
- la complejidad del contenido que el equipo está produciendo en los sprints,
- duración de un sprint,
- número de componentes afectados en el sistema
- el número de personas que usan y solicitan los cambios,
se debe establecer y seguir un proceso de liberación repetido en el futuro. Las reglas exactas del proceso pueden volver a ser flexibles en la definición. Pero como sucede con las actividades de prueba, convertirlo en un hábito sólido, predecible y programado para días concretos en el futuro lo convierte en algo en lo que confiar y consultar.
Opciones para elegir
Las posibles formas de tal proceso podrían ser cualquiera de las siguientes u otras:
- Complete la prueba de las funciones del sprint actual durante el siguiente sprint y publique el contenido al final de ese sprint (una vez que se complete la prueba). Esto significa que cada lanzamiento no tendrá ningún contenido del último sprint, pero contendrá historias de los 2 sprints anteriores.
- El último sprint antes del lanzamiento siempre se dedica a probar el contenido de los dos sprints anteriores.
- Esto no significa que se detendrá el desarrollo durante el “sprint de prueba”; solo dice que el contenido desarrollado en ese sprint de prueba aún no se incluirá en la próxima versión.
- Si ya hay suficientes actividades de prueba automatizadas, esfuércese por realizar el lanzamiento después del final de cada sprint. Entonces este debe ser un proceso muy estricto con personas dedicadas enfocándose en esos pocos días al 100%. Todavía no debería afectar al resto del equipo de desarrollo de ninguna manera.
- También puede elegir publicar una vez al mes o una vez cada N meses, principalmente si eso está bien desde la perspectiva de los usuarios finales. Esto aumentará el esfuerzo en el lado de las pruebas para cada sprint (ya que el contenido será más grande para cada versión). Pero por otro lado, supondrá una menor cantidad de actividades repetidas en el tiempo, lo que en este caso, puede tener beneficios para el equipo. Como resultado, puede permitir que el equipo cree más funciones nuevas entre los lanzamientos, a pesar de que las funciones llegarán a producción con una cadencia más lenta.
Pero como ya se dijo algunas veces antes, no es tan importante cuál de esos procesos se elegirá. Es mucho más importante qué tan bien el equipo se adherirá a ese proceso y lo convertirá en un hábito resistente.
También puede leer esta guía sobre el proceso y las prácticas de gestión de versiones.