Institucionalizando el nivel 2 de CMMI en el Departamento de I+D de una PYME

Por su interés enlazo el vídeo de la ponencia que realizamos en la Universidad Carlos III dentro del ITGSM 2011 el pasado junio sobre nuestra propia experiencia implementando el nivel 2 de CMMI en el Departamento de I+D de Answare Technologies.

En él explicamos los principales desafíos que supuso la adaptación de las diversas áreas de proceso de CMMI al modelo de negocio del I+D+i, así como las pautas que a nosotros mejor nos funcionaron para implantar exitosamente las prácticas en la organización.

La ponencia surgió a raíz del interés de la organización del congreso en difundir el contenido del artículo -del mismo nombre que la ponencia- que se puede encontrar en este enlace.

Gestión básica de requisitos

A partir de las nociones que he adquirido a lo largo de la carrera y los primeros años de trabajo sobre Gestión de Requisitos de software, y empleando el marco que proporciona CMMI -concretamente el área de proceso REQM- para la realización a un nivel básico de este proceso vital en el ciclo de desarrollo, dejo aquí unas notas sobre cómo realizar la gestión de requisitos de modo que se cumplan unos criterios mínimos de calidad:

1º Entender los requisitos: Plántate delante de cada requisito como si fuera uno de aquellos problemas de física del colegio. Siéntate, ponte a estudiarlo, consulta otros documentos, pide ayuda, especialmente a la persona que lo detectó y/o lo propuso, y no lo des por cerrado hasta que no estés absolutamente seguro -y otra persona así lo haya verificado- de que el requisito está entendido y de que están claras las razones por las que lo aceptas o lo rechazas.

2º Obtener el compromiso con los requisitos: Sabiendo como sabemos que los requisitos son un entorno cambiante, siempre hay que tener bien claro cómo nos impacta la incorporación de un cambio o la agregación de un nuevo requisito. Documenta los cambios que van surgiendo: que quede bien claro quién propone los cambios, quién los acepta, quién los desarrolla, quién los prueba y cómo queda el proyecto antes y después del cambio. Un requisito no debe incorporarse hasta que no haya sido mínimamente negociado.

3º Gestionar los cambios en los requisitos: Mantente abierto a los cambios, porque los cambios no son un marrón, sino que son propuestas que añaden valor al producto desde el punto de vista del cliente. Esto no significa que debas aceptar cualquier cambio, especialmente sin evaluar antes su impacto en colaboración con la fuente del propio cambio y con el equipo de desarrollo. Simplemente se trata de enfocar los cambios en los requisitos como un proceso de mejora continua del producto. Asesórate a la hora de estimar su impacto, no solo con el juicio de expertos sino sobre todo echa mano de experiencias pasadas con incidencias similares. Ah, y algo muy importante: guarda la historia de los cambios, versionando los requisitos para que se pueda ver cómo ha evolucionado cada uno a lo largo del proyecto.

4º Mantener la trazabilidad bidireccional de los requisitos: Es conveniente saber en cada momento de dónde viene y adónde va cada requisito. Los requisitos técnicos, esos que metes en fichas y que lucen un aspecto más o menos estructurado, detallando su importancia, urgencia, etc., deben tener su correspondencia con alguna línea o punto del documento de especificaciones que envía el cliente. Además, conviene que la relación entre los propios requisitos técnicos esté a su vez documentada y que se sepa de dónde vienen los productos de trabajo. Una forma habitual de afrontar todo este lío es mediante la matriz de trazabilidad, pero a mí me parece un tanto confusa y difícil de mantener. Prefiero que este tipo de relaciones vengan detalladas dentro de la ficha de cada requisito, al estilo de lo que propone la herramienta REM. Si consigues tener bien definida y mantener actualizada la trazabilidad, resultará más sencillo saber qué elementos se ven impactados cuando ocurre algún cambio. La trazabilidad se puede llevar a varios niveles, en función de tus necesidades.

5º Asegurar que los productos de trabajo cumplan con los requisitos: Realiza auditorías periódicas que aseguren que lo que se está desarrollando esté de acuerdo con lo que se pedía. A partir de estas auditorías -que no debemos confundir con las pruebas- se deben lanzar acciones correctivas a las inconsistencias detectadas. Lógicamente estas auditorías deben ser realizadas por alguien independiente al desarrollo de los requisitos a evaluar. Vamos, que no vale auditarse a uno mismo.

