CMMI experiences [I] – Introducción

Bueno!, han sido unas semanas muy duras… pero al fin hemos terminado con la evaluación SCAMPI para CMMI nivel 2.

MadurezAntes de continuar, aprovecho para hacer una reflexión:

El modelo CMMI no tiene demasiados adeptos en el mundo del software, ya que el esfuerzo que exige, es grande y no se obtiene valor añadido a corto plazo. De hecho, yo estaba en ese grupo de gente, que le gustaba mas seguir metodologías de desarrollo ágiles, las cuales no me exigian cierta “burocracia” a la hora de gestionar mis proyectos y podía profundizar mas en el ámbito tecnológico. El caso es que, al verme “forzado” a aprenderlo y aplicarlo, con el tiempo… me he dado cuenta, que es un modelo que me ha aportado muchas cosas… ¡he aprendido mucho!, pero sobre todo, ahora tengo mucho mas control sobre mis proyectos. Es por ello que ahora me encuentro en “el lado oscuro de la fuerza”, ¡Que nadie piense que es síndrome de Estocolmo! … esta reflexión sale desde la razón, y a día de hoy me considero un firme defensor del modelo. Habrá gente que piense “bueeenooo, un purista a darnos clases de gestión de proyectos”… No pretendo!! únicamente contar como me fue y como, la cantidad de cosas buenas, que me aportó el modelo, me hizo inclinar la balanza. Bien! pues una vez aclarado esto, voy a contar como son este tipo de auditorías y las cosas buenas que me ha aportado este sistema de trabajo.

Han sido una serie de entrevistas duras en las que han participados numerosos miembros de la empresa y han tenido que contestar a preguntas de todo tipo relacionadas con cada una de las areas de proceso en las que hemos sido auditados:

  1. REQM – Gestión de Requisitos
  2. PP – Planificación de Proyectos
  3. PMC – Seguimiento y Control de Proyectos
  4. SAM – Acuerdos con Proveedores
  5. MA – Medición y Análisis
  6. PPQA Aseguramiento de la Calidad de Procesos y Productos
  7. CM – Gestión de la Configuración

La evaluación, como ya he dicho, ha sido dura. El evaluador realiza una serie de entrevistas personales de una hora y media de duración en las que te pone a prueba, te “dispara” con preguntas de los diferentes áreas de proceso, algo parecido a un interrogatorio, intentando detectar alguna debilidad en alguno de los áreas de proceso, tratando de buscar la institucionalización. Este tipo de evaluaciones orales y personales, van orientadas a identificar el nivel experiencia que tienes con proyectos reales bajo el modelo CMMI. No sirve de nada, sólamente, estudiar la teoría… es necesario tener experiencia, diaria, gestionando proyectos CMMI.

A continuación voy a lanzar una serie de preguntas como las que te puede hacer el auditor:

¿Serías capaz de …?

  1. Identificar las tareas y pruebas funcionales relacionadas con un requisito concreto
  2. Identificar las partes de código fuente a las que afecta un cambio de requisito
  3. Decir cuando se realizó una tarea en concreto y la cantidad de esfuerzo que supuso
  4. Realizar una estimación precisa de una tarea que ya realizaste en algún proyecto anterior
  5. Listar las tareas que tienes pendientes en un determinado módulo de tu proyecto
  6. Decir el tiempo restante para terminar un módulo de tu proyecto
  7. Sacar un listado de las incidencias de un proyecto y la desviación en esfuerzo, tiempo y coste
  8. Sacar un listado de las peticiones de cambio de un cliente
  9. Certificar que los requisitos del proyecto han sido entendidos y comprometidos por el equipo de trabajo
  10. Identificar, si una prueba falla, que requisitos se ven afectados
  11. Entregar una versión del producto, mas o menos estable, al cliente, ahora mismo
  12. Decir el porcentaje de contrucción del producto o proyecto
  13. Certificar el coste actual, “on the fly”, del producto
  14. Decir los riesgos activos que hay en tu proyecto
  15. Enumerar las personas dedicadas al proyecto y el porcentaje de ocupación
  16. Decirme cuando queda liberado un recurso en concreto
  17. Decir las medidas correctivas que has tomado cuando has tenido desviaciones
  18. Contar lo que se habló en la ante última reunión de seguimiento con el cliente
  19. Enumerar las tareas y esfuerzo que te va a suponer la puesta en producción

Con esta pequeña muestra intento dar una idea del nivel de control de proyectos que exige el modelo.
Como ya he dicho, a mí, personalmente me ha enriquecido mucho, aunque no tenía mucha fé en ello, cuando comenzamos, ya hace más de un año y medio.

Es muy interesante la parte de histórico de estimaciones, trazabilidad, planificación, auditorías, métricas… si el tema despierta interés, en futuras entradas comentaré cada área de proceso por separado, que cosas buenas tiene y también las malas, que también creo que las hay, intentando dar una visión objetiva, personal y en base a la propia experiencia.

