Por dónde comenzar

En un grupo dedicado a CMMI, un participante preguntó: "es el área de REQM (gestión de requerimientos) un buen lugar para comenzar con CMMI?". Yo no me atrevía a contestarle, en parte porque no quería exponerme a una quema por hereje.

CMMI plantea un área de proceso de gestión de requerimientos (REQM) en su nivel 2 con un solo objetivo específico: gestionar los requerimientos. Puedo imaginarme que significa 'Gestionar los Requerimientos', pero si uno anda corto de imaginación, el SEI proporciona una guía.

El SEI define como único componente obligatorio del modelo de CMMI a los objetivos específicos y generales, mientras que las prácticas son componentes esperados (o deseables?). Menos obligatoria es la, emho, siniestra lista de productos típicos (que es capaz de incluir un producto llamado ‘lista de criterios para distinguir las fuentes apropiadas de requerimientos’), así que nos quedamos solo con la descripción del objetivo.

La idea, según la definición de CMMI, es mantener un conjunto de requerimientos aprobados y consensuados a desarrollar. Ni más ni menos que un backlog.

Nada en la definición de CMMI dice que ese backlog no debe cambiar, ni que el nivel de consenso debe ser el mismo para todos los requerimientos del backlog. Es perfectamente posible que convivan en el backlog requerimientos de los que se tiene un entendimiento profundo con algunos que son comprendidos vagamente. Si esto no fuera aceptable para CMMI, daría lo mismo: sería inevitable. El problema viene cuando uno trabaja en un entorno donde no se acepta que los niveles de entendimiento diferentes generan grados de compromiso diferentes.

La gestión de requerimientos según CMMI implica mantener las relaciones entre los requerimientos y de estos con el plan de proyecto y los productos producidos. Esto es algo que uno puede hacer en la forma tradicional, armando planillas donde se relacione cada requerimiento con cada tarea identificada con cada producto de trabajo. Y cada producto podría ser un componente identificado en los modelos de diseño. Y lo mejor, hacer todo eso de entrada, antes de tirar una sola línea de código.

También se podría entender que el producto en un producto de software es el módulo a ser desplegado. Así, un determinado requerimiento está relacionado con un cierto build de una cantidad de módulos (si tenemos un proyecto grande), y la relación entre un requerimiento y el plan se completa indicando la fecha en que suponemos liberaremos el requerimiento, si es que la sabemos. Y por supuesto, no tenemos que entender como encajan todos los requerimientos antes de comenzar a desarrollar el primero, porque el entendimiento es un proceso iterativo.

Yo veo una pequeña diferencia entre las dos opciones, y es que la primera es irrealizable.

Además, CMMI también indica la necesidad de la gestión de cambios de requerimientos. Los agilistas acuerdan (acordamos) en que el control de cambios no debería servir para impedir el cambio, pero es útil conocer la tasa de cambio de un backlog porque es útil saber cuan bien venimos entendiendo el producto a construir.

Además, me gustaría agregar un detalle: recuerdo los valores ágiles de responsabilidad, honestidad, y demás virtudes. Pero ocurre que la gente es gente, y cuando las papas queman y alguien pregunta por determinados retrabajos o por qué se ha invertido seiscientas horas de desarrollo en algo que debería haber tardado doscientas, no es descabellado esperar que quien nos ha guiado a través de un camino sinuoso intente endilgarle la responsabilidad a otro. Quiero decir: que un Product Owner que nos ha hecho trabajar y retrabajar haciendo una cosa y luego la contraria continuamente intente explicar el poco valor conseguido luego de un tiempo considerable hablando de la falta de habilidades técnicas de los programadores.

Pienso que quizá no todos los requerimientos del backlog deban ser sometidos al control de cambios, solo aquellos donde se ha consensuado un cierto nivel de entendimiento, ya que muchos requerimientos del backlog ingresan a él simplemente como recordatorios de que algo hay que hacer respecto de un determinado tema. Pero aún así, el control de cambios es necesario.

Así planteadas las cosas, no se si el área de REQM es un buen lugar para comenzar por CMMI. Lo que me queda claro es que si no se ha comenzado a pensar como gestionar los requerimientos de un proyecto de software, no se está en condiciones de comenzar el proyecto. Dicho de otra manera, REQM no es un buen lugar para comenzar con CMMI, es un lugar por el que tenés que comenzar salvo que quieras llevar tu proyecto al desastre.

CMMI y la agilidad: el largo y sinuoso camino a la paz

Ya había escrito sobre el asunto, basado en lo que SEI había publicado alguna vez. Hace unos meses, el SEI publicó un artículo mucho más extenso sobre la relación de CMMI y Ágil, analizando la historia de CMMI y del enfoque ágil, los problemas de comunicación entre ambas comunidades, y de la posibilidad de coexistencia.

