Me hicieron esta pregunta en una entrevista y no pude encontrar la solución, así que pensé en venir aquí.
Básicamente, trabajaba principalmente como desarrollador y tenía mi propio conjunto de pruebas unitarias para las tareas que estaba terminando. Pero si yo fuera propietario de un producto o experto en scrum, ¿cómo me aseguraré de que el equipo de desarrollo haya creado suficientes pruebas unitarias o haya probado el código correctamente?
Creo que podemos realizar pruebas de aceptación o incluso considerar los errores como parte del próximo sprint. Existe otra opción de que el propietario del producto y el experto en scrum creen un conjunto de pruebas básicas durante las reuniones de sprint. Pero eso hará que la reunión de sprint se prolongue durante horas. Estas son las dos posibles ideas que podría sugerir.
¿Hay alguna otra forma en que el propietario del producto pueda garantizar la calidad?
La aplicación de la Definición de Listo (DoD) es el principal mecanismo del propietario del producto para garantizar la calidad del producto. El DoD define la calidad del proyecto. Asegurarse de que el trabajo que no llega al DoD se devuelva al Product Backlog es el control del proyecto para evitar que los defectos conocidos se escapen del Sprint.
NB: Debido a que la capacidad del equipo es finita, el Propietario del producto controla la calidad intercambiando la capacidad por elementos explícitos del trabajo pendiente y tareas implícitas asociadas con el Departamento de Defensa.
En marcos ágiles, la forma de administrar la calidad es a través de la "Definición de Listo". Esta es una definición formal de todas las puertas de calidad por las que debe pasar un incremento potencialmente entregable para que se considere realizado al final de un Sprint. Dado que Scrum requiere que el producto siempre esté en un estado potencialmente liberable al final de cada Sprint, el Departamento de Defensa también incluye pruebas de aceptación, pruebas de regresión y otros criterios de calidad para validar que el producto en sí (y no solo el incremento de trabajo actual) cumple con los criterios de calidad definidos.
Debido a que el trabajo se realiza o no se realiza al final de cada Sprint, el trabajo que no cumple con el DoD se considera "no realizado" y debe devolverse a Product Backlog para volver a priorizarlo y replanificarlo. Los elementos de la cartera de productos parcialmente completados nunca se consideran terminados y nunca se transfieren automáticamente. Este es un control clave para el marco Scrum.
Debido a que Scrum es un marco iterativo, el DoD puede evolucionar con el tiempo. El propietario del producto puede ajustar la calidad del producto trabajando con el resto del equipo Scrum para determinar el alcance y la granularidad del DoD en función de las lecciones aprendidas y la información obtenida de las retrospectivas de Sprint.
Un equipo con un DoD muy complejo o que consume mucho tiempo deberá reducir sus pronósticos de capacidad en consecuencia, ya que más capacidad del equipo se dirige a lograr que los incrementos de trabajo estén "terminados". Por otro lado, aumentar el desarrollo de funciones a expensas de un DoD adecuado puede generar una deuda tecnológica o una mayor tasa de defectos, lo que también puede reducir la velocidad del desarrollo de funciones.
NB: La velocidad de trabajo no se reduce, ya que la gestión de defectos también es trabajo.
En resumen, el propietario del producto y el equipo Scrum deben encontrar un DoD que sea suficiente pero no excesivo. Demasiada sobrecarga del proceso y el desarrollo de características sufre. Muy poco, y la calidad sufre. Es un acto de equilibrio, por lo que no existe un estándar universal para la definición de hecho.
Esta pregunta no tiene que estar orientada a la metodología ágil, sino que puede responderse de manera agnóstica porque afecta a todos los métodos, productos e industrias de la misma manera.
La respuesta es: no puede garantizar un lanzamiento libre de defectos de su producto.
Ambas palabras en cursiva implican un grado de perfección que no está disponible para nosotros.
En cambio, mitiga la amenaza de defectos a través de la inspección para llevar el nivel de defectos tanto a una cantidad como a una gravedad que se encuentran dentro de un nivel definido de especificación.
Esto significa que el organismo rector debe crear esa definición de especificación para el producto como parte de la definición del proyecto durante el inicio y significa definir qué significa inspección en función de su industria.
También significa que usted mitiga la amenaza de defectos de forma proactiva, madurando sus procesos y métodos de construcción, usando herramientas comprobadas, usando talento calificado y usando métricas para medir el desempeño. Las métricas pueden exponer una amenaza creciente de defectos incluso antes de que se detecte un defecto en el producto más adelante en el proceso.
A menudo se pasa por alto el papel fundamental que tiene un Product Owner para garantizar la calidad.
Hay una serie de factores en juego, que incluyen:
El propietario del producto contribuye a todos estos factores haciendo lo siguiente:
jitendragarg
Todd A. Jacobs