Aprendizajes extremos

Primera parte: Manejo de Versiones con Fecha Fija de Release.

Buscando mejorar nuestra productividad en el desarrollo del software, en los últimos dos meses hemos implementado cambios en la forma en que estamos trabajando. Manteniéndonos en los principios básicos de XP, hemos hecho algunos ajustes menores y radicales en otros.

El objetivo fundamental de estos cambios es lograr cerrar la mayor cantidad de funcionalidades, y que éstas lleguen rápidamente a los clientes.

En la forma en que estábamos trabajando se venía presentando una situación dónde no teníamos el foco en hacer llegar las nuevas funcionalidades. El foco se trasladó al proceso del "cierre" de la funcionalidad pero esta funcionalidad no tenía que llegar al cliente para ser aprobada. Entonces se presentaban una situación dónde se podían cumplir las metas pero el cliente no veía ninguna mejora.

Versiones con Fecha Fija

El concepto de los User Stories en XP permite separar claramente cada nueva funcionalidad y manejarla como una unidad independiente. El riesgo que presenta este enfoque es que terminemos con una seria de funcionalidades inconexas que se van entregando al usuario en forma desordenada. Hasta hace un par de meses, estábamos sufriendo este síndrome. Las nuevas funcionalidades iban pasando sin ton ni son al ambiente de producción, pero no teníamos coherencia en cómo se generaban. Ni tampoco teníamos la sensación de Urgencia.

El primer cambio importante que aplicamos es definir exactamente las versiones, con su alcance mínimo y con fecha definida. La fecha se mantenía fija ("tallada en piedra") y se tiene flexibilidad con las funcionalidades que se deben incluir en la versión. Adicionalmente se implementó Maven (con el repositorio de Nexus) para ayudarnos a mantener claramente definidas las versiones con su numeración específica.

Asumimos la convención de que cada release se maneja después del primer punto y cualquier corrección que se haga sobre una versión específica en producción se le agrega otro punto. Entonces la primera versión que trabajamos con este esquema es la 4.1, y si hubiera algún Patch o corrección sobre esta versión sería la versión 4.1.1.

Este sencillo cambio creo que ha sido de gran importancia. El primer objetivo que se logra es que todos nos enfocamos en cerrar. Como la fecha está definida todo el mundo tiene la presión para cerrar su funcionalidad antes de ese período de tiempo.

Otro objetivo que se logra, es que realmente separamos lo "deseado" de lo "importante". Nos obliga a escoger entre constantemente entre distintas opciones. Y a pensar por qué vale la pena hacer esto o posponer aquello. No ponerles fechas fijas genera la falsa sensación que siempre se puede incluir de todo y nos obliga a enfocarnos. Cuándo tienes la fecha fija dejas de pensar con Gula y te concentras en lo realmente alimenticio.

Segunda parte: Una sola tarea a la vez.

Este me parece una de los aprendizajes más contra-intuitivos. Por lo regular uno piensa que mientras más tareas le asignes a una persona más posibilidades hay que se terminen las cosas. Cuándo se distribuyen las tareas tenemos la sensación que ya hemos avanzado y que estamos más cerca de terminar.

En mi experiencia resulta todo lo contrario.

A nível personal cuándo una persona tiene varias asignaciones por desarrollar termina menos cosas que recibiendo una asignación por vez. Creo que tiene que ver con la sensación de angustia que se genera al tener muchas cosas pendientes.

A nível grupal el efecto es aún más perverso; primero que la distribución del trabajo se realiza al principio del ciclo cuándo todavía no se tiene claro cuánto tiempo toma cada tarea. Entonces una persona podría acabar con mucho más trabajo que otras.

El grupo no se concentrar en cerrar sino en abrir. Lo más importante termina siendo "abrir" o comenzar con la nueva asignación en vez de concentrarse en "cerrar" la única que tenemos en cada momento.

En nuestro caso cada nuevo desarrollo es cerrado por el representante del usuario; cuándo un desarrollador tiene varias tareas pendientes sucede un ciclo totalmente antiproductivo. El ciclo se resume en estos pasos:

1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas
3) Desarrollador "abre" la próxima funcionalidad y comienza a trabajar. Saca de su mente el problema anterior e introduce este nuevo problema.
4) Rep del Usuario, realiza las pruebas y hace unas correcciones.
5) Desarrollador no quiere dejar de trabajar en su nueva funcionalidad (en la que ya está inmerso) y pide tiempo para realizar las correciones.
6) Vuelve al punto 1.

Despues de mucha energía y tiempo invertido se tienen muchas funcionalidades "abiertas" y ninguna cerrada.

