Lycka Bonita

Recién firmada la tercera propuesta recibo otra noticia que afectará al proyecto : CMMI aparece en escena ya que mi empresa quiere alcanzar la certificación de CMMI de Nivel 2 a final de año, y pasar a Nivel 2 es más duro de lo que me pensaba, y a CMMI Nivel 3 a final del año siguiente. 

CMMI no es una metodología, es una guía que te dice qué es lo que tienes que hacer, no cómo lo tienes que conseguir. Persigue convertir un artesano en un ingeniero.

En la auditoría sobre CMMI se nos dice que supondrá una sobrecarga de trabajo del 10% en nuestro proyecto actual. Yo lo puse en duda en su momento, creo que supondrá una mayor sobrecarga en el trabajo (del rol de Jefe de Proyecto por cierto, no de un Desarrollador o Pruebas), y me temo que para cumplir en tiempos tendré que currar más de lo que recomiendan los médicos

Empresas ágiles y tradicionales ?

Cuando me entero me choca la noticia porque la filosofía de mi empresa es utilizar software libre y metodologías ágiles, lo que según yo tenía entendido va un poco en contra de las metodologías tradicionales (en las que por cierto el software de pago es el rey).

Además nuestra empresa es bastante pequeña y vertical y asumir CMMI implicará hacer escalones y perder comunicación y agilidad. No tengo claro que merezca el sobrecoste de CMMI para las ventajas en marketing que nos aportará, el tiempo lo dirá.

Metodologías, para qué servirán ? Para entendernos una metodología ágil es medir 1 vez y cortar 2 veces : vamos recortando y probando (iteración) hasta que encaja bien; una metodología tradicional es medir 2 veces y cortar 1 : nos aseguramos que la medida es correcta, marcamos y así nos aseguramos de hacerlo bien a la primera.

Es por eso que ninguna es mejor que la otra, simplemente cada una es más adecuada según las circunstancias. Cuando el cliente lo tiene MUY claro las metodologías tradicionales ofrecen mejores resultados : abaratas costes y obtienes un producto de mayor calidad en menor plazo. Sin embargo cuando el cliente no sabe muy bien lo que quiere, como es el caso en este proyecto, las metodologías ágiles ofrecen mejores resultados : vas enseñando funcionalidades poco a poco y el cliente va solicitando modificaciones sobre la marcha (iteraciones) para asegurarse de obtener al final exactamente lo que quiere. 

Qué metodología es mejor ?

No es la pregunta acertada, la pregunta acertada sería

Qué metodología cumple mejor con mis necesidades ?

Lo importante es saber utilizar las dos metodologías y acertar a la hora de cuál emplear según cada situación.

En este proyecto, nuestra empresa es ágil pero intentando adoptar ciertas costumbres tradicionales y el cliente es tradicional, pero después de tres propuestas no creo que tengan las cosas muy claras. En el mismo proyecto utilizar agilidad y tradicionalidad simultáneamente ? Después de valorarlo más detenidamente entiendo que no es contradictorio.

Otro cambio más en el proyecto ?

Este proyecto en concreto estaba enfocado utilizando una metodología ágil sin pensar en CMMI. Ahora que este proyecto va a ser foco para la certificación en CMMI por parte de mi empresa, hay que hacer nuevos reajustes.

Pones más esfuerzo en CMMI ? Es decir, documentar bien, gestionar los cambios de requisitos, y sobre todo cerrar bien el alcance para poder ofrecer un presupuesto cerrado.

O pones más esfuerzo en adelantar trabajo e ir enseñando al cliente indeciso ? Al dar visibilidad cuanto antes al cliente te arriesgas a más cambios y más errores que depurar al final pero te aseguras de que finalmente el cliente tiene lo que realmente quería.

Qué hacer en este caso ? Pariremos un híbrido ágil – tradicional : necesitamos las dos ventajas (es necesario acotar al máximo el alcance y tener un documento firmado sobre el que partir para cerrar un presupuesto, pero también es necesario dar transparencia del trabajo al cliente indeciso). Tendremos que pagar sus dos costes.

Por un lado debemos reflejar esa sobrecarga del 10% en el trabajo, representada por varias nuevas tareas y rutinas como reuniones de seguimiento. Un 10% ? Y hay que documentar. Y para escribir algo en un documento tienes que arrancar un consenso. También tenemos que cambiar algunas plantillas de documentos y generar más entregables. Ese 10% sale por supuesto del margen (o debería de decir del no-margen?).

Por otro lado cada iteración implica re-documentar, así que debemos reducir al máximo el impacto de cada iteración. Para ello planificamos con cuidado cada hito y entregables, dando lugar a cuatro entregas.

• Una primera demo sólo para presentar el look&feel de la aplicación. Tiene truco, ya que es el mismo utilizado en el otro proyecto y es un requisito inamovible, así que no nos generará trabajo extra.
• Una primera versión con el 75 % de las funcionalidades, que no esperamos que acarree mucho trabajo, quizás unas pocas incidencias preventivas.
• Una versión beta sobre la que probar y corregir.
• Una versión final.

Manos al CMMI

Pero… y aprender a trabajar según CMMI ? El aprendizaje es uno de los grandes olvidados en nuestro sector, junto con las pruebas, la documentación, los riesgos y la calidad. Una presentación en power point de una hora es todo el aprendizaje que recibimos Aitor y yo, del que salgo con más dudas que cuando entré (lo que es bueno porque pensaba que sí sabía cosas que en realidad no sé como líneas base).

LLega un poco más tarde de lo que me hubiese gustado, llega en la tercera propuesta. Pero me alegro, siempre cuesta más hacer las cosas por primera vez y adoptar CMMI en un cliente ya conocido con una tecnología ya conocida ayudará a capear este sobrecoste.

Entre las vacaciones y las movidas diarias del proyecto… a ver si cuando nos estabilicemos un poco todos sacamos tiempo para meterle mano a CMMI.

Actualización Diciembre 2010

Por un lado Kotasoft no conseguirá la certificación de nivel 3 este año, y no consiguió la certificación de nivel 2 el año pasado, ni siquiera dio el primer paso que se dice en cualquier libro, curso y auditoría : un escrito de la dirección informando del cambio, pidiendo el esfuerzo y resaltando las razones y ventajas. La situación de partida no era mala, pero a día de hoy creo que la empresa ha empeorado perdiendo a dos excelentes profesionales que iban en esta dirección y dando peso a personas que van en la dirección contraria.

El balance que hago a día de hoy es que sí merece la pena, es gastar pesetas para ahorrar duros y conseguir una velocidad de crucero mayor en el futuro. 

Por otro lado el proyecto no pasaría nunca la certificación, ya que sin la colaboración del cliente es imposible. Pero lo que sí podemos hacer es intentar cumplir con lo que estaba en nuestra mano, ya que las buenas prácticas son buenas por algo y la experiencia de 50 años para algo valdrá. El pero fue abandonar otras tareas más críticas en el inicio del proyecto como el diseño o la supervisión, ya que hemos sufrido estos errores durante toda la vida del proyecto y cuesta enderezar el rumbo.

No related posts.