Ouracademy

Bolsa de 5 libras

o los problemas de tener un plan fijo y como lidiar con ello.

Una traducción del articulo de Martin Fowler: When to make a Type

No puedes poner 10 libras de mier.. en una bolsa de 5 libras

— Cualquiera que lo haya intentado

Cuando Kent y yo escribimos Planning Extreme Programming, incluimos este caprichosa cita para ayudar a entender la esencia de la planeación.

Una de los grandes problemas con el desarrollo de software es que las personas tienen poco sentido de lo que se puede realmente hacer en un tiempo limitado. Con mucha frecuencia vemos funcionalidades apretadas en una bolsa sin entender que encajara en ella. Siendo los deseos humanos lo que son, la bolsa a menudo es muy pequeña. Una de las cosas que me gusto del enfoque de planificación de Kent era la forma simple de tratar de lidiar con esto.

Un plan fijo es como un arreglo: deseas agregar una nueva funcionalidad? Mueve todos los entregables! Y si se lleno el arreglo? Uppss

El principio realmente es muy simple. Divides el tiempo del proyecto en iteraciones. Divides la funcionalidad pedida en características (o historias, como a XP le gusta llamarlas). Estimas cuanto trabajo cada característica tomará hacer. Mantienes un registro de cuánto se hace en cada iteración, y no pones más caracteristicas en una iteración de las que caben. La planeación de entregables (releases) de XP es acerca de decidir que características van en cada iteración.

Como muchas cosas, este es un proceso humano. En una conferencia reciente, mi colega Tim Mackinnon describió que al coubicar algunos comerciantes con el equipo de desarrollo hizo una gran diferencia en que los ayudo a tener un sentido realista de lo que se podría construir. Los comerciantes aún hacían su trabajo a tiempo completo, pero la comunicación informal que sucedía por la coubicación hizo la diferencia.

Las personas suelen caracterizar los métodos ágiles como anti-planes. Aunque la calidad de planificación fue una de las cosas mas impresionantes de Extreme Programming que encontre cuando lo vi por primera vez en su estado de larva. En particular la naturaleza simple de un plan hace difícil agregar características (tendrás que mover las fechas de los entregables) en el proyecto sin tener que enfrentar a sus consecuencias. Esta es la esencia de la planificación adaptable (o adaptativa) de los métodos ágiles — el plan cambia frecuentemente pero de una forma controlada. Si deseas agregar una nueva característica siempre preguntaras ‘que debo sacar para tener más espacio?’ Así que si ves características agregadas a un proyecto ágil sin tomar en cuenta eso, sin hacer un espacio para ella; puedes concluir con seguridad que la planificación se está haciendo mal.

Si te fue útil este artículo, por favor compártelo. Apreciamos los comentarios y el aliento.
Compartelo por:

Quiza te pueda interesar...

Agile vs Lean

desarrollo agil o lean? cual es mejor? son lo mismo? cual es su diferencia? Qué debería usar? traducido de Martin Fowler

Las cosas pequeñas importan

Uno de los principios fundamentales en el desarrollo de software que aparecen incluso en la vida misma

Detestable: testing

Tu sistema no es testeable?, bueno aquí un término para ese problema