La calidad en cada parte 

Toda espada Japonesa que se precie de su calidad debe pasar un detallado examen denominado kantei. Este proceso se basa en una completa observación y evaluación de la hoja de la espada siguiendo una secuencia precisa sobre cada una de las partes. De manera que para evaluar la calidad general de la espada se evalúa la calidad de cada una de sus partes individualmente. Ahora, ¿qué sucede cuando el elemento a evaluar es algo tan intangible como lo es el software?

Siguiendo con la analogía deberíamos considerar que la calidad se encuentra en cada una de sus partes: cada especificación, cada decisión de diseño, cada línea de código, cada defecto que se encuentra en una etapa temprana.

Solo por mencionar algunos de los tantos factores que determinan la calidad final percibida por el usuario y por el equipo de desarrollo, podemos considerar:

  • Performance
  • Mantenibilidad
  • Cantidad de bugs
  • Cobertura de unit tests

Pero, ¿cómo hacemos para que la calidad se tenga en cuenta en cada detalle?

En proyectos o desarrollos pequeños puede ser simple que una o unas pocas personas vigilen y realicen los cambios necesarios. Pero ¿qué sucede en proyectos medianos o grandes? Rápidamente nos encontraremos con las limitaciones de este esquema.

Para lograr resultados sostenibles en el tiempo necesariamente se debe incluir a todo el equipo en ese compromiso. A cada una de las partes que forman el software que estamos desarrollando, incluyendo en esto a cada una de las personas involucradas en el desarrollo.

Ahí es donde se encuentra el gran desafío: establecer en un equipo que la calidad importa, que no se trata de un objetivo más sino de un medio. En definitiva que cada miembro esté implícitamente comprometido con la calidad del trabajo que realiza diariamente.

Una forma es generando una ambiente de trabajo donde cometer errores es inevitable. En ese contexto no se espera que nadie se equivoque pero si que aprendamos a sobreponernos y buscar alternativas rápidamente. Ciclos de implementación, error, aprendizaje.

Algunos tips que pueden ayudar a generar esta cultura y un diferencial en pro de la calidad del desarrollo son:

  • Code reviews involucrando a todo el equipo
  • Dar lugar a diferentes opiniones
  • Hacer uso de métricas: code coverage, número total de bugs, bugs reopen, etc
  • Feedback del cliente
  • y necesariamente tener una comunicación fluida y constante.

Difícilmente se pueda definir una secuencia de pasos que sean aplicables en cualquier caso. Depende de la magnitud del equipo, las personas involucradas, tipo de proyecto, etc. Pero definitivamente vale la pena el esfuerzo. Pudiendo ver los resultados desde el corto plazo: menos defectos, código más mantenible, mayor facilidad para el cambio, motivación en el equipo y seguramente clientes más contentos.

Links / Further reading:

http://en.wikipedia.org/wiki/Broken_windows_theory

http://books.google.com.ar/books?id=5wBQEp6ruIAC&printsec=frontcover#v=onepage&q&f=false

http://www.developer.com/tech/6-practical-agile-techniques-you-can-start-using-today.html

Facebooktwitterredditlinkedinby feather

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Avatar

    Excelente artículo, creo que es totalmente cierto, el trabajo colaborativo hace mucho más eficiente el trabajo, independiente del rol que se tenga en el proyecto.