¿CMMI-ML4 en 4 Meses?... reto superado

Qué es lo primero que cruza por su mente cuando le dicen “Necesitamos el Nivel 4 de CMMI-DEV y tenemos como plazo 4 meses para lograrlo, tenemos datos, aunque no sabemos de qué calidad y el equipo no está del todo “contento” con este proyecto, ¿Cómo ves? ¿Te lo avientas?”

Ya imaginan mi expresión al escuchar esta propuesta. La palabra Imposible cruzaba por mi mente, sin embargo algo me hizo continuar escuchando y me di cuenta que en esta organización no se buscaban culpables ni pasar bolitas, lo que buscaban eran soluciones. Así que ante esa premisa el reto como tal era bastante interesante y así comenzó la aventura que resultó todo un éxito.

Antes de adentrarse en este tipo de aventuras uno tiene que entender el contexto sobre el cuál está parado. Esta organización ya venía trabajando durante mucho tiempo con técnicas de PSP y TSP, habían venido recolectando datos de procesos durante ya un par de años, sin embargo los cambios estructurales y las salidas de personas claves habían hecho decaer la implementación de procesos lograda hace un año. Era como tener un auto Mercedes Benz arrumbado en la cochera de la casa, con un par de golpes, lleno de polvo y la maquinaria desengrasada, sí andaba, pero todo le sonaba y era demasiado para las nuevas necesidades de la empresa.

La primer pregunta que se harán estimada audiencia es, ¿por dónde se empieza en un proyecto así? La respuesta es: Consolidando a un gran equipo de trabajo.

Se debe contar con un líder de equipo con una visión clara del proyecto, personal con la experiencia en proyectos similares y con roles claramente definidos y el compromiso total de los sponsors; así y sólo así, uno puede animarse a trabajar en un proyecto de estas características.

Pero vayamos por partes, al inicio el líder del proyecto tenía claro que para afrontar un proyecto de este tipo tenía que tener la combinación correcta de personas y la estrategia de “divide y vencerás” fue ideal.

Se separó la parte de baja madurez y a cargo de esa parte se dejaron dos personas responsables que se encargaron de asegurar que la organización tuviera las prácticas claramente definidas e implementadas. Esto ya existía de trabajo previo en la organización, así que lo único que se tenía que hacer era asegurar que los equipos de desarrollo recobraran la orientación a procesos.

El responsable de procesos y el responsable de aseguramiento de la calidad fueron los roles clave para asegurar que esto estuviera en su lugar y funcionando.

Para lo relacionado con la alta madurez se necesitaba experiencia y una estrategia clara sobre la orientación del trabajo. Ahí se consiguió a un responsable de mediciones con experiencia en las prácticas de alta madurez que ayudó a dirigir las acciones comenzando, obviamente, desde la dirección.

Se hizo un análisis de los objetivos de negocio que tenían y a partir de ellos se definió una estrategia que fuera lo más ligera posible y que se basara en los datos históricos que habían venido generado de un par de años mediante las técnicas de PSP y TSP. La calidad fue la piedra angular en esta implementación, la organización ya contaba con datos relacionados con los defectos, las fases donde se inyectaban y dónde se detectaban, sin embargo habían olvidado un poco el valor de las revisiones que se hacían.

Esto fue importante porque necesitábamos una estrategia en la cual involucráramos a los responsables de la operación, es decir a los desarrolladores, analistas y responsables de pruebas de los proyectos quienes veían con malos ojos que se les presionara con un proyecto “externo” de CMMI.

De ahí que buscábamos su completa colaboración con este proyecto pero no desde el punto de vista impositivo, sino más bien desde el punto en el cual sintieran que se generará valor a su trabajo con lo cual buscamos asegurar que su adopción fuera más sencilla.

Trabajar con revisiones por pares fue lo que comenzó a agregarnos valor, las revisiones por pares son procesos que consideramos como críticos para medir la calidad del trabajo en cuestión y necesitábamos darles alternativas para que no se sintieran forzados a hacerlas por el hecho de cumplir sino por el contrario para comenzar a valorar su uso.

Antes de comenzar con el proyecto lo más común era que el cliente estuviera detrás del equipo de trabajo molesto por la cantidad de errores que encontraba, desesperado porque no sentía que las entregas tuvieran la calidad necesaria y la constante era que devolvieran el trabajo con una lista anexa de todos los defectos detectados con lo cual se tenía que posponer el paso a producción del sistema.

Mediante la elaboración de un modelo predictivo basado en las estadísticas de capacidades de inyección y remoción de defectos se ayudó a que el equipo visualizara el comportamiento que había estado teniendo durante las más recientes entregas y cómo esos defectos que no estaban siendo detectados en etapas tempranas del proyecto eran descubiertos en última instancia por el cliente.

Este modelo sirvió para dar retroalimentación continua y rápida del desempeño del equipo justo después de que se realizaban las revisiones entre colegas, con esto ellos podían visualizar el resultado de las revisiones y cómo afectaban a la entregas, la fortuna era que, como se trataba de un modelo de predicción, les daba la ventaja de anticiparse al resultado y fomentar la realización de más y mejores revisiones entre pares.

El equipo observaba los resultados, veía las gráficas y detectaba inmediatamente los problemas con sus revisiones debido a que usaban gráficos de control que les permitían conocer si los procesos que seguían se comportaban como lo esperado y en caso contrario el mismo equipo comenzaba a cuestionarse el porqué de las anormalidades.

Como resultado, en tan sólo 2 iteraciones del proyecto, la cantidad de reclamos y devoluciones que el cliente hacía del producto disminuyeron significativamente, al punto de escuchar a los mismos miembros del equipo de desarrollo decir asombrados “Wow, nunca pensé que nos fueran a aceptar el producto a la primera”.

El resultado, como imaginarán apreciable audiencia, fue el reto superado, el equipo de desarrollo percibió el valor de las revisiones dentro de su forma actual de trabajo mientras que iban cumpliendo punto por punto las buenas prácticas del modelo y con esto logramos el objetivo de asegurar el paso a la alta madurez.

Intellego página web - http://www.jaguarlabs.com/

Resultado publicado del SEI - https://sas.cmmiinstitute.com/pars/pars_detail.aspx?a=21075