Estamos trabajando en un equipo de desarrollo de pila completa compuesto por tres gremios (backend, frontend, control de calidad), por lo que como equipo compartimos un solo tablero de sprint.
Las historias de usuarios que llevamos a nuestros sprints están escritas de manera que pueden requerir el trabajo de al menos uno o varios gremios.
Hasta ahora, la historia recibió una estimación única como una composición de votos para todos los gremios involucrados. Pero de esta manera no podemos decir cuán pesada será la historia para cada gremio involucrado, lo que nos causa complicaciones en las reuniones de planificación de sprints y luego en los sprints.
Imagina que quieres maximizar la efectividad del equipo minimizando los tiempos de inactividad de cada gremio. Debido a que (no todas, lo sé) las historias de usuario pueden ser trabajadas en paralelo por varios gremios, puede hacerlo seleccionando dichas historias para sprint donde el resumen de las estimaciones para cada gremio brinde la capacidad más cercana de ese gremio. Por supuesto, no debes olvidarte de contar con dependencias entre historias.
¿Está bien que la historia de un solo usuario tenga estimaciones para cada uno de los gremios involucrados? Y si es así, ¿Jira (nube) es capaz de lidiar con eso? ¿Alguien tiene alguna experiencia personal?
También pensamos en estimar solo las subtareas, no la historia del usuario en sí, pero lo rechazamos porque esto inflaría la estimación de manera irrazonable.
Imagine una sola historia con el trabajo requerido por los tres gremios. En refinamiento, la historia recibe las siguientes estimaciones (3 SP: backend, 1 SP: frontend, 2 SP: QA). Los gremios acuerdan una estimación única de 5 SP y le dan esto a la historia del usuario. Las subtareas para cada gremio se dejan sin estimar (con estimación cero).
Por el contrario, cuando la historia en sí no recibiría ninguna estimación (cero), pero las subtareas para cada gremio recibirían sus respectivas estimaciones. Esto daría un recuento de SP irrazonablemente más alto (aquí 6 SP en lugar de 5 SP en el primer caso), porque tendría que sumar todos los SP para cada subtarea.
Imagina que quieres maximizar la efectividad del equipo minimizando los tiempos de inactividad de cada gremio.
Tratar de obtener más trabajo de un equipo minimizando el tiempo de inactividad se denomina trampa de utilización de recursos. Aquí hay un buen video que muestra cómo minimizar el tiempo de inactividad en realidad no aumenta la producción del equipo.
El objetivo de un sprint no debe ser que todos estén ocupados todo el tiempo, sino la cantidad de trabajo que se entrega con buena calidad.
La optimización de la cantidad de trabajo que se puede entregar comienza con saber cuánto trabajo puede completar el equipo en su conjunto dentro del plazo de un sprint. Y como estamos mirando al equipo como un todo, el mayor valor está en una sola estimación de todo el equipo.
Hay un punto en el que las estimaciones por disciplina pueden ser útiles, y luego las estimaciones tradicionales en horas son las más útiles. Eso es durante la planificación, cuando hay una especialización bastante fuerte dentro del equipo, para asegurar que el trabajo que se está planificando no sobrecargue demasiado una disciplina.
No se espera que estas estimaciones tengan un valor duradero, por lo que puede anotarlas en una hoja de papel durante la sesión de planificación o, si está acostumbrado a estimar antes, incluir un comentario en el ticket.
En esta situación, primero planificaría las historias de acuerdo con la capacidad de todo el equipo para entregar el trabajo. Por lo general, esto se basará en su historial anterior, como lo indica la velocidad que alcanzaron en los sprints anteriores. Después de que el equipo haya indicado que se sienten bastante seguros de que pueden completar por completo el trabajo que está sobre la mesa, pero que no pueden completar otro del trabajo pendiente, haría una verificación cruzada comparando la disponibilidad esperada de los miembros del equipo con la estimaciones por disciplina para garantizar que la carga no esté demasiado sesgada. A medida que el equipo madure, es posible que observe que comienzan a quejarse antes en la planificación acerca de una carga sesgada. En cualquier caso, cuando la carga está sesgada, se puede negociar con el propietario del producto para intercambiar algo de trabajo para nivelar más el trabajo (y si tiene suerte, asumir más trabajo).
Usar términos como "gremio" me hace pensar que estás organizado como algo similar al modelo de Spotify. Sin embargo, lo que describe como un "gremio" no parece ser consistente con eso. En el modelo de Spotify, el trabajo lo realiza un equipo multifuncional, al que se refieren como "escuadrón". Un gremio es una organización de escuadrones cruzados (y también de tribus cruzadas) que trabaja en un tipo particular de problema transversal para difundir el conocimiento en toda la organización.
Por lo general, en cualquiera de los métodos ágiles, desea equipos multifuncionales que asuman el trabajo. Esto significa que el equipo tiene todas las habilidades necesarias para llevar un trabajo arbitrario desde su estado inicial a un estado final definido sin salir del equipo. No siempre se puede lograr, puede haber expertos en la materia a los que el equipo necesite recurrir para algún trabajo, pero es un estado deseado.
Si tuviera que estructurar su trabajo de esta manera, el equipo podría estimar el esfuerzo para entregar todo el trabajo. Idealmente, no habría dependencias fuera del equipo. Si hubiera una dependencia, eso se puede considerar en la estimación, pero sospecho que tendría un impacto mucho mayor en la planificación del trabajo que en la estimación del trabajo.
La estructura de equipo interfuncional probablemente también conduciría a una menor resistencia de las herramientas que está utilizando, siempre que esté configurado para usarlas de una manera diseñada para admitir métodos ágiles de desarrollo de software.
meridiano
Bart van Ingen Schenau
Bart van Ingen Schenau