lunes, 27 de diciembre de 2010

Aprendizajes Extremos (3era parte)

Continuo con los aprendizajes que hemos obtenido en los últimos meses en la aplicación de la metodología de Programación Extrema en Imolko. En este post, comento sobre como mantener el foco en el cierre para lograr los resultados deseados.

Puedes ver el primer artículo aqui.

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.

En el siguiente post (el último de esta serie) comento sobre el uso de versiones integrales o coherentes.

viernes, 10 de diciembre de 2010

Aprendizajes Extremos (2da parte)

Este post forma parte de una serie de cuatro artículos sobre aprendizajes en la utilización de Programación Extrema. En el primer post, comentaba sobre el manejo de Versiones con Fecha Fija de Release.

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.

En la próxima parte, hablaré sobre como mantener Foco en el cierre.