domingo, 19 de octubre de 2008

Implantando una metodología ágil

Implantar una metodología ágil en una empresa no es fácil. Desde nuestra posición de desarrolladores se pueden hacer algunas cosas pero es importante tener un jefe que te permita ciertas licencias. Si este es tu caso, siempre tienes posibilidades de llegar más lejos en tu implantación.

Aqui vienen algunas directrices desde nuestra pequeña expieriéncia en nuestra empresa. Quizá no es el mejor modo de hacer las cosas, pero es el que nosotros hemos podido hacer dentro de nuestras posibilidades. Esperemos que te sirva de ayuda.
  • Implanta un repositorio de código: Si quieres hacer trabajo colaborativo, que el hacer merge de tu código con el de tus compañeros no sea un infierno en el que se pierden funcionalidades y mucho tiempo, si quieres recuperar versiones anteriores sin dificultad, esto es lo primero que debes hacer. Y lo mejor de todo es que no hace falta que te gastes un duro. Puedes, por ejemplo, utilizar subversion. Si todavía te quieres complicar menos la vida, instala el servidor de subversion llamado svnserver. Y sobretodo, aprende a utilizar bien el repositorio de código. Si no lo haces puedes perder el trabajo de varias horas de trabajo y lo que conseguirás es justo el resultado contrario: no vas a poder implantar la metodología.
  • Empieza a programar testeos unitarios en tu código: Al principio verás que tu velocidad de programación se reducirá bastante ( puede llegar a descender hasta un 50% ) pero a medio plazo ( o incluso a corto plazo ) verás que tener tu red de seguridad de los tests unitarios es una gozada. Puedes refactorizar el código, hacer canvios en el diseño, hacer pequeños cambios en el código o lo que quieras, que siempre sabrás que tu código cumple con lo que especifican los tests. No hace falta que hagas TDD, con hacer los tests después de programar hay suficiente.
  • Porque no pruebas SCRUM? O alguna otra metodología ágil. Nosotros te recomendamos esta, que es la que intentamos implantar. Te será dificil al principio concienciar a tus jefes de seguir esta metodología al pie de la letra, pero poco a poco los irás convenciendo. Intenta ser estricto en su utilización. Programa las reuniones de inicio de sprint, utiliza planning poker para tus estimaciones, decide la duración de tu sprint, decide qué cosas entran y cuales no en tu sprint, programa un dia para la demo y diselo a todo el mundo. Haz las reuniones diárias y que estas no se alarguen en demasía. Haz la demo el dia que has programado y haz después una reunión de revisión de sprint.
  • Implanta un sistema de integración continua: Algo muy importante para mejorar el rendimiento de tu equipo es la detección temprana de errores. Junto con el testeo unitario, otra de las herramientas claves para conseguirlo es la implantación de un sistema de integración continua (CI). Puedes hacer que cada vez que alguien sube código al repositorio, el servidor de CI inicie una compilación del código, pase los tests programados y te enviee el resultado de todo esto. Así puedes saber al momento si una modificación hecha por algún desarrollador ha roto la build.
  • Conciencia a tu equipo de las bondades de las metodologías ágiles: todo el equipo tiene que estar concienciado en este nuevo camino. Si no motivas al equipo, no notarás el avance en la implantación. Si la gente no es consciente de que todo lo que se está haciendo es para mejorar el trabajo de todo el mundo no se esforzarán lo suficiente en hacer todo lo que se propone. Es importante que entre todos paséis el abismo que se abre al implantar una nueva forma de trabajar para poder avanzar a mayor velocidad.
  • Documentate: Lee mucho. Sé critico con tu trabajo y también con lo que lees. Aprende de la expieriéncia de la gente que lleva muchos años más que tu implantando este tipo de cosas. Documéntate sobre otras metodologías y evalua cual se adapta mejor a tu entorno. Habla con tu equipo, con tus jefes y con todo el mundo que puedas sobre tus ideas. No intentes imponer nada, sinó que intenta que todo el equipo sea quien toma la decisión.
Bueno, estos son sólo unos pequeños consejos que provienen de nuestra experiéncia. No los tomes al pie de la letra, cada uno tiene un equipo distinto, trabaja en una empresa distinta, tiene unos jefes distintos, etc. Tampoco hace falta que los implantes en este orden. Este es el orden en que lo hemos hecho nosotros y por ahora nos va bastante bien ( por lo menos sobrevivimos! ).

Nos leemos en el siguiente artículo.

2 comentarios:

Unknown dijo...

Sobre "Te será dificil al principio concienciar a tus jefes", aquí tienes un argumentario: http://www.proyectosagiles.org/beneficios-de-scrum

Te invitamos a contribuir en http://www.proyectosagiles.org, una base de conocimientos gratuita de Scrum, escribiendo allí tus experiencias con Scrum.

vgaltes dijo...

Hola Xavier,

me parece muy interesante lo que comentas en tu página. Sin embargo, lo que yo queria decir es que a gestores de la vieja usanza a los que les gusta controlar todo lo que se hace en un proyecto, decirles que a partir de ahora trabajarán con un equipo auto-organizado y que su rol se "limita" a priorizar historias de usuario, les cuesta un montón.

Desgraciadamente lo digo por propia experiéncia. Tras explicar las bondades de Scrum y parecer que tenia una buena recibida, al ponernos a trabajar las reuniones de inicio de sprint le parecian una pérdida de tiempo, hablaba directamente con los programadores a medio sprint cambiando todas las prioridades, nunca asistia a las reuniones de seguimiento y si lo hacia queria imponer su visión en todos los temas...

En fin, que por nuestra experiéncia, por mucho que les cuentes todo lo que les va a aportar Scrum, acostuma a costar bastante. Por suerte, siempre hay gestores mucho más abiertos.