¿CMMI y Ágiles? Es más complejo…

En base a recientes lecturas me vinieron a la mente aquellos días en los que fui partícipe de un SCAMPI, el modelo de evaluación de CMMI. Previamente, había tenido experiencias en metodologías ágiles. Posteriormente también y, de hecho, con mayor intensidad. Pero no muchas veces había pensado sobre estos “dos mundos” en conjunto.

Primero lo primero: ¿qué es CMMI? Básicamente es uno de los estándares internacionales más reconocidos utilizados por la industria del software y servicios informáticos para la evaluación y mejora de procesos. ¿Cuáles son los otros? Podríamos mencionar a ISO 9001, más generalista, e ISO 15504 (SPICE), más utilizado en el desarrollo de software de la industria automotriz.También podríamos mencionar a Six Sigma, aunque definitivamente es más generalista que los anteriores y más bien utilizado en manufactura.

Segundo lo segundo: ¿qué son las metodologías ágiles? Son diferentes prácticas y enfoques surgidas a mediados de la década de 1990 y afianzadas a partir de la firma del “Manifiesto Ágil” de 2001 por un grupo de personas preocupadas porque la gestión de los proyectos de software dejaba mucho que desear (sí!, incluso más que ahora!). Este grupo de personas acordaron que las personas, el software funcionando, el cliente y la apertura a los cambios era más importante que las jerarquías, los procesos, la documentación, los contratos y la mayoría de las cosas que consideraríamos necesarias a la hora de firmar cualquier contrato.

Lo más interesante es que las metodologías ágiles no prometen falsas promesas. De hecho, son muy sinceras. Demasiado, tal vez. De alguna forma el “equipo ágil” le dice al cliente: “no tengo idea de lo que saldrá tu software, ni para cuándo lo vas a tener listo, pero te prometo que cada poco tiempo te voy a ir entregando pedacitos para que veas y me digas qué te parece”.

Esta es una contraposición fuerte con respecto a la metodologías tradicionales, cuyo mejor adjetivo es “predictivas”. ¿Porqué? Por que se preocupan en tener en sus fases iniciales claramente definido el alcance (claro, como si el cliente supiera lo que quiere, vamos!), el costo, los recursos y materiales involucrados, el cronograma, riesgos y un sinnúmero más de cosas. Puede resultar un poco más sensato en las industrias tradicionales, como la manufactura y la construcción, pero cómo prever lo mismo en algo tan abstracto como un software. Al fin y al cabo, si pides que te construyan un edificio de 3 pisos, no a muchos se les ocurriría decir al final de la obra “¿porqué no agregamos 10 pisos más?” Pero en desarrollo de software estas cosas sí suceden: “y ahora podríamos agregar un módulo de gestión de proveedores?”. Si, claro que se puede. Al fin y al cabo es “más fácil” modificar un software corriendo en “la nube” antes que llamar a revisión miles de coches vendidos por una falla detectada “un tantito tarde”, ¿no?

Sepan disculpar las simplificaciones del caso, ya que no es la idea profundizar demasiado en definiciones formales más extensas. Nos conformaremos, de momento, con este brevísimo “a be cé”.

Parecerían dos posiciones contrapuestas. Dos visiones casi apuestas. Las “ágiles” versus las “predictivas”. Y definitivamente lo son, para qué les voy a mentir. En el momento en la que una dice “cronograma fijo” y la otra dice “si quieres que te mienta, te miento, sino vamos avanzando y vemos a donde llegamos”, ¡desde ya que son opuestas!

A todo esto, ¿dónde entra CMMI? Bueno, va bastante en consonancia con las metodologías tradicionales, predictivas, básicamente porque parecerían no importarle demasiado los preceptos de Manifiesto Ágil, desde el momento en que este pone a las personas y sus interacciones explícitamente por encima de las herramientas y procesos. Procesos. Es la palabra clave. Es lo que dicen las ágiles que no deben ser el foco. Es lo que dicen los estándares internacionales, como CMMI, que es lo que hay que mejorar. Que la calidad del producto de software es consecuencia de un buen proceso, y no de las personas y la comunicación con el cliente. Procesos. Es en lo que se basan las metodologías tradicionales.

No es que las ágiles desprecien a los procesos, tampoco es la idea. De hecho, metodologías ágiles como Kanban dicen que “lo importante no es el proceso, sino el proceso para mejorar el proceso”. Scrum también ES un proceso en sí mismo. XP (eXtreme Programming) propone sentarse y reflexionar periódicamente sobre el proceso utilizado. El “problema” es que delegan en el mismo equipo (siempre autoorganizado, sin jerarquías) esta cuestión de los procesos. Aquí estamos llegando a algo: al final el proceso era importante para todos. Pero ágiles y predictivas le dan una impronta totalmente distinta.

CMMI propone 5 diferentes niveles de madurez a través de la implementación incremental de prácticas de gestión específicas. Se supone que un nivel de madurez 5 implicaría que la organización está compenetrada en experimentar en sus propios procesos y con el fin de mejorarlos. Se supone que esto llevará a una mejora en la calidad del producto desarrollado, a la vez que se mejora la productividad, se reducen costos, aumenta el ROI, aumenta la felicidad del cliente y el equipo trabaja extremadamente motivado.

Las ágiles dicen que si el programador programa, recibe feedback del cliente, se autogestiona con sus colegas, hace entregas periódicas, y reflexiona sobre su forma de trabajar, todo esto traerá una mejora en la calidad del producto desarrollado, a la vez que se aumenta la felicidad del cliente y el equipo trabaja extremadamente motivado.

¿Entonces…?

Entonces entendamos que no todo es color de rosas y, a pesar de las expectativas,  estos enfoques tienen sus bemoles.

Tendré que ser autoreferencial y hablar de lo vivido y conocido. Por lo que haré una crítica a cada modelo desde un punto de vista personal:

  • Tradicionales: ser predictivo y acertar, es un oxímoron en el desarrollo de software.
  • Ágiles: dejar en manos de un grupo autocontrolado la mejora de sus propios procesos… es, al menos, dudoso de asegurar que ocurra

¡Vamos! No le vamos a pedir a un banco que firme un contrato sin ningún parámetro concreto  que indique duración o costos de un proyecto. Pero tampoco es simpático que un grupo de técnicos, lideres, analistas, expertos y gerentes reciban órdenes de cómo hacer su trabajo por parte de gente que no participó directamente de un proyecto de software hacer 20 años (un cariño para Sandrita).

Es un buen caso de “es más complejo”.

Miremos el vaso medio lleno: ¿qué cosas buenas y complementarias nos aportan ambos modelos? Sigamos concretamente con CMMI y las principales metodologías ágiles (Scrum, XP y Kanban).

CMMI:

  • Ordena: da un marco de referencia de cómo trabajar en proyectos similares
  • Mide: lo que no se mide, no se puede mejorar (ya lo sabemos)
  • Vende: algunos grandes clientes siguen valorando el modelo de mejora de procesos, lo cual puede resultar en un buen argumento de marketing
  • Separa las responsabilidades: se lleva como un proyecto en sí mismo, con su propio equipo dedicado a analizar indicadores, capacitar/difundir las prácticas, realizar las auditorías, PENSAR los procesos…

Ágiles:

  • Foco: lo importante es el software y la mejor medida de avance de un proyecto es el software funcionado
  • Aporta realismo: estima en base a las necesidades concretas que el cliente le manifiesta al equipo (se evitan los niveles de indirección que tanta subjetividad aportan al proceso de estimación)
  • Priorización: el cliente (en sus diferentes formatos) es el que decide por dónde avanzar junto con el equipo
  • Abierto al cambio: es visto como parte del proyecto y de las necesidades del cliente. Luchar contra el cambio y documentar excusas es una forma de confrontar con el cliente

¿Podría pensarse en una convivencia feliz?

Hay algunas evidencias publicadas en el sitio del SEI (Software Engeneering Institute, la “cuna” de CMMI) sobre experiencias mixtas, pero poco convincentes. Y no son muy recientes. Ni tampoco abundan.

Más allá de esto, podría llegar a plantearse un escenario complementario de convivencia realista:

  • Equipo de procesos: los procesos tienen que estar pensados en función con lo que equipo técnico necesita, no pueden ser definidos por terceros, más allá de lo eruditos que pudiesen ser. Es el barro de la trinchera lo que se está definiendo.
  • “Evangelización” de procesos: en contraposición con las decisiones anárquicas, evitando “héroes”. Lo que funciona en un proyecto, es posible que le sirva a un proyecto similar, ¿para qué reinventar la rueda?
  • Prácticas ágiles de desarrollo: integración continua, revisión de pares, desarrollo guiado por pruebas (TDD), refactoring, entregas interativas e incrementales periódicas
  • Prácticas ágiles de gestión: revisiones y “demos” con el cliente, retrospectivas, estimaciones tipo poker planning, comunicación (MUCHA comunicación) directa entre cliente y equipo

El programador, programa. El equipo de procesos mide y propone mejoras en los procesos. En conjunto toman las decisiones con base estadística. El agua y el aceite no se mezclan, pero pueden estar en el mismo recipiente. Si el “fin final” es entregar productos de mejor calidad, ¿porqué deberían estar enfrentados, si comparten el mismo objetivo? ¿Porqué no reconocer los puntos en los cuales los modelos se complementan?

Bueno, me imagino varios “porqués”:

  • Status quo: alguien debería lidiar con los egos para que cada uno ocupe el lugar que le corresponde, sin invadir límites ajenos ni boicotear objetivos antipáticos a los intereses personales (que siempre los hay)
  • Costos: no solamente vamos a tener dos equipo de personas (procesos y técnicos), sino que alguien deberá coordinarlos
  • La justa medida: ¿quién es el que pone los límites? ¿El Chief Process Officer o el Chief Technology Officer? Porque tampoco le vamos a pedir al Executive que lo haga… ¿o si

En teoría suena sensato. Al menos, de nuevo, desde mi experiencia.

En la práctica seguro que “es más complejo”.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *