Nuestro equipo de desarrollo estima el trabajo en horas, pero no incluimos ningún tiempo de prueba en la estimación original. Por ejemplo, si los desarrolladores dicen que un artículo tardará 4 horas, se convertirá en nuestra estimación para ese artículo, pero nuestro equipo de control de calidad puede tardar una hora más en probarlo. ¿Agregas esa hora a la estimación original de 4 horas para que sean 5 horas?
Incluya la mayor cantidad de detalles posible en su respuesta en lugar de simplemente decir sí o no.
Además, no sugiera usar puntos de historia ya que esto no funcionó para nosotros.
La estimación de un artículo debe cubrir el tiempo que llevará hacerlo. Suponiendo que lo que define como hecho cubre tanto las pruebas como el desarrollo, entonces debería estar en la estimación original.
La mejor manera de asegurarse de que todo lo que debe cubrirse para alcanzar lo hecho se incluye en la estimación es asegurarse de que todos los involucrados (por ejemplo, los probadores) estén invitados a la reunión de planificación del sprint.
Una contrapregunta rápida probablemente pueda responder esto. "¿Haría la entrega al cliente después de 4 horas de desarrollo?"
Dado que no puede realizar la entrega solo después del trabajo de desarrollo, la estimación del control de calidad debe incluirse en las estimaciones originales.
Como sugirió @David, debe optar por la Definición de Listo, que incluye todas las actividades necesarias para completar el trabajo desde el inicio hasta la entrega.
Algunas cosas a considerar:
Si el control de calidad encuentra un error, los desarrolladores deben corregirlo. Entonces, es probable que el control de calidad deba volver a realizar la prueba para confirmar que se solucionó el error. Así que simplemente decir que los controles de calidad necesitan 2 horas puede ser bastante engañoso. Las pruebas impactan tanto en los desarrolladores como en los QA.
Si su recurso de control de calidad es limitado y desea estimar en unidades de tiempo, debe considerar no sobrecargar o subcargar los controles de calidad. Por ejemplo, decir que tiene 100 horas de trabajo de desarrollo y 100 horas de trabajo de control de calidad solo funciona si tiene la misma cantidad de desarrolladores que de control de calidad.
Estas complicaciones son la razón por la que mucha gente prefiere usar puntos de historia. Los puntos de la historia son una estimación de la complejidad relativa de la historia en lugar del tiempo que espera que le dedique cada disciplina (que es muy difícil de adivinar correctamente).
Las estimaciones de QA deben incluirse en las estimaciones originales, porque las actividades de QA también consumirán tiempo e impactarán el hito de finalización del proyecto.
Las estimaciones de desarrollo son para el equipo de desarrollo y las estimaciones de control de calidad son para el equipo de SQA. Incluimos tanto el tiempo de desarrollo como el de prueba en las estimaciones, pero por separado.
Si los fusionamos - - No podemos identificar las estimaciones para el desarrollo y el control de calidad por separado. - No podemos comparar las estimaciones con el tiempo real necesario para el desarrollo y el control de calidad por separado. - No podemos tener el desarrollo de hitos completo y el control de calidad completo por separado. - No podemos seguir el desarrollo y el progreso de SQA por separado.
El desarrollo y el control de calidad los realizan (en su mayoría) equipos separados, por lo que es mejor separarlos.
La estimación del equipo de desarrollo debe incluir el tiempo para realizar pruebas automatizadas. Además , se debe estimar el tiempo para un período de control de calidad de la versión . Se deben tener en cuenta los recursos adicionales en el período de control de calidad de la versión para las pruebas de experiencia del usuario.
Mi equipo ha encontrado que esto es muy útil a lo largo de múltiples proyectos. Las pruebas automatizadas, generalmente completadas a través del desarrollo basado en pruebas, detectan problemas a lo largo del ciclo normal de desarrollo. Nuestro especialista en experiencia del usuario realiza pruebas de versión con usuarios de prueba durante el período de control de calidad de la versión para descubrir cualquier cosa que no haya sido detectada en las pruebas automatizadas.
Tener períodos de lanzamiento designados para las pruebas de la experiencia del usuario también libera al equipo de desarrollo para agregar brillo a la aplicación e incorporar los aprendizajes de las pruebas de los usuarios que están dentro del alcance.
La respuesta simple es que el alcance de las tareas debe quedar claro, por ejemplo, código, prueba unitaria, prueba, control de calidad, etc., y luego sabrá dónde permitir las pruebas y todos los demás esfuerzos en sus estimaciones, y si la codificación espera incluir un elemento de prueba por parte del programador, entonces esto debe ser incluido en sus estimaciones
Incluimos pruebas que realizarán nuestros desarrolladores en nuestra estimación (por ejemplo, escribir pruebas para TDD, escribir pruebas unitarias adicionales o pruebas de funciones para nuestras pruebas de regresión nocturna).
También discutimos el tipo de prueba que realizará el equipo de control de calidad y la probabilidad de que encuentren problemas que debamos solucionar (que rastrean con varios tipos de complejidad o cosméticos). Estimamos la cantidad de tiempo de desarrollo adicional que se requerirá para respaldar o iterar con la gente de control de calidad, y lo incluimos en nuestra estimación.
Suele ser útil discutir las cosas desde la perspectiva de los probadores, ya que eso puede hacer que nos demos cuenta de que hay cierta complejidad adicional y revisemos nuestra estimación de desarrollo original.
En realidad, no importa en la planificación de sprint normal, siempre que sea coherente, es decir, utilice el clima de ayer (es decir, la velocidad) para planificar, o si realiza algún tipo de planificación de capacidad tradicional en su lugar, entonces excluiría la capacidad de prueba disponible si también excluya la prueba de la estimación.
Si está haciendo una oferta sobre un proyecto de tiempo y materiales o algo así, probablemente desee incluir el esfuerzo de prueba, a menos que sepa que los costos de prueba se cubren con algún amortiguador o algo así.
En mi opinión, la clave es centrarse en la 'Definición de Hecho', principalmente desde la perspectiva del Product Owner. Ahora el equipo (equipo interfuncional para ser más precisos) puede tener algunas (o muchas) preguntas que deben resolverse entre el equipo (recuerde que no estoy diciendo el Desarrollador o los Testers) y el PO, para que tengan una 'Definición de Terminado' común. Aquí es donde entran en escena las habilidades de un Scrum Master experimentado. Él / ella realmente puede orquestar la discusión para que ambos encuentren un terreno común. Por cierto, el lugar apropiado para tal discusión es la reunión de Planificación de Sprint.
Respuesta rápida: SI
Siempre tenga en cuenta TODO el esfuerzo que su equipo necesitará para dedicarse a una historia o trabajo, independientemente de la técnica de estimación utilizada. La forma en que realiza las pruebas, etc., debe ser parte de su definición de hecho, y sus estimaciones deben reflejar ese trabajo.
Perdón por la gramática/ortografía, estoy en el móvil -
WBW
soy las calles
Shawn
Felipe