¿Quién pone a prueba qué criterios para las epopeyas?

Hacer un esfuerzo para escribir historias independientes más pequeñas.

...historias adicionales que no le interesan ni entiende.

No escriba historias que el PO no entienda. Si es para conveniencia de los desarrolladores, no es una historia. Es solo una tarea técnica. Esfuércese más en escribir historias más pequeñas que el PO entienda. Vea la discusión anterior en PMSE aquí sobre cómo dividir historias más grandes.

Por cierto, no es que el Product Owner se esfuerce solo en escribir historias y criterios de aceptación. En las reuniones de refinamiento de la cartera de pedidos, el equipo de desarrollo debe colaborar con el propietario del producto para dividir las historias y escribir los criterios de aceptación.

... conjuntos de pruebas unitarias para cosas que aún no tienen una interfaz.

Las pruebas unitarias son para la productividad del desarrollador. Pueden reducir la cantidad de pruebas de regresión que debe realizar el equipo de control de calidad. Sin embargo, no sustituyen a QA y PO haciendo pruebas de aceptación desde el punto de vista del usuario final. Las historias deben ser cortes verticales (con un front-end y un back-end a juego).

Así que mi pregunta es: ¿ves algo intrínsecamente malo en esto?

Sí. Su equipo parece estar agobiado por el pensamiento en cascada. Esto no es inusual para los equipos que intentan hacer la transición de cascada a ágil. Trate de obtener ayuda (usando recursos en línea o un mentor) para dividir las historias verticalmente. Su Gerente de Ingeniería parece tener los instintos correctos. ¡Eso es un gran positivo!

¿Cómo abordas las pruebas de epic, etc.?

tu no El equipo debe esforzarse por escribir historias independientes más pequeñas que la OP pueda entender y probar.

TL;RD

¿Quién pone a prueba qué criterios para las epopeyas?

Las epopeyas y los temas generalmente no se pueden probar, por lo que la respuesta es realmente "nadie". En su lugar, todo el Equipo Scrum debe descomponer estos elementos demasiado grandes durante el Refinamiento del Backlog o la Planificación de Sprint hasta que sean historias que contengan criterios comprobables que se puedan medir.

Todo el Equipo Scrum, que incluye explícitamente al Propietario del Producto, debe colaborar en la definición de historias de usuario procesables que sean comprobables y demostrables . Su proceso actual no fomenta la colaboración suficiente para que esto suceda.

Además, su proceso actual hace que el equipo pierda oportunidades de colaborar con el propietario del producto para negociar detalles de implementación que agreguen valor, reduzcan los costos del proyecto o conduzcan a una mayor sostenibilidad. Si bien el propietario del producto no debería tener que preocuparse por los detalles a nivel de código, comprender las compensaciones involucradas en diferentes implementaciones puede ayudar a todo el equipo a garantizar que se construya lo correcto y que las oportunidades para crear un incremento potencialmente entregable sean aumentado a través de debates abiertos sobre las características mínimas viables y los principios de YAGNI .

Las épicas y los temas nunca, jamás, deben salir de la Lista de Producto y entrar en la Lista de Sprint. Hacerlo es un "olor a proyecto" muy fuerte que indica un problema fundamental con la implementación del proceso Scrum del equipo.

Tareas frente a historias dependientes

Cuentos

Las historias y las tareas son dos cosas diferentes. Una historia de usuario tiene un formato que se espera que actúe como marcador de posición que define una función, un punto de vista que representa al beneficiario de la función y un contexto. Las variaciones del formato Connextra son lo que la gente piensa con más frecuencia:

Como [rol o "consumidor de valor"],
quiero [característica o funcionalidad]
para que [se beneficie dentro de algún contexto].

Una historia es un marcador de posición conversacional para permitir la colaboración y no pretende ser una especificación completa. Las historias generalmente se estiman en puntos de la historia (p. ej., secuencia de Fibonacci modificada, tallas de camisetas, etc.).

Las historias generalmente viven en la Lista de Producto, porque mientras se adhieren al mnemotécnico INVEST , representan valor para el proyecto y características potencialmente entregables.

Tareas

Por otro lado, una tarea es un elemento de la lista de verificación que ayuda al equipo a realizar un seguimiento de su progreso hacia la finalización de la historia. Una historia debe tener tareas, pero una historia (como regla general) no debe tener historias dependientes.

Las tareas a menudo residen en el Sprint Backlog, en lugar del Product Backlog, porque en realidad son detalles de implementación o hitos técnicos en lugar de historias que deben cumplir estrictamente con los criterios de INVEST. Sin embargo, deben ser pequeños y comprobables, por lo que ciertamente hay un poco de superposición.

Las tareas pueden ser puntuales, pero a menudo se estiman en horas ideales en lugar de niveles de esfuerzo. Por ejemplo, una historia como:

Como cliente bancario
, quiero poder usar cualquier cajero automático sin cargos
para tener acceso inmediato a mi dinero en cualquier lugar.

