miércoles, 29 de enero de 2014

¿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

miércoles, 20 de febrero de 2013

El salto a la alta madurez en 2 años

Pocas son las ocasiones que una organización que sin ningún nivel formal de CMMI, se anima a dar un brinco gigante de estar en un nivel 1 (Inicial) a un nivel 5 (optimizado), y todo esto en menos de 2 años. Se necesita coraje y depositar la confianza en la gente que lo rodea para saberse ayudar en la toma de decisiones, pero al final del camino el logro sabe a la gloria misma. Intellego Software Development Services (antes Certum) se dejó asesorar por los mejores consultores de Qualtop y Liveware quienes le introdujeron en el excitante mundo de la alta madurez de CMMI.


Características de la Organización

Intellego es una compañía líder en servicios de Tecnologías de Información (TI) . Está conformada por más de 1,200 profesionales con operaciones en México, Brasil, Chile, Colombia y Estados Unidos. Intellego cuenta con una sucursal en el norte de la Ciudad de México donde consolida un equipo de profesionales en ingeniería de software que desarrollan productos a la medida para grandes corporativos del país. Cuentan con equipos de trabajo de gran calidad caracterizados por ser profesionales auténticos en el ciclo de vida de desarrollo de software. Los proyectos no distan de ser tan comunes como los que cualquier otra organización en la que me ha tocado participar, equipos de aproximadamente 4 a 6 personas, con una buena mezcla de conocimientos, hay analistas, arquitectos, codificadores, testers y obviamente el líder de proyecto sobre quien recae el control administrativo del proyecto así como el liderazgo y gestión de las necesidades internas y de los clientes.

Como se inició

Intellego tiene la peculiaridad de contar con una mentalidad muy firme con respecto a sus objetivos, son muy ambiciosos y no toman un no como respuesta. La decisión de adentrarse al mundo de CMMI confirma esta mentalidad puesto que se plantearon el objetivo de lograr a ser CMMI-DEV-ML5 en 1 año sin contar anteriormente con un nivel acreditado de CMMI.
Como todo proyecto de mejora de procesos, se comenzó haciendo una evaluación del estado de las cosas para saber en donde estábamos y que tanto esfuerzo sería necesario para llegar a nuestro objetivo.
Intellego es una empresa con más de 10 años en el mercado y durante estos años han sido muy disciplinados para documentar y medir sus procesos, lo cual se vio reflejado durante la primera evaluación puesto que, a pesar de no contar con una implementación completa de todas las áreas de proceso del modelo alcanzaba para en un año lograr como mínimo el nivel 3.
Sin embargo siempre se fue claro que, el objetivo deseado era el nivel 5, así que se fijó ese objetivo como guía y arrancamos con el proyecto.

Comenzamos definiendo la parte organizacional, OPF, OPD y OT para dar un buen sustento al responsable de proyecto por parte de Intellego, quien sería el responsable de llevar a cabo las diferentes tareas de definición y capacitación en el uso de los procesos. Un punto a favor de Intellego es que, al no ser una empresa novata en el rubro, tenía ya consolidada bastante información de sus procesos, lo cual hacía que MA estuviera bastante implementada y solo faltara ordenar un poco sus necesidades de información.
Intellego como empresa líder desde siempre ha tenido claro la necesidad de un buen liderazgo en las organizaciones, por esta razón es que las áreas de proceso de CMMI asociada con administración de proyectos tales como PP, PMC, IPM y RSKM fueron relativamente sencillas de implementar, lo único que se necesitó fue que el Grupo de Procesos de Ingeniería de Software (SEPG - Software Engineering Process Group) fuera con los equipos prácticamente a “extraerle” el conocimiento de los líderes de proyecto y transformarlo en procesos definidos. El paso siguiente fue asegurar la correcta implementación de manera horizontal para que todos los proyectos siguieran los procesos. El rol clave ahí fue PPQA puesto que se encarga de asegurar la calidad de los procesos y los productos que son definidos por el SEPG. Ahí vino el primer reto, conseguir un buen PPQA.
Muchas veces estos roles son complicados de conseguir en primer lugar por el hecho de que la gente técnica es reacia a adentrarse al camino de las técnicas de mejora de procesos y aseguramiento de la calidad (no software testing sino PPQA a la CMMI) por considerar que estos puestos demandan una “documentitis” la cual no se lleva bien con su naturaleza técnica de resolución de problemas que tiene el personal técnico.

Lo más importante: un buen equipo

Si me permiten dar un consejo en este punto, cualquier empresa que tenga una firme convicción de lograr cualquier nivel de calidad debe tener al mejor equipo de su lado y la selección de un buen responsable de PPQA es la clave en todo esto, como lo fue para el caso Intellego.
Y no solo eso, Intellego también contaba con un experimentado responsable de mejora cuya experiencia en la parte de administración de proyectos fue crítica.
Cuando se busca implementar CMMI en una organización hay cosas que son asumidas por el modelo y una de ellas es que, existe un responsable de procesos que tiene suficiente experiencia en Administración de Proyectos. Me atrevería a decir que una de las razones por la cual las implementaciones de CMMI son dolorosas es precisamente esa, que las organizaciones no cuentan con un responsable de procesos dedicado al 100% en el proyecto y que también sus capacidades de gestión de proyectos es bastante pobre, pero no fue el caso para Intellego.

Para mediados del primer año del proyecto de acreditación, Intellego contaba con 2 roles clave dentro del equipo del SEPG. Los líderes de proyecto comenzaron a alinearse a las necesidades de la organización oponiendo la resistencia típica de cualquier persona que es inducida al cambio viniendo de una organización que ya su historia había comprobado mucha eficiencia en su trabajo y en sus proyectos.
Sin embargo hacía falta un rol clave para alcanzar la alta madurez que es el Responsable de Mediciones.
Al contrario de los niveles de baja madurez de CMMI (2 y 3) el rol como tal de Responsable de Mediciones no es algo crítico, ni tampoco es considerado como una necesidad apremiante para las empresas de baja madurez, sin embargo, para la alta madurez es crítico como lo es a su vez conseguir a alguien con las características necesarias para satisfacer el rol. Esta persona llegó para finales del primer año de proyecto y fue un gran aporte, dado que con su visión externa logro en un par de meses encaminar los esfuerzos para lograr el tan ansiado nivel 5.
En este punto contábamos con un equipo completo.

Enfoque, la palabra clave

A finales del primer año teníamos que tomar una decisión muy importante, lanzarnos de filo sobre la alta madurez o solamente llegar hasta el 3er escalón.
Intellego no es una organización cuyo objetivo principal es implementar procesos de CMMI, el negocio de Intellego está dado por la elaboración de proyectos de alta tecnología que cumplan con lo que ellos llaman el trinomio de la calidad: Confiabilidad, Tiempo de entrega y Costo.
Las necesidades de negocio de la organización en algunos momentos del proyecto llevaron a la necesidad de distraer a los miembros del SEPG para ubicarlo en otras tareas, esto hizo que el esfuerzo se disipara y que el proyecto de acreditación tuviera que postergarse al menos por un par de semanas. Esas semanas generaron una especie de efecto dominó lo cual llevó a la organización a decidir que se llegaría primero al nivel 3 pero el día siguiente de la evaluación el objetivo estaba claro, nivel 5 tenía que llegar ese mismo año.
Dirección se aseguró que dicho enfoque se diera, el personal del SEPG no iba a ser distraído de sus labores, los líderes de proyecto y mandos medios tenían como prioridad cumplir las necesidades del modelo sin descuidar el trinomio de calidad.

La estrategia hacia la alta madurez

Se había logrado la acreditación de nivel 3 de manera sobresaliente, se contaba con el entusiasmo de los equipos de proyectos y del SEPG para continuar por el camino hacia la alta madurez, pero ¿contamos con la capacidad cuantitativa para lograr un proyecto de alta madurez?
Esta pregunta fue resuelta mediante un taller realizado por Liveware que tiene como objetivo conocer la capacidad que tiene una organización para conocer sus procesos de desarrollo de software de manera cuantitativa. Dicho taller tomo 2 días y arrojó buenas noticias. Si bien no todas las áreas revisadas dentro de este taller contaban con suficiente nivel de granularidad para considerarlas como óptimas, si dio buenos presagios sobre el continuar con el camino hacia la alta madurez. Con esto lo único que faltaba era la estrategia para lograrlo.

