¿Quién es responsable de la calidad?

(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)




El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.

Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:

  • La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
  • La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner.
  • La calidad interna no suele poder ser verificable directamente por el Product Owner.

Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.

Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum  Master guía al Product Owner y al equipo para conseguir que:

  • El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
  • El equipo cumpla con la definición  de hecho que ha sido consensuada con el cliente.
  • El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
  • El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración.
  • Similarmente, el Scrum Master debe hacer recapacitar al Product Owner si quiere rebajar la calidad a cambio de conseguir objetivos en fechas determinadas (lo cual produciría defectos en el producto una vez entregado, ralentizaría después la velocidad del equipo y tiene el riesgo de mala imagen respecto a los consumidores/clientes/usuarios). Si finalmente es necesario hacer esto, el Scrum Master tiene que hacer que esta decisión se tome al nivel más alto posible y que sea visible. Con posterioridad a la toma de esta decisión, el Scrum Master debe ser capaz de demostrar, si es necesario, las consecuencias de haber rebajado la calidad mediante gráficos de tendencias de velocidad y defectos, así como explicar sus causas objetivas (menos testing, menos refactoring, ...) [1].

Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.

 

Enlaces relacionados

Referencias

 [1] Succeeding with Agile: Software Development Using Scrum - Mike Cohn.

 

Comments

Hola a todos,

Me ha gustado mucho el artículo pero se me plantean algunas cuestiones.

Hablando de calidad externa e interna dice Xavier que:

  • "La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner"
  • A mi me parece que el PO debería, en gran medida, poder verificar éstos aspectos dado que representa a los usuarios y para poder evaluar si lo que se le está entregando realmente aporta valor, debería tener medios para hacer sus comprobaciones al margen de que ocasionalmente se apoye en los Stakeholders para temas puntuales. ¿Estoy en lo cierto?

"La calidad interna no suele poder ser verificable directamente por el Product Owner".

Totalmente de acuerdo, pero si recurre a auditorías externas para comprobar,  por ejemplo, la calidad del código, ¿cuándo las realiza? ¿para cada entregable que recibe? ¿sólo en las release importantes? ¿no supone eso un gasto adicional que ataca directamente al ROI?

Entendiendo que se trabaja con una compañía que asume  y hace suyo lo que comporta trabajar con Scrum y el compromiso de calidad que ello implica, ¿no se supone que nos deberíamos fiar de sus controles internos de optimización de código?

Por otro lado, el Scrum Maser es un facilitador del trabajo del Equipo y el PO solucionando problemas cuando se presentan pero, por mucho que sea el responsable de la calidad en el proceso, no lo veo revisando código. ¿La calidad interna no seria por ello un aspecto propio solamente del Equipo y, en todo caso, también de las directries de trabajo de su empresa?

Disculpad si suelto alguna barbaridad pero soy novato en éstos temas y aún me quedan muchos conceptos por afianzar y dudas por aclarar.

Gracias y un saludo.

 

 

Hola Francesc,

"debería tener medios para hacer sus comprobaciones al margen de que ocasionalmente se apoye en los Stakeholders para temas puntuales. ¿Estoy en lo cierto?"

Depende :) Depende de las capacidades que tenga el Product Owner. En algunos casos será autosuficiente y en otros tendrá que recurrir a expertos como, por ejemplo, un usuario final.

"si recurre a auditorías externas para comprobar, por ejemplo, la calidad del código, ¿cuándo las realiza? ¿para cada entregable que recibe? ¿sólo en las release importantes?"

Depende :) Depende del contexto del proyecto.

"¿no supone eso un gasto adicional que ataca directamente al ROI?"

Será un gasto adicional si no se previó. Será un gasto necesario si hace falta hacerlas.

"¿La calidad interna no seria por ello un aspecto propio solamente del Equipo y, en todo caso, también de las directrices de trabajo de su empresa?"

Sí, es de lo que estamos hablando :)

Salud,
Xavier Albaladejo

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta.

Si el PO tiene que pedir una auditoria externa para verificar ciertos parámetros de calidad es porque no confía en el equipo, tu equipo son tus expertos en tecnología si confías más en la opinión de un tercero que en la de tu equipo mal asunto, quizás la próxima vez deberías plantearte contratar directamente a ese tercero o a profesionales con ese mismo nivel y te ahorras auditorias.

Otro tema puede ser que para alguna parte especifica del proyecto tanto el PO como el equipo decidan que estaría bien contar con alguna opinión experta (por ejemplo para temas de usabilidad, de optimización de un servidor de aplicaciones etc,etc). Pero el enfoque es distinto, el equipo que es responsable de la calidad decide junto con el PO que necesita ayuda para algún tema concreto, es una situación que parte de la confianza en el aspecto más delicado "reconocer tus limitaciones" y que va a permitir que el equipo crezca aprendiendo cosas nuevas y que el producto mejore. Si el PO se dedica a pedir auditorias y cosas así nunca va a conseguir tener un equipo con la suficiente confianza como para llegar a este punto y corre el grave riesgo de cargarse la motivación del equipo.

Hola Alfredo,

Efectivamente una auditoría externa puede implicar que hay una falta de confianza en el equipo, la auditoría puede ser el resultado de un problema mayor, es decir, hay una causa todavía no resuelta que ha llevado a la necesidad de la auditoría.

Por otro lado, una auditoría también puede ser parte de un proceso de aseguramiento de la calidad y alineamiento tecnológico a nivel organizativo. Por ejemplo, se puede hacer de manera sistemática en todos los proyectos o tomando muestras aleatorias de diferentes proyectos. Tendría un paralelismo a cuando una persona hace un peer review del trabajo de otra. Puede servir para alinear maneras de trabajar y a la vez para difundir maneras alternativas de hacer las cosas, tanto para el que está desarrollando el proyecto como para el que realiza la auditoría.

Salud,
Xavier Albaladejo

Tu comentario nos ayuda a enriquecer el articulo

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Este formulario es para impedir el abuso de spambots.
Image CAPTCHA
Copy the image characters keeping the upper/lower case.