En el enfrentamiento (si es que se puede usar esta palabra) entre ambos paradigmas, es el SEI el que, desde hace un tiempo, se ha encaminado a mostrar que la confrontación es, no solo innecesaria, sino que perjudicial.

Por su parte, la comunidad ágil, en tanto comunidad, no tiene una voz unificada: las reacciones que he escuchado incluyen la declamación de victoria (el SEI se rinde ante la victoria de la agilidad y no quiere perder su base de cliente), la indiferencia, o el acuerdo con la visión del SEI. Yo tiendo a compartir esta última opinión.

En este artículo, que no es una excusa para no leer el documento original, recorro los puntos que me parecen más interesantes. El documento se defiende de las acusaciones que relacionan CMMI con cascada, diciendo algo que es cierto: CMMI es básicamente un conjunto de objetivos, y las prácticas no son más que puntos de partida que sirvan para guiar al que adopte CMMI en la forma de lograr esos objetivos.

CMMI no es un estándar, lo que hace que esas prácticas no sean obligatorias. CMMI está injustamente asociado con el desarrollo en cascada: las prácticas y los objetivos no son procesos, nada específica que se deban ejecutar en un determinado momento del proyecto. El documento desliza críticas a sus propios appraisals por no tener en cuenta que CMMI no establece requerimientos, sino un marco para organizar el análisis y las acciones de mejora, diciendo textualmente que:

"However, for people and organizations that do not have the skills or experience to understand, interpret, and implement the practices and goals to their specific contexts, the informative material takes on the mantle of requirements. This situation is also true for appraisal teams and lead appraisers. Thus, the over-emphasis on specific model examples, typical work products, and subpractices often results in prescriptive processes with little gain in quality or organizational performance. "

Salvando el hecho de que a pocos puede culpar el SEI más que sí mismo de este problema (tal vez debe revisar a quienes le da patente de appraiser) la frase me parece gran resumen: el problema es que se toma el marco de CMMI, pensado para guiar y ayudar a pensar, analizar y actuar como requerimientos que toman la fuerza de mandamientos.

Yo veo un problema adicional, e iría más lejos: veo valor en CMMI, pero no veo valor en la certificación de CMMI. El hecho de que el mismo SEI cuestione a sus appraisals en un documento público no mejora mi apreciación de la certificación precisamente. Pero el problema, emho, no es este (que es coyuntural) sino otro (más bien estructural): yo en mis procesos de desarrollo hago unas cuantas cosas, que tienen que ver con algunas áreas de proceso de CMMI (como por ejemplo Verificación, Validación y hasta Análisis y Resolución de Decisiones), pero no me detengo a dejar 'rastro' (documentos formales) de estas actividades porque decido que no aportan valor. Eso provoca que un SCAMPI juzgue que mi proyecto no cumple con los objetivos de esas áreas de proceso. Me encuentro con un problema: si bien el proceso aporta valor, para llegar a la certificación tengo que perder valor.

Definitivamente, y dejando de lado cuestiones comerciales, la certificación no agrega valor.

Otro aspecto interesante del documento es su análisis histórico. Se hace una recorrida por la historia del desarrollo de CMMI, partiendo de los problemas del DoD y su necesidad de resolverlos. Admite que la asociación Cascada/CMM está justificada, ya que CMM se focalizaba en una serie de procesos y actividades que intentan obtener la descripción acabada de lo que hay que hacer antes de comenzar. Es una pena que no pueda ver de primera mano esto, ya que nunca leí nada de CMM de primera mano del SEI y han retirado la especificación, dejando solo información para la actualización de una a otra.

Menciona, además, algunas características del entorno que vio nacer a CMM: se trataba de un entorno donde lo que se buscaba era cubrirse, no buscar la mejor solución. Esto estaba generado por la naturaleza de entidad estatal del DoD y su necesidad de registración y transparencia para cualquiera que preguntara que se estaba haciendo con el dinero público, la forma de contratar y la naturaleza de los problemas que resolvían: software relacionado al control de aviones, misiles, instrumental médico y cosas por el estilo. Este último punto (negar la agilidad para desarrollos donde esté en juego la vida humana) es discutible, y no lo tengo claro: aplicaría un método ágil para construir el software de control de un misil?.

Como dice el artículo, lo que puede aportarle CMMI a un enfoque ágil son métodos y prácticas para apoyar y guiar la adopción de metodologías ágiles en una organización: básicamente, foco en la definición e integración de los equipos y el proceso. No es que no se pueda guiar la adopción de un enfoque ágil en una organización grande y compleja sin CMMI, pero CMMI ayuda a que los esfuerzos de adopción y expansión del enfoque ágil no queden en el folclore oral de la organización.

Asimismo, se reconocen algunos puntos que ningún agilista está dispuesto a negar: en necesario acordar una visión global de la arquitectura, a veces es necesario escribir documentación y, en definitiva, sin algo parecido a un proceso nos vamos al demonio.

Es muy interesante la comparación que se hace entre el paradigma ágil y CMMI en una serie de puntos. En particular, me interesaron dos puntos:

• El primero, que tiene que ver con el foco en la organización: mientras CMMI se focaliza en la organización completa, el paradigma ágil se focaliza en cada proyecto y en el equipo. Creo que vale la pena recordar que la focalización en la organización puede llevarnos al peligro de querer optimizar el funcionamiento de la operación de la organización y no del proyecto, y esto es, definitivamente, un peligro. Trato de explicarme: puestos a mirar la organización como un todo, nos podríamos sentir tentados de reducir los tiempos muertos de un equipo de analistas, cuando en realidad, desde el punto de vista de un proyecto complejo y particularmente sensible, es conveniente asumir esos tiempos muertos. No veo mayor problema aquí siempre que se recuerde que, a veces es conveniente que el foco esté en el proyecto antes que en la organización.
• El segundo, es el que tiene que ver con la confianza: el paradigma ágil requiere la confianza casi como un prerrequisito. Yo veo esto como una debilidad, porque a veces, hay que hacer cosas aún cuando no hay confianza entre las partes. Vamos, en algún momento se empieza y uno no confía la primera vez.

Y por último, lo mejor: el SEI me da la razón a mí (ja) en que la evidencia de que la agilidad funciona es, hoy por hoy, puramente anecdótica. Esto no implica que la agilidad no funcione, sino que es necesario un esfuerzo de formalización de los resultados.

La agilidad y CMMI

Luego de haber pasado por unos cuantos proyectos de desarrollo, he visto cosas que ustedes sí creerían (porque ustedes también las vieron, que no me refiero a naves de guerra en llamas más allá de Orion, ni rayos C resplandeciendo en la oscuridad). Y luego de haber visto tan terribles cosas,tengo un par de conclusiones apresuradas:

• Cualquier proyecto de desarrollo de sistemas debe manejar el cambio, no intentar impedirlo. Intentar impedir el cambio (en el entorno, en las especificaciones, en el equipo de trabajo), es similar a buscar la fuente de la eterna juventud.
• Muchas organizaciones necesitan adoptar marcos que les permitan, entre otras cosas, darle visibilidad a la ejecución de proyectos, delimitar responsabilidades, ser predecibles y construir una historia que pueda ser explotada con el objeto de saber donde deben mejorar.

La primera conclusión me hace mirar con simpatía las metodologías ágiles (debo -admitir que solo conozco XP) y la segunda me hace pensar en la necesidad de un marco formal y más riguroso, al estilo CMMI (que no es exactamente un metodología, sino un marco ). Un prejuicio ( el marco más comunmente usado para tomar decisiones ) me decía que no se podía estar a la vez de un lado y del otro: o sos ágil y desordenado o sos lento, paquidérmico, y eso sí, muy ordenado.

Conforme fui conociendo más de CMMI y XP, el prejuicio se fue debilitando ( es notable cuan perniciosa es la información y el conocimiento para la supervivencia de los prejuicios ), y hasta encontré que el SEI ya lo había contestado (no es exactamente CMMI, sino CMM, pero es una lectura recomendable).

Como sabemos, CMMI establece los famosos cinco niveles, con áreas de procesos en cada una de ellas. Cada área de proceso tiene objetivos específicos y prácticas específicas para cumplir sus objetivos. XP, por su parte, consiste en una serie de buenas prácticas asociadas al desarrollo del software.

Ninguna de estas es, como dirían los americanos del norte, rocket science: se trata de sentido común y lecciones aprendidas por la industria durante muchos años, llevadas al extremo en el caso de XP.


XP y CMMI, punto por punto …

… o más o menos, simplificando las áreas de proceso de manera caprichosa, vamos a recorrer las similitudes:

Requerimientos: CMMI plantea dos areas relacionadas con requerimientos en los niveles dos y tres: gestión de requerimientos y desarrollo de requerimientos, con foco en la elicitación, definición, verificación, validación y control de los requerimientos. XP plantea integrar un usuario o representante del usuario (como un jefe de producto) al equipo, con el objeto de que sea él mismo quien defina sus requerimientos, esté disponible permanentemente para consultas y pueda dar feedback sobre la implementación de los requerimientos luego de cada release.