Lo primero que se estableció fue mejorar las revisiones por pares que realizaba la organización, que, curiosamente, resultó ser una de las prácticas donde se detectaron algunas debilidades durante el SCAMPI A de nivel 3.
El responsable de mediciones se encargó de organizar los planes y de coordinar las estrategias de la organización para traducirlas en aspectos específicos del proyecto de alta madurez, mientras tanto el responsable de PPQA junto con el líder de proyecto tenían la tarea de asegurarse que las prácticas de nivel 2 y 3 se mantuvieran.
Se conformó también un equipo de “Champions” adheridos al SEPG que se encargarían de investigar las innovaciones necesarias para cubrir OPM y también para encontrar alternativas de los subprocesos críticos que ayudaran a tener de donde escoger al momento de hacer la administración cuantitativa de proyectos (QPM).

El responsable de mediciones se aseguró de obtener las revisiones necesarias, de consolidar los datos asociados a la confiabilidad (defectos, tiempo de corrección, etc.) y con esta información se realizó el primero modelo de predicción basado en simulaciones de Montecarlo.
También, para el tiempo de entrega, el responsable de mediciones se encargó de consolidar toda la información relacionada con los esfuerzos de los procesos y subprocesos para desarrollar un modelo de estimación, también basado en simulaciones de Montecarlo.

Las líneas base para dichos procesos y subprocesos fueron creados y usados para ser comparados con las innovaciones planteadas y con esto asegurar la implementación de las prácticas de nivel 5, específicamente para OPM.

El resultado

Con la palabra “enfoque” como estandarte de trabajo, los miembros del equipo del SEPG, siguieron a detalle el comportamiento de los procesos críticos, se aseguraron de que los procesos se llevarán a cabo como estaban estipulados y analizaron los resultados constantemente para conocer las tendencias.
Identificaron una gran mejora en la manera de realizar las revisiones por pares lo cual fue clave para asegurar la confiabilidad de los productos de trabajo y motivar la confianza de los líderes de proyecto en el trabajo que venían desempeñando día con día.
Dichos líderes comenzaban a sentirse confiado en los resultados de las revisiones y en los resultados de las predicciones de sus modelos, sentían la certeza de conocer los resultados antes de llegar a las etapas críticas del proyecto y en caso de que algo estuviera desviándose de los límites naturales de control de sus procesos, contaban con suficiente tiempo para ver soluciones con su equipo de trabajo y/o con los clientes.
El espíritu de la alta madurez había sido instalado exitosamente en todos los niveles de la organización, haciendo que la evaluación de nivel 5 fuera un mero trámite y no una experiencia llena de dolor y frustración.


Referencias

Intellego página web - http://www.intellego.com.mx/es


Acerca de 
Ra Acosta es un asesor de mejora de procesos bajo el modelo de CMMI-DEV. Actualmente se encuentra desarrollando un proyecto propio nombrado bossacorp, brindando asesorías a empresas del giro cinematografico y enfocado a la codificación de software creativo y la producción audiovisual.

jueves, 27 de diciembre de 2012

Aspectos clave de un plan de mediciones

El comienzo de un buen camino de la medición está dado por entender, antes que nada, que queremos medir, que objetivos tenemos como organización que me lleve a buscar los mejores métodos de medición y de toma de decisiones.
Las buenas practicas de los modelos de calidad hacen que inevitablemente tomemos como base las enseñanzas de autores como Edward W. Deming quien con su famoso circulo de calidad nos ayuda a tener un patron de trabajo para lograr la excelencia.

Las practicas son sencillas:
- Identifica tus objetivos y necesidades (y documentalos)
- A partir de ellos asegurate de identificar que mediciones serán las que te ayudaran a saber si estas cumpliendo o no tus objetivos
- Define como analizaras dichas mediciones, por lo menos, identificando que gráficos utilizaras para dichos análisis.
- Una vez que obtienes mediciones, realiza el análisis según lo planeaste, aprende de los resultados  y refina tu documento de mediciones.

Llevar a cabo este proceso por repetidas ocasiones hará que en algún momento llegues a ser un especialista de mediciones.

Realizamos un webinar para software guru donde se explican estas características.
Características esenciales de un Plan de Métricas

miércoles, 23 de mayo de 2012

¿Todo lo que hacemos es verdaderamente autentico?, ¿nunca se han puesto a pensar que a alguien mas se le puede haber ocurrido lo mismo que se nos ocurre?.
Kirby Ferguson (@goodiebag) es un cineasta americano que ha logrado un maginifico trabajo con su serie de cortometrajes llamados "Everything is a Remix", cuestiona el valor de la propiedad intelectual y de las ideas, y como en general los buenos productos son el resultado de cosas que ya se han hecho antes y que simplemente se han ido refinando.
Realmente recomendable esta serie de documentales, dense tiempo...