CMMI/Agile. Un híbrido que se viene – I

Posted on 23 diciembre 2008. Filed under: Calidad del Software, CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Testing, Trabajo en Equipo | Etiquetas: , , , |

He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI.

Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un híbrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles.

Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfocan en uno u otro modelo.

Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto.

Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes.

Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

Otro precepto que aleja CMMI de ágile (keep it simple).

Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero… ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear, …?

Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

4 comentarios to “CMMI/Agile. Un híbrido que se viene – I”

RSS Feed for CBASQA – Desarrollo de Software, SQA, Testing, Servicios Informáticos, Project Management Comments RSS Feed

CMMi Agile comentarios muy interesantes

Gerard, no dispongo de un “plan” genérico tipo receta de cocina para que puedas implementar mejores prácticas para el control de calidad. De hecho para poder diseñar un plan lo óptimo es que formes un proyecto inicialmente, tal cual como lo haría un Líder de Proyectos para construir un sistema.
Inicia con observaciones de las prácticas actuales tratando de comprender sus ciclo de vida completo, ten en cuenta para esto cuales son los elementos de entrada y salida para poder definir en concreto que es lo que se hace con esas prácticas en particular.
Luego te sugiero que te tomes una semana, dos o un mes para analizar las prácticas relevadas, sus contextos operacionales, sus entradas y salidas, sus procesos, haz esto mientras aprendes cada vez más del procesos de desarrollo completo en el que opera tu equipo. Haz esta actividad en forma cíclica es decir que nunca terminarás de relevar y analizar, pero debes al fin de cada fase de tu “proyecto” determinar que elementos son útiles, cuales se pueden despreciar y cuales se pueden mejorar.
Ten en mente la simpleza, sencillez y considera que los que ejecutan esas actividades son personas, no máquinas.
Siempre piensa en el inicio y fin dentro del horario normal de trabajo y con esto estimarás mejor los costos de las actividades de cada práctica y serás realista al ponderar los proyectos de calidad.
Si no se ajustaron aún a un modelo de calidad en particular, es posible que solo tengan un proceso informal o semi formal, pero no es necesario que sigas al pie de la letra otros procesos conocidos, como CMMI o ISO 9000/2001, aunque es muy bueno que los comprendas. Lo más importante ya te lo dije al principio; no hay recetas de cocina y no debes exigir que el equipo de trabajo se amolde directamente a un modelo o una norma y todos los procesos que implican. Lás mejores prácticas debes diseñarla.
Y la última sugerencia que te doy, es que nunca trabajes solo, por que nadie comprenderá tu trabajo. Inicialmente busca el consenso de las personas más importates, es decir la Gerencia, luego pide el apoyo de los líderes de los equipos, por ejemplo Líder de Proyecto y Líder de Desarrollo como también y fundamentalmente el del Líder de Testing, salvo que cumplas ese rol al mismo tiempo. Ten en cuenta y siempre recalca, que el objetivo de cualquier Software Factory, empresa IT o prestadora de servicios, es brindar productos y servicios dentro de los plazos establecidos, cada día más cortos, a los costos pactados, y con la mejor calidad posible a tal punto que se perciba tanto dentro como fuera de tu organización.

Saludos,
Javo.

Estimado Alejandro
recibe mis cordiales saludos, te comento que estoy encargado del area de control de calidad y quisiera saber si me podrias ayudar en ver como empiezo, ya que de eso depende mi estadia en la empresa, por favor me seria de mucha ayuda si me envias un plan ya echo para basarme en eso.

Alejandro:

Talvez tenga más éxito la mezcla con OpenUp, dado que es un derivado de RUP. No es quizás lo más ágil, pero no es el mastodonte RUP.

Mauricio.


Los comentarios están cerrados.

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: