 |
Basándome en las lecturas de diferentes autores (entre otros Javier Garzás y Joel on software) y por supuesto en mi propia experiencia, me gustaría reflejar en este post, el cual espero no sea muy extenso, unas reflexiones sobre la complejidad que las personas podemos añadir a los proyectos de desarrollo de software, aunque perfectamente extensible a cualquier otro ámbito.
Las metodologías de desarrollo ágil (scrum, XP, ASD, TDD, BDD,...) no tan nuevas, pero si tan de moda en los últimos años, parece que se están imponiendo a otro tipo de metodologías mas tradicionales como el desarrollo en cascada o el proceso iterativo (iteraciones largas). Esta victoria parcial y localizada, seguramente se impone por el auge de pequeñas empresas de emprendedores (a mi me gusta llamarlas autónomos de España) -Startups- , y por la exigente demanda del mercado, que obliga a la evolución continua y rápida de las aplicaciones, con entregas tempranas y funcionalidad limitada (incluso incluyendo errores).
¿Qué opinarían ustedes si les dijera que todo esto de la agilidad es un espejísmo? que la flexibilidad, velocidad y calidad en el desarrollo de software que promueven no es real. Antes de que dejeis de leer me explico, no se vaya a pensar que estoy en contra de las metodologías ágiles (todo lo contrario). Lo que si me atrevo a afirmar es que cualquier metodología por si misma no es mejor que otra, todas se apoyan en un pilar, para mi, fundamental, y que sin él no tienen ningún sentido. Esa base de sustentanción para hacer que la metodología que usemos nos lleve al éxito de un proyecto, es la ACTITUD.
La actitud del equipo de desarrollo, pero también la actitud de los directores (o directivos), incluso la actitud del cliente, es la clave para que un proyecto marche bien. ¿De que sirve aplicar SCRUM, si en la reunión mañanera (daily meeting), la mitad de los desarrolladores están callados? o si por ejemplo, a mitad de un sprint semanal, el cliente te cambia su necesidad, y el director de proyecto acepta el cambio, por supuesto sin cambiar la planificación del sprint (¡¡no!! ¡eso son se toca!). O incluso lo que es peor, intentar que el cliente valide unas pruebas de aceptación que nadie comprende ni tienen claras. Se podría decir que en estos ejemplos no se está aplicando correctamente la metodología. Pero es que quizá tampoco se aplicarían bien los clásicos modelos de desarrollo, y no por ello deben ser peores.
Bueno, pues aquí es cuando escribo otra palabra de moda: PEOPLEWARE. Un concepto no tan nuevo, pero si de moda desde hace un tiempo. Efectivamente, las personas, y la aceptación de estas como pieza fundamental para que un proyecto de desarrollo de software sea exitoso. Entendiéndose por exitoso que todas la partes involucradas (desarrolladores, directores, cliente,...) queden satisfechas.
Hoy por hoy, la mayor parte del software sigue siendo desarrollado por personas, y dependerá de la actitud con la que afronten los problemas, y busquen soluciones, que el proyecto navegue fluidamente hacia el éxito, o se convierta en un "infierno". Pero no solo la actitud al iniciar el proyecto, la buena predisposición se debe mantener en el tiempo, y aquí es donde se complica la cosa, y donde parece ser que algunas organizaciones, en su empeño por (des)motivar a sus desarrolladores suelen meter la pata, creando las normas, y estas normas matarán la flexibilidad que promueven las metodologías ágiles, con lo cual se terminará por minar la actitud de las personas, y todo esto llevará sin mas remedio a que el proyecto no sea exitoso.
Nuevamente somos las personas las que complicamos lo simple. Voy a poner un ejemplo. La flexibilidad horaria es una medida que favorece la conciliación de la vida personal, familiar y laboral. La empresa ofrece esta opción a sus trabajadores, permitiendoles hora de entrada y salida flexibles (por supuesto siempre que se atienda el trabajo). Otra opción es registrar esta flexibilidad en una normativa (por ejemplo convenio colectivo), indicando que la flexibilidad de entrada es de 8 a 9 y la salida de 2 a 3. ¿Sigue siendo flexible el horario de entrada y salida? para mi no, en la segunda opción se ha creado una norma, lo cual ha matado la flexibilidad. Este ejemplo es perfecto para los desarrolladores (en otros puestos de trabajo no se podría aplicar flexibilidad horaria). Otro ejemplo podría ser establecer reuniones todos los viernes a las 8 de la mañana. En principio podría parecer buena idea, pero posiblemente a la larga eso se convierta en otra regla mas que cumplir, monotonía y adíos flexibilidad (agilidad). La norma mató a la agilidad.
¡Ey, ey! ¡un momento!. Después de tantos años, tantos estudios, experimentos, metodologías, formación, etc. ¿cómo me atrevo a decir que las metodologías ágiles no sirven? bueno, no se me entienda mal. Si que sirven, pero no por estar plasmadas en un conjunto de procedimientos a seguir (mas o menos flexibles), sino por preocuparse cada vez mas por las personas que han de seguir esas metodologías, por entender que sin la actitud adecuada no sirve de nada intentar imponer una manera de trabajar.
Por supuesto que además de la ACTITUD tenemos la APTITUD. ¿Cómo saber cual es la persona ideal para desempeñar un determinado trabajo? ¿Cómo conseguir y conservar en mi equipo a un buen desarrollador? ummm... Bueno, esto ha dado para muchos libros, y seguirá dando. Pero tengo claro que formar un equipo con los mejores no garantiza el éxito del proyecto, si no se dispone de predisposición, implicación y actitud adecuada. Quizá algún dia me atreva a escribir un post sobre la aptitud, pero mientras tanto puedes leer este post: alcanzando las notas altas.
Comentarios