Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

The Agile Quality Concept

Como todo, la calidad del software puede ser entendida y tratada de formas muy diferentes, que en teoría buscan el mismo objetivo. Estoy presenciando personalmente cómo chocan de frente dos enfoques, el ágil y el pesado, pero ¿qué caracteriza a cada uno de estos enfoques?.

Un enfoque pesado se caracteriza por seguir ciertas normas predefinidas y comunes para todos los proyectos, independientemente de la naturaleza de los mismos. En mi opinión, un enfoque ágil debe aportar valor en los aspectos que realmente son importantes para cada proyecto concreto.

Enfoque “ágil” de la calidad

  • Filosofía de aporte de valor. Como comentaba antes el aporte de valor a los aspectos realmente importantes de cada proyecto es la base de un enfoque ágil. No existen unas normas perfectamente definidas en un libro de 300 páginas, la norma es: si aporta valor al equipo de proyecto y al cliente, se hace (siempre dentro de los límites económicos del proyecto, porque como sabemos, la calidad cuesta dinero).
  • Documentación útil. La documentación es una tarea que consume mucho tiempo, y por tanto hay que dosificarla. Solamente se generará la documentación que realmente sea útil durante el desarollo y mantenimiento del proyecto, no tiene sentido la redacción de pesados documentos que en el mejor de los casos acaban en el cajón del cliente sin haber sido leídos. Es fundamental mantener la documentación, ya que es un entregable que evoluciona al mismo ritmo que el desarrollo en una metodología ágil, la perdida de coherencia en la documentación puede ser una gran fuente de errores (y por tanto de trabajo extra).
  • Software que funciona. Una medida de calidad será el software que funciona, y además funciona reflejando el catálogo de requisitos en la implementación, y por supuesto, siendo la implementación correcta a nivel técnico. La piedra angular para asegurar estos dos aspectos es el testing. Si se consigue todo lo anterior, posiblemente otra medida de calidad será la enhorabuena del cliente.
  • Calidad del código fuente. Este es uno de los aspectos que más se dejan de lado en las metodologías pesadas. Cuando uno se enfrenta a un proyecto cuyo código es de calidad, las cosas son más fáciles. La calidad del código comprende aspectos como el seguimiento de una guía de estilo y codificación, evitar el uso de formas de programación que pueden provocar errores potenciales, mantener un código usable, legible, extendible, eficiente, portable y correctamente versionado para su posterior mantenimiento.
  • Integración continua. En un enfoque ágil del aseguramiento de la calidad no puede faltar un sistema de integración continua. Con él automatizaremos las pruebas definidas para el proyecto, compilaremos el código integrando los cambios efectuados por lo desarrolladores, generaremos documentación periodicamente que puede ser consultada incluso por el cliente y mantendremos el código sano en todos los sentidos.

En mi opinión estos son los puntos fundamentales de un enfoque ágil del aseguramiento de la calidad.

6 Respuestas a “The Agile Quality Concept

  1. jmbeas 16 diciembre 2008 en 6:17 am

    Muy acertado, Antonio, aunque quizás sería oportuno también recordar el Manifiesto ágil:

    * Individuos e interacciones sobre procesos y herramientas
    * Software que funciona sobre documentación exhaustiva
    * Colaboración con el cliente sobre negociación de contratos
    * Responder ante el cambio sobre seguimiento de un plan

    http://www.agile-spain.com/agilev2/manifiesto_agil

    Todos los puntos que mencionas derivan (más o menos directamente) de este manifiesto, igual que lo hacen los Principios ágiles (http://www.agile-spain.com/agilev2/principios_agiles).

    En realidad, en mi opinión, la clave que hace *completamente* diferentes las metodologías “en cascada” y las “ágiles” es la diferencia de “humildad” al asumir o no que durante la vida del proyecto van a producirse cambios y que estos van a ser asimilados por el mismo (o no).

    Los métodos tradicionales niegan los cambios (de una manera sutil puesto que hablan de “gestión de los cambios”) mientras que los métodos ágiles *favorecen* los cambios y trabajan sólo para satisfacerlos. Lo cuál no quiere decir que unos y otros no busquen la calidad, pero resulta evidente que se buscan desde perspectivas muy diferentes.

    En cualquier caso, estoy totalmente de acuerdo contigo, especialmente en cuanto a la calidad del código fuente. A veces nos olvidamos de que el software lo escribimos personas. Incluso los propios programadores nos olvidamos de esto y escribimos código “al peso”. No hace mucho hablaba en mi blog sobre la “Artesanía del software” (http://jmbeas.blogspot.com/2008/10/artesana-del-software.html).

    Lo dejo aquí que si no me va a salir más largo el comentario que tu artículo. :-)

  2. Rafa Muñoz 28 enero 2009 en 10:37 am

    Muy buena aportación, el tema de encontrar el balance entre “ambos mundos” es siempre complejo y seguramente significará el premio Nobel para el que lo consiga.

    Yo no creo que haya esos 2 mundos, no niego que hay metodologías de 300 o más páginas, que se ven muy bonitas en un librero, pero que luego nadie lee (yo mismo he sufrido algunas), sin embargo, me parece que no hay porque hacer una muralla entre ellas.

    Hay quien resume el manifiesto ágil como “cero documentación”, sin embargo, la documentación no necesariamente son archivos en Word, Excel o, peor aún, Power Point. En algunos casos los scripts de JUnit o de Ant funcionan como tal.

    Mi búsqueda desde hace algunos meses ha sido, dónde está la frontera real, porque me surgen preguntas como (en el orden del enfoque ágil de calidad):
    1. Quién dice qué le aporta valor a un proyecto?, el “Techy” que quiere usar la última versión de jBPM para hacer una herramienta que reserva salas de reuniones o el cliente que dice que una hoja de excel compartida en la red le sirve?

    2. Un “ladrillo” de 300 páginas para definir un proyecto de 6 meses es un claro ejemplo de documentación inútil, pero cuando vemos un ejemplo cotidiano como un proyecto que hace una PYME para controlar su facturación, cuántas páginas son útiles para describir la funcinoalidad completa? – ojo que no solo me refiero a páginas en prosa, cuentan también diagramas UML, prototipos, descripciones conceptuales, etc.

    3. Sin duda este es el fin máximo y meta suprema de cualquier metodología, pero siempre hay una pregunta: Si ya no encontramos errores, es porque ya no hay o porque somos incapaces de encontrarlos?, cómo sabemos cuándo es suficiente testing antes de liberar una aplicación bancaria, de seguros o de navegación de misiles?

    4. Yo he visto, que en muchos casos, la guía de estándares de programación Java de SUN ha sido descrita como “un libro hecho y derecho”, estos estándares se consideran parte de las metodologías pesadas?

    5. Continuum es sin duda la llave del éxito para el desarrollo de software de nuevos productos!!!

    Finalmente, para tenerlo claro, CMMI es parte de las metodologías pesadas?

    Antonio, sigue escribiendo, el sitio es muy bueno y tiene muchas ideas que moverán viejos paradigmas y prácticas empolvadas que no sirven de nada.

    Suerte!

    RMG

    • Antonio Manuel Muñiz Martín 28 enero 2009 en 8:41 pm

      Hola Rafa.

      Gracias por el comentario :)
      Estoy contigo en que no hay que poner un muro infranqueable entre las dos vertientes, de hecho la generación de documentación es necesaria tanto en un enfoque como en otro, pero la forma y las líneas generales a seguir son distintas.

      Como decía en el post, se generará documentación útil, que aporte valor, no documentación generada para marcar un “tick” de conformidad en una hoja de cálculo.
      ¿Quién decide si aporta valor o no?, evidentemente el equipo de desarrollo y el cliente; como tú dices, es necesario un equilibrio, aunque si ambos perseguimos el mismo fin… el equilibrio no debe ser difícil de conseguir… ¿no? ;)

      Para definir la funcionalidad completa de una aplicación hace falta un documento de análisis, y éste se puede hacer tan pesado o tan ágil como se quiera, puedes enfocarlo a exponer todos y cada uno de los requisitos, casos de uso, etc, perofectamente detallados; o por el contrario puedes usar un conjunto de diagramas conceptuales, pequeñas anotaciones en ellos, diagramas de casos de uso, etc, y dejar un margen al buen hacer de tu equipo de desarrollo (experto en esta materia) e ir refinando en sucesivas iteraciones.
      De todas formas, en mi opinión, este documento es el único que puede extenderse algo más.

      ¿Cómo sabemos cuando es suficiente testing?, eso depende del presupuesto del proyecto, como dice un amigo, -“Antonio, la calidad cuesta”-. Es posible que no haya límites, como comentaba la responsable de calidad de ISBAN.

      En cuanto a CMMI, en nuestro caso aplica CMMI-DEV, y sí, pienso que es una metodología pesada desde el momento que se instaura a nivel de organización y no a nivel de proyectos concretos. CMMI-DEV define una serie de pautas metodológicas generales, que en ocasiones puede que no apliquen, y por tanto, no aporten valor, sin embargo para CMMI son necesarias.

      Un saludo. De nuevo, gracias por tu aportación.

  3. Rafa Muñoz 29 enero 2009 en 12:21 am

    No me des las gracias, que es un placer interactuar con gente que está “desde la trinchera” mejorando la calidad del software, que para muchos es más que un trabajo, es un modo de vida :)

    Quería retocar un par de puntos que a lo mejor no ha sido explotado suficientemente, por temas históricos, comerciales, contractuales … etc.

    Primero, que CMMI no es una metodología, es un modelo; es decir, dice qué hay que hacer, pero no cómo hacerlo, por lo que cada organización puede implementarlo de acuerdo a sus creencias y valores fundamentales.

    Por otro lado, dado que CMMI es un modelo pensado para medir la madurez y/o capacidad de los procesos de una organización, la línea que divide cada uno de sus niveles es muy clara, pero esto es solo una forma de representar el modelo, cada organización puede decidir qué subconjunto de prácticas (específicas o genéricas) aplicar en sus proyectos, si considera que el modelo no le es válido como está planteado y su objetivo no es conseguir un nivel de madurez o de capacidad.

    Dejo aquí la liga a uno de los “papers” que publicó el SEI en Nov/2008, que podría marcar una tendencia interesante en cómo pueden interactuar CMMI y las metodologías ágiles:
    http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

    Espero que sea útil

    RMG

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: