Lycka Bonita

Había comentado previamente que mi empresa quiere conseguir la certificación de CMMI Nivel de Madurez 2. En realidad el objetivo es conseguir el Nivel de Madurez 3 el año que viene.

Por ello estuve hace dos semanas recibiendo un curso que concentraba 5 días en 3 jornadas, Introducción a CMMI v1.2 (me enteré el día anterior). Ahora vedrá la segunda parte, aplicar los conocimientos para implantar CMMI y conseguir a final de año la certificación de Nivel de Madurez 2.

Quién gestiona CMMI ?

El SEI (Software Engineering Institute) es el organismo fundado en 1984 por el Congreso de los Estados Unidos de América para desarrollar modelos de evaluación y mejora en el desarrollo de software. Está financiado por del Departamento de Defensa de Estados Unidos y administrado por la Universidad de Carnegie Mellon.

Primero liberó el CMM, que ha evolucionado hasta el actual CMMI versión 1.2. El lanzamiento de CMMI versión 1.3 está previsto que llegará en breve, centrado sobre todo en Alta Madurez.

Qué es CMMI ?

CMMI (Capability Maturity Model Integration) es un modelo de procesos que nos muestra un conjunto de buenas prácticas fruto de la experiencia estructuradas en 22 áreas temáticas (PAs Process Areas) y 5 niveles para cada área temática.

Qué no es CMMI ?

CMMI no es la única y verdadera respuesta.

All models are wrong, but some are useful

George Box

No es un workflow de procesos

Tampoco nos dice cómo se deben implementar las buenas prácticas que recoje, aunque sí es posible contratar auditorías para ayudarnos.

Me parece altamente llamativo que el propio SEI no siga CMMI de Nivel de Madurez 5 para "desarrollar" su propio modelo, ya que nos encontramos con varias lagunas e incongruencias. A parte de las más leves como que CAR sea de Nivel de Madurez 5 en lugar de -1, quién hace PQMA de CMMI ? y quién hace PQMA de estos ? También repetir 200 veces durante el curso que una PA (Process Área) no es un proceso, que "mitigación" significa en CMMI "mitigación y contingencia" y que "establecer y mantener" en realidad significa en CMMI :

This phrase means more than a combination of its component terms; it includes documentation and usage.

Lo más grave es que no ponen en práctica precisamente lo más costoso de implementar, y lo que a mí personalmente más dudas me producen : la recogida de datos cuantitativos para dar soporte a las decisiones.

Un ejemplo para entender esto es la gestión de riesgos: si me cuesta más evitar que se materialice un riesgo que el que se produzca, pues no cubro ese riesgo.

El SEI debería recoger datos de sus auditados, de cómo estaban antes y después de CMMI, permitirme hacer un simple análisis de coste / beneficio. Si me cuesta más implantar un Nivel X de CMMI que los beneficios que me produce, para qué implantarlo ? Cuánto tiempo necesito para llegar a un Nivel ?

Entonces, por qué CMMI ?

Mejorar nuestros procesos personales y profesionales nos permite avanzar, hacer más cosas, mejor, már rápido, aprender de nuestros errores y éxitos. Además aprovechar la experiencia de 

In God we trust, all others bring data

W. Edwards Dening

Está claro que implantar CMMI tiene un coste que deberíamos de amortizar, gastar pesetas para ahorrar duros : debería ser una inversión. Como menciono anteriormente, el SEI debería de ofrecer más datos para ayudarnos a decidir si implementar CMMI y qué nivel.

Está claro que CMMI recoge buenas prácticas que debemos seguir sí o sí, pero hasta dónde merece la pena esforzarse para conseguir una chapita que te certifique ? No olvidemos que nuestro negocio es fabricar software, no colgarnos chapitas.

Nivel CMMI ?

Para alcanzar un determinado nivel en un área temática se deben satisfacer todas las Metas Específicas (Specific Goals) del área, además de las Metas Genéricas (Generic Goals) del mismo nivel e inferiores. Cada Meta Específica incluye una o más Prácticas Específicas (Specific Practices), y cada Meta Genérica (Generic Practices) una o más Prácticas Genéricas.

Por ejemplo, para alcanzar el nivel 3 del área temática de Gestión de la Configuración, debemos satisfacer sus 3 Metas Específicas :

1. SG 1 Establecer líneas bases
2. SG 2 Seguir y controlar los cambios
3. SG 3 Establecer la integridad

Y además debe de satisfacer GG1, GG2 y GG3 :

1. GG1 Cumplir todas las Metas Específicas
2. GG2 Institucionalizar un proceso gestionado
3. GG3 Institucionalizar un proceso definido

El mecanismo para evaluar el "nivel" CMMI es un SCAMPI (Standard CMMI Appraisal Method for Process Improvement) realizado por una institución certificada por el SEI. El equipo auditor evalua las prácticas que cumple la empresa.

Hay dos formas de representar nuestro "nivel" CMMI : 

• Representación continua : Para cada una de las 22 áreas temáticas se evaluan las prácticas que se cumple y se califica con un nivel de capacitación
• Representación por niveles : Las áreas temáticas se clasifican en 5 niveles de madurez :

1. Nivel de Madurez 1 - Inicial o Ad Hoc.
2. Nivel de Madurez 2 - Gestionado (Gestión de Proyectos Básica). Las siguientes áreas temáticas deben poseer un Nivel de Capacitación 2.
1. REQM - Gestión de Requisitos
2. PP - Planificación de Proyectos
3. PMC - Monitorización y Control del Proyecto
4. SAM - Gestión de Acuerdos con Proveedores
5. MA - Mesaurement and Analysis
6. PPQA - Aseguramiento de la Calidad de Procesos y Productos
7. CM - Gestión de la Configuración
3. Nivel de Madurez 3 - Definido (Estandarización de Procesos). Se deben de llevar a un Nivel de Capacitación 3 las anteriores áreas temáticas, y además las siguientes :
1. RD - Requirements Development
2. TS -Technical Solution
3. PI - Product Integration
4. VER - Verification
5. VAL - Validation
6. OPF - Organizational Process Focus
7. OPD + IPPD - Organizational Process Definition
8. OT - Organizational Training
9. IPM + IPPD - Integrated Projecto Management
10. RSKM - Risk Management
11. DAR - Decision Analysis and Resolution
4. Nivel de Madurez 4 - Gestión Cuantitativa, se dice que ya estamos en Alta Madurez. Debe llevarse a un Nivel de Capacitación 4 todas las áreas temáticas mencionadas previamente, además de las siguientes :
1. OPP - Organizational Process Performance
2. QPM - Quantitative Project Management
5. Nivel de Madurez 5 - Optimizando (Mejora Continua de Procesos). Todas las áreas temáticas deben llevarse a un Nivel de Capacitación 5, es decir, todas las anteriores además de :
1. OID - Organizational Innovation and Deployment
2. CAR - Casual Analysis and Resolution

Más información

• CMMI en la Wikipedia y en liderdeproyecto.com.
• SEI en la Wikipedia y en su página oficial

Para completar una tarea y por tanto entregar un producto o servicio, una persona o un equipo de personas utilizan unas herramientas siguiendo un proceso o procedimiento (unos pasos secuencialmente ejecutados). La combinación entre personas, tecnología y proceso es lo que determinará el tiempo que tarda en completarse la tarea, así como la calidad del producto o servicio entregado.

Las personas necesitamos un tiempo de aprendizaje para manejar óptimamente las herramientas y seguir eficientemente los procesos, tras el cual se puede considerar que se es experto en el manejo de una herramienta y que los procesos han sido institucionalizados (se repiten de forma natural sin pararse a pensar).

Estos dos párrafos son el esquema básico de cualquier actividad humana, ya sea profesional o personal, ya sea construir un complejo sistema software o bien limpiar la cocina. Hay un tercer paso en nuestras actividades diarias y profesionales : la mejora continua, es decir conseguir mejores productos en menos tiempo : la experiencia (para reutilizar los éxitos pasados y no repetir anteriores fracasos) y la formación mejora a las personas, apoyándonos en mejores herramientas, refinando los procesos que se utilizan y reduciendo los tiempos de aprendizaje e institucionalización.

Yo vengo del mundo de la metodología tradicional, tanto por mi formación académica como por mi experiencia en el mundo laboral con metodologías RUP y Metrica3 : las cosas se piensan primero bien y luego se sigue el plant para conseguir hacerlo bien a la primera, medimos dos veces y luego cortamos una única vez.

En los últimos años se están poniendo de moda las metodologías ágiles y las iteraciones. Es más transparente y el cliente va viendo cómo está quedando lo que estás construyendo. Medimos una y cortamos; si no queda bien volvemos a medir y a cortar… hasta que queda perfecto. Medimos una vez y cortamos 2.

Las dos tienen sus puntos fuertes y sus debilidades, y hasta ahora yo las he aplicado según las necesidades del momento. Qué es más barato en cada caso ? medir una vez y cortar 2 o medir 2 veces y cortar 1 ?

Actualmente mi empresa sigue la filosofía ágil y sin embargo estamos en proceso de certificarnos en CMMI (no es una metodología, pero sí es tradicional), lo que en concreto ha introducido una sobrecarga del 10 % en la estimación de mi proyecto (que creo que se traducirá en más tiempo real consumido, que no facturado).

Se puede ser ágil a la vez que tradicional ? Y tú de quién eres, ágil o tradicional ?

Cuando empecé a programar profesionalmente, yo pensaba que escribir código por párrafos era de cajón y que todo el mundo lo daría por supuesto por las enormes ventajas que aporta a la hora de mantener un sistema, pero para mi sorpresa me encontré que no es asi.

Cuando leo una novela y veo un párrafo de varias páginas, tiemblo porque el autor no ha sabido / querido  ordenar suficientemente bien sus ideas y te lo suelta todo ahí de sopetón. Como si fueses a un restaurante y pidieses una entrada, un plato, un postre, un café y una bebida y el camarero te lo sirviese todo junto pasado por la batidora.

Y a la hora de escribir código ? No importa si es HTML, XML, C, Pascal, Java… Es importante escribir por párrafos para que la persona que no conoce el código lo lea y entienda rápidamente. Yo lo aprendí en Pascal, todos mis programas tenían únicamente 3 funciones : inicializar, procesar y finalizar.

Pongamos un ejemplo, un bean POJO en Java. Normalmente el contenido del bean lo podemos estructurar en 2 párrafos : declaración de las variables locales y declaración de los métodos públicos get y set de cada variable. A veces podemos tener 3, si declaramos constructores para ese bean. O 4 si sobreescribimos métodos get o set. O 5 si declaramos otros métodos (como sobreescribir el toString())… Pero si el bean está organizado por párrafos de un vistazo lo vemos, cualquiera tardaría 5 segundos en leer y entender la clase por muy grande que sea sin necesidad de leer cada letra.

En mis años de aprendizaje en mi escuela aprendí que la construcción de un software de calidad se basaba en dos pilares, la modularidad y la reutilización. Mi experiencia profesional me ha demostrado su enorme importancia : he podido disfrutar de sistemas que han seguido estos principios y he tenido que sufrir sistemas que no los siguieron. También que son insuficientes.

La modularidad es básica en software, como bien nos decía Jack el destripador :

Vamos por partes

La curva de aprendizaje es más suave, se puede desarrollar en paralelo reduciendo el tiempo de entrega, es más fácil realizar pruebas unitarias, es más fácil de mantener porque se aislan los errores en módulos.

Pero con qué criterios debemos dividir un sistema monolítico en módulos ? La reutilización es la respuesta, ya que nos permite disminuir el número de módulos necesarios en el sistema e incluso aprovechar módulos para futuros desarrollos.

Estos dos conceptos son suficientes ? Creo que se deberían completar con otros dos conceptos : desacoplo y sencillez.

El desacoplo se consigue con un buen interfaz y la reducción de dependencias externas. Debe ser un criterio complementario a la reutilización a la hora de dividir nuestro sistema en módulos. Por ejemplo si queremos hacer una llamada a base de datos para preguntar el número de usuarios de nuestro sistema, podemos tener un módulo para cada SGDB (uno para MySQL, otro para Oracle, otro para SQL Server…) o un único módulo que obtenga el mismo resultado para cualquier SGBD utilizado. Este módulo será un poco más complejo pero se convierte en mucho más reutilizable.

Ya lo dice el refrán :

Lo simple es bello

La sencillez es la meta común de todo lo anterior, y no sólo por alcanzar la belleza : nuestro sistema global es más sencillo, lo que se traduce en un sistema más barato de desarrollar, reducimos el tiempo del desarrollo, más barato de mantener, más fácil de aprender, reducimos el tiempo de respuesta a incidencias, conseguimos una calidad mayor y nos resultará más fácil de repetir con éxito en el futuro.

La aplicación de estos cuatro simples principios redunda en un beneficio para el cliente, para la empresa de software y para todas las personas participantes en el proyecto.

No olvides además que siempre hay tiempo para hacer las cosas bien, lección que he tenido que aprender en mis propias carnes : no se pierde un día, se invierte un día para luego ahorrarnos una semana.