¿Cómo lidiar con la sobrecarga de los errores de registro de control de calidad que los PO no están interesados ​​en corregir?

Muchas veces he observado que se registran errores en historias particulares que les lleva mucho tiempo a los propietarios de productos clasificar y que no terminan siendo lo suficientemente importantes como para corregirlos. O es un comportamiento aceptable que no tendría un impacto material en el cliente o simplemente no es algo que los propietarios de productos consideren tan importante como otra cosa en la cartera de pedidos. ¿Cómo se puede enfrentar este fenómeno para que los equipos puedan seguir moviéndose?

Suena como una desconexión entre QA y PO en términos de criterios de aceptación. Ambos deben estar de acuerdo en lo que constituye "hecho".

Respuestas (3)

Esto suena como un buen tema para mencionar en la retrospectiva del equipo. Hay muchos enfoques posibles, pero el equipo debe decidir por sí mismo.

Algunas cosas que podría considerar:

  • El control de calidad muestra errores al propietario del producto antes de que los registre
  • Si el propietario del producto no considera que un error sea importante, resuélvalo como "no se solucionará".
  • Discutir en equipo los tipos de errores que tal vez no sea necesario registrar
+1. Siempre predeterminado para "preguntar al equipo". Si se resisten y quieren registrar los errores de todos modos, recuérdeles que es responsabilidad del Dueño del producto administrar el trabajo pendiente y que se debe respetar la decisión del PO. Último matiz, el equipo de desarrollo posee la calidad, por lo que si los errores son lo suficientemente importantes, están obligados a hacer todo lo posible para persuadir al PO de su importancia e inclusión en la cartera de productos.

Le sugiero que arregle todos los problemas de las nuevas historias sin tener que acudir al propietario del producto. Si constantemente crea errores y no los soluciona, esto es una señal de un problema de calidad. Lamento decirlo, pero si haces esto el tiempo suficiente, terminarás en muchos problemas.

¿No correspondería tradicionalmente al propietario del producto decidir si se trata de un error o no? En muchos de estos casos, el propietario del producto (y los ingenieros) no ven los problemas como errores en absoluto.
No necesariamente @BrianDavidBerman. Algunos equipos adoptan una política de "cero errores conocidos" y la tratan como una cuestión de ingeniería y calidad.
@RubberDuck ¿Alguna lectura sobre este tema en la comunidad Agile? Toda mi investigación/práctica ha sugerido que el propietario del producto es el guardián de lo que trabaja el equipo. Consideran las opiniones del resto del equipo, sin embargo, al final depende de ellos.
@BrianDavidBerman Sugeriría que incluya "cero defectos" en su definición de hecho ( agilealliance.org/glossary/definition-of-done ). Así es como no tiene que acudir al PO para decidir si corregir un error o no.
"Toda mi investigación/práctica ha sugerido que el propietario del producto es el guardián de lo que trabaja el equipo". -- esto es cierto en lo que se refiere a las nuevas funciones. El equipo es responsable de entregar un producto de calidad, que no necesariamente incluye la orden de compra.
@MitaKa: me gusta la idea de agregar "cero defectos" a la Definición de Hecho, sin embargo, creo que en muchos de los casos que describo, no es solo el PO el que no está de acuerdo si algo es o no un error, es todo el resto del equipo. Si de repente nuestra capacidad se llena con correcciones de errores que no han sido validadas por el PO, técnicamente podríamos estar trabajando en problemas que la empresa no considera valiosos y la gerencia podría cuestionar estas decisiones. Me pregunto si mi problema podría ser simplemente una cuestión de definir qué es un error y qué no lo es.

Desde la perspectiva del control de calidad, es muy importante que cada error se registre en algún lugar (ya sea en el backlog o en un lugar diferente). Si bien la prueba es muy poco práctica si para cada hallazgo primero necesita analizar si es lo suficientemente importante o no, eso ralentiza el proceso de prueba y corre el riesgo de perder errores esenciales (porque los confunde con errores similares con diferentes causas subyacentes).

En nuestro equipo hemos tenido bastantes discusiones con respecto a este tema, y ​​al final esto es lo que decidimos:

  1. Asegúrese de que los evaluadores tengan claro lo que esperan las partes interesadas (requisitos, cosas que están fuera del alcance, nivel de calidad, etc.)
  2. Las actividades de prueba están guiadas por una evaluación de riesgo del producto: las partes más importantes (alta probabilidad de falla o alto impacto) reciben la mayor atención (esto ya filtra muchos errores no esenciales)
  3. Cada problema se registra durante la prueba.
  4. Después de cada esfuerzo de prueba significativo, los problemas se agrupan y analizan. Los evaluadores preparan la reunión, el propietario del producto decide la prioridad (los problemas de bloqueo tienen la máxima prioridad)
  5. Los problemas de alta prioridad también obtienen una clasificación alta en la cartera de pedidos
  6. Los problemas con prioridad baja o más baja rara vez se solucionan individualmente; en cambio, se resuelven cuando se realiza un trabajo relacionado en la misma área

De esta forma, los límites entre las diferentes clases de prioridad son transparentes para todos (y pueden cambiar con el tiempo). Los evaluadores pueden registrar todos y cada uno de los errores, mientras que el propietario del producto escucha un resumen de sus hallazgos y puede dedicar su tiempo a los más importantes.