Un recorrido por el manifiesto ágil

Hace poco vi un video de una conferencia de Martin Fowler sobre por qué la agilidad funciona. Expone entre él y Neal Ford varias tecnicas agiles como ejemplo de por qué estan añadiendo valor a las empresas que lo usan. Este vídeo  me dió la idea de exponer un listado de tecnologias denominadas ágiles relacionadas con los 4 postulados del manifiesto ágil. Empecemos por el primero.

Individuos e interacciones sobre procesos y herramientas

Este es el que más tiene que ver con el nucleo duro del desarrollo software, el equipo de desarrollo y su trabajo diario.. Cómo empezó a descubrir Fred Brooks en el Mitico Hombre Mes, un desarrollador no se tiene nada que ver con una máquina de producción en serie que se puede establecer un rendimiento fijo. Ese rendimiento depende de mil factores y uno muy importante es su comunicación con el resto de integrantes del equipo. Es importante que cada miembro del equipo esté motivado y tenga un compromiso proveniente de él mismo hacia el equipo y su proyecto.

En el libro Management Rewired de Charles S Jacobs, define como el grupo de producción perfecto el formado por un pequeño numero de personas (5-7) autonomos cuya subsistencia depende  del proyecto que tienen entre manos. Segun Jacobs, esta organización fue la que funcionaba cuando habia grupos de herreros, de carpienteros, de ganaderos… Esto mismo  es lo que plantea Scrum, un grupo de 5-7 personas autonomas. Si se añaden más personas se complica la gestión por una necesidad excesiva de comunicacion y con menos personas no se consigue la sinergía que se genera con un equipo multidisciplinar motivado.
La agilidad plantea la comunicación de tal modo que sea lo más eficiente posible. Las reuniones se establecen para que se interambie la información necesaria para seguir trabajando sin  gastar más tiempo que el estricatamente necesario. Cada reunión tiene definidos un objetivo y un timebox, es decir, un tiempo máximo que una vez terminado se da por finalizada la reunión. La comunicación offline mediante un sistemas de tarjetas, por ejemplo,  aportan un elemento  concreto y una ubicacion (al lado del tablero) para realizar decisiones. El pair programming es otro elemento interesante de interacción entre desarrolladores. Es muy dificil,sino imposible, medir la productividad de una pareja de programadores comparado con lo que produciría uno sólo. Es por esto por lo que la medida en la que mejora el resultado de un desarrollo no es facilmente cuantificable pero es patente en el resultado. En el vídeo que comento al principio del post, Martin Fowler comenta que una pareja que trabaja en el mismo codigo trabaja como un cerebro con sus dos lados activos a la vez. El que está con el teclado usaría la parte logica y matematica del cerebro (el izquierdo) para resolver el problema de código que tiene entre manos y el desarrollador que está al lado, con su visión más amplia aporta el lado más creativo  (el derecho).
El entorno es tambien importante para esta comunicación. El entorno de trabajo debe favorecer la comunicación de todos con todos de modo visual cara a cara. Se descartan los cubiculos y se intenta crear un entorno en el que la información del proyecto esté visible en todo momento para todos y se promueva la creatividad.

Software funcionando sobre documentación extensiva

Los programadores no somos buenos escritores de narrativa. De hecho normalmente somos muy malos en la expresión escrita (yo admito que lo soy). La documentación hay que usarla como herramienta para un proposito concreto. Un diseño de clases basico o un diagrama de interacción entre clases puede ayudar a entender un código y saber dónde hacer un mantenimiento de modo más optimo. Ese diseño, dentro de poco tiempo qudaría obsoleto a no ser que se dedique su tiempo en mantenerlo al día.  Sin embargo, lo que más importa es tener un pedazo de software que pueda aportar valor al cliente. A partir de él se puede generar la documentacion mediante analizadores de código y metadata pero no al reves. Al realizar distintos niveles de test se ofrece un testeo cada vez más amplio. Empezamos con un testeo de los métodos de una clase mediante el testeo unitario en el PC del desarrollador. Seguimos con un test de integracion mediante un build centralizado que testea todo el codigo de los desarrolladores juntos. Al final del sprint hay un test de aceptación realizado por el product owner en el que se ven posibles problemas y se añaden sugerencias.

Colaboración con el cliente sobre negociación contractual

En Scrum se define un rol muy importante que es el  Scrum Owner. Esta persona (unica persona) debe hacer lo posible por conocer el negocio y aportar su conocimiento al equpo de desarrollo entre incrementos de producto. El nuevo requerimiento a mitad de proyecto no es una incidencia que haya que intentar evitar sino que es algo que le dará  valor añadido al producto por lo que hay que aceptarlo. El sistema de gestion de proyectos iterativo es la mejor manera de ir adaptando el software a las necesidades del cliente segun se va dando cuenta de ellas. La demo que se realiza al  final de sprint es para él cliente y/o el Product Owner y todos los que puedan aportar ideas. El cliente no se siente atado por haber firmado un documento de requierimientos ni el equipo tiene que modificar todo el proceso rompiendo el proyecto a mitad por un requerimiento inesperado.

Respuesta ante el cambio sobre seguimiento de  un plan

El permirir introducir cambios a mitad de desarrollo tiene sus métodos, no es un simple ASM (A Salto de Mata). No se hace un diseño complejo al inicio sino que se hace el diseño más simple que cumpla lo necesario por el test. A muchos desarrolladores nos gusta pensar  a lo grande e intentar preveer todos los casos pero esto es algo que normalmente provoca que el proyecto se sobredimensiento. El código basado en ese diseño simple está lo suficientemente cubierto pro tests unitarios para poder refactorizarlo y adaptarlo a las nuevas necesidades. Se cambia la mentalidad de tenerlo todo previsto por la de intentar  tener toda la información (feedback) lo más pronto posible para reaccionar y adaptar si es necesario el proceso  Si hacemos un recuento de tipos de  feedback de más proximo al desarrollador a más lejano empezaremos por el compañero del pair-programming que nos indica un error en el que no hemos caido justo al teclearlo,el  unit-test que nos salta cuando la hemos cagado sin querer en cuanto damos a compilar, el build centralizado diario que nos muestra nada más llegar a la oficina que ha habido un problema de integracion, el kanban a la vista de todos para ver cuando alguien ha cambiedo de estado una tarea nos da la posibilidad de verificar ese cambio inmediatamente, la demo de final de sprint que nos verifica que ese incremento ha sido todo un exito.

Anuncios
Post a comment or leave a trackback: Trackback URL.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: