TEIS, una herramienta para evolucionar la calidad del software

by Gastón Guillerón

Cuando uno desarrolla un producto, obviamente tiene -al menos la intención- de hacerlo con la máxima calidad posible.

La expresión “…al menos…” no es accidental. La calidad de un producto tiene una fuerte dependencia de la calidad con la cual se desarrolla el proceso que construye dicho producto.

Claro es que las organizaciones maduras en certificaciones, normas y lineamientos de calidad muy probablemente puedan implementar, sostenidamente, mejores procesos aumentando así las probabilidades de obtener mejores productos.

Ahora bien, también es claro que nadie puede asegurar nada, y menos en el ámbito del software, el cual presenta características inherentes que tornan su construcción, aún para los más preparados, en un verdadero mundo de complejidades[1]. Pero nada está perdido, dado que la industria hoy cuenta con cientos de metodologías, prácticas, técnicas y herramientas para enfrentar el desafío de desarrollar software de calidad.

Aún considerando el espíritu alentador, el cierre del párrafo anterior introduce su propia complejidad para los equipos: ¿como gestionar este universo de posibilidades?.

¿Qué metodología utilizamos? ¿Qué prácticas podemos probar? ¿cuales aplican mejor? ¿Funcionaron? ¿Vamos mejorando? ¿Estamos haciendo software de calidad?

En este post pretendo realizar mi aporte a la cruzada precisamente en el campo de organizar la batalla. Así, se presenta una propuesta elaborada a partir de experiencias, que he utilizado en diversas oportunidades, con equipos de diferentes tamaños (inclusive en proyectos individuales) y que puede perfectamente incluirse en la valija de herramientas de gestión/calidad de cualquier equipo de trabajo.

La herramienta la he denominado Tablero de Evolución de la Ingeniería del Software (TEIS).

Tablero de Evolución de la Ingeniería del Software

Al iniciar el proyecto, el TEIS tiene la siguiente típica estructura:

Existen dos zonas, una de Registro para reflejar lo que sucede durante el desarrollo del proyecto, y otra de Mediciones para facilitar el análisis de la evolución.

  • Backlog de Mejores Prácticas: En la Zona de Registro, el tablero dispone en las primeras dos columnas de un backlog de mejores prácticas, clasificadas por etapas. La idea es que durante todo el desarrollo se puedan ir incorporando todas aquellas mejores prácticas que vayamos identificando como deseables o interesantes de probar o aplicar durante el proyecto. Estas mejores prácticas pueden provenir desde cualquier origen (metodología, estándar, modelo, etc), como podría ser el SWEBOK [2]. Algunos ejemplos de mejores prácticas pueden ser: Implementar Integración Continua, Code Review, Análisis estático de código, Pruebas Unitarias y Pair Programming.
  • Iteración 1…iteración n: representan las diferentes iteraciones de trabajo, por ejemplo Sprints. La idea es que al finalizar cada iteración, el equipo evalúe como resultó la implementación de cada práctica según la siguiente escala:
SI (verde): La práctica se implementó efectivamente. Por “efectivamente” entendemos el cumplimiento de los criterios de buen uso exigidos por dicha práctica.
NO (rojo): La práctica no se implementó efectivamente.
Vacío (amarillo): La práctica no fue necesario implementarla.

Con el avanzar del proyecto, el TEIS va adoptando la siguiente colorización, según como nos fue con la implementación de las prácticas.

  • En la Zona de Registro tenemos el resultado de la evaluación de la implementación de las 9 prácticas seleccionadas a lo largo de 5 iteraciones.
  • En la Zona de Mediciones disponemos de dos mediciones que nos serán de utilidad:
# Practicas: Cantidad de Prácticas implementadas por iteración.
% Efectividad: Efectividad acumulada de la implementación de las prácticas. Esto es, contabilizamos la totalidad de implementaciones efectivas (“SI”) respecto la totalidad de implementaciones.

Análisis de Resultados

El objetivo último del TEIS es contribuir a la evolución de la ingeniería del software de un proyecto, la cual mejora a medida que:

  • Implementamos continuamente nuevas mejores prácticas y,
  • dicha implementación se hace de manera efectiva.

El análisis de la evolución se realiza graficando las dos mediciones presentadas anteriormente:

El análisis de resultados que podemos extraer para el ejemplo son:

  • El equipo del trabajo fue implementando durante todo el proyecto una creciente cantidad de mejores prácticas. Eso es bueno!.
  • El equipo del trabajo fue aumentando la efectividad de la implementación de las mejores prácticas. Eso también es bueno!.

Conclusiones

El TEIS presenta muchos aportes. Es una herramienta que:

  • De forma sencilla, puede ayudar a un equipo de trabajo a mejorar la calidad del software a partir de mejorar la calidad del proceso que lo produce.
  • Incentiva la incorporación efectiva de buenas prácticas al motivar visualmente que ambas curvas de las mediciones asciendan de manera continua.
  • Es una herramienta que se puede actualizar naturalmente en los proyectos, como por ejemplo, durante la retrospectiva de un sprint.
  • Es escalable a otros tipos de productos diferentes al software, dado que las etapas y mejores prácticas pueden adoptarse para diferentes industrias.
  • Es adaptable a cualquier equipo de trabajo, desde profesionales individuales a organizaciones con certificaciones de calidad.
  • Es integrador, puesto que permite considerar diferentes inputs de metodologias, técnicas y herramientas para conformar el backlog de buenas prácticas.
  • Finalmente, es de muy bajo costo, dado que se puede confeccionar en cualquier planilla de cálculo, en papel o una pizarra.

Como desventaja, el TEIS presenta los inconvenientes que toda herramienta puede llegar a tener.

  • No es una bala de plata que resuelva todo!.
  • Requiere gestión y eso implica tiempo.

Referencias

1. http://www.informit.com/articles/article.aspx?p=726130&seqNum=2
2. http://www.computer.org/web/swebok