Aplicando Scrum y XP: ¿realmente es lo que necesito?

Esta entrada pretende ser la primera de una serie dedicada a la aplicación de scrum y xp, intentare que no consista en una explicación teórica de estás metodologías (para eso sólo tenéis que usar el google y encontrareis información a montones) sino más bien en dar un punto de vista practico de nuestra experiencia con estas metodologías, tratando de explicar que practicas hemos aplicado y cuales no, que cosas nos han funcionado y que cosas no tanto, que herramientas hemos usado para poner en marcha las distintas practicas etc,etc

Lo primero es lo primero, así que antes de ponerme a contar nada voy a tratar de justificar porque hemos elegido una aproximación ágil con estas metodologías y que problemas tratábamos de resolver con ellas.

¿por qué aplicar Scrum y XP?

Antes de plantearse un cambio tan importante como el que puede suponer usar una metodología ágil es necesario mirar a tu alrededor y tener claro donde estas y hacia donde quieres ir. Si estas pensando en meterte en el largo (y posiblemente tortuoso) camino de cambiar tu metodología de trabajo lo primero es identificar que problemas tienes y evaluar si una metodología ágil te va a ayudar a resolver estos problemas; si esta metodología encaja en tu organización y es posible aplicarla, si el equipo de desarrollo que las va ha aplicar cuenta con los conocimientos y los medios necesarios..., vamos que lanzarse a lo loco a usar esto o aquello simplemente porque esta de moda es como poco "arriesgado" y podemos terminar consiguiendo que el remedio sea peor que la enfermedad.

En nuestro caso empezamos a aplicar Scrum y XP para tratar de resolver algunos de los problemas que teníamos en nuestro entorno de desarrollo, para que os podáis hacer una idea de a que nos dedicamos, estamos construyendo un software de gestión documental (tipo CMS) bastante complejo que debe servir como plataforma de desarrollo para luego personalizarlo en distintos proyectos, vamos que se trata de un proyecto a largo plazo donde la misma empresa es "el cliente" y el tamaño del equipo es de aproximadamente 5 personas (digo aproximadamente porque el número puede variar por distintos motivos).

Por mencionar algunos de los problemas más importantes que queríamos resolver (quizá alguno os suene de algo...):

• Planificaciones a muy largo plazo que nunca se cumplen a tiempo, planificaciones que podían tener duraciones tipo 6 meses tres semanas y un día... vamos como una condena.
• Las desviaciones sobre el plan sólo se detectan al final, cuando ya es tarde y la única opción es echar horas y horas para terminar lo imposible.
• Desarrollos que no cumplen con la calidad deseable, muchos bugs en gran medida provocados por las prisas para entregar algo y cumplir con la planificación inicial.
• Falta de una "cultura de calidad" en el desarrollo, pocas pruebas y en la mayoría de los casos manuales y desorganizadas, luego pasa lo que pasa, que el cliente se convierte, a su pesar, en un tester más...
• Por todo lo anterior al final los miembros del equipo terminaban dedicando gran cantidad de tiempo a resolución de incidencias y se hacia muy difícil hacer avanzar un producto e incluir nuevas características.
• Mucha dependencia de determinados miembros del equipo, ya sabéis esto que pasa cuando la gente tiene como apellido el nombre de la aplicación/modulo en el que trabaja, “manolo el de la contabilidad”, “pepito el de la aplicación güeb”, ¿falla el acceso a la base de datos? Pregunta a luisito que eso es “suyo”...

Evidentemente ningún desarrollo es un camino de rosas, siempre habrá problemas y en el fondo esto del desarrollo del software consiste en irlos superando, no existe ninguna metodología mágica que resuelva todos tus problemas de un plumazo y convierta a tu empresa en google, pero tampoco nos vamos a rendir, los métodos ágiles ofrecen cosas muy interesantes para tratar de resolver algunos de estos problemas:

