TL;DR

Ninguna de las opciones indicadas es verdaderamente ágil. Está haciendo un mal uso de los puntos en un intento de representar el progreso o de "responsabilizar a las personas". Ninguno es apropiado dentro del marco Scrum.

Los puntos son una herramienta de estimación. Solo son significativos en conjunto y se necesitan principalmente para estimar la capacidad del equipo durante la planificación de Sprint. Usarlos como una métrica de productividad es engañoso, y el mal uso continuo del sistema de puntos de la historia eventualmente dañará tanto al equipo como al proyecto.

Los puntos no son recompensas

De esta forma el equipo consigue algunos puntos en ambos sprints.

En Scrum, una historia se hace o no se hace; nunca se hace parcialmente. Ciertamente, puede manipular el sistema descomponiendo historias artificialmente para que pueda "ganar" puntos en un Sprint al completar ciertas historias, incluso cuando la función subyacente real no está completa, pero esto no tiene ningún propósito práctico más que inflar la velocidad. . La velocidad inflada finalmente sesgará sus estimaciones, dañará al equipo y dañará su proyecto. No hagas eso.

Los puntos tampoco son recompensas. No son piruletas que regalas por un trabajo bien hecho; son simplemente una métrica de trabajo-esfuerzo. Específicamente, puntos de la historia:

1. Se convierten en una métrica de velocidad agregando sobre una ventana histórica, rastreando la capacidad de trabajo del equipo a lo largo del tiempo.
2. Se utilizan como un control de cordura para determinar si una historia puede ofrecer el valor previsto en una sola iteración.

Puntos Medida Capacidad

Los puntos son tanto una herramienta de estimación como un medio para rastrear la capacidad del equipo a lo largo del tiempo. Al estimar, los puntos de la historia le dicen:

1. Cuánto esfuerzo cree el equipo que requerirá una historia.
2. Si la historia (en su totalidad) puede encajar o no dentro de la iteración actual.
3. Si el equipo debe aceptar la historia en el sprint tal cual, o si el equipo necesita trabajar con el Product Owner para refinar, clarificar, descomponer, descartar o redefinir el alcance de la historia para lograr el Sprint Goal actual.

Los puntos también actúan como un indicador de la capacidad del equipo a lo largo del tiempo. Ganar puntos no agrega valor al proyecto, pero poder decir que el equipo generalmente puede completar un promedio de 12 a 16 puntos en una iteración típica ayuda al equipo a estimar su capacidad para aceptar historias durante la Planificación de Sprint. Esto ayuda al equipo a evitar compromisos excesivos, evita que el equipo fracase al crear una carga de trabajo insostenible y evita planificar un sprint que no cumplirá con el Sprint Goal establecido para la iteración.

Las historias deben caber dentro de un Sprint

Si sus historias no caben en un solo sprint, entonces tiene una epopeya que debe descomponerse o la duración de su sprint no se optimizó para su proyecto. Siempre hay una compensación involucrada en la determinación de la duración óptima del sprint para un proyecto, pero el desafío de escribir historias que se ajusten a un cuadro de tiempo finito sigue siendo un desafío constante.

En Scrum, una historia debe ser una porción vertical de funcionalidad completa que involucre a todo el equipo multifuncional. Las pruebas nunca son una historia aparte; más bien, es una tarea integral requerida para garantizar que una característica determinada cumpla con la "definición de hecho" formal definida por el proyecto.

Las historias que se espera que se extiendan más allá del final de una iteración indican un problema de proceso que debe solucionarse durante la preparación del trabajo pendiente o la planificación del Sprint. Del mismo modo, las historias que no cumplen con la definición de hecho también son problemas de proceso que el equipo necesita abordar con urgencia.

Al mirar historias problemáticas, el mejor consejo es utilizar los principios INVEST y, en particular:

Las historias entregan valor

Si el control de calidad es una actividad que se debe realizar para entregar, entonces no se puede dividir. ¿Tuviste una reunión de "definición de hecho" ? ¿"Terminado" incluye control de calidad?

Si su historia no ofrece valor, no es una historia.

Las historias son pequeñas

Todas las historias deben tener menos de un sprint de duración para ser planificadas. Divida su historia entregando un subconjunto de las características (menos valor, pero aún algo de valor).

La opción 2 solo parece válida si ve las pruebas como un servicio y no como una responsabilidad del equipo. Si ese es el caso, me preguntaría qué tan ágil es el equipo y si realmente necesita comprimir 2 equipos separados (desarrollo y control de calidad) en un solo sprint. Si su objetivo es ser ágil, podría valer la pena no distinguir entre desarrollo y prueba y considerar una historia como "terminada" cuando se prueba correctamente. De esa manera, terminará estimando el trabajo general que se debe realizar como equipo, y no solo las subpartes.

Muy bien, por favor no me disparen, pero argumentaré en contra de lo que la mayoría de la gente recomienda aquí, y es dividir ciertas actividades de prueba en sus propias historias. Para que quede claro, con las actividades de prueba me refiero específicamente a la creación de casos de prueba automatizados. Las pruebas manuales/exploratorias son una ventaja.

Comencemos con alguna teoría para la cual usaré mi referencia para estrategias de prueba (microservicio) . Creo que todos estaremos de acuerdo en que la pirámide de prueba tiene sentido, que habrá MUCHAS más pruebas unitarias que pruebas de componentes (automatizadas). , y aún menos pruebas (automatizadas) de extremo a extremo. Dejemos de lado por un momento quién hace qué... Normalmente observo el siguiente patrón en Agile/Scrum/lo que sea:

• Una característica se compone de varias historias (promedio 3-5)
• Cada historia suele ser un producto individual que se puede demostrar y que (con suerte) proporciona algún valor al usuario final.
• Cada historia incluye el código fuente, pruebas unitarias, posiblemente algunas pruebas de integración (consulte la definición de pruebas de integración aquí ), documentación, etc. Aquí no se discute que este tipo de pruebas deben ser parte de una historia, ya que estos tipos de pruebas deben ser escrito por el implementador de la historia de todos modos.
• Para cada característica, solo hay un puñado de pruebas E2E escritas, y esas pruebas E2E generalmente ni siquiera prueban cada historia individualmente, sino que prueban las contribuciones de varias historias en un caso de prueba.
• Es difícil escribir pruebas E2E mientras la funcionalidad bajo prueba aún no está completamente disponible en un entorno DEV o TEST.
• Una observación relacionada es que las herramientas utilizadas para las pruebas unitarias y de integración suelen ser diferentes de las utilizadas para las pruebas E2E.
• Debido a las diferentes herramientas, y también por razones históricas, incluso en los días de Agile en todas partes, persiste la especialización en desarrolladores y probadores/ingenieros de control de calidad.

La pregunta ahora es cómo manejar las pruebas E2E: ¿Incluirlas en cada historia o crear historias separadas? En mi opinión, cuando tomo en consideración todas las influencias enumeradas anteriormente, la conclusión es dividirlas. En mis proyectos, normalmente terminamos agregando una historia de prueba de componente/E2E a cada característica. La creación de casos de prueba generalmente completa un sprint después de que se completa la implementación de la última historia. Las funciones no se pueden configurar como completadas a menos que la historia de prueba E2E asociada esté completa, un mecanismo de control limpio y simple.

Argumentaré que esto no viola el espíritu de entregar historias, ya que cada historia aún es completamente demostrable y viene con un conjunto completo de pruebas unitarias y de integración y, por lo tanto, se puede asumir que es de alta calidad. Con la división en roles de desarrollador y evaluador, esta ha demostrado ser la forma más eficiente y sistemática para mí. De lo contrario, las actividades de creación de pruebas de E2E "retrasarán" constantemente la finalización de historias individuales, especialmente de aquellas para las que el trabajo de "desarrollo" se completó cerca del final de un sprint.

Ahora, en un mundo ideal, probablemente no habría especialización en desarrollador y evaluador/ingeniero de control de calidad. Entonces pude ver que las pruebas de componentes y E2E se podían incluir en cada historia (aún sujetas a ineficiencias debido a la falta de coincidencia entre las historias detalladas y las pruebas de componentes/E2E detalladas). Pero en las organizaciones en las que he trabajado, ya era bastante difícil establecer una mentalidad ágil, para no depurar el concepto de funciones dedicadas de probador/control de calidad.

Tal vez no sea el enfoque más puro, pero sí el más práctico y factible que se me ocurrió.

Tenga cuidado al dividir historias

Si se encuentra dividiendo una historia de usuario, pregúntese "¿Esta historia que estoy creando agrega valor por sí misma?". Si la respuesta es no, entonces debería ser una tarea como parte de una historia de usuario más grande.

La respuesta correcta depende totalmente de sus objetivos.

Si el objetivo es cumplir con los requisitos de scrum: no debe dividir la historia en, llamémoslo tareas, ya que no habrá un valor dentro de cada una de ellas.

Sin embargo, si ve una opción para aumentar la transparencia y la previsibilidad dentro de su proceso de desarrollo: dividir las tareas en pequeños elementos sólidos le brindará mucha información (por ejemplo, qué parte de su canal de entrega es un cuello de botella, etc.)

Aquí hay algunos pensamientos más abstractos: (opiniones)

No dejes que los "puntos" se interpongan: los puntos son un concepto muy abstracto: ¿quién no quiere ganar más? La búsqueda de ellos puede distraer la atención de lo que realmente está tratando de lograr. Por esta razón no los uso.

Las historias de "usuario" solo llegan hasta cierto punto: muchas de las cosas que se deben hacer para construir un sistema de software nunca son explícitamente visibles para el usuario. Muchas de estas cosas se cruzan con muchas "historias o actividades de usuarios".

Los usuarios no son programadores, y sus "historias" no pueden informar completamente a los programadores: se suben al automóvil y lo conducen, pero nunca levantan el capó y no saben realmente a qué está conectada la palanca de cambios. Nunca son conscientes de lo que se debe lograr para que puedan conducir con seguridad por la carretera. Tienen ideas de lo que se necesita para construir un automóvil, pero en realidad no lo saben. "Y, ¿por qué deberían hacerlo? ¡Son conductores, no mecánicos de automóviles!"

Las "Historias de usuarios" son fundamentalmente [en mi humilde opinión...] un dispositivo de comunicación : te mantienen firmemente en contacto con lo que el usuario verá y sabes que lo que estás produciendo será realmente útil para ellos, y le brindan a ambas partes una marco de referencia común que no exige "conocimientos de programación". Todo esto es muy bueno!! ... ¡¡Muy valioso!! ... Pero hay más que el equipo debe generar por sí mismo, abordando esos temas que los "usuarios" desconocen pero que son fundamentales para darles lo que requieren. Como gerente de proyecto y como equipo de diseño, las "historias de usuario" son entradas. No son planes de implementación, pero ayudan a impulsar esos planes.

"Scrum es [en mi humilde opinión...] una metáfora: una muy, muy útil. Acéptelo por lo que ofrece y sepa cuándo dejarlo ir. No es una religión, y nunca tuvo la intención de serlo. Es es un proceso valioso y una excelente forma de pensar, en la medida en que va. No escribirá su plan de implementación por usted, ni debería (por supuesto...) esperar que lo haga.