¿Deberíamos asignar estimaciones por hora separadas para tareas de prueba además de las tareas de desarrollo?

Cuando tiene probadores dedicados, puede parecer que tiene sentido tener una tarea de prueba separada para ellos. Pero cuando lo piensas, las pruebas son realmente una actividad de equipo.

Por ejemplo, un probador puede necesitar hablar con un BA o Product Owner para comprender más sobre lo que está probando. Es posible que también necesiten hablar con los desarrolladores para comprender la nueva funcionalidad. Y, por supuesto, pueden generar errores que los desarrolladores deben corregir.

Siento que es mejor estimar las tareas como un todo, incluyendo todo lo que se necesita para llevarlas a 'terminadas'.

En resumen: lo que funcione mejor para el equipo, el proceso de desarrollo y hacer las cosas.

Profundizando desde el nivel de la historia:
la historia debe ofrecer un producto totalmente viable. Si eso incluye la prueba en su definición de hecho o criterio de aceptación, la prueba es parte de la historia.

Puede dividir las historias en tareas, si esto ayuda al desarrollo (todos acuerdan en detalle qué tareas son parte de terminar la historia). La prueba podría ser una tarea separada. También podría incluir pruebas en cada tarea. Incluso podría crear una tarea de prueba separada, vinculada a cada tarea de desarrollo. Lo que sea que ayude al equipo a hacer el producto.

Mi opinión personal es que estimar horas para tareas de prueba separadas, pertenecientes a una tarea de desarrollo, es demasiado en la mayoría de los casos. Es una gran cantidad de gastos generales, que sería mejor gastar en el trabajo real. La complejidad de la historia y sus pruebas deben reflejarse en la cantidad de puntos de la historia. Estimar horas muy específicas para las tareas de prueba no debería afectar la complejidad general o el tiempo necesario. Su situación puede necesitar esto o tal vez no. Es imposible decirlo, sin saber cómo es su equipo y su proceso. Creo que es poco probable que tenga muchos beneficios.

Depende del equipo. Algunos equipos tienen probadores dedicados donde tiene sentido tener tareas de prueba separadas, ya que puede obligar a los desarrolladores y probadores a explorar los requisitos de prueba. Otros equipos usan prácticas XP o tienen desarrollo/control de calidad donde la mayoría de las pruebas se realizan en línea con las actividades de desarrollo.

La asignación de tareas es una herramienta para ayudar al equipo a explorar la historia en términos de implementación táctica. La asignación de horas-hombre se encuentra en el extremo inferior de la escala de valor del uso de tareas y, por lo general, no es una buena razón para usar tareas, ya que es una actividad costosa (en términos de tiempo).

Creo que depende de quién sea el público objetivo.

Si la audiencia es el cliente, no creo que les importe mucho que le tome X horas desarrollar e Y horas probar, solo cuánto tiempo lleva hacerles llegar el producto.

Si la audiencia es su equipo de proyecto interno, puede ser de gran ayuda separar las estimaciones para el desarrollo y las pruebas. Si por ninguna otra razón, le brinda datos para poder refinar sus estimaciones para sprints posteriores, lo que le permite identificar más fácilmente dónde se descomponen las cosas cuando (no si) encuentra que sus estimaciones son inexactas.

TL;RD

A menos que su Definición de Listo excluya las pruebas como uno de los criterios, debe incluir las pruebas en sus estimaciones generales para el Elemento de la Lista de Producto. El marco no prescribe si trata las pruebas como una tarea implícita o una tarea explícita.

Las estimaciones deben incluir todos los aspectos de la "Definición de Terminado"

¿La estimación inicial para el desarrollo de la tarea debe INCLUIR las horas hombre estimadas para completar la historia o debemos tener estimaciones adicionales por horas en las tareas de prueba?

En Scrum, el entregable de cada Sprint es un incremento potencialmente entregable que alcanza el Objetivo del Sprint y cumple con la "Definición de Terminado". Sus estimaciones para cada elemento de la cartera de productos (o historia de usuario, si usa ese formato) siempre deben incluir todo lo necesario para cumplir con todos los elementos de la Definición de Listo, incluidas las pruebas, la documentación, la validación y cualquier otra cosa que el equipo haya acordado que se requiere. asegurar que un incremento sea realmente completo.

En general, los elementos de la definición de hecho se entienden como aspectos implícitos de cada elemento de la cartera de productos (PBI), y simplemente se integran en la estimación general de PBI en lugar de desglosarse como tareas individuales para cada elemento o historia de usuario. Sin embargo, si desglosa las pruebas para cada elemento como tareas explícitas en su Sprint Backlog, entonces ciertamente debe estimar esas tareas de la misma manera que cualquier otra tarea.

Esto realmente equivale a un problema de contabilidad. Asegurarse de que las pruebas se tengan en cuenta en la estimación general del nivel de esfuerzo para completar un elemento de la cartera de productos es una técnica de estimación más ágil que la falsa sensación de precisión que se obtiene al asignar horas exactas a las tareas de prueba propuestas, especialmente porque a menudo hay muchas de ping-pong entre las pruebas y el desarrollo en técnicas ágiles como el desarrollo basado en pruebas, pero no hay nada de malo en estimar las tareas de prueba explícitamente siempre que lo haga de manera consistente en todos los elementos de la cartera de productos.

La razón por la que la mayoría de las tiendas no hacen esto es que si va a tener en cuenta las pruebas por separado del desarrollo, también debe tener tareas y estimaciones para todos los demás elementos de la Definición de Listo. Esto generalmente conduce a una mayor sobrecarga del proceso, una falsa sensación de precisión y rara vez es más preciso que la estimación agregada para un elemento de la cartera de productos que incorpora implícitamente la definición completa de Listo.

Scrum visualiza a todo el equipo para que trabaje en conjunto en una sola historia de usuario hasta que se termine . Para mí, la definición de hecho incluye probar y garantizar que se cumplan los criterios de aceptación. Todo el equipo es responsable de hacer la historia del usuario y, por lo tanto, es probable que dedique tiempo a la historia del usuario. Por lo tanto, se debe estimar el esfuerzo de prueba.

Además, en Scrum no existe el rol de "probador" o "desarrollador". Todos entran en la categoría de miembros del equipo. Dado que un miembro del equipo (léase probador aquí) trabajará en una historia de usuario, sus esfuerzos deben estimarse y registrarse.