Home > Desarrollo, Ing. Software > La deuda técnica como medida de calidad del software ¿ es negociable la calidad ?

La deuda técnica como medida de calidad del software ¿ es negociable la calidad ?

No hace mucho tiempo se iniciaba una discusión en un grupo de LinkedIn sobre si la calidad en un proyecto software podía ser negociable o no. Aunque se vertieron gran variedad de opiniones, la principal conclusión que saqué era que había muchas interpretaciones del concepto de calidad aplicado al software. Así que, sobre si encima dicha calidad es negociable o no, ya os podéis imaginar que no saqué nada en claro.

Y eso me ha animado a escribir este artículo para expresar mi punto de vista sobre la calidad, cómo medirla, y si es negociable o no.

¿ Qué es la calidad del software ? ¿ Cómo se puede medir ?
Existen sistemas de control de calidad que se han aplicado exitosamente en otras industrias y se han intentado aplicar al mundo de desarrollo software. Buena parte de ellas se basan en las líneas de código (LoC) como una medida del trabajo realizado por los desarrolladores, y usan métricas como cantidad de defectos introducidos por líneas de código.

Basándose en estas métricas, el sistema define qué acciones se deben tomar en cada instante y cómo llevarlas a cabo. Por ejemplo, se define si se debe realizar una revisión de código (Peer Review) básandose en la cantidad de líneas de código afectadas por dicho cambio. Y de acuerdo a dicha cantidad de LoC, se define la duración y la cantidad de líneas de código que deben revisarse en cada sesión, así como la cantidad de defectos a encontrar. No, no estoy de coña. Desgraciadamente.

He podido presenciar como, ante estas imposiciones, hay desarrolladores que recurren a prácticas como eliminar comentarios que habían añadido para facilitar la comprensión del código con el único fin de que la cantidad de líneas a añadir no llegase al mínimo necesario para convocar una revisión, que retrasararía inevitablemente la publicación del fix dos o tres días mas. O cosas como añadir bugs estúpidos y fácilmente localizables para que se identifiquen en la revisión y garantizar así que se cumplan los objetivos de defectos encontrados por líneas de código.

Otros sistemas mas modernos, ante la dificultad para evaluar objetivamente la calidad de un desarrollo software, optan por definir y monitorizar los procesos de desarrollo del software, en lugar del software en sí. Ya es un avance, puesto que reconocen que un grupo de desarrollo de software no es un cadena de producción de tornillos.

Sin embargo, no hay que perder de vista el objetivo básico del software: el software se desarrolla ante la necesidad de un cliente, ya sea un cliente real que realiza un encargo, otro departamento de la empresa o, en el caso de Scrum, el Product Owner. Por lo tanto, parece lógico que sea el cliente el que defina la calidad que debe tener el producto, ya que su percepción de calidad puede ser muy distinta de la que tenga el equipo de desarrollo.

Y es que, en efecto, el cliente debería definir cómo resolver el compromiso entre funcionalidad que desea recibir, la calidad que desea percibir, y los plazos en los que los desea tener. Dicho compromiso debería reflejarse en los requisitos o historias de usuario. Por lo tanto, no es que este aspecto de la calidad sea negociable, sino que debe ser definida por el cliente. En este caso, la única métrica de calidad es el grado de cumplimiento de los requisitos. Y no es fácilmente generalizable porque depende del cliente.

Por otra parte, es normal pensar que el equipo de desarrollo tiene un conocimiento del funcionamiento interno del sistema que no tiene por qué tener el cliente. En este caso, se podría definir la calidad interna como la habilidad del equipo de desarrollo para no introducir deuda técnica en el sistema. Es decir, el sistema goza de buena calidad si no se introduce deuda técnica. Por el contrario, la introducción de deuda técnica implica el empeoramiento de la calidad interna. Nadie mejor que el propio equipo para determinar si se está introduciendo deuda técnica o no.

La introducción de deuda técnica puede tener consecuencias tan graves como:

  • aumento progresivo del tiempo necesario para proporcionar fixes ante defectos detectados o adición de nueva
    funcionalidad.
  • aumento del riesgo de introducir nuevos defectos al proporcionar fixes para defectos detectados o adición de nueva
    funcionalidad.
  • aumento de la difcultad para detectar defectos.

Pero, sin embargo, sigue siendo el cliente quien manda. El equipo de desarrollo debe informar al cliente sobre los riesgos que implica no mantener la calidad interna, pero debe ser el cliente quien tenga la última palabra. Claro está, siempre y cuando esté dispuesto a asumir los riesgos: no son raros los clientes que desoyen los consejos del equipo y, ante una merma de la calidad percibida o el riesgo de no cumplir plazos por el progresivo incremento del tiempo necesario para realizar cambios en el sistema, piden milagros de última hora, ya sea en forma de noches en vela del equipo de desarrollo, contratación temporal masiva de “recursos” para sumar al equipo, o cualquier otra forma.

Conclusión
Desde mi punto de vista, la calidad debería ser completamente negociable. La calidad interna queda en manos del propio equipo de desarrollo, ya que son los encargados de medirla y mantenerla en niveles aceptables, aunque dejando siempre la última palabra al cliente, con la obligación de informarle de las posibles consecuenciasde no mantenerla en dichos niveles.

Por otra parte, la incorporación de la calidad percibida a las historias de usuario permite que el cliente defina su propia visión de lo que debe ser la calidad del sistema e incluso, por qué no, sacrificar parte de esa calidad para mejorar en otros aspectos. Ejemplos comunes podrían ser la disminución del Time To Market, aprovechar las ventajas de poder mostrar ciertascaracterísticas en alguna convención o feria de muestras, …

Al estar incorporadas a los requisitos o historias de usuario, este tipo de calidad no debe medirse (lo que además, sería muy complicado, al depender de cada cliente), sino cumplirse.

Y tú… mides la calidad ? Permites que se negocie con ella ?

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: