Este post comenzaba su vida como un comentario en respuesta a otro comentario de Antonio Quiros en un post en el que, al hilo de un artículo suyo, yo escribía sobre CMMI y la madurez. Me encanta que mi blog se convierta, gracias a la participación de Antonio y otros expertos y desarrolladores, en una tribuna libre en la que discuitir y comentar uno de los temas que mas me apasiona de la informática: la gestión de proyectos.
Bueno vayamos al grano…
Antonio en su comentario, dice que ‘no ve necesidad el debatir la validez de metodologías como CMMI’, este es el punto que menos comparto de su comentario. En mi opinión es imprescindible cuestionar un modelo de desarrollo de software y gestión de proyectos que no esta dando frutos. Bueno, si que está dando frutos al SEI y a los consutores SCAMPI y a quienes venden certificadiones. Uso el termino vender con toda consciencia, obtener un certificación CMMI solo es resultado de una inversión económica, de nada más. Toda empresa que lo intenta y ‘afloja la gallina’ consigue su certificación, luego no es un factor diferencial. Sobre mi conocimiento de como funcionan las certificaciones ISO, que Antonio cuestiona, decir que trabajé en calidad durante una parte de mi carrera (en industria no en desarrollo de software, pero las lecciones aprendidas se aplican) y que en todas las empresas por las que he pasado he sufrido el ‘sistema de calidad’. Todos tenemos certificaciones ISO (u otras) y todos sabemos como se consiguen.
A parte de estos frutos, tras muchos años hablando sobre la familia CMM siempre que voy a una presentación sobre CMMI (poniendonos puristas deberiamos decir CMMI for Software Development), desde hace años, los ponentes, empiezan con la misma ppt, una mostrando estadísticas sobre cuantos proyectos de desarrollo de software fallan. ¿Qué ha hecho CMMI en todo este tiempo por mejorar el desarrollo de software? Nada. Si duda hay que cuestionar un modelo que sigue tropezando en las mismas piedras una y otra vez: no involucra al cliente, no entiende que las personas no los procesos son la clave en desarrollo de software, no asume que si algo es cierto es que el software cambia, y sigue aproximando el modelo de vida de ciclo de desarrollo desde una clara visión en cascada, asumiendo que se pueden conocer los requisitos a priori. Todos estos son errores ciertos, repetidos una y otra vez, que CMMI, RUP y otras metodologías no ágiles siguen cometiendo versión tras versión. Nada está más en contra del sentido común que perseverar en el error.
Aunque quiza estos errores no sean achacables completamente a CMMI, que en esencia no es la pesima idea en la que se suele convertir, MSF for CMMI Process Improvement es un ejemplo, sino a cómo se realizan la implantaciones de CMMI. CMMI o RUP son modelos tan complejos, que cuando se implantan se acaban convirtiendo en un proceso en cascada porque, en la práctica, es la única manera de atajar la complejidad impuesta por la burocracia que estos modelos generan. Tienes que cubrir ciertas areas, con independencia de que sean de valor o no para tu proyecto, y recolectar evidencias de que las cubres y eso conlleva un esfuerzo que para nada repercute en el avance real del proyecto. No sirve de nada generar documentación y diagramas que la experiencia nos dice que van a acabar obsoletos, debemos centrarnos en construir software que se ejecuta sin errores, acepta el cambio sin un esfuerzo inviable y cubre las necesidades desde el cliente. Nada aporta al cliente que tu hagas una extensísima documentación de analisis y que cubras mil formularios para recolectar evidencias solo con el afán de recolectarlas para el auditor SCAMPI, quien es el único, que en alguna ocasión va a leer esta documentación, y el único que no sabe que cuando la lee ya está obsoleta. Ya escribí en dos ocasiones ( Por qué no me gusta UML y Documentando software y… más motivos por los que UML no es la solución) sobre la escasa utilidad que tiene esta aproximación a la documentación. Las metodologías ágiles tampoco son una bala de plata, pero si son una aproximación diferente a la que lleva fallando unos cuantos años y en mi opinión si algo necesita esta industria es una nueva visión.
La base de estos errores está muy enraizada en la escuela de pensamiento clásica sobre gestión de proyectos. El resumen de este pensamiento es asumir que un proceso de desarrollo excelente es lo que garantiza un desarrollo de software excelente. Antonio en su comentario expone algunos de los argumentos clásicos de esta escuela de gestión de proyectos: ‘si pongo los ingredientes de una paella en la mesa y a diez personas delante, la probabilidad de que salga una buena paella será más alta si junto a los ingredientes pongo una receta que si no la pongo’ o ‘un procedimiento es por definición una serie de pasos que nos permite hacer un proceso repetible. Seguir un procedimiento demostrado válido para gestionar proyectos nos da más garantías que no seguirlo. ¿Preferirias que te operase un medico siguiendo un procedimiento aprobado mundialmente? o por el contrario ¿prefieres la lotería y cruzar los dedos para que la forma de trabajar del cirujano, su sentido común y experiencia le digan como tiene que operar’.
No seré yo quien este en contra de seguir un proceso, lo que estoy en contra es de pensar en un proceso de desarrollo como en una receta. Las recetas están bien siempre que sepas exactamente cual es el plato que quieres hacer y siempre que tu cliente este de acuerdo en cual es la receta a utilizar. El problema es que en los procesos de desarrollo de software eso no ocurre casi nunca. Tenemos clientes que no saben que quieren comer, que no van a decidir si quieren la paella de marisco hasta que vean la de carne, es más antes de ver la de marisco ni sabian que es lo que querian. Tengo algunos clientes que odian los pimientos y unos cuantos realmente enamorados de ellos, otros son alergicos y no puedo ponerlos en sus platos. En este entorno el jefe de concina (lease jefe de proyecto) no tiene más opción que tratar de contar con un equipo que no necesite una receta, que sea capaz de hacer la paella que el cliente quiere en base a unos fundamentos ferreos pero sin seguir unos pasos totalmente marcados (es mala práctica hechar azucar a la paella por ejemplo). Y además debemos dotarles de las herramientas que necesitan, básicamente, si no hay pollo, como jefes de proyecto (perdon de cocina), tenemos que conseguir uno (eliminar el impedimiento), porque sino nada podrá hacer nuestro equipo, por mucho que tengamos una metodología cinco estrellas certificada por la Nasa. Solo tener un excelente equipo nos salva, y tener cierto proceso, que apoye al equipo, que evangelize en las buenas prácticas, que no encorsete la creatividad y que no hunda al equipo bajo una montaña de burocracia. Mi abuela hace una excelente paella, por supuesto, sin receta. Es más dudo que dos veces seguidas ponga exactamente los mismos ingredientes y el mismo tiempo de cocción. No hay recetas, ni procedimientos ‘aprobados muldialmente’ para garantizar una gestión existosa de un proyecto, el motivo es simple, ¡cada proyecto de desarrollo es radicalmente diferente!. Esto es simplemente una ‘verdad verdadera’ que nadie que trabaje en esta industria puede negar… la tecnología es diferente, el cliente es diferente, el equipo de desarrollo es diferente, etc…
Tampoco el desarrollo de software es comparable a la cirugia, todas las operaciones de, digamos por ejemplo, transplante de riñon son iguales. Solo algunas se complican, y en ese caso solo salvará al paciente la agilidad del cirujano y su equipo para actuar de manera creativa y basada en excelentes prácticas: no vale olvidarse de la esterilización o de poner anestesia, por mal que vaya la operación. En gestión de proyectos no puedes olvidarte de la calidad, o de realizar integración contínua o de tener un gestor de fuentes organizado o de mantener la legibilidad del código. El problema es, que en los proyectos de desarrollo de software, las cosas, nadie puede negarlo, siempre se complican, con independencia de la metodología que se utilize. Es que desarrolla software es una tarea muy compleja, mucho más compleja que ninguna otra. Un solo error, en una sola línea de código y los resultados son miles de usuario sin poder acceder a la web de comercio electrónico de tu principal cliente. Por lo tanto el punto es: ¿Si sea cual sea la metodología los proyectos se complican, por qué elegir una metodología pesada? Elegir una metodología pesada, de partida, solo garantiza que es probable que tu pesado proceso no te ayude, sino te entorpezca. Cada vez menos gente en la industria del software discute esta aproximación.
Lógicamente, no usar metodología alguna no es la solución. No hay peor metodología que ninguna. En Peopleware hay un capitulo excelente dedicado a las metologías con mayúsculas y a por qué no es buena idea confiar en ellas, básicamente pone el valor en las buenas prácticas. Ni siquiera estoy seguro que de una metodología ágil sea la solución total, pero si estoy seguro que no molesta tanto a los desarrolladores como una pesada y a menudo incluso les ayuda. Tendemos a olvidarmos de que la principal labor de una metodología es ayudar a los desarrolladores a hacer su trabajo, porque ellos hacen el trabajo duro. Propongo a los gerentes que han decidido implantar una metodología pesada tipo CMMI o RUP que salgan de sus despachos, y hagan el siguiente ejrecicio: Coger al primer desarrollador que encuentren, y depués de dejarle claro que su respuesta no influirá para nada en sus posibilidades de conseguir un aumento a fin de año hacer la siguiente pregunta: ¿Qué opinas de nuestra metodología?. No olvideís que quien principalmente sufre las carencias de una metodología son los desarrolladores. Luego pueden buscar un equipo de desarrollo ágil y hacer esta misma pregunta. Si no conocen ninguno, tienen las puertas abiertas en el proyecto en el que yo participo para hacer esta misma pregunta y comparar las respuestas.
El problema es que cuando las metodologías no ayudan, molestan y esto daña la moral del desarrollador, que en lugar de poder concentrarse en su trabajo, se tiene que concentrar en que la metodología no le moleste. Y no debemos olvidar que numerosísimos estudios llegan a la conclusión de que nada afecta más a la productividad de un equipo de desarrollo que la moral y la motivación de los desarrolladores.
Si comparto con Antonio su comentario sobre la carencia de profesionales realmente formados en gestión de proyectos. Es un problema grave. La universidad no prepara en temas relativos a la gestión de proyectos, al menos desde una prespectiva moderna y actualizada de la gestión de proyectos. Otro problema grave es que las certificaciones más reconocidas, estilo PMI y similares, están basadas en la gestión de proyectos clásica, guiada por un plan. Pero esto está cambiando: la certificación de mayor crecimiento y reconocimiento en los últimos años es la de Scrum Master. Esta certificación tiene el mismo escaso valor que el resto, pues cualquiera con el dinero suficiente la puede conseguir, pero su crecimiento, quizás resultado de su orientación completamente práctica, sin duda es señal de un cambio claro de tendencia en la gestión de proyectos en los últimos años.
Invitio a todos los lectores de este post a discutir los temas que trato. Si algo tengo claro sobre la gestión de proyectos es que no hay más verdad absoluta que la máxima de que las personas son lo que marcan la diferencia de un proyecto a otro. El resto esta abierto a discusión y esta discusión siempre es enriquecedora.