Si se quiere avanzar más en la gestión de los requisitos existe un área de proceso en CMMI -concretamente la de Requirements Development, del nivel 3- que detalla una serie de prácticas adicionales que completan la gestión en varios aspectos, si bien estos cinco puntos son los que se consideran necesarios y suficientes para adquirir un nivel de madurez aceptable en el tratamiento de los requisitos.

Una guía que me ha parecido muy completa a pesar de su tamaño relativamente reducido es la que proporciona el INTECO, y que se puede ver en el siguiente enlace: [pdf].

El nivel 2 de CMMI

“Y al principio fue el caos…”

Una de las particularidades de CMMI como modelo de procesos para la fabricación de software es que considera perfectamente factible la entrega de productos de acuerdo a las especificaciones originales de los mismos aún a pesar de no cumplir ninguna de las prácticas de calidad que su propio modelo predica. Eso sí, sufriendo al menos dos inconvenientes nada despreciables: por un lado la necesidad de contar con el esfuerzo de los llamados héroes para superar el trámite y por otro, la pérdida de oportunidades por parte de la organización de acumular conocimiento para superar futuras situaciones de riesgo, reforzándose el círculo vicioso que lleva a una empresa de desarrollo de software a ser poco más que la suma de la experiencia de sus miembros en un momento dado, en vez de ostentar un conocimiento propio.

Este estado es el que CMMI reconoce como Nivel 1 de madurez: los productos se entregan y aparentemente funcionan bien, pero acostumbran a sobrepasar las previsiones, si es que había tal cosa, de coste y calendario.

Un primer paso en el camino hacia la madurez, según el modelo CMMI, es trepar hasta el Nivel 2: el nivel Gestionado. Aunque existen consultores y expertos que aseguran que el paso más complejo en la larga carrera de la certificación es el avance del nivel 2 al 3, a mí personalmente me resulta complicado pensar que puede haber algo más difícil para una organización que pasar del caos absoluto a la definición de procesos adecuados para al menos siete áreas del desarrollo: la Gestión de Requisitos, la Planificación, la Monitorización del Proyecto, el Aseguramiento de la Calidad, la Gestión de Configuraciones, la Medición y Análisis y la Gestión de Acuerdos con Proveedores. Ni qué decir tiene que según se va avanzando de nivel, nuevas áreas de proceso surgen con nuevas metas que alcanzar y nuevas prácticas que implementar.

Además, no conviene olvidar que existe una serie de prácticas generales aplicables a cada una de las siete áreas del nivel 2, que son si cabe más importantes que las metas particulares de cada área. A menudo estas prácticas genéricas son despreciadas por los responsables de los procesos en las organizaciones, que las ven como un agregado al modelo sin demasiado que aportar. Craso error. De hecho las prácticas genéricas son la argamasa que junta todas las áreas y da consistencia al proceso.

CMMI para principiantes (y III)

Los niveles de madurez de CMMI

Como comenté en el post anterior, CMMI está representado escalonadamente en 5 niveles de madurez, que califican a las empresas según la calidad de su proceso de producción. Estos niveles, además de por su correspondiente ordinal (del 1 al 5), se conocen por el adjetivo que los describe: Inicial, Gestionado, Definido, Cuantitativamente gestionado y el más alto de todos, Optimizado. Veamos brevísimamente en qué consiste cada uno de ellos.

Nivel 1 (Inicial): La organización no sigue conscientemente las prácticas especificadas en el modelo CMMI, pero de una forma u otra consigue que sus productos salgan al mercado. Supone una gran dependencia de los llamados héroes, profesionales sobresalientes que con su esfuerzo y habilidad personal sacan a la empresa del atolladero. La organización no genera conocimiento y la pérdida de estos héroes supone generalmente la pérdida de la capacidad acumulada.

Nivel 2 (Gestionado): Supone el cumplimiento, por parte de cada proyecto, de varias áreas de proceso de CMMI relacionadas con la gestión de requisitos, la planificación, la monitorización, la gestión de la configuración, el aseguramiento de la calidad, el acuerdo con los proveedores y la medición y análisis de los procesos. Se trata de asegurar que las buenas prácticas se mantengan independientemente de los vaivenes coyunturales que afecten a la organización. El conocimiento reside en la organización.

Nivel 3 (Definido): En este nivel, los procesos ya no sólo se definen de manera independiente para cada proyecto sino que toda la organización goza de unas pautas comunes. Se instaura una serie de procesos que, llevando la explicación al paradigma de la orientación a objetos, suponen la clase sobre la cual se instancian los proyectos. En resumidas cuentas, la empresa goza de una plantilla bien caracterizada que al ser aplicada a cada caso particular, genera un proyecto.

Nivel 4 (Cuantitativamente gestionado): Llegados a este punto, la organización ya no sólo gestiona los proyectos mediante procesos bien definidos, sino que además, se fijan objetivos tangibles que los procesos deben cumplir en lo relativo a su calidad, de manera que se analizan estadísticamente los procesos, propiciando una exactitud y predictibilidad, si se me permite el palabro, de la que no goza el nivel anterior.

Nivel 5 (Optimizado): En el nivel más alto de CMMI, la organización entera experimenta una optimización continua de los procesos a través de la innovación en los mismos y de las mejoras tecnológicas. Se modifican y reconducen los procesos en función de los defectos revelados durante el análisis estadístico.

¿Y cómo se le reconoce oficialmente a una organización su nivel de madurez?

La evaluación, conocida como Appraisal, del grado de madurez de una empresa es llevada a cabo por un equipo que debe estar formado, según el método SCAMPI (Standard CMMI Appraisal Method for Process Improvement), por un evaluador oficial (Lead Appraiser) formado por el SEI y por un conjunto de personas que deben haber recibido el curso de introducción a CMMI y entre las que se puede encontrar, y de hecho es lo habitual, personal de la propia organización. Este enfoque de que gente de la propia organización evalúe el grado de madurez que su empresa merece puede parecer chocante, y con razón. Sin embargo de una forma u otra el complejo método SCAMPI se las apaña para asegurar la objetividad, o al menos eso garantiza el SEI.

Se trata de una prueba exigente, que puede llegar a durar varias semanas, durante las cuales, entre otras cosas, se recogen y analizan las evidencias de cumplimiento de las áreas de proceso a evaluar y se entrevista a los involucrados en la organización. Al finalizar la Appraisal, el evaluador emite un informe que debe ser confirmado en Estados Unidos por nuestros amigos del SEI.

Conclusiones

En resumen, CMMI, y más concretamente CMMI for Development, puede ser en mi opinión un estupendo modelo para la mejora de procesos en una empresa, si es que esta organización se adecúa al modelo, es decir: la organización persigue la mejora real antes que la certificación, está dispuesta a asumir el elevado coste que conlleva la implantación y evaluación y su tamaño y características evitan que CMMI suponga una elevada carga adicional a los proyectos.

<< Ver CMMI para principiantes (II)

CMMI para principiantes (II)

¿Eso de las prácticas, cómo va?

Es sencillo, y a la vez complejo. CMMI-DEV (El CMMI for Development del que hablé el otro día), se divide en áreas de proceso, 22 en total, que a su vez se dividen en metas para cubrir satisfactoriamente el área. Para complicar un poco más el tema, cada meta se compone de varias prácticas específicas, que son las que realmente nos aportan la chicha de lo que hay que cumplir. Por si fuera poco, además de haber una serie de metas y prácticas específicas por cada área, existen metas genéricas, con sus respectivas prácticas genéricas, que deben de cumplirse para todas las áreas. Incomprensible, ¿no? Veámoslo entonces con un ejemplo:

Una de las 22 áreas de proceso es REQM, Requirements Management. La gestión de requisitos, según CMMI, debe cumplir una única meta específica: gestionar los requisitos. De cajón. ¿Y qué es gestionar los requisitos? Eso se explica mediante las cinco prácticas específicas que componen la meta de gestionar requisitos. A saber:

SP1.1 Entender los requisitos: desarrollar un entendimiento sobre el significado de los mismos con sus proveedores.

SP1.2 Acordar los requisitos: obtener el acuerdo de todos los participantes en el proyecto.

SP1.3 Gestionar los cambios de los requisitos: gestionar los cambios mientras los requisitos evolucionan durante el proyecto.

SP1.4 Mantener la trazabilidad bidireccional de los requisitos: mantener la trazabilidad entre los requisitos y los productos de trabajo.

SP1.5 Asegurar la consistencia entre los requisitos y los productos de trabajo: mantener alineados los planes y el trabajo realizado con los requisitos acordados.

Además, la gestión de requisitos debe cumplir una serie de prácticas genéricas que son aplicables de manera transversal a todas las áreas (REQM no iba a ser menos). Éstas son, entre otras: establecer una política organizacional para la gestión de requisitos, diseñar y mantener un plan al respecto, proveer recursos, asignar responsabilidades, etc.

