4.3 Variables de programación extrema

Las cuatro variables.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito. 

Además de estas cuatro variables, Beck propone que sólo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en función de las otras tres.

Pongámonos en un episodio diario de desarrollo.

El jefe de proyecto: “Quiero estos requisitos realizados para el día 1 de mes próximo, con lo que contáis con el equipo actual. ¡Ah ya sabéis que la calidad es lo primero!”

-Todos sabemos qué es lo primero que salta por la ventana en estos casos: “la calidad”, ¿ Por qué ? Porqué nadie es capaz de trabajar bien cuando se le somete a mucha presión.

- XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el valor que alcancen las cuatro variables sea el correcto para todas las partes: “Si quieres mas calidad en menos tiempo tendrás que aumentar el equipo e incrementar el coste”.

- Además con el agravante de que estas cuatro variables no guardan una relación tan directa como en principio pueda parecer. El incremento del número de programadores no repercutirá de manera lineal en el tiempo de desarrollo del proyecto, siendo de todos conocido el dicho: “nueve mujeres no pueden tener un hijo en un mes”.

- Con la calidad suele suceder un fenómeno extraño: frecuentemente un proyecto que tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo, siempre con unos márgenes obviamente. Es verdad que cuando un equipo de desarrollo se acostumbra a realizar pruebas intensivas, se siguen estándares de codificación, poco a poco

se comenzara a andar mas rápido y mas seguro, por tanto mas preparados para futuros cambios, sin estrés y así sucesivamente.

-Frente a esto existe la tentación de entregar el trabajo mas rápido, por tanto probar menos, codificar más rápido y peor, sin hacer planteamientos maduros, esto repercutirá en la confianza de nuestros clientes, al entregarle trabajos con fallos. Esta es una apuesta a muy corto plazo y suele ser una invitación al desastre, conduce a la desmoralización del equipo, y con ello a la larga a la ralentización del proyecto y la perdida de tiempo que habríamos conseguido en un principio.

- La cuarta variable, el ámbito del proyecto, suele ser conveniente que sea establecida por el equipo de desarrollo. Es una variable muy importante que nos va a decir donde vamos a llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para siguientes versiones. Cuantas veces hemos escuchado “Los clientes no nos pueden decir lo que quieren. Cuando le damos lo que nos piden no les gusta”. Y es que los requisitos nunca son claros al principio y el mismo desarrollo del software hace cambiar los requisitos. Por tanto el ámbito debe de ser dúctil, podremos jugar con el, si el tiempo para el lanzamiento es limitado, siempre habrá cosas que pudramos diferir para siguientes versiones. Por tanto implementaremos primero los requisitos mas importantes para el cliente, de forma que si tenemos que dejar algo para después que sea menos importante que las que ya incorpore un sistema.

Material extra:
http://www.willydev.net/descargas/prev/ExplicaXP.pdf