La primera decisión

La primera decisión que debemos tomar cuando implantamos Team System en un proyecto u organización es ¿MSF CMMI o MSF Agile?, o lo que es lo mismo madurez o agilidad. Existe una tercera via, utilizar nuestra propia metodologia, pero para que esto sea viable, debe existir una metodologia que podamos llevar a Team System y eso rara vez ocurre. Y me refiero a una escrita blanco sobre negro, lo que ocurre menos aún.

Y una cuarta, utilizar alguna de la otras métodologias que existen para Tema System y sobre las que ya hable anteriormente.

Cuando planteo esta cuestión en los proyectos en los que participo, sea como parte activa de los mismos, como formador o como consultor, la primera respuesta es la misma siempre, agilidad.

Sin duda mucha gente no conoce a fondo las diferencias entre los dos enfoques y elige agilidad guiada por la fama de CMMI de ser excesivamente burocrático. El razonamiento que lleva a esta elección es, «lo ultimo que necesito es burocracia, ya tengo bastante trabajo». Además, ¿A quien no le tienta la agilidad? Es una característica positiva, todos preferimos ser ágiles, tener un coche ágil, una hipoteca ágil, un proyecto ágil…

Con posterioridad, hasta ahora en un gran porcentaje de casos, se ve que la respuesta primera es errónea. Tratare de explicar porque.

CMMI no es burocrática, aunque muchas de sus implementaciones prácticas en empresas si lo son. De hay viene la inmerecida fama CMMI establece una serie de niveles de madurez en el proceso de desarrollo de software, para cada uno de los niveles establece una serie de objetivos a cumplir para

alcanzarlo, pero nada dice de como se cubren esas metas. Antes de Team System, las organizaciones que avanzaban a lo largo del proceso de mejorar la madurez del su actual proceso de desarrollo, solían hacerlo creando una gran cantidad de plantillas de documentos que se debían completar, efectivamente burocracia. Esto ha cambiado radicalmente con Team System, puesto que la herramienta nos ayuda enormemente en el manejo de la información que es necesario recuperar para alcanzar esa madurez, haciendo esa burocracia casi imperceptible.

Madurez significa buenas prácticas, y pocas empresas, al menos en nuestro país, llevan a cabo las buenas prácticas mínimas necesarias para llevar a cabo un proceso de desarrollo sano. Además madurez significa ser predecible, y realmente ese es un gran paso en la mayoría de los proyectos. A menudo el único dato fehaciente que se tiene sobre un proyecto es como se llama, cuando empezó y que esta retrasado. Si a apenas sabemos andar, como vamos a intentar correr, como vamos a ser ágiles, si a duras penas estamos dando los primeros pasos en una metodología de desarrollo de software. La agilidad requiere excelencia, repasad el manifiesto ágil. Excelentes gestores que puedan gestionar los individuos y sus relaciones de una manera diferente a la que estamos acostumbrados. Excelentes programadores que logren crear software que continuamente funcione y que sea capaz de absorber cambios. Excelentes clientes, que sean capaces de involucrarse en el proceso de desarrollo. Y no nos engañemos la excelencia no abunda.

La gráfica que representa el beneficio de añadir carga metodológica sobre el desarrollo de software muestra un punto a partir del cual la metodología empieza a ser dañina. Muchas implementaciones de CMMI superan este punto pero sin duda la gran mayoría de los proyectos que actualmente se desarrollan en este país se encuentran en un estado en que por mucha metodología que añadamos no vamos a llegar al punto en el que la metodología empieza a ser dañina, a convertirse en burocracia. Además la implementación de CMMI en Team System se ha desarrollado tratando de evitar esto y eso garantiza que no nos pasemos.

Con todo esto no quiero decir que la metodologías ágiles no sean útiles. Si tienes un proyecto donde el cliente esta dispuesto a colaborar, el equipo es excelente y trabaja excelentemente junto, los promotores del proyecto prefieren tener exactamente lo que quieren en lugar de tenerlo exactamente cuando quieren o con el presupuesto con el que cuentan y tu organización demostrado madurez en sus anteriores proyectos, no lo dudes, la agilidad es un gran valor.

De todos modos, antes aun que la metodología, están las buenas practicas. Si no estas haciendo aquello que siempre has leído, escuchado y sabido que debes hacer, olvídate de metodologías, empieza a hacerlo. Utiliza un gestor de fuentes, una herramienta de gestión de defectos, se capaz de construir e integrar tu software ejecutando un solo comando, escribe pruebas unitarias, realiza pruebas de humo, escribe una especificación por pequeña que sea, gestiona los cambios, involucra al cliente etc… Una vez que hagas todo esto o, al menos, una buena parte, empieza a preocuparte por hacerlo de forma metódica. Resumiendo, pasa el test de Joel y luego preocupate de la metodología.