Las otras 21 áreas tienen una estructura similar, si bien pueden constar de más metas. Como se observa en el ejemplo de REQM, el modelo no explica cómo hay que implementar las prácticas, sino simplemente qué es lo que hay que obtener (entendimiento, acuerdo, gestión de cambios, trazabilidad y consistencia).

Pero… yo he leído que CMMI va por niveles, ¡no sabía nada de 22 áreas!

Paciencia. Existen dos representaciones alternativas que permiten trepar por CMMI en la búsqueda constante de la excelencia. Una es la representación continua, que permite seleccionar en cuál o cuáles de las áreas queremos mejorar y centrarnos en las metas y prácticas de ese área independientemente de lo bien que gestionemos las demás. Es una opción útil para organizaciones interesadas en la mejora de determinados aspectos del desarrollo, conscientes de sus debilidades y poco interesadas en la obtención de certificados, o al menos no obsesionadas con ello. Por ejemplo, una empresa puede estar preocupada por cómo se gestionan los requisitos y cómo se realiza la medición y análisis de los datos de sus proyectos y acudir por tanto únicamente a las áreas REQM y MA de CMMI, dejando de lado las 20 restantes.

Sin embargo, la opción más habitual es emplear la representación escalonada, que divide las 22 áreas en 5 niveles de madurez, de tal forma que las organizaciones poco conocedoras de sus propios defectos (la mayoría, para qué negarlo), obtienen una hoja de ruta sobre la que emprender su camino hacia la excelencia. Cada nivel supone cumplir las metas de una serie de áreas de proceso nuevas, y además, seguir cumpliendo las de los niveles anteriores. Una empresa que cumpla las 22 áreas de proceso y además satisfaga todas las metas genéricas, tendrá un nivel de madurez 5, la crème de la crème de CMMI. Sólo hay tres empresas así en toda España, así que nada de lanzarse en tromba a por el máximo nivel.

En el próximo post hablaré más en detalle de estos niveles y de cómo CMMI evalúa el grado de madurez de las organizaciones.

<< Ver CMMI para principiantes (I)

Ver CMMI para principiantes (y III) >>

CMMI para principiantes (I)

A lo largo de los próximos posts trataré de explicar brevemente qué es y en qué consiste CMMI, desde el punto de vista de un principiante que por el hecho de llevar pocos meses familiarizado con el modelo, conoce y aún sufre las dudas que asaltan a cualquier profano en la materia.

¿Qué es CMMI?

CMMI son las siglas de Capability Maturity Model Integration. Es un modelo desarrollado por el Software Engineering Institute para la mejora de los procesos de las empresas de software que califica las compañías según su nivel de madurez. Por proceso se entiende un conjunto de fases sucesivas que llevan a la obtención de un resultado, y por nivel de madurez, el grado de calidad que alcanzan los procesos. Recientemente el modelo fue aupado a la versión 1.3.

Así pues, y en pocas palabras, CMMI establece una serie de buenas prácticas que las empresas deben cumplir para ser consideradas de un grado de madurez determinado a la hora de generar resultados. Pero ojo: CMMI no te dice cómo llevar a cabo estas prácticas, simplemente te indica qué debes cumplir. Es cosa de cada empresa buscar el modo de cumplir con dichas prácticas (y es aquí donde comienza el gran negocio de los consultores en torno a CMMI, pero ésa es otra historia).

Existen tres tipos de CMMI, nombrados como constelaciones por algún gurú de las altas esferas. Está la constelación CMMI for Acquisition, para la mejora de procesos de contratación externa, la CMMI for Services, para el establecimiento y la entrega de servicios, y la que más nos interesa y de la que hablaré a partir de ahora: CMMI for Development, para la mejora del desarrollo de productos, esto es, software.

¿Y por qué tiene tanto prestigio?

Es una gran pregunta, pero lo cierto es que hoy en día CMMI es el certificado de moda para empresas de desarrollo de software por encima de otras muchas en principio igual de exigentes o completas. Atrae inversiones y genera clientela, eso es un hecho. Tal vez sea por tratarse de un invento americano auspiciado por el Departamento de Defensa, tal vez por la solidez de sus evaluaciones (conocidas como SCAMPI, y de las cuales hablaré otro día) o tal vez, quién sabe, porque realmente sea muy bueno.

En el próximo post hablaré sobre la división de CMMI en áreas, metas y prácticas y los diferentes caminos (dos, de hecho) que existen para certificarse en el modelo.

Ver CMMI para principiantes (II) >>