debe dividirse en tareas discretas y medibles durante la planificación de Sprint. Las tareas para esta historia, ya sea que estén en el reverso de una tarjeta de historia, elementos en el Sprint Backlog, filas en una hoja de cálculo o contenidas en sus propias tarjetas de índice, podrían verse así:

• ☑ Agregue una columna de base de datos para rastrear la membresía de la red de cajeros automáticos. (2 horas)
• ☑ Agregue una columna de base de datos para realizar un seguimiento de las tarifas asociadas con los retiros de cajeros automáticos de redes extranjeras. (16 horas)
• ☐ Agregue devoluciones de llamadas modelo para reembolsar a los clientes las tarifas de los cajeros automáticos atribuibles a retiros en cajeros automáticos extranjeros. (8 horas)

El equipo puede agregar, eliminar o modificar tareas a lo largo del Sprint a medida que se aprenden cosas o se descubren dependencias o detalles de implementación. El Sprint Backlog pertenece al Equipo de desarrollo, no al Product Owner, por lo que el contenido del Backlog del equipo refleja el trabajo que el Equipo de desarrollo debe realizar para implementar la historia de usuario del Product Backlog.

Colaboración

Si bien el Product Backlog pertenece al Product Owner y el Sprint Backlog pertenece al equipo, es útil asegurarse de que ambos artefactos sean visibles para todos en la organización para fomentar la colaboración.

Un Product Owner que no puede ver el nivel de esfuerzo o las horas involucradas en las tareas relacionadas con la historia tiene una visibilidad insuficiente de los costos reales de una historia determinada, y el equipo pierde valiosas oportunidades para colaborar en los detalles de implementación que son negociables . Por ejemplo, durante un Sprint puede resultar que el Propietario del producto no cubra todas las tarifas de todos los bancos; la regla 80/20 significa que tal vez el equipo pueda concentrarse en codificar valores para los tres bancos locales que generan la mayor cantidad de quejas, en lugar de tener que diseñar una solución más flexible que se aplicaría a todos los bancos en todas partes.

Pruebas de unidades/características y demostraciones de revisión de sprints

Las epopeyas no son comprobables o (generalmente) demostrables. Los temas tampoco. Eso los hace inadecuados para Sprints; solo deben usarse para la planificación a largo plazo y descomponerse según sea necesario durante el Refinamiento del Backlog o la Planificación de Sprint.

Todas las historias que se adhieren a los criterios de INVEST son intrínsecamente comprobables. En mi experiencia personal, las historias generalmente deben estar impulsadas por pruebas de función o integración, y las tareas deben estar impulsadas por pruebas unitarias. Ciertamente, hay todo tipo de advertencias y excepciones a esta regla general, pero seguir este consejo ayuda de muchas maneras, entre ellas:

1. Las pruebas de funciones (como las pruebas automáticas del navegador) muestran la función desde un punto de vista visible para el usuario e incluso pueden reemplazar las pruebas de aceptación del usuario en muchas situaciones.
2. Las pruebas de características generan confianza con las partes interesadas y, a menudo, demuestran que se creó Right Thing™.
3. Las pruebas unitarias son para el equipo de desarrollo y ayudan a impulsar el diseño y evitar regresiones. Por lo general, no son interesantes como demostraciones de Sprint Review, pero son los elementos más importantes desde el punto de vista del desarrollo sostenible.

4. Este estilo que divide TDD y ATDD según las líneas de funciones frente a tareas ayuda a mantener la pirámide de pruebas , con algunas pruebas lentas de alto nivel respaldadas por una capa base de pruebas unitarias ultrarrápidas. Por ejemplo:

   

Como siempre, habrá excepciones y advertencias, pero como regla general, he encontrado que lo anterior es una práctica razonablemente sólida. YMMV.

Una respuesta más corta que las otras epopeyas:

Sí, hay problemas con este enfoque. Si bien funciona siempre que todos estén contentos, el riesgo se pierde de detalle en los requisitos.

Si su solución general se ha vuelto tan complicada que los cambios 'simples' (según lo considerado por el PO) son considerados 'épicos' por los ingenieros, el PO no comprenderá el impacto de los cambios y/o los retrasos y es posible que los ingenieros no implementen con el PO 'realmente quiere'

Creo que es un desafío legítimo para las metodologías ágiles preguntar cómo manejar estos sistemas más grandes de múltiples capas, donde, por cualquier motivo, los pequeños cambios en lo que ve el usuario pueden implicar grandes cambios 'detrás de escena' en las capas de servicios/bases de datos, etc. El enfoque de segmento de ofrecer una funcionalidad discreta puede, de hecho, empujarlo a esta posición, donde en lugar de un requisito para una interfaz flexible genérica para un nivel inferior, puede terminar con una multitud de mini interfaces inflexibles.

Me gustaría contrarrestar este problema escribiendo un metarrequisito/historia para sus niveles inferiores para recuperar esa flexibilidad y admitir cambios 'simples' en la funcionalidad del usuario sin necesidad de cambiar la funcionalidad base.

Es posible que sus niveles inferiores incluso necesiten dividirse en su propio producto con su propia orden de compra