Al crear estimados de tiempo para boletos, ¿debe incluirse el tiempo necesario para los evaluadores (QA) en un estimado de boletos? Anteriormente siempre hemos estimado sin el tiempo de los evaluadores, pero estamos hablando de incluirlo siempre. Tiene sentido para nuestro sprint actual, el último antes de un lanzamiento, ya que necesitamos saber el tiempo total que demorarán las entradas dentro de una semana.

Siempre entendí que la estimación era solo para el tiempo del desarrollador, ya que tiende a ser el recurso limitante en los equipos. Un colega dice que donde sea que hayan trabajado antes del tiempo de prueba también se ha incluido.

Para ser claros, esto es para un proceso en el que los desarrolladores escriben pruebas de unidad, integración y UI con buena cobertura.

Mi recomendación: puede incluir el tiempo de prueba en el ticket o agregar un ticket para representar la tarea de prueba en sí. Cualquier otro enfoque hace que subestimes el trabajo real que necesitas.

Si bien el tiempo del desarrollador suele ser un cuello de botella, en mi experiencia, hay muchos equipos limitados en las pruebas. Asumir que el recurso limitante es uno u otro sin evidencia, puede morderte.

Como colega, no he visto una organización exitosa que no tenga en cuenta el tiempo de prueba.

Anexo según su aclaración: incluso si los desarrolladores escriben pruebas automatizadas, en particular pruebas unitarias (las pruebas de integración funcionan mejor), no son suficientes para probar adecuadamente.

Si hay personas involucradas en el control de calidad, es necesario estimar su tiempo, de una forma u otra. Solo si decide eliminar a las personas de control de calidad de la nómina, su tiempo de trabajo se ha desvanecido efectivamente y puede eliminarlo de la estimación. Pero esto tendría efectos secundarios que son fáciles de ignorar. Y es posible que aún le falten pruebas de rendimiento, estrés, seguridad y aceptación.

Enfáticamente sí

Las pruebas son parte del proceso de desarrollo. Si su equipo realmente pasa tiempo probando el software, el tiempo dedicado a las pruebas debe ser parte de la estimación.

Si esto es ágil, incluiría el esfuerzo de prueba como parte de los puntos totales de la historia. Por ejemplo, el esfuerzo de desarrollo puede ser de 1 día y probar 1 día para que sea una historia de 2 puntos.

Depende de cuál sea su definición de hecho, pero por lo general su desarrollo completo, la aceptación del negocio y la aprobación de la prueba en la iteración. Si el DoD es solo aceptación comercial, entonces el esfuerzo de prueba no necesariamente debe incluirse en los puntos de la historia, pero aún debe rastrearse.

La estimación debe tener en cuenta todo el trabajo necesario para completar el ticket. Si la prueba es una parte requerida del boleto, entonces debe incluirse en la estimación. Si la prueba es un boleto separado, entonces no debería.

Eso, por supuesto, puede volverse borroso una vez que comience a usar puntos de historia, ya que la diferencia entre un dev-5 y un dev-8 será bastante proporcional a un dev-and-QA 5 versus un dev-and-QA 8.

Lo he visto incluyendo el trabajo del tiempo del probador. He visto historias separadas trabajar. He visto tareas separadas, cada una estimada por el grupo que las hace trabajar. Haz lo que tenga sentido para ti, después de todo el proceso está ahí para servirte, no al revés.

El hecho de que no pueda responder esto sugiere fuertemente que no sabe por qué está escribiendo estimaciones (o al menos no está de acuerdo con su colega por qué está escribiendo estimaciones). Este es un problema mayor que si las estimaciones deberían o no incluir pruebas.

Descubra, o llegue a un acuerdo, por qué está escribiendo estimaciones. Si es para predecir lo que un equipo en particular logrará en un momento en particular, entonces la respuesta simplemente depende de si ese equipo, el que está estimando, realiza la prueba o no. Si su equipo de control de calidad está separado y tiene su propia programación, entonces podrían estar interesados ​​en saber cuánto tiempo de prueba usted (los desarrolladores) cree que se necesita de ellos en un ticket determinado. Pueden ignorar sus números y poner los suyos. De cualquier manera, pueden rastrear eso por separado de las estimaciones de tiempo de desarrollo.

Por otro lado, si un equipo está haciendo todo el desarrollo, las pruebas y el control de calidad, y el propósito de las estimaciones de tiempo es predecir y planificar lo que ese equipo está haciendo en un marco de tiempo particular, entonces, por supuesto, las estimaciones de tiempo deben incluir Control de calidad, junto con cualquier otra tarea que sea necesario para ese equipo para lograr el objetivo establecido. Para el caso, si tiene que tener una reunión inicial para cada boleto, o completar un poco de papeleo al finalizar, entonces el tiempo para el administrador debe estar allí en algún lugar . No puedes simplemente ignorarlo.

Si se trata de un solo equipo pero con roles separados de "desarrolladores" y "evaluadores", eso podría significar que tiene muchas entradas en las que solo un lado de la división es capaz de trabajar, y su gráfico de Gantt (tal vez completamente hipotético) se ve exactamente como se vería la tabla para dos equipos separados. Este hecho alterará algunas metodologías más que otras, y es posible que sea mejor dividir la planificación debido a eso, pero si no lo divide, entonces debe emitir un boleto y estimar todo lo que el equipo necesita hacer o sus predicciones serán inútiles. .

Si el propósito de las estimaciones es algo más que la predicción y la planificación, por ejemplo "porque seguimos sin pensar un ritual vacío que las incluye", o "porque la administración las usa como un palo para golpearnos y sacarnos horas extra", o "porque tenemos que hacer una oferta de precio fijo y los números entran en una fórmula enorme" (gracias John Wu), entonces podría ser más difícil averiguar qué deberían incluir ;-)

Siempre calcule todo el trabajo que se necesita hacer para que una historia / función / boleto de usuario esté realmente hecha. A esto lo llamamos DoneDone .

Terminamos cuando estamos listos para la producción .

Esto incluye cualquier prueba manual y exploratoria, pero incluso pruebas de aceptación del usuario.

Un equipo ágil debería poder liberar una nueva parte del trabajo terminado en cualquier momento. Como:

El software de trabajo es la medida principal del progreso.

¿Cómo sabes si funciona, si no lo has probado? Ahora escribe que el tiempo de desarrollo es el cuello de botella de su tiempo. Como ingeniero de control de calidad, creo que la mayoría de los equipos tienen un cuello de botella en la capacidad de prueba o simplemente están tomando atajos.

Para resumir, también estimar el esfuerzo de prueba. Tenga en cuenta que esto podría influir en su velocidad . Si ha estado haciendo estimaciones relativas en puntos de historia, la prueba ya podría estar incorporada en su velocidad promedio.

Aquí hay algo muy importante: todas las estimaciones deben ir acompañadas de supuestos y exclusiones .

Esto incluye especificar lo que se incluye: solo desarrollo, diseño y desarrollo, pruebas de desarrollo y unidades, cobertura para pruebas de aceptación, construcción de infraestructura, etc.

Si proporciona un documento de estimación a un gerente de proyecto, lo convertirá en una orden de trabajo o declaración de trabajo para un cliente o (si es un proyecto interno) para el PMO . Es posible que hayan establecido fórmulas para agregar gastos generales (por ejemplo, algunos proyectos pueden agregar X% para cubrir el control de calidad, luego agregar Y% para cubrir el gobierno y la gestión de proyectos) que se establecen por contrato o por experiencia. Y no quieres contar dos veces. Por otro lado, podrían no agregarlos automáticamente.

Las prácticas difieren. Quien esté usando estos números necesitará saber qué significan los números, y usted debe ser explícito acerca de si está incluyendo el tiempo de prueba o no.

El tiempo debe incluirse en la estimación, pero no debe estimar el tiempo de los evaluadores, sino que los evaluadores deben estimar su tiempo .

No incluir el tiempo de prueba es una estimación falsa del tiempo total que llevará, pero el tiempo de desarrollador y el tiempo de prueba no son intercambiables (sobre todo porque presumiblemente trabajas en paralelo, con los probadores una iteración detrás), por lo que debes estimarlos por separado. Además, no está en condiciones de estimar el tiempo que los evaluadores necesitarán para probar cualquier cambio, solo el equipo de prueba debe hacerlo.

Encapsulamiento

Voy a abordar esto desde un punto de vista y lenguaje de desarrollo de software.

• Eres un diente pequeño en una máquina grande.
• Desde el exterior de su equipo, su sistema de tickets actúa como una interfaz / API para su equipo
• Los usuarios comerciales que usan el sistema de tickets no son desarrolladores

Desde un buen diseño de software, debe simplificar y encapsular tanto como sea posible.

Por lo tanto, para ver el proceso desde el punto de vista de los usuarios comerciales, en realidad solo se preocupan por 2 cosas.

1. ¿Cuanto costara?
2. ¿Ya terminamos?

Permitir que el usuario comercial sepa sobre el proceso interno de su equipo es una mala administración; similar a dar publicacceso al estado interno.

Si no se protege el estado interno de su equipo, se invita a otros equipos a administrar sus recursos y meterse con su estado interno.