Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro... bueno, pues ese futuro ya es presente :-)
La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.
En la imagen se puede apreciar el cómo quedó la pared de la oficina cuando comenzamos la experiencia. Comento un poco como lo hicimos, aunque la verdad, fue algo muy básico.
Usando Scrum
Lo primero que hicimos fue localizar los grandes grupos a desarrollar. En este caso, lo que había que desarrollar, principalmente, era una interfaz web para un cliente específico. Así que nos encargamos de convertir, cada parte importante de la interfaz en un bloque de tareas.
Dentro de cada uno de los bloques (alrededor), se agrupaban las tareas que había que realizar para completar ese bloque.
Los papeles se ordenan de arriba a abajo, según su prioridad, de más alta a más baja, respectivamente. Todos ellos, a su vez, se colocan en la parte izquierda del marco que se vaya a emplear para el proyecto de scrum. La idea es que, cuando una tarea se esté realizando, se pase a una zona central y, cuando haya sido terminada, se pase a la zona derecha. Nosotros usamos la separación física existente entre vidrio y vidrio, considerando la parte central justo la línea de unión entre ambos.
¿En qué beneficia?, pues básicamente en que cuando una tarea se finaliza, todos ven que se ha finalizado y que, cuando alguien no sabe que hacer, se puede levantar y mirar las tareas que hay por realizar.
Cabe señalar dos aspectos muy importantes y a tener muy en cuenta:
- Hay que definir, y muy bien, lo que significa terminado. Ya que alguien puede considerar una tarea terminada cuando ha terminado de codificarla (sin probarla), mientras que quien la solicita, considera que se termina cuando ya no se debe de tocar más, ha sido comprobada, validada y está lista para producción.
- El scrum master es la única persona que debe de mover los papeles, así como agregar nuevos o eliminar, según se dé el caso. Esto es para controlar que, realmente, se ha terminado, como se decía antes, la tarea. Además, el hecho de agregar/eliminar tareas es una actividad muy sensible, que no se debe de dejar a todos, puesto que sino, podrían sucederse situaciones indeseables.
Y un poquito de Xtreme programming
Hay otra práctica que realizamos ese mismo día, y es la del empleo del Xtreme Programming, otra vez, a nivel muy básico. En esencia, se trataba de realizar la programación más costosa (o la que se hacía ya con sueño :-P ) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).
Los beneficios de esta técnica fueron la velocidad a la hora de desarrollar ciertas partes, puesto que la presión que ejerce el navegante al piloto y la dinámica que se crea, hace que el desarrollo carezca de partes de inactividad y cada tarea se acabe antes.
Algunas conclusiones
Puedo decir que la valoración acerca de estas técnicas, en sus inicios dentro de la empresa, han sido muy positivas, llegándose a conseguir los objetivos deseados, por lo que seguiremos empleando dichas técnicas, así como implementando cada una de ellas de forma más completa para ganar en eficiencia y conseguir que los proyectos se puedan medir de forma más precisa en el tiempo.
Pero de eso ya contaré más adelante... :-)