Planificación y control: con XP estamos planificando continuamente: antes de cada iteración se recolectan requerimientos (‘user stories’, para XP), lo que se explica con la metáfora del carrito de compras: se recolectan user stories hasta colmar la capacidad del carrito (o sea, la capacidad de trabajo del equipo). La planificación es explícita (se seleccionan las user stories a implementar en cada release) y se actualiza continuamente, se estima el esfuerzo requerido para cada story y se planifica cada iteración antes de comenzar. El avance de cada iteración se monitorea durante las stand up meetings. La métrica de project velocity (la suma de la estimaciones de las stories implementadas en la iteración) proporciona una idea de la performance del equipo de trabajo. El avance global del proyecto se mide de forma muy conveniente por la cobertura funcional, es decir, por el porcentaje de user stories implementadas.

Quality Assurance, Validación y Verificación: la práctica de pair programming, la propiedad compartida del código y la integración continua refuerzan el foco de XP en QA. El código es verificado dado que se programa en pares que se verifican muamente. Más aún, se pueden incorporar al proceso de integración continua herramientas de verificación estática. XP hace foco en los test unitarios (toda clase o componente debe tener sus test unitarios) y los test de aceptación, que pueden ser perfectamente automatizados.

Gestión de la configuración: las releases sucesivas y cortas requieren una gestión de la configuración importante, aún cuando XP no lo mencione explicitamente: sin una adecuada gestión de la configuración, las prácticas de releases cortas, propiedad compartida de código e integración continua son imposibles.

Gestión de Riesgos: si bien XP no incorpora una práctica específica de gestión de riesgos, la integración continua, la disponibilidad permanente del usuario y las iteraciones cortas son, en definitiva, las políticas de mitigación para los riesgos más frecuentes en los procesos de desarrollo de software. Asimismo se recomienda acomodar las stories más problemáticas en las primeras releases para tener tiempo de corregirlas, lo que ayuda a mitigar los riesgos más comunes en los proyectos de desarrollo

Métricas y Análisis de las métricas: o existe en XP una práctica específica de análisis de métricas, pero el proceso produce métricas que pueden ser analizadas para identificar áreas de mejora. Las métricas como project velocity, bugs encontrados, cobertura de los test, errores de integración son producidas por el proceso y las herramientas que lo soportan.


Donde comenzamos a diverger

Existen algunas divergencias entre CMMI y XP, en particular, en áreas de proceso que adquieren mayor importancia conforme el número de integrantes del equipo de trabajo crece.

No existe ninguna práctica en XP asociada a las areas de proceso con foco en la organización, que tienden a asegurar la adherencia de toda la organización al proceso y encausar las actividades de mejora en toda la organización.

XP no posee ningún foco en estructurar guías de arquitectura al inicio del proyecto, lo que puede ser necesario para equipos grandes que trabajen en un desarrollo desde cero y no en mantenimiento. Esto último puede corregirse implementando primero las user stories más significativas desde el punto de vista de la arquitectura y que sirvan como molde, pero aún así, en determinados contextos la documentación de diseño puede ser necesaria ( en otros, puede ser absolutamente innecesaria y contraproductiva).

La práctica del refactoring continuo puede no ser extensible a grandes equipos, donde sea difícil mantener la visión global del producto a construir, o, al menos, donde es complicado que todo el mundo la tenga.


Mis personalísimas conclusiones

XP propone unas cuantas ideas que cualquier equipo de desarrollo que no quiera verse inmerso en un gran quilombo haría bien en seguir, como la planificación continua, el monitoreo de avance en virtud de lo que se hizo y no de lo que se supone que falta, el testing, tanto unitario como de aceptación, el diseño simple y el no tratar de resolver problemas que uno no tiene hoy.

De todas maneras, puedo pensar en contextos donde implementar XP en todo su esplendor sería peligroso: en los proyectos llave en mano, donde se asume de antemano un compromiso en tiempos y costos, no solo no tendremos a un cliente sentado aquí para que nos diga que quiere, sino que no podemos soportar el cambio continuo (tenemos que ganar dinero). Por otra parte, un compromiso inicial en tiempos y costos requiere un entendimiento inicial de todos los requerimientos, y un cambios en estos últimos podría significar un cambio en los primeros aspectos. En estos casos, seguimos sin poder anular el cambio, pero podemos saber cuando ocurre, por qué ocurre y que cambios adicionales (en tiempo y costos) se generan por un cambio en los requerimientos y el marco de CMMI nos ayuda a hacerlo.

Creo también que conforme el equipo crece en tamaño se necesita más foco en los aspectos organizacionales de la metodología, la gestión y el diseño y arquitectura

En definitiva, como dice el artículo del SEI linkeado más arriba, la postura extrema de XP requiere un management competente, y en eso se enfoca CMMI, por lo que un enfoque que complementario entre XP y CMMI puede ser valioso.


Fuentes:
Extreme Programming from a CMM Perspective, Mark C. Paulk
Planning Extreme Programming, Kent Beck
Extreme Programming Explained, Kent Beck