[LUG.ro Mix] Reflecciones sobre programación extrema y SL.

[Horacio Castellini]

--Boundary-00=_auLHCu/BR3kFo/g
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Adjuntado al mensaje...

--Boundary-00=_auLHCu/BR3kFo/g
Content-Type: text/plain;
  charset="us-ascii";
  name="pe.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="pe.txt"

=C9rase los tiempos en que la inform=E1tica empez=F3 a hacerser popular, en=
 el=20
que solo hab=EDa pantallas en modo texto, las impresoras usaban papael con=
=20
agujeros a ambos lados y rayas horizontales. En aquellos tiempos las=20
aplicaciones eran mucho m=E1s sencillas que las actuales. Bastaba con uno=20
o dos programadores, que libres y con un tiempo razonable, eran capaces=20
de hacer programas =FAtiles. Para imprimir una lista de clientes bastaba=20
con pulsar "1" en el men=FA de impresi=F3n y mirar si la impresora imprim=
=EDa=20
o estaba el trabajo clavado en la cola. El programador era visto como=20
una especie de "mago" que hac=EDa su aplicaci=F3n y solo =E9l sab=EDa como=
=20
funcionaba. A lo sumo hac=EDa un diagrama de flujo.=20
Con el transcurso de los tiempos las m=E1quinas fueron cada vez m=E1s=20
potentes y las aplicaciones cada vez m=E1s exigentes, aparecieron los=20
entornos de ventanas y de alta resoluci=F3n. Ahora para imprimir una lista=
=20
de clientes, hay que arrastrar el =EDcono "cliente rechoncho" sobre=20
el =EDcono de la impresora, haciendo que camine como un egipcio mientras=20
lo arrastra con el rat=F3n. La impresora debe imprimir gr=E1ficos, en=20
negritas y con 32 fuentes simult=E1neas. Adem=E1s los parlantes de la=20
salida de sonido toquen "Bailando como un egipcio" de Banguels...
Todas estas exigencias condujeron a que los programas se agrandaran=20
como una progreci=F3n geom=E9trica en l=EDneas de c=F3digo y se complicaran=
 un=20
monton. Ya no basta con un par de programadores sino con un equipo de=20
desarrollo. Aparecieron las "metodolog=EDas de desarrollo". Antes de hacer=
=20
un programa hay que planificar que es lo que se quiere hacer, de forma=20
de asegurarse que el desarrollo y los clientes hablen el mismo idioma, y=20
acuerden sobre el producto final.
De alguna forma toda esta organizaci=F3n le quit=F3 el encanto de la=20
programaci=F3n de los primeros tiempos. Los programadores de apliciones,=20
en vez de dedicarse a lo que se supone m=E1s les gusta, programar, deben=20
dedicar bastante de su tiempo a hacer papeles y asistir a reuniones con=20
los clientes.
Tratando de recuperar un poco los viejos tiempos, naci=F3 un tipo nuevo de=
=20
operatoria de trabajo y metodolog=EDa de desarrollo: "La programaci=F3n=20
extrema" (PE).

En la PE se da por supuesto que es imposible preveer todo antes de=20
empezar a escribir el c=F3digo fuente. Es imposible tener en cuenta todos=20
los requisitos del sistema. La id=E9a de la PE consiste en hacer=20
mini-versiones con mucha frecuencia (cada dos semanas, por ejemplo). En=20
cada mini-versi=F3n se hace el m=EDnimo de c=F3digo posible y lo m=E1s simp=
le=20
para que funcione correctamente. El dise=F1o se va armando sobre la marcha=
=20
con un di=E1logo con el cliente. Se asume que el c=F3digo fuente es el mejo=
r=20
documento del proyecto, por lo tanto debe ser, al menos, abierto para=20
todos los interesdados.

En un proyecto de desarrollo que usa PE se sigue m=E1s o menos los=20
siguientes pasos: El cliente junto al equipo de desarrollo definen que=20
es lo que se quiere hacer. Para ello se utilizan las "historias de=20
usuario". Estas son textos que dice algo que debe hacer el sistema.=20
Luego se asocia cada mini-versi=F3n a cada historia de usuario.
Toda esta planificaci=F3n en principio va a ser inexacta. No se puede=20
saber todo. La planificaci=F3n se debe revisar y modificar continuamente a=
=20
lo largo de un proyecto. La historia de usuario se modificar=E1, se=20
quitar=E1n o se a=F1adir=E1n nuevas historias sobre la marcha seg=FAn las=20
exigencias del cliente.

Para las primneras historias, se elabora una prueba para saber si la=20
mini-versiones cumplen con las historias. Estas deben ser autom=E1ticas,=20
de forma que haya un programa prueba que se ejecute y no certifique si=20
la mini-versi=F3n es correcta o no. Los programadores se ponen por parejas=
=20
o ternas de mini-grupos de trabajo para codificar esas historias. Estas=20
se intercambian de forma que todos acaban laburando contodos. Esto tiene=20
la siguientes ventajas:

1) Cuato o seis ojos ven mejor que dos.
2) Los programadores novatos aprenden de los expertos.
3) Si un mini-grupo realiza una porci=F3n de c=F3digo, habr=E1 al menos dos=
=20
programadores que lo sepan, y que lo reutizaran cuando puedan. De forma=20
que el conocimento del c=F3digo se propaga en forma natural sobre el=20
equipo de trabajo.
4) El estilo de programaci=F3n tiende a uniformarse.

Cada vez que se consigue codificar una mini-versi=F3n y que funcione seg=FA=
n=20
las historias de usuario, se la da al cliente para que la vea, la pruebe=20
y a=F1ada las posibles modificaciones para las siguintes mini-versiones.=20
Hasta que se llega a la versi=F3n usuario-final. En la cu=E1l el cliente se=
=20
da por satisfecho.

Para que todo esto funciones, la PE se debe basar en trece "pr=E1ctica=20
b=E1sicas" dichas pr=E1cticas son (traducidas del ingl=E9s, perd=F3n si a=20
alguien no le gusta) (ver http://www.xprogramming.com/xpmag/whatisxp.htm)

1) Equipo completo: Forman parte del equipo todas las personas que est=E1n=
=20
relacionadas con el proyecto, inclusive el cliente.
2) Planificaci=F3n: Se hacen las historias de usuario y se planifican en qu=
e orden=20
se har=E1n las miniversiones
3) Test de cliente: El cliente, con la ayuda de los desarrolladores, propon=
e sus=20
propias pruebas para las mini-versiones.
4) Versiones peque=F1as: Las mini-versiones deben ser lo suficientemente ch=
icas=20
como para poder hacer una cada lapso breve de tiempo. Deben ofrecer algo =
=FAtil al=20
usuario final y no trozos de c=F3digo que no funcionen.
5) Dise=F1o simple: Hacer lo m=EDnimo imprescindible de la forma m=E1s senc=
illa=20
posible.
6) Grupos de tareas reducido: Los programadores trabajan en grupos no mayor=
es a=20
tres o en parejas, intercambi=E1ndose los miembreos bajo alg=FAn criterio.
7) Desarrollo guiado por las pruebas: Deben realizarse programas de prueba=
=20
autom=E1tica y se deben ejecutar con frecuencia. Cuantas m=E1s pruebas se h=
agan=20
mejor.
8) Depurar y mejorar el dise=F1o: Mientras se codifica, se debe mejorar y e=
liminar=20
partes innecesarias.
9) Integraci=F3n cont=EDnua: Debe tenerse siempre un ejecutables del proyec=
to que=20
funcione y en cuanto se tenga una nueva funcionabilidad, debe recompilarse =
y=20
probarse. Es un grave error mantener una versi=F3n conjelada por a=F1os o m=
eses,=20
mientras se hacen mejoras, para luego integrar todo de golpe. Pues cuando a=
lgo=20
falle, no se sabr=E1 porqu=E9.
10) El c=F3digo es de todos: Cualquiera puede y debe conocer el c=F3digo.
11) Uniformidad de codificaci=F3n: Se debe hacer un estilo comun de codific=
aci=F3n,=20
de forma tal que paresca hecho por una =FAnica persona.
12) Met=E1foras: Hay que usar frases o nombres que definan c=F3mo funcionan=
 las=20
distintas partes del programa, de forma que con solo el nombre de una llama=
da se=20
pueda hacer una id=E9a de la funci=F3n que cumplir=E1.
13) Ritmo sostenido: Se debe trabajar a un ritmo que pueda mantenerse=20
indefinidamente.

Como ejemplo de aplicaci=F3n real, estas reglas son aplicadas al mundo de l=
os=20
usuarios de CVS. En la cu=E1l se basa en gran medida los desarrollos de sof=
tware=20
de c=F3digo abierto o de libre lectura. Sea tanto GNU, BSD, etc.

--Boundary-00=_auLHCu/BR3kFo/g--