¿CMMI o AGILE? ¿Juntos es posible?

CMMI tiene una carga y una exigencia que equipos conformados AGILE (típicamente pequeños) no pueden soportar, simplemente por que no tienen la estructura de personal. Al menos eso sucede con equipos para SCRUM.

Ejemplos sencillos son las exigencias de CMMI-2 sobre las Áreas de Proceso “Planificación de Proyectos” y “Aseguramiento de Calidad”, donde están vigentes los “Procedimientos de Planificación de Proyectos” y “Procedimientos de Estimación y Presupuestación”, como los “Procedimientos de Planificación de Calidad” y “Procedimientos de Auditoria y Revisiones”.

Estas solas áreas de procesos exigidas por CMMI-2 y sus correspondientes procedimientos pueden poner "en jacke" a quienes sostienen que con un equipo pequeño es posible certificar CMMI-2 o 3, dado que para solo cumplimentar las prácticas específicas para esos dos procedimientos que mencionas, necesitas de un equipo QA completo y al menos dos niveles de gerencia para escalar las aprobaciones.
La Planificación de Proyectos para CMMI es lo que me parece crítico y no es fácilmente adaptable a equipos SCRUM, por que es necesario formar y tener aprobado el Cronograma del Proyecto, lo cual por si mismo significa haber confeccionado un Plan de Iteraciones, Plan de Participación de los Interesados y un Plan de Integración, más un Plan de Riesgos, un Plan de Decisiones Técnicas y un Plan de Capacitaciones o certificar en una matriz de capacitaciones organizacionales, que para iniciar el proyecto el equipo del proyecto tiene las habilidades requeridas.
En lo que a calidad se refiere, debe existir documentación objetiva y sólida confeccionada por el Líder de Proyecto (no Gerente de Calidad ni Líder de Testing) sobre los Objetivos de Calidad y Performance y eventualmente utilizar procedimientos de Gestión de Cambios para modificar requerimientos u objetivos de calidad cuando existen contraposiciones y Procedimientos de Análisis y Toma de Decisiones para establecer esos cambios. Finalmente se debe registrar cuales objetivos se gestionarán estadísticamente.
Si quieres podemos hablar de las revisiones por pares, las cuales no están referidas a (pair programing) sino que son prácticas específicas para un muy alto porcentaje de los productos de software generados.
Todas estas decisiones, principalmente Gestión de Cambio y Toma de Decisiones, se realizan por comité organizacional.
Si considero interesante y posible que la agilidad se puede insertar en toda la organización con prácticas como SCRUM (…muchas otras…según), pero debemos conseguir de una vez por todas que nuestras soluciones de consultoría Agile trasciendan el ámbito del área de desarrollo, por que lamentablemente hasta el día de hoy son pocas las organizaciones que lograron traspasar esa barrera en las organizaciones de envergadura mediana o grande.
Un simple ejemplo es que ni a duras penas logran unificar un criterio para establecer prácticas en Testing o sostener un circuito de auditorías de calidad, sin pretender absorber este departamento QA hasta hacerlo desaparecer para conformarse en el equipo de desarrollo.
Para acercarme a una conclusión, estoy seguro que la simplificación de los procesos debe hacerse concienzudamente, sin ofrecer a las organizaciones "recetas de menudencias" que en un principio parecen ser buenas, pero a la larga podrían dejar el sabor insípido de la pérdida de prácticas que alimentan la base del conocimiento organizacional.

3 thoughts on “¿CMMI o AGILE? ¿Juntos es posible?

  1. Creo que se suele confundir, cuando se habla de Scrum, al equipo de desarrollo con el grupo de personas que hace código. Personalmente, y veo en el post, que estos elementos que aparentarían faltar encajan sin ningún problema en Scrum y por ende pueden ser llevadas a cabo. Creo que el problema principal de CMMi en niveles elevados es, más que nada, su carga burocrática que, a pesar de que puedas seleccionar partes del proceso en el inicio del proyecto y demás, se tiende a querer negar esta situación lo que lleva al encontronazo con Scrum, donde, si lo necesitas dentro de tu proyecto (documentacion, planes, etc.) no estas restricto a no poder agregarlos. Por ende, el equipo de testing, QA, y demás también son parte, en Scrum, del equipo de desarrollo, y los artefactos producidos son parte del mismo modelo. Actualmente estoy trabajando bajo Scrum en una empresa tipicamente CMMi nivel 5, y salvo algunos ajustes necesarios, no he visto conflictuada la puesta en marcha de Scrum (Hay más problemas culturales que de funcionamiento)

  2. Matías, en lo personal me sería muy útil que cuentes tu experiencia en Motorola utilizando SCRUM. Principalmente me interesa aquello que trascienda al equipo de codificadores.
    Sería muy bueno observar con detalle como se hacen las adaptaciones de procedimientos exigidos por CMMI-5 al modelo SCRUM, independientemente de lo referido a la documentación.
    Yo quisiera entender mejor como SCRUM facilita la interrelación de áreas independientes como QA & Testing en equipos de desarrollo Agiles.
    En mi experiencia, solo me fue posible concebir equipos independientes utilizando dos gestiones separadas, una para Desarrollo y Testing y otra QA. Ambas gestiones con el mismo Backlog de storys, pero con Sprint separados.
    Pronto me tomaré el tiempo de hablar de este modelo que adapté en su momento para poder seguir con mi gestión QA independiente de Desarrollo y otras áreas interesadas.

  3. Lo que comentas es un problema real y que pasa, típicamente, por problemas de adaptación cultural de la empresa y sus empleados, creo que la solución viene de la mano de que el equipo de Testing y Q&P (Separados), entiendan y apliquen Scrum a su modelo de trabajo. Con esto me refiero a que, dependiendo de la cultura organizacional y de las personas, estas tienen una modalidad de trabajo estructurada, muchas veces por años de trabajo bajo modelos documentales, con pasos rigurosos a seguir, basándose en un procedimiento estático. Es ahí, donde creo, se producen las asperezas y te llevan a lo que comentabas; tener equipos, con sprints separados entre otras cuestiones. Actualmente, tanto testing como desarrollo operan bajo el mismo backlog, pero noto la tendencia a la rigidez por parte de testing no pudiendo adaptarse fácilmente al modelo agile planteado. Ahora, esto no quiere decir que todo tenga que ser un caos, de hecho, tenemos muchas reglas que dan estructura a la agilidad, pero hemos limpiado aquellas que consideramos excesivas o innecesarias, dejando una estructura mucho mas liviana, que sigue manteniendo mecanismos de trazabilidad, calidad, entre otras cuestiones típicamente adjudicadas a modelos formales.

    Lo que se hace actualmente no es perfecto, pero cumple para los dos lados. Personalmente mejoraría bastantes cuestiones en lo que hacemos, pero nuevamente la cultura, mas que el proceso, se imponen. Tal vez, para describir mejor esto tendría que escribir varios posts🙂. Por lo que podría contarte personalmente mas detalles y luego plasmarlos de alguna forma.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s