– ¿Te gusta la agilidad? OK, lo suponía, eres fan de la agilidad.
– Y ¿te parece razonable controlar las versiones y gestionar la configuración software? Bien, sabía que ibas a decir que sí, que es necesario, para mí es de lo más importante.
– Por cierto ¿y qué hay de gestionar los requisitos (o historias de usuario), planificar el proyecto y realizar un seguimiento del mismo? Bien, sabía que ibas a decir que sí, que te parecen buenas prácticas.
– Una última. ¿Y un mínimo control de calidad y tener algunas métricas? ¿Qué opinas? Perfecto, en línea con lo anterior.
– Pues que sepas que todo lo que te pregunté antes, y que me dijiste que era necesario en un proyecto, es sintetizadamente lo que te dice CMMI (en nivel 2) que sería recomendable que incorporaras a tu proyecto.
– Mmm, entonces… Si pensamos lo mismo… ¿por qué hay tanto lío entre la agilidad y CMMI?
– En mi opinión, porque una cosa son las buenas prácticas que recomienda CMMI para un proyecto… y otra muy diferente presentarse a una auditoría (o evaluación) de las mismas. Y esto de la auditoría muchas veces “no es muy ágil”. Me explico….
Según la Guía de supervivencia en una auditoría CMMI, para preparar una auditoría (evaluación siendo rigurosos en la terminología) de CMMI nivel 2 se requiere que la empresa presente al auditor entre 816 y 1224 evidencias. Haciendo una estimación, si registrar una evidencia lleva aproximadamente 10 minutos de media (tirando por lo bajo), registrarlas todas, para presentarlas al auditor, nos llevará entre 17 y 26 jornadas de trabajo, prácticamente un mes o mes y algo. Y esto no es ágil.
Y aún hay más. Cualquier empresa utilizando Scrum, o cualquier metodología ágil, es muy raro que no mejore aún más incorporando buenas prácticas de CMMI. Hasta este punto todo es felicidad. Pero el problema viene cuando hay que preparar las evidencias para el auditor. CMMI me dice que gestione el proyecto, y prácticas de Scrum como el product backlog, sprint backlog, etc., cumplen perfectamente este cometido (si quieres profundizar en este punto te recomiendo este post).
Normalmente, prácticas como las de Scrum se generan de manera dinámica, se basan mucho en la interacción entre personas, se suelen usar pizarras, post-it, etc., pero… ¿Cómo le enseño yo al auditor esas pizarras? ¿Cómo le enseño que hicimos reuniones diarias (“daily meetings”)? ¿Cómo le enseño requisitos que tengo sintetizados en historias de usuario? (te recomiendo el post de la historia de usuario no es el “requisito” de las metodologías ágiles). Y aún peor, todo esto se lo tengo que enseñar meses después de haberlas creado.
La manera de resolver lo anterior, es incorporar «cosas» que algunos equipos consideran “artificiales”, como utilizar herramientas, documentar para tener evidencias, etc. Y esto no es ágil.
Pero recuerda para siempre… el problema de unir la agilidad con CMMI es de la auditoría de CMMI, no del modelo de buenas prácticas CMMI (siendo rigurosos en la terminología, el CMMI-Dev). Y puedes utilizar CMMI sin tener porque auditarte en el mismo…
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Pingback: Bitacoras.com
Pingback: Resumen semanal – del 4 al 10 de Junio - Javier Garzás, sobre calidad software y otros temas relacionados