Para romper con esta situación la solución es muy sencilla: Una sola asignación a la vez. Esta regla sencilla requiere mucha disciplina pero se gana full.

El ciclo queda así:
1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas. El tiempo solicitado se minimiza por que se entiende que el desarrollador no va a comenzar con más nada)
3) Desarrollador realiza pruebas de su funcionalidad, exactamente igual a como lo haría el rep del usuario. Si tiene errores corrige de una vez.
4) Rep del Usuario realiza pruebas, y se consigue con una versión más estable. Hace recomendaciones al desarrollador
5) Desarrollador termina correcciones y se cierra la funcionalidad.
6) Vuelve al punto 1.

Cada vez que se ejecuta este ciclo se tienen funcionalidades cerradas y la sensación de avance que a todos nos sube el auto estima. Y cada vez que cerramos tenemos ganar de seguir cerrando.

Tercera parte: Foco en el Cierre.

Nada más importante que lograr el cierre de una tarea o funcionalidad. Debemos obligarnos todo el tiempo a hacernos dos preguntas claves:

1) ¿Qué hace falta para cerrar lo que estoy haciendo?

Muchas veces cuándo se está desarrollando una funcionalidad se hace sin ningún plan específico. Simplemente voy desarrollando a medida que voy necesitando y no tengo claro cuál es el siguiente paso. Esto lleva a que termine invirtiendo demasiado tiempo y energía en cosas que realmente no me hacen falta. O que me desenfoque en otras tareas (investigar en Internet, ver otros problemas o terminar chateando con otra gente) y no tengo claro cuáles actividades me faltan para cerrar.

Por el contrario cuándo tengo un plan mental sobre las actividades faltantes, puedo administrar mejor mi tiempo e incluso pedir ayuda para tareas específicas que me ayuden a cerrar.

2) ¿Qué puedo posponer para cerrar más rápidamente la funcionalidad que estoy haciendo?

Esta pregunta es aún más dificil de hacer que la primera. Esta pregunta ayuda a definir claramente que es lo más importante en lo que estoy haciendo. Una vez qu entiendo que es lo más importante, puedo ver con claridad cuáles cosas se pueden posponer. Cada vez que posponemos podemos cerrar más rápidamente.

Y cada cierre es una victoria. Con cada cierre estamos entregando más valor a nuestros clientes. Por que al final del día, nuestro cliente nos agradece que le entreguemos una funcionalidad pequeña cada mes, en vez de sólo entregarle en dos años una mega funcionalidad.

Inicialmente estas dos preguntas las he estado haciendo todo el tiempo a todo el mundo. Pero realmente lo importante es que todo el equipo las haga todo el tiempo; consigo mismo y con todo el resto del equipo.

Cuarta parte: Versiones integrales o coherentes.

Con versiones integrales me refiero a un conjunto de funcionalides individuales que apuntan todas en la misma dirección. El contrario es cuándo se hacen versiones con un montón de funcionalides pero cada una apuntando a dirección distinta.

Cuándo todo el equipo se concentra en un mismo "tipo" de funcionalidades se logra una sinergia dificil de lograr cuándo se realizan funcionalidades inconexas. Esta sinergía además se transmite a toda la empresa, puesto que es mucho más fácil comunicar un concepto que agrupa a todas las funcionalides que cada una de las funcionalidades independientes. Incluso comercialmente es mucho más fácil de comunicar.

Para lograr esto es necesario que en la definición de la versión se defina el objetivo a lograr y se agrupen todas las funcionalides que apuntan a ese objetivo. La forma de agrupar puede variar en cada caso, pero es importante que se tenga un concepto para transmitir.

Creo que como ejemplos de estas versiones integrales podrían ser cosas como "Mejoramiento del API" (todo el mundo concentrado en mejorar el API), "Conexión con Facebook" (todo el mundo concentrado en crear funcionalidades relacionadas con Facebook), etc. En las dos últimas versiones hemos tenido foco en "Optimización en manejo de Volúmen" e "Implementación de Campos Relacionales".

La sinergía se logra en que todo el mundo resuelve problemas similares en el mismo período de tiempo; entonces las soluciones encontradas por los primeros se transmiten más fácilmente a los demás. El código se puede encapsular más fácilmente. Los problemas se pueden resolver fácilmente entre varios. Se evita el retrabajo, etc.

Este concepto tambien a ayudar a definir más fácilmente que se puede posponer. Todo lo que no apunta en el concepto de esta versión se puede pasar a otra versión.

Fuente: Roberto Matute – imolko.com