martes, 30 de agosto de 2011

El mito de la mantenibilidad

Parece que seguimos revisando mitos.

¿Realmente es necesario que un software sea mantenible? Si la respuesta es que sí...¿en qué grado? ¿hasta qué punto? ¿para qué usuarios/clientes? ¿Cuándo lo hacemos y a través de qué actividades?

El IEEE define mantenibilidad como: “La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno”.

En la ISO 9126-1 se define que la mantenibilidad está indicada por los siguientes subatributos:
  • Facilidad de análisis
  • Facilidad de cambio
  • Estabilidad
  • Facilidad de prueba
Desde mi punto de vista, el uso de buenas prácticas en el análisis y desarrollo nos conducen a:
  • Facilidad de análisis: la documentación facilita el análisis y entendimiento de la arquitectura, decisiones tomadas, etc. Una arquitectura coherente en todo el producto, facilita el análisis.
  • Facilidad de cambio: la documentación facilita la identificación de elementos afectados por un cambio, su trazabilidad, etc.
  • Estabilidad: el aislamiento entre componentes y el uso de una arquitectura coherente en sus distintos aspectos, facilita que los cambios no produzcan efectos indeseados. 
  • Facilidad de prueba: las buenas prácticas en el diseño, desarrollo y ejecución de pruebas, facilitan llevar esta tarea a buen término.
Es decir, vemos que para conseguir la mantenibilidad, podemos hacerlo a través de todas estas vías. 

En mi opinión, normalmente no es necesario hacer un esfuerzo adicional (extraordinario) para que un software sea mantenible. Lo que sí es necesario, es que se sigan ciertas pautas en todo desarrollo, independientemente de que se nos exija esa mantenibilidad. La mantenibilidad debería estar "de serie" en cualquier desarrollo. De hecho, es de las características del software que deberían ir EN PRIMER LUGAR. El resto, pueden derivarse de ella.

A continuación, vamos a revisar unas cuantas técnicas específicas enfocadas a mejorar la mantenibilidad, y que por tanto deberían estar presentes en todo desarrollo software (independiente de que la metodología sea tal o cual, ágil o no...):
  • Establecer políticas de diseño, codificación y pruebas enfocadas a este tema. Por ejemplo, el uso de patrones puede ayudar. Sin embargo, no debemos caer en el uso indiscriminado de patrones (la conocida "patronitis").
  • Facilitar la configuración del software.
  • Evitar cambios significativos en la arquitectura del sistema durante el desarrollo.
  • Coherencia (en arquitectura, en nomenclatura, en comentarios, etc). No podemos trabajar con técnicas heterogéneas, del mismo modo que no podemos ser superexigentes en la arquitectura, y relajados en los comentarios o nomenclatura). 
  • Uso de estándares conocidos. Hacer públicos dichos estándares, manteniendo informado al equipo sobre los mismos, y sobre cualquier cambio en los mismos. Asegurar la formación del equipo en estos estándares. Realizar controles (llamadlos revisiones, auditorías, da igual), y asegurarse de que se cumplen.
  • Documentación (de los casos de prueba, de resultados de pruebas, de requisitos, de decisiones funcionales y técnicas, etc).
  • Mejora del código en base a métricas (complejidad, etc). Sin control y seguimiento, no se puede mejorar. No podremos mejorar si no sabemos como estamos.
  • Planificación del mantenimiento.

Scrum - Chuck Norris

Para variar, un poco de humor. Este post resultará especialmente divertido para los que conozcan Scrum, y va en la línea de los chistes de Chuck Norris:

http://www.genbetadev.com/metodologias-de-programacion/scrum-norris-es-scrummaster-sin-haber-sido-certificado

El mito de la burocracia

Con frecuencia me encuentro con rechazo a las tareas a realizar durante el proyecto, y en muchas ocasiones la respuesta tiene una raiz común: la gente las llama burocracia.

Si a un programador le pides que anote las horas que ha dedicado a hacer una tarea, lo tildará de burocracia. Sin embargo, si tiene que probar una nueva tecnología para la que existe la rara posibilidad de que se use en el proyecto, esas horas las considerará una inversión.

Hay una importante corriente de favor por metodologías y prácticas "ágiles", y es sorprendente la facilidad con que todo el mundo se apunta a "ser ágil" (aunque realmente hay poca gente que te sepa decir exactamente qué supone ser ágil). Muchos contestan que ser ágil, es básicamente, eliminar la burocracia.

El problema reside en que primero, esa definición de agilidad no es correcta, y además, tampoco existe un acuerdo en qué es la burocracia. En mi empresa nos hemos certificado CMMi nivel 3, y constantemente leo en internet un constante rechazo a CMMI, en muchos casos recibiendo la calificación de "burocrática".

Sorprendentemente, los equipos de trabajo que usan nuestra metodología raramente se quejan de burocracia. Las tareas que se realizan, hay que realizarlas si o si, ya que proporcionan la única forma de llegar a tener control sobre el proyecto. Además, las tareas que se realizan no se llevan a cabo por CMMI, sino por el valor que aportan al proyecto o a la organización. Las quejas surjen durante las fases de implantación de la metodología, lo que nos lleva a concluir que el problema es de formación y falta de conocimiento.

Por otro lado, la burocracia, se presenta como principal argumento de metodologías ágiles como SCRUM. Se busca en muchas ocasiones rechazar dos conceptos que en realidad tienen poco que ver entre sí, y mucho menos con SCRUM:
  • CMMI
  • Ciclo de vida en cascada
Para empezar, CMMI no es una metodología, como tampoco lo es el ciclo de vida mencionado. CMMI es un modelo de madurez. El ciclo de vida en cascada, como cualquier ciclo de vida, es un modelo más o menos teórico que presenta una forma de realizar las actividades. Normalmente lo que se busca con afirmaciones de este tipo es conseguir crear en el modelo CMMI una imagen de burocracia y antiguedad. Por confrontación, conseguiríamos obtener una imagen (ficticia como vemos), de modernidad y agilidad en SCRUM.

Vemos entonces que la burocracia, sin terminar de definirse como término (aunque está claro que es negativo), sirve como argumento positivo (por confrontación).

Mi opinión es que en la mayoría de ocasiones nos gusta escondernos en nuestro pequeño mundo, y llamamos burocracia a las actividades que no nos aportan directamente algo a nosotros mismos. En una escala comparativa, tendríamos tareas cuyo beneficio va a parar:
  • Al individuo
  • Al proyecto
  • A la empresa
Las actividades que producen principalmente beneficio al individuo (actividades que producen satisfacción personal, autoformación, investigación, etc), no se consideran nunca burocracia. Los integrantes del equipo se sienten cómodos con ellas.

Las actividades que aportan al proyecto, son calificadas como burocráticas por las categorías más bajas (programadores principalmente). Las necesidades de la gestión del proyecto no les importan, y la supresión de estas actividades, serían a su modo de ver, síntoma de agilidad.

Las actividades que aportan a la empresa, amplían el conjunto de individuos que las rechazan, incluyendo a las categorías medias/bajas.

Como conclusión, vemos que normalmente la definición de burocracia está asociada de forma egoísta o personal a unas actividades u otras, en función de nuestro rol. Se echa en falta pues, una visión más global de las actividades en los proyectos, y de su relación con los distintos roles. Un punto por ejemplo que no se suele tener en cuenta es el coste o beneficio en cada actividad, que suele ser percibido de forma diferente en función del rol en el proyecto.