Hay algo que siempre me ha molestado con Scrum. Espero poder obtener alguna idea aquí.
Con Scrum, tratamos de dividir el trabajo pendiente en segmentos verticales. Digamos las historias A y B. Se supone que estas historias están orientadas al cliente y brindan valor. Suponga aquí que tienen un valor similar para el cliente.
Ahora, digamos que, para implementar, A y B necesitan una infraestructura compartida. Así que digamos que estamos en el refinamiento de la cartera de pedidos. Si le pido al equipo de desarrollo que calcule los puntos de la historia, podrían estimarlos en 8 puntos cada uno, si se estiman por separado: A8, B8. Esto es bueno para mí como PO porque puedo mover las historias en el backlog sin romper nada.
Sin embargo, cuando pronostico, mi backlog parecerá más pesado porque, si se combinan, podrían entregarse con menos esfuerzo que la suma de las partes. Si mi equipo tiene una velocidad hipotética de 13, parecerá que no podrán entregar en 1 sprint. Si hay muchos elementos como este, será imposible tener visibilidad de una línea de tiempo más allá del sprint planificado.
Si tenemos varias historias con una misma infraestructura compartida, el backlog parecerá muy pesado y el pronóstico será imposible.
He visto 2 variantes:
Dividir el trabajo de infraestructura en una historia "técnica" separada: A3, B3, T5 Esto resuelve el proceso de estimación, pero es una porción horizontal. La infraestructura en sí no tiene valor para el cliente. Además, el backlog ahora contiene dependencias, porque las historias ya no son atómicas, lo que significa que no puedo reordenarlas sin conocer las dependencias. Sin mirar los detalles, habría elegido A y B para hacer primero, porque son de bajo esfuerzo y alto valor. Así que está volviendo a la planificación clásica de proyectos.
Estime el esfuerzo de infraestructura en uno de los pisos solamente, y estime el segundo como si el primero ya estuviera hecho: A8, B3. La desventaja aquí es que una historia parecerá más compleja que la otra, así que si no miro los detalles, me inclinaré a priorizar la historia B, porque tendrá el mismo valor para el cliente que A, con menos esfuerzo.
Entonces las preguntas son:
Los he tratado un poco de manera ad-hoc, usando una de las dos opciones anteriores y marcando las dependencias, de modo que no coloque las tareas de requisitos previos antes de las siguientes. Si lo hago, redistribuyo los puntos de la historia. Pero se ve mal para cualquier otra persona que mire la acumulación, y prefiero que la acumulación sea un artefacto útil y transparente.
(Demasiado grande para un comentario)
No estoy de acuerdo con dos de sus comentarios en el punto 1:
Parece que está bloqueando "diseñemos un sistema que funcione" (*) con "debería ser" teórico. ¿Por qué quieres aferrarte a tus cortes verticales?
Entonces sí, divídanse en A3, B3, T5 y vean cómo funciona.
Cuando haya hecho esto un par de veces, evalúelo. Su mayor 'riesgo' es hacer T5 y luego decidir que A3 y B3 no son necesarios.
(*) No es 'verdadero', ya que te tomas el esfuerzo de preguntar aquí
Este problema no es exclusivo de Scrum. Es bastante común en los métodos ágiles, que exigen la entrega frecuente de software valioso y funcional a los clientes y usuarios. He encontrado dos formas de manejar esta situación, las cuales han funcionado bien.
La primera forma sería definir la infraestructura que se necesita como parte de A y B. Luego, estime tanto A como B como si la infraestructura se creara y probara como parte de ambos. El segundo enfoque es dividir la infraestructura en un elemento dependiente que debe completarse antes de que se complete A o B, asegurando que el dimensionamiento de A y B se base en el supuesto de que la infraestructura está en su lugar.
Evitaría la solución propuesta de estimar A y B de una manera que requiera que uno se haga antes que el otro. Esto agrega una restricción innecesaria y potencialmente poco clara a la forma en que debe trabajar el equipo. Si se inicia primero el incorrecto, se subestimará significativamente.
Tengo que estar de acuerdo con el punto de Jan Doggen de que definir cada elemento de la cartera de productos en términos de valor directo para el cliente no siempre es la mejor manera de abordarlo. Algunos trabajos, como el trabajo para diseñar, construir y validar la infraestructura compartida, no tienen un valor directo para una parte interesada, pero eliminar esta dependencia compartida abre oportunidades para que el equipo de desarrollo entregue cualquier cantidad de trabajo que sea directamente valioso para las partes interesadas. manteniendo la integridad del sistema.
Me gusta pensar en cada elemento de la cartera de productos como una entidad que se puede diseñar, implementar, probar y entregar de forma independiente. Puede diseñar la infraestructura, levantarla, realizar pruebas en ella y ponerla en producción. Esto le brinda la oportunidad de tener en cuenta la configuración de la infraestructura, las pruebas de rendimiento y el ajuste de la configuración, las pruebas de seguridad. Tener la infraestructura ya instalada antes de implementar el software que la usa a menudo alivia la presión de la implementación. Teniendo en cuenta todo esto, vale la pena asegurarse de que sus opciones de infraestructura sean correctas para cumplir con los requisitos no funcionales antes de entregar el software que la utiliza.
La elección entre una dependencia técnica en su Product Backlog e incluir el trabajo en ambos Elementos de Product Backlog depende más de su contexto que de cualquier otra cosa. Cosas como la cantidad de equipos que respaldan el producto, los conocimientos técnicos del gerente de producto, las herramientas utilizadas para realizar un seguimiento de la cartera de productos, el tiempo de demora entre identificar este trabajo y comenzar este trabajo, y la presión sobre todo el equipo, todo afectaría mi decisión. De una u otra forma.
No creo que las preocupaciones sobre la pesadez del Product Backlog deban pesar en la decisión en absoluto. Después de todo, no estás haciendo un horario firme y comprometiéndote con él. Está pronosticando la cantidad de trabajo. Si está estimando, todas sus estimaciones tienen ruido. Si ha sobreestimado la cantidad de trabajo, siempre puede usar ese tiempo de manera efectiva, ya sea tomando un tiempo adicional para el refinamiento de la cartera de productos, el desarrollo de habilidades, el pago de la deuda técnica o comenzando algún otro trabajo temprano.
Este es un dilema común. El equipo debe decidir cómo quiere estimar en cada caso, pero puede estar perfectamente bien dividir la diferencia y dar a cada historia la misma estimación aunque sepa que una de ellas llevará más tiempo. Tratarlos como iguales significa que no necesita realizar un seguimiento de ninguna dependencia estricta y, aunque puede tener una velocidad ligeramente más baja en un sprint, verá un aumento en los sprints posteriores cuando complete los otros elementos. Esto es bastante razonable, especialmente porque tales situaciones tienden a ocurrir cerca del comienzo de un nuevo trabajo en el que podría esperar que la velocidad sea menor.
La velocidad y los puntos no son las únicas cosas, ni siquiera las principales, que los equipos usan para decidir qué puede incluirse en un sprint. Durante la planificación de Sprint, el equipo debe obtener una comprensión adecuada de lo que se debe hacer. En la reunión de planificación deben ser muy conscientes de que una historia necesita cierta infraestructura que aún no está instalada; pueden tener en cuenta ese hecho al decidir qué elementos pueden encajar en el sprint.
Esta es una de las razones por las que es valioso hacer su estimación y planificación cerca de cuando comienza el trabajo.
La conversación puede ser algo como:
"Sabemos que tenemos un poco de trabajo de infraestructura, ¿deberíamos agregarlo a Story X ya que parece ser el primero en el que trabajaremos en el próximo sprint? Si cambiamos de opinión sobre el orden de las historias, siempre podemos cambiar pasarlo a otra historia y volver a estimar durante la planificación".
Para responder a su pregunta: el mejor enfoque es ser consciente del problema potencial e incorporarlo en sus sesiones de planificación y perfeccionamiento.
No confunda "valor para el usuario final" con "valor del producto". No son ni fungibles ni ortogonales. El valor para el usuario final es simplemente un subconjunto mucho más pequeño del valor general que debe entregar un Producto, y restringir en exceso su Lista de Producto en función del valor para el usuario final es un conjunto muy desagradable de olores de gestión de proyectos y productos.
Estás trabajando bajo una aprensión común sobre Scrum. La guía Scrum actual tiene algunos consejos generales (pero poco para decir que es prescriptivo) sobre la forma en que se ordena el Product Backlog, excepto para decir que debe ordenarse de acuerdo con criterios específicos del producto.
En ninguna parte de la Guía de Scrum se establece que el "valor" sea el valor de cara al cliente. Incluso la sección sobre el artefacto Product Backlog simplemente dice:
El refinamiento de la cartera de productos... es una actividad continua para agregar detalles, como una descripción, orden y tamaño. Los atributos a menudo varían con el dominio del trabajo.
Si bien también dice que un producto es un vehículo para entregar valor, y otras secciones de la guía hablan sobre el Incremento (por ejemplo, el Sprint Goal cohesivo) que entrega valor, en ninguna parte exige que el valor sea únicamente para el cliente, o define qué SAFe llama " pista arquitectónica " como carente de valor.
En lugar de tratar de calzar todos los elementos de la cartera de productos en una definición artificial de valor, debe tratar el valor como una métrica agregada, o al menos como el resultado de un conjunto de controles deslizantes, para determinar si los elementos de la cartera de pedidos agregan valor a el producto que está construyendo.
El trabajo de infraestructura que es un requisito previo para generar un incremento de producto claramente agrega valor al producto, ya que no se puede generar el incremento sin él. Del mismo modo, las características que agregan valor para las partes interesadas en lugar de los clientes también tienen valor. Como ejemplo aleatorio, construir una función de manera que su departamento legal pueda patentar no tiene ningún valor para los usuarios finales, pero puede tener valor para la empresa. Excluir ese tipo de pensamiento orientado al valor de su Product Backlog es definitivamente un anti-patrón.
Piense en el "valor" como una métrica holística, pero también considérelo como una forma de identificar las prioridades de los recursos. Todos los proyectos tienen limitaciones, incluido el tiempo, el presupuesto, el alcance, la calidad y las personas. Al priorizar las actividades que brindan valor, independientemente de cómo las defina, inherentemente dirige los recursos limitados de un proyecto hacia objetivos de productos específicos.
En abstracto, tal vez una empresa ganaría más dinero a largo plazo al ampliar un widget. Por otro lado, tal vez la empresa pueda obtener más valor a corto plazo con sus recursos limitados al reducir un therblig. ¿Cuál es un mejor uso de los recursos limitados del proyecto? La métrica de valor agregado incorporada por Product Backlog responde esa pregunta para el Equipo Scrum, ese Producto en particular y los objetivos comerciales de las partes interesadas.
No hay respuestas únicas para este tipo de preguntas, razón por la cual Scrum no es preceptivo al respecto. En cambio, el marco proporciona alguna orientación, implica estrictamente que se debe consultar a las partes interesadas y luego dice explícitamente que la decisión final es competencia exclusiva del propietario del producto. En resumen, depende del Product Owner definir cómo se debe aplicar el "valor" dentro de un proyecto determinado, con la intención de maximizar el valor del producto y dirigir indirectamente las asignaciones de recursos del proyecto.
"¿De qué sirven todos esos bloques de hormigón en la base de las paredes de mi casa? Están sentados directamente sobre la tierra, no son bonitos, y nunca los miro... ¿de qué 'valor' son para ¿a mí?"
No piensas en estas cosas hasta que empiezan a aparecer grietas en el panel de yeso... entonces tienes un problema bastante costoso con el que lidiar.
Recomiendo separar estas tareas de "infraestructura" compartidas como una historia separada. Luego, de alguna manera que sea clara para cualquiera que esté mirando las métricas, vincule estas historias con todas las demás historias que dependen de ellas y también aclare cómo dependen de ellas. ¿Es este un requisito previo? ¿Un correquisito? ¿Es una funcionalidad compartida pero visible para el usuario?
La documentación de estas dependencias es extremadamente importante: debe asegurarse de identificar cada una de esas dependencias. En el texto de la "historia compartida", enumere todas las historias que la comparten y explique brevemente por qué. Asimismo, en el texto de las "historias compartidas", enumere todo lo que se comparte. Debe tener mucho cuidado con esto para que el lector de cada historia comprenda completamente la imagen total, especialmente cuando llega el momento de desarrollar la "historia compartida" en un plan de implementación.
Finalmente, podría darse el caso de que el material compartido deba anticipar necesidades futuras. Debe explorar eso con mucho cuidado y deliberadamente en la descripción de la(s) historia(s) compartida(s). Considere si esta funcionalidad anticipada debe implementarse ahora o simplemente "aplicarse".
En mi opinión, una buena "historia" debe describir con precisión una próxima unidad de trabajo desde un punto de vista significativo, de modo que un lector objetivo pueda tener una posibilidad razonable de evaluarla y planificarla basándose únicamente en lo que contiene la historia. Y, como se señaló, debería mencionar explícitamente cada dependencia o impacto potencial en la cadena lateral.
Daniel
Tomas Owens