• Entregas periodicas en ciclos cortos, es decir, dar pasitos pequeños pero seguros. Los Sprint de Scrum se ajustan perfectamente a esta idea.
• Necesitabamos algo para controlar mejor el estado del desarrollo en un momento determinado, algo que te permita llegar a la oficina por la mañana y saber si vas reservando mesa en un restaurante para celebrarlo o vas preparando las maletas para poner tierra de por medio antes de la tempestad. En este caso las reuniones de Scrum diarias y las gráficas de burndown son herramientas simples pero que pueden resultar muy efectivas.
• Pruebas unitarias, integración continua, definir una guía de estilo, refactorizaciones, muchas de las practicas de XP nos parecían un buen modo de mejorar la calidad de nuestros desarrollos.
• Movilidad de los miembros del equipo y propiedad colectiva del código, tanto scrum como XP promueven la idea de equipos con miembros que se puedan hacer cargo de cualquier tarea en cualquier parte del proyecto frente a la idea de especialistas. Muy importante para evitar los problemas de dependencia y conseguir que todos los miembros del equipo tengan una visión general del proyecto y no se queden en sus respectivas islas.

Por todos estos motivos nos decidimos a intentarlo, pero aunque todo pueda sonar muy bonito y muy facil, antes de liarse la manta a la cabeza conviene intentar averiguar si estamos preaparados para lo que se viene encima

¿Estoy preparado para Scrum y XP?

Hay unas cuantas cosas que se tienen que cumplir para que esto funcione, en mi opinión las más importantes son:

• Implicación, mucha implicación por parte del equipo de desarrollo. No creo que una metodología ágil se pueda imponer a un equipo que no afronte el cambio de una manera positiva y predispuesto a hacer un gran esfuerzo. Si en tu equipo el cambio se ve como “vaya rollo ahora con el Scrum este, las pruebas y no se que, y ¿XP? Si eso es lo que ya tenemos instalao!, con lo tranquilos que estabamos!!”. Entonces no te esfuerces que no va ha funcionar.
• Cerciorate de que el equipo tiene la preparación técnica necesaria para llevar a cabo las practicas, algunas pueden resultar complejas al principio si no se tiene experiencia en el tema. El ejemplo más claro son en mi opinión las pruebas unitarias, que realmente son muy complejas si las quieres hacer bien y que sirvan para algo. Si el equipo no tiene estos conocimientos no quiere decir que tengas que descartar Scrum o XP, pero eso si, tendrás que dedicar un tiempo inicial a formación y adaptación del equipo a las nuevas tecnicas, si la gente esta predispuesta la cosa saldrá adelante.
• Y aún así todo esto no sirve de nada si desde arriba no se colaborá, es decir, se va a exigir mucho al equipo de desarrollo, pues también hay que exigir a los que están arriba, no se puede llegar a mitad de un sprint y interferir pidiendo cuarenta historias nuevas, no se puede venir todos los días pidiendo una demo, no se puede romper el equipo sacando y metiendo gente cada dos por tres. Si ponemos unas reglas jugamos todos con las mismas, y si no rompemos la baraja
• Hay que poner los medios que hagan falta, sin racaneo, si hace falta un servidor para montar un entorno de CI, un subversión y un app server para pruebas rascate el bolsillo y compra uno bueno. Y que la gente no tenga equipos donde mientras se arranca el netbeans, el eclipse o el visual studio te de tiempo a leerte la mitad de las noticias del marca. Recuerda, hardware is cheap, programmers are expensive

Y tampoco hacen falta muchas más cosas, ganas de cambiar las cosas, implicación y que todo el mundo reme en la misma dirección, ¡Que fácil es decirlo! ¿verdad?.

¿Y esto funciona?

Pues no se si a todo el mundo le funcionara, cada empresa y cada equipo de desarrollo es un mundo y tiene su ecosistema propio, es labor del director tecnico/arquitecto/comoloquierasllamar evaluar si esto puede funcionar o no en su contexto. Lo único que puedo decir es que nosotros estamos muy contentos y estas metodologías nos han ayudado a mejorar en muchos aspectos. Tampoco voy a decir que han conseguido resolver todos nuestros problemas, ni que las estemos aplicando con la precisión de un relojero suizo, pero si que tenemos la sensación de haber dado un paso hacia adelante muy importante

En próximas entradas intentaré ir explicando aspectos más concretos de como las estamos aplicando, hablar sobre los roles en un equipo scrum, las reuniones diarias, las demos, las retrospectivas, pruebas unitarias, integración continua... y bueno quizás a alguien le sirvan de algo nuestras experiencias, o quizá no, pero al menos podre decir que tengo un blog!!