Me gustaría poder terminar recomendando algún libro o web que de una visión real del proceso, pero no he encontrado nada, al menos fácilmente legible, entendible y práctico.

Espero, al menos, haber despertado curiosidad por el CMMI y aportado un punto a favor de este modelo tan criticado, creo que en la mayoría de los casos por desconocimiento, y que se tenga en cuenta, como una opción para aportar calidad o madurez al desarrollo de software.

 

19 comentarios en “CMMI experiences [I] – Introducción”

  1. Hola!!

    Una pregunta,el consultor conocía otras metodologías? sabías dar razones a favor o en contra para el uso de uno u otra metodología?

    Yo también he estado metido en una implantación de Scrum y los consultores que vinieron fueron de risa….sí, nos hacías esas preguntas, yo creo que la mismas!! porque realmente es la checklist de preguntas que siempre se hace y que cualquier puede hacer….

    ¿ Tienes una lista de riesgos que….? Pues igual no la tengo, porque no la necesesito, porque no gestiono los riesgos de una forma explícita….al consultor sólo le interesa SI o NO.

    Un saludo!

  2. En tu post hay algo que me llama la atención. Y es la comparación entre agilidad y falta de documentación. Ya que dices que ahora llevas un mejor seguimiento de tus proyectos, o sea, con CMMi 2. Digo que me llama la atención porque he estado escuchando muchos mitos urbanos referentes a esta situación, diciendo que la agilidad es sinónimo de desorden, o de descontrol, o como quieras llamarlo. O sea, si eres ágil no debes planear, no debes controlar, no debes documentar, y no debes todas las cosas que el “formalismo” te dice que DEBES si o si, hacer. Donde trabajo, somos CMMi 5, y al mismo tiempo tenemos proyectos bajo Scrum. Y hasta ahora no he visto problemas de compatibilidad para satisfacer los dos lados. En todo caso, es posible que antes, la agilidad que realizabas no fuera necesariamente agilidad.

  3. Por fin te animastes a escribir sobre CMMI. La primera impresión en comparación con Scrum es “Complejidad y control exaustivo”, desde luego mayor control hace tambien que la burocracia aumente, veremos si es tan complejo como aparenta y me hago una pregunta ¿ una empresa pequeña de 5 o 6 empleados seria capaz de aplicar un modelo CMMI tal y como lo utilizaís vosotros ?. Es muy interesante que hables de experiencias propias.

    Saludos.

  4. Atento gente… no confundir: CMMI es un modelo de maduración empresarial… una manera de hacer las cosas para ir mejorando los procesos internos en una empresa de software, y validarlos contra un modelo ya probado, y Scrum (y similares) son Metodologías de desarrollo de software. Esto quiere decir que se puede seguir un modelo CMMI con Scrum, o con XP, tranquilamente. En CMMI sólo hay que cumplir con las prácticas del modelo, no importa la metodología que uses.

  5. Agustin, por eso preguntaba en mi comentario anterior. Porque me resultaba llamativo el post en algunas partes. O sea, como si los dos mundos se repelieran mutuamente.

  6. No esperaba encontrar tanto comentario tan pronto, voy aclarando por puntos.
    @Ibón, No se si el consultor era conocedor de otros métodos de trabajo, aunque estoy casi seguro que si. Han venido a evaluar si reálmente estamos siguiendo un modelo y aunque las preguntas iniciales, si es cierto que salían de un checklist, despues había una batería de preguntas derivadas e improvisadas, que no eran de checklist. Con respecto a los riesgos me parece muy importante tratarlos, catalogarlos, gestionarlos… al igual que una tarea mas (con su importancia, gravedad, fechas, impacto, medidas correctivas o preventivas si proceden…)
    @Matias, ¡pareces enfadado! En ningún momento he mencionado falta de planificación, gestión, documentación,… la documentación puede estar en un wiki y ser mas útil que un documento en base a una megaplantilla. No comparo agilidad con CMMI, lo que intento reflejar, es que nosotros tambián hacemos scrum, pero encima de todo esto se ha puesto una capa organizativa de si quieres llamarlo “burocracia” y esto me ha mermado, al menos de momento la agilidad que tenía primero.
    @Juan, Sinceramente creo que este modelo no es productivo para proyectos pequeños y hablo de proyectos y no de empresas.

  7. Para nada enfadado, lo que pasa que me hizo un poco de ruido esto que pusiste: “…De hecho, yo estaba en ese grupo de gente, que le gustaba mas seguir metodologías de desarrollo ágiles, las cuales no me exigian cierta “burocracia” a la hora de gestionar mis proyectos y podía profundizar mas en el ámbito tecnológico…” junto con esto: “…he aprendido mucho!, pero sobre todo, ahora tengo mucho mas control sobre mis proyectos…”

    Digo, me hizo mucho ruido el hecho de que se vinculara la falta de control con la agilidad. Esto lo digo porque suele ser un comentario comun a la hora de plantear cual forma de trabajo o metodolocia usar en los proyectos (dependiendo del tipo de proyecto, claro). Muchas veces los grandes defensores de los procesos aseguran que el motivo por no usar metodologias como Scrum se debe a que pierden control sobre lo quep asa en el proyecto, o extremos como que no se planifica :S, algo que dista completamente de la verdad, ya que por eso se habla de metodologías y no de procesos que tienden a la estandarización. O sea, hay una diferencia entre: HAZ ESTO. A: SI LO NECESITAS, HAZLO.

    En fin… creo que se entiendo por donde iba mi duda. Pero para nada enfadado. No podría estarlo al estar trabajando en una empresa que, como dije, es CMMi 5, además de ISO 9000 😉

  8. A mi lo que más me llama la atención del tema, es que yo podría contestar todas y cada una de la preguntas del auditor pero:
    1) Sin burocrácia
    2) Sin tener que haber invertido la autentica burrada que cuesta una implantación de CMMi.

    Evidentemente que CMMi tiene beneficios. Una gestión explicita por mala que pueda ser mejor que cero gestión. Es el ratío coste beneficio lo que yo discuto de CMMi. Eso y que imponga la misma burocracia a todos los proyectos.

    Miguel, te apuesto una cena en el restaurante que elijas, a que una vez certificados y en el plazo de un año la mayoría de vuestros proyectos no se gestionan siguiendo CMMi… y eso que solo estáis en el nivel 2, que razonable. (Solo es una disculpa para vernos y charlar del tema, jajajajaj….)

    ¡Un saludo!

  9. Ya sabía yo que me iba a meter en un buen fangal!! en el que no iba a contar con mucho apoyo, pero estoy convencido que es una buena opción.

    @Matias, insisto en que a mi me ha aportado mas control… un control, que he de reconocer, que antes no tenía. No digo que las metodologías ágiles no aporten control. Y ya que me has insistido tanto en el tema del nivel CMMI, te diré que hay mas diferencia del nivel 1 al 2 que del 2 al 5, y por cierto nosotros tambien tenemos un montón de certificados de calidad: http://www.cic-sl.es/calidad/Calidad.aspx, creo que todas esas certificaciones te aportan algo cuando aprendes cosas y cuando estas convencido de sus beneficios.

    @Rodrigo, no me esperaba menos que una apuesta en formato gastronómico 😉 … CMMI, en la organización, es opcional para proyectos de menos de una cuantía económica determinada, en desarrollo (sin hardware). Pero si, acepto la apuesta!! La implantación del modelo ha costado mucho a la compañia, te lo puedo asegurar, pero estoy convencido que nos va a aportar muchas cosas. No digo que sea el mejor sistema de trabajo, pero si defiendo que es un buen sistema, y que me a aportado mucho conocimiento.

    Estoy convencido que hay equipos de trabjo sin ninguna certificación que trabajan estupendamente, pero yo creo que al final… en esencia, este tipo de certificaciones no son mas que un filtro, que indica que no eres un chapuzas en la gestión.

  10. Cena a la vista? jaja yo como muchos de vosotros también he pasado el trago de un SCAMPI y una certificación CMMI nivel 2. Como comenta Ibón, mismo checklist 😉 Nuestro consultor de apoyo era de Bilbo, muy majete, pero que no me dio ninguna impresión de controlar de forma real la gestión de proyectos más allá de las directrices de CMMI. Ya no trabajo en la empresa que se certificó en CMMI, pero según sé esta empresa está invirtiendo grandes esfuerzos por “agilizarse” y migrar a SCRUM… yo creo que no pasaron 6 meses antes de tomar esta decisión 😀 Un abrazo

  11. Personalmente prefiero los modelos ágiles, y en lo que explicas sobre más control del proyecto es verdad -en una estructura en base a la desconfianza (así algunos definen CMMI)- pero ¿que pasa si desapareces del proyecto o tu empresa?. Es por eso que prefiero el “caos” de ágil que el control jeráquico total de CMMI por ejemplo. En ágil todo el equipo está informado de todo. Y agregaría otra pregunta: ¿Si le hago esas mismas preguntas a cualquier otro integrante del equipo respondería lo mismo?

  12. Hola Porquero! la respuesta es rotunda: SI!
    Una de las principales cosas que busca el modelo es la institucionalización, no lo busques en wikipedia 😉

  13. Y no nos olvidemos de uno de los principales beneficios que nos aporta el ser CMMI nivel 3 (en mi caso), y es el poder optar a concursos de proyectos para el Ejército Americano, el cual te exige que seas CMMI nivel 3.
    Un saludo a todos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *