Diseño Agil con TDD nos enseñará a: * Escribir tests que aumenten la fiabilidad del código. * Escribir tests de aceptación que nos ayudarán a centrarnos, específicamente, en el problema a resolver. * Mejorar nuestros diseños para hacerlos más simples y flexibles. * Escribir código fácil de mantener. Con TDD, los test son documentación viva y actualizada de nuestro código, la mejor documentación posible. * Encajar TDD dentro del paradigma ágil y relacionarlo con otras técnicas como la integración continua.

1. Dise˜o Agil con TDD
n
Carlos Bl´ Jurado y colaboradores.
e
Prologo de Jos´ Manuel Beas
e

2. Primera Edici´n, Enero de 2010
o
www.iExpertos.com
El libro se ha publicado bajo la Licencia Creative Commons
2

3. ´
Indice general
I Base Te´rica
o 31
1. El Agilismo 33
1.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . . 35
1.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . . . . . 37
1.3. El manifiesto ´gil . . . . . . . . . . . . . . . . . .
a . . . . . 38
1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico
e a . . . . . 40
1.5. La situaci´n actual . . . . . . . . . . . . . . . . .
o . . . . . 44
´
1.6. Agil parece, pl´tano es . . . . . . . . . . . . . . .
a . . . . . 46
1.7. Los roles dentro del equipo . . . . . . . . . . . . . . . . . . 47
1.8. ¿Por qu´ nos cuesta comenzar a ser ´giles? . . . .
e a . . . . . 49
2. ¿Qu´ es el Desarrollo Dirigido por Tests? (TDD)
e 53
2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . . 56
2.1.1. Escribir la especificaci´n primero . . . . . . . . . . .
o 56
2.1.2. Implementar el c´digo que hace funcionar el ejemplo
o 57
2.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . . 58
2.2. Consideraciones y recomendaciones . . . . . . . . . . . . . . 60
2.2.1. Ventajas del desarrollador experto frente al junior . . 60
2.2.2. TDD con una tecnolog´ desconocida . . . . . . . .
ıa 60
2.2.3. TDD en medio de un proyecto . . . . . . . . . . . . 61
3. Desarrollo Dirigido por Tests de Aceptaci´no (ATDD) 63
3.1. Las historias de usuario . . . . . . . . . . . . . . . . . . . . 64
3.2. Qu´ y no C´mo . . . . .
e o . . . . . . . . . . . . . . . . . . . 68
3.3. ¿Est´ hecho o no? . . . .
a . . . . . . . . . . . . . . . . . . . 70
3.4. El contexto es esencial . . . . . . . . . . . . . . . . . . . . 71
3

4. ´
INDICE GENERAL ´
INDICE GENERAL
4. Tipos de test y su importancia 73
4.1. Terminolog´ en la comunidad TDD
ıa . . . . . . . . . . . . . 74
4.1.1. Tests de Aceptaci´n . . . . .
o . . . . . . . . . . . . . 75
4.1.2. Tests Funcionales . . . . . . . . . . . . . . . . . . . 76
4.1.3. Tests de Sistema . . . . . . . . . . . . . . . . . . . 76
4.1.4. Tests Unitarios . . . . . . . . . . . . . . . . . . . . 78
4.1.5. Tests de Integraci´n . . . . .
o . . . . . . . . . . . . . 80
5. Tests unitarios y frameworks xUnit 83
5.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . . . 84
6. Mocks y otros dobles de prueba 95
6.1. Cu´ndo usar un objeto real, un stub o un mock . . . . . . . 97
a
6.2. La met´fora Record/Replay . . . . . . . . . . . . . . . . . . 108
a
7. Dise˜o Orientado a Objetos
n 111
7.1. Dise˜o Orientado a Objetos (OOD) . . . . .
n . . . . . . . . 111
7.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . . 112
7.2.1. Single Responsibility Principle (SRP) . . . . . . . . . 113
7.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . . 113
7.2.3. Liskov Substitution Principle (LSP) . . . . . . . . . 114
7.2.4. Interface Segregation Principle (ISP) . . . . . . . . . 114
7.2.5. Dependency Inversi´n Principle (DIP)
o . . . . . . . . 115
7.3. Inversi´n del Control (IoC) . . . . . . . . . .
o . . . . . . . . 116
II Ejercicios Pr´cticos
a 119
8. Inicio del proyecto - Test Unitarios 121
9. Continuaci´n del proyecto - Test Unitarios
o 157
10.Fin del proyecto - Test de Integraci´n o 231
10.1. La frontera entre tests unitarios y tests de integraci´n
o . . . . 233
10.2. Dise˜o emergente con un ORM . . . . . . . . . . . .
n . . . . 243
10.2.1. Dise˜ando relaciones entre modelos . . . . .
n . . . . 246
10.3. La unificaci´n de las piezas del sistema . . . . . . . .
o . . . . 247
11.La soluci´n en versi´n Python
o o 249
12.Antipatrones y Errores comunes 289
4

5. ´
INDICE GENERAL ´
INDICE GENERAL
A. Integraci´n Continua (CI)
o 297
A.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . .
o . . . . 297
A.2. Pr´cticas de integraci´n continua . . . . . . . . . . .
a o . . . . 299
A.2.1. Automatizar la construcci´n . . . . . . . . .
o . . . . 299
A.2.2. Los test forman parte de la construcci´n . . .
o . . . . 300
A.2.3. Subir los cambios de manera frecuente . . . . . . . . 302
A.2.4. Construir en una m´quina de integraci´n . . .
a o . . . . 302
A.2.5. Todo el mundo puede ver lo que est´ pasando
a . . . . 303
A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . . 304
A.3. IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . . 304
A.4. Conclusi´n . . . . . . . . . . . . . . . . . . . . . . .
o . . . . 305
5

6. ´
INDICE GENERAL ´
INDICE GENERAL
6

7. A la memoria de nuestro querido gatito Lito, que vivi´ con total atenci´n y
o o
entrega cada instante de su vida
7

8. 8

9. Pr´logo
o
´
Erase una vez que se era, un lejano pa´ donde viv´ dos cerditos, Pablo
ıs ıan
y Adri´n que, adem´s, eran hermanos. Ambos eran los cerditos m´s listos
a a a
de la granja y, por eso, el gallo Iv´n (el gerente de la misma) organiz´ una
a o
reuni´n en el establo, donde les encarg´ desarrollar un programa de ordenador
o o
para controlar el almac´n de piensos. Les explic´ qu´ quer´ saber en todo
e o e ıa
momento: cu´ntos sacos de grano hab´ y qui´n met´ y sacaba sacos de
a ıa e ıa
grano del almac´n. Para ello s´lo ten´ un mes pero les advirti´ que, en
e o ıan o
una semana, quer´ ya ver algo funcionando. Al final de esa primera semana,
ıa
eliminar´ a uno de los dos.
ıa
Adri´n, que era el m´s joven e impulsivo, inmediatamente se puso manos
a a
a la obra. “¡No hay tiempo que perder!”, dec´ Y empez´ r´pidamente a
ıa. o a
escribir l´ıneas y l´
ıneas de c´digo. Algunas eran de un reciente programa que
o
hab´ ayudado a escribir para la guarder´ de la vaca Paca. Adri´n pens´ que
ıa ıa a o
no eran muy diferentes un almac´n de grano y una guarder´ En el primero
e ıa.
se guardan sacos y en el segundo, peque˜os animalitos. De acuerdo, ten´
n ıa
que retocar algunas cosillas para que aquello le sirviera pero bueno, esto del
software va de reutilizar lo que ya funciona, ¿no?
Pablo, sin embargo, antes de escribir una sola l´ ınea de c´digo comenz´ acor-
o o
dando con Iv´n dos cosas: qu´ era exactamente lo que podr´ ver dentro de
a e ıa
una semana y c´mo sabr´ que, efectivamente, estaba terminada cada cosa.
o ıa
Iv´n quer´ conocer, tan r´pido como fuera posible, cu´ntos sacos de grano
a ıa a a
hab´ en cada parte del almac´n porque sospechaba que, en algunas partes del
ıa e
mismo, se estaban acumulando sacos sin control y se estaban estropeando.
Como los sacos entraban y sal´ constantemente, no pod´ saber cu´ntos
ıan ıa a
hab´ y d´nde estaban en cada instante, as´ que acordaron ir contabiliz´ndo-
ıa o ı a
los por zonas y apuntando a qu´ parte iba o de qu´ parte ven´ cada vez
e e ıa,
que entrara o saliera un saco. As´ en poco tiempo podr´ tener una idea
ı, ıan
clara del uso que se estaba dando a las distintas zonas del almac´n. e
9

10. Pr´logo
o
Mientras Adri´n adelantaba a Pablo escribiendo muchas l´
a ıneas de c´digo,
o
Pablo escrib´ primero las pruebas automatizadas. A Adri´n eso le parec´
ıa a ıa
una p´rdida de tiempo. ¡S´lo ten´ una semana para convencer a Iv´n!
e o ıan a
Al final de la primera semana, la demo de Adri´n fue espectacular, ten´
a ıa
un control de usuarios muy completo, hizo la demostraci´n desde un m´vil y
o o
ense˜o, adem´s, las posibilidades de un generador de informes muy potente
n´ a
que hab´ desarrollado para otra granja anteriormente. Durante la demostra-
ıa
ci´n hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa
o
pero, salvo eso, todo fue genial. La demostraci´n de Pablo fue mucho m´s
o a
modesta, pero cumpli´ con las expectativas de Iv´n y el programa no fall´ en
o a o
ning´n momento. Claro, todo lo que ense˜o lo hab´ probado much´
u n´ ıa ısimas
veces antes gracias a que hab´ automatizado las pruebas. Pablo hac´ TDD,
ıa ıa
es decir, nunca escrib´ una l´
ıa ınea de c´digo sin antes tener una prueba que le
o
indicara un error. Adri´n no pod´ creer que Pablo hubiera gastado m´s de la
a ıa a
mitad de su tiempo en aquellas pruebas que no hac´ m´s que retrasarle a
ıan a
la hora de escribir las funcionalidades que hab´ pedido Iv´n. El programa de
ıa a
Adri´n ten´ muchos botones y much´
a ıa ısimas opciones, probablemente muchas
m´s de las que jam´s ser´ necesarias para lo que hab´ pedido Iv´n, pero
a a ıan ıa a
ten´ un aspecto “muy profesional”.
ıa
Iv´n no supo qu´ hacer. La propuesta de Pablo era muy robusta y hac´
a e ıa
justo lo que hab´ acordado. La propuesta de Adri´n ten´ cosillas que pulir,
ıan a ıa
pero era muy prometedora. ¡Hab´ hecho la demostraci´n desde un m´vil!
ıa o o
As´ que les propuso el siguiente trato: “Os pagar´ un 50 % m´s de lo que
ı e a
inicialmente hab´ ıamos presupuestado, pero s´lo a aquel de los dos que me
o
haga el mejor proyecto. Al otro no le dar´ nada.”. Era una oferta complicada
e
porque, por un lado, el que ganaba se llevaba mucho m´s de lo previsto. Muy
a
tentador. Pero, por el otro lado, corr´ el riesgo de trabajar durante un mes
ıan
completamente gratis. Mmmmm.
Adri´n, tan impulsivo y arrogante como siempre, no dud´ ni un instante.
a o
“¡Trato hecho!”, dijo. Pablo explic´ que aceptar´ s´lo si Iv´n se compro-
o ıa o a
met´ a colaborar como lo hab´ hecho durante la primera semana. A Iv´n le
ıa ıa a
pareci´ razonable y les convoc´ a ambos para que le ense˜aran el resultado
o o n
final en tres semanas.
Adri´n se march´ pitando y llam´ a su primo Sixto, que sab´ mucho
a o o ıa
y le asegurar´ la victoria, aunque tuviera que darle parte de las ganancias.
ıa
Ambos se pusieron r´pidamente manos a la obra. Mientras Adri´n arreglaba
a a
los defectillos encontrados durante la demo, Sixto se encarg´ de dise˜ar unao n
arquitectura que permitiera enviar mensajes desde el m´vil hasta un webser-
o
vice que permit´ encolar cualquier operaci´n para ser procesada en paralelo
ıa o
por varios servidores y as´ garantizar que el sistema estar´ en disposici´n de
ı ıa o
dar servicio 24 horas al d´ los 7 d´ de la semana.
ıa ıas
10

11. Pr´logo
o
Mientras tanto, Pablo se reuni´ con Iv´n y Bernardo (el encargado del
o a
almac´n) para ver cu´les deber´ ser las siguientes funcionalidades a desarro-
e a ıan
llar. Les pidi´ que le explicaran, para cada petici´n, qu´ beneficio obten´ la
o o e ıa
granja con cada nueva funcionalidad. Y as´ poco a poco, fueron elaborando
ı,
una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas.
A continuaci´n, Pablo fue, tarjeta a tarjeta, discutiendo con Iv´n y Bernardo
o a
cu´nto tiempo podr´ tardar en terminarlas. De paso, aprovech´ para anotar
a ıa o
algunos criterios que luego servir´ para considerar que esa funcionalidad
ıan
estar´ completamente terminada y eliminar alguna ambig¨edad que fuera
ıa u
surgiendo. Cuando Pablo pens´ que, por su experiencia, no podr´ hacer m´s
o ıa a
trabajo que el que ya hab´ discutido, dio por concluida la reuni´n y se
ıan o
dispuso a trabajar. Antes que nada, resolvi´ un par de defectos que hab´
o ıan
surgido durante la demostraci´n y le pidi´ a Iv´n que lo validara. A conti-
o o a
nuaci´n, se march´ a casa a descansar. Al d´ siguiente, cogi´ la primera de
o o ıa o
las tarjetas y, como ya hab´ hecho durante la semana anterior, comenz´ a
ıa o
automatizar los criterios de aceptaci´n acordados con Iv´n y Bernardo. Y lue-
o a
go, fue escribiendo la parte del programa que hac´ que se cumplieran esos
ıa
criterios de aceptaci´n. Pablo le hab´ pedido ayuda a su amigo Hudson, un
o ıa
coyote vegetariano que hab´ venido desde Am´rica a pasar el invierno. Hud-
ıa e
son no sab´ programar, pero era muy r´pido haciendo cosas sencillas. Pablo
ıa a
le encarg´ que comprobara constantemente los criterios de aceptaci´n que
o o
´l hab´ automatizado. As´ cada vez que Pablo hac´ alg´n cambio en su
e ıa ı, ıa u
programa, avisaba a Hudson y este hac´ una tras otra, todas las pruebas de
ıa,
aceptaci´n que Pablo iba escribiendo. Y cada vez hab´ m´s. ¡Este Hudson
o ıa a
era realmente veloz e incansable!
A medida que iba pasando el tiempo, Adri´n y Sixto ten´ cada vez
a ıan
m´s problemas. Terminaron culpando a todo el mundo. A Iv´n, porque no
a a
les hab´ explicado detalles important´
ıa ısimos para el ´xito del proyecto. A la
e
vaca Paca, porque hab´ incluido una serie de cambios en el programa de la
ıa
guarder´ que hac´ que no pudieran reutilizar casi nada. A los inventores de
ıa ıa
los SMS y los webservices, porque no ten´ ni idea de c´mo funciona una
ıan o
granja. Eran tantos los frentes que ten´ abiertos que tuvieron que prescindir
ıan
del env´ de SMS y buscaron un generador de p´ginas web que les permitiera
ıo a
dibujar el flujo de navegaci´n en un gr´fico y, a partir de ah´ generar el
o a ı,
esqueleto de la aplicaci´n. ¡Eso seguro que les ahorrar´ mucho tiempo! Al
o ıa
poco, Sixto, harto de ver que Adri´n no valoraba sus aportaciones y que ya
a
no se iban a usar sus ideas para enviar y recibir los SMS, decidi´ que se o
marchaba, a´n renunciando a su parte de los beneficios. Total, ´l ya no cre´
u e ıa
que fueran a ser capaces de ganar la competici´n. o
Mientras tanto, Pablo le pidi´ un par de veces a Iv´n y a Bernardo que le
o a
validaran si lo que llevaba hecho hasta aquel momento era de su agrado y les
11

12. Pr´logo
o
hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvi´ para
o
corregir algunos defectos y cambiar algunas prioridades. Iv´n y Bernardo
a
estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre
ellos comentaron m´s de una vez: “¿Qu´ estar´ haciendo Adri´n? ¿C´mo lo
a e a a o
llevar´?”.
a
Cuando se acercaba la fecha final para entregar el programa, Adri´n se a
qued´ sin dormir un par de noches para as´ poder entregar su programa.
o ı
Pero eran tantos los defectos que hab´ ido acumulando que, cada vez que
ıa
arreglaba una cosa, le fallaba otra. De hecho, cuando lleg´ la hora de la
o
demostraci´n, Adri´n s´lo pudo ense˜ar el programa instalado en su port´til
o a o n a
(el unico sitio donde, a duras penas, funcionaba) y fue todo un desastre:
´
mensajes de error por todos sitios, comportamientos inesperados... y lo peor
de todo: el programa no hac´ lo que hab´ acordado con Iv´n.
ıa ıan a
Pablo, sin embargo, no tuvo ning´n problema en ense˜ar lo que llevaba
u n
funcionando desde hac´ mucho tiempo y que tantas veces hab´ probado. Por
ıa ıa
si acaso, dos d´ antes de la entrega, Pablo hab´ dejado de introducir nuevas
ıas ıa
caracter´ısticas al programa porque quer´ centrarse en dar un buen manual de
ıa
usuario, que Iv´n hab´ olvidado mencionar en las primeras reuniones porque
a ıa
daba por sentado que se lo entregar´ Claro, Adri´n no hab´ tenido tiempo
ıan. a ıa
para nada de eso.
Moraleja:
Adem´s de toda una serie de buenas pr´cticas y un proceso de desarrollo
a a
´gil, Pablo hizo algo que Adri´n despreci´: acord´ con Iv´n (el cliente) y con
a a o o a
Bernardo (el usuario) los criterios mediante los cu´les se comprobar´ que
a ıa
cada una de las funcionalidades estar´ bien acabada. A eso que solemos lla-
ıa
mar “criterios de aceptaci´n”, Pablo le a˜adi´ la posibilidad de automatizar
o n o
su ejecuci´n e incorporarlos en un proceso de integraci´n continua (que es
o o
lo que representa su amigo Hudson en este cuento). De esta manera, Pablo
estaba siempre tranquilo de que no estaba estropeando nada viejo con cada
nueva modificaci´n. Al evitar volver a trabajar sobre asuntos ya acabados,
o
Pablo era m´s eficiente. En el corto plazo, las diferencias entre ambos en-
a
foques no parecen significativas, pero en el medio y largo plazo, es evidente
que escribir las pruebas antes de desarrollar la soluci´n es mucho m´s eficaz
o a
y eficiente.
En este libro que ahora tienes entre tus manos, y despu´s de este inusual
e
pr´logo, te invito a leer c´mo Carlos explica bien clarito c´mo guiar el desa-
o o o
rrollo de software mediante la t´cnica de escribir antes las pruebas (m´s
e a
conocido como TDD).
12

13. Agradecimientos
Una vez o´ a un maestro zen decir que la gratitud que expresa una per-
ı
sona denota su estado moment´neo de bienestar consigo misma. Estoy muy
a
contento de ver que este proyecto que se empez´ hace casi a˜o y medio, ha
o n
concluido con un resultado tan gratificante.
Tengo que agradecer cosas a miles de personas pero para no extenderme
demasiado, lo har´ hacia los que han tenido una relaci´n m´s directa con el
e o a
libro.
En primer lugar tengo que agradecer a D´cil Casanova que haya sido
a
la responsable de calidad n´mero uno en el proyecto. Sin ella este libro no
u
se hubiera escrito de esta forma y en este momento. Quiz´s no se hubiese
a
escrito nunca. No s´lo tengo que agradecer todo lo much´
o ısimo que me aporta
en lo personal sino que adem´s me anim´ constantemente a no publicar el
a o
libro hasta que estuviera hecho lo mejor posible. Ha revisado mi redacci´n o
corrigiendo mil faltas de ortograf´ y signos de puntuaci´n.
ıa o
El toque de calidad que dan los dem´s coautores al libro, es tambi´n un
a e
detallazo. Adem´s de escribir texto han sido buenos revisores. Estoy profun-
a
damente agradecido a Juan Guti´rrez Plaza por haber escrito el cap´
e ıtulo 11
y por haber hecho correcciones desde la primera revisi´n del libro hasta la
o
ultima. Ha sido un placer discutir juntos tantos detalles t´cnicos. Gracias a
´ e
Fran Reyes Perdomo tenemos un gran ap´ndice sobre Integraci´n Cont´
e o ınua
que de no haber sido por ´l no estar´ en el libro, con lo importante que es
e ıa
esta pr´ctica. Mil gracias Fran. Gregorio Mena es el responsable de que el
a
cap´ıtulo 1 no sea un completo desastre. Ha sido para m´ el m´s dif´ de
ı a ıcil
escribir de todo el libro y a ning´n revisor le acababa de convencer. Gregorio
u
ha refactorizado medio cap´ ıtulo d´ndole un toque mucho m´s serio. Espero
a a
que sigamos trabajando juntos Gregorio :-) Para terminar con los coautores
quiero agradecer a Jos´ Manuel Beas que haya escrito el pr´logo del libro a
e o
pesar de lo muy ocupado que est´ liderando la comunidad ´gil espa˜ola y
a a n
13

14. Agradecimientos
haciendo de padre de familia. Un bonito detalle JM ;-D
A continuaci´n quiero agradecer a la decena de personas que han le´
o ıdo
las revisiones del libro previas a la publicaci´n y que han aportado correccio-
o
nes, palabras de ´nimo e incluso texto. Agradecimientos especiales a Esteban
a
Manchado Vel´zquez que tiene much´
a ısimo que ver con la calidad de la redac-
ci´n y que ha sido uno de los revisores m´s constantes. Yeray Darias adem´s
o a a
de revisar, escribi´ el cap´
o ıtulo que le ped´ sobre DDD, aunque finalmente
ı
queda para un libro futuro. Mi buen amigo Eladio L´pez de Luis ha dejado
o
alg´n comentario en cada revisi´n que he ido enviando. Alberto Rodr´
u o ıguez
Lozano ha sido una de las personas m´s influyentes en las correcciones del
a
cap´ıtulo 9, aportando comentarios t´cnicos de calidad. No puedo olvidar al
e
resto de revisores que han seguido el libro en distintas etapas aportando
tambi´n comentarios muy brillantes: N´stor Bethencourt, Juan Jorge P´rez
e e e
L´pez, Pablo Rodr´
o ıguez S´nchez, Jos´ Ram´n D´ Jose M. Rodr´
a e o ıaz, ıguez de
la Rosa, V´ ıctor Rold´n y N´stor Salceda. Tambi´n agradezco a todas las
a e e
personas que han le´ alguna de estas revisiones previas y me han enviado
ıdo
emails personales de agradecimiento.
Hadi Hariri me influenci´ mucho para que partiese el libro en dos y dejase
o
para ´ste, solo aquellos temas de relaci´n directa con TDD.
e o
Ahora, m´s all´ de los que han tenido relaci´n directa con el libro, quiero
a a o
agradecer a Rodrigo Trujillo, ex director de la Oficina de Software Libre de
la Universidad de La Laguna (ULL), que me diera la oportunidad de dirigir
un proyecto y carta blanca para aplicar TDD desde el primer d´ porque ıa,
durante el a˜o que trabaj´ ah´ aprend´ toneladas de cosas. Rodrigo es una de
n e ı ı
las personas que m´s se mueve en la ULL; no deja de intentar abrir puertas
a
a los estudiantes que est´n terminado ni de preocuparse por la calidad de su
a
universidad.
Gracias tambi´n a Jos´ Lu´ Roda, Pedro Gonz´lez Yanes y Jes´s Alberto
e e ıs a u
Gonz´lez por abrirme las puertas de la facultad de inform´tica y tambi´n por
a a e
permitirme que impartiese mi primer curso completo de TDD. De la facultad
tengo tambi´n que agradecer a Marcos Colebrook que me diese el empuj´n
e o
que necesitaba para terminar la carrera, que la ten´ casi abandonada. Sin
ıa
Marcos y Goyo, el cambio de plan hubiera hecho que abandonase la idea de
terminar la carrera.
A Esteban Abeledo y al resto del Colegio de Informaticos de Canarias les
agradezco mucho hayan homologado nuestros cursos de TDD.
Los alumnos de mis cursos de TDD tienen mucho que ver con el resultado
final del libro ya que he volcado en ´l muchas de sus dudas y comentarios
e
t´
ıpicos. Gracias a los dos grupos que he tenido en Tenerife y al de Sevilla,
todos en 2009. Menci´n especial a las personas que ayudaron a que saliesen
o
´
adelante: Alvaro Lobato y los ya citados Gregorio, Pedro y Roda.
14

15. Agradecimientos
Gracias a todos los que est´n promoviendo XP en Espa˜a. A saber: Al-
a n
fredo Casado, Xavier Gost, Leo Antol´ Agust´ Yag¨e, Eric Mignot, Jorge
ı, ın u
Jim´mez, Iv´n P´rraga, Jorge Uriarte, Jes´s P´rez, David Esmerodes, Luismi
e a a u e
Cavall´, David Calavera, Ricardo Rold´n y tantos otros profesionales de la
e a
comunida Agile Spain, entre los cuales est´n los coautores y revisores de este
a
libro. Y tambi´n a los que est´n promoviendo XP en Latinoam´rica: Fabi´n
e a e a
Figueredo, Carlos Peix, Angel L´pez, Carlos Lone y tantos otros. Y al pibe
o
que vos viste nos rrre-ayud´ a traer el Agile Open a Espa˜a, Xavier Quesada
o n
;-)
Alfredo Casado adem´s ha escrito la sinopsis del libro.
a
Quiero saludar a todas las personas con las que he trabajado en mi paso
por las muchas empresas en que he estado. De todos he aprendido algo. Gra-
cias a los que me han apoyado y gracias tambi´n a los que me han querido
e
tapar, porque de todos he aprendido cosas. Ha sido tremendamente enrique-
cedor cambiar de empresa y de proyectos. Thank you all guys at Buy4Now
in Dublin during my year over there in 2007. Tambi´n he aprendido mucho
e
de todos aquellos desarrolladores con los que he trabajado en proyectos open
source, en mi tiempo libre.
A quienes han confiado en m´ para impartir cursos de materias diversas,
ı
porque han sido claves para que desarrolle mi capacidad docente; Agust´ ın
Benito, Academia ESETEC, Armando Fumero, Innova7 y Rodrigo Trujillo.
Agradecimientos tambi´n a Pedro Gracia Fajardo, una de las mentes
e
m´s brillantes que he conocido. Un visionario. Pedro fue qui´n me habl´ por
a e o
primera vez de XP en 2004. En aquel entonces nos cre´ ıamos que ´ramos ´giles
e a
aunque en realidad lo est´bamos haciendo fatal. La experiencia sirvi´ para
a o
que yo continuase investigando sobre el tema.
Gracias a la comunidad TDD internacional que se presenta en un grupo
de discusi´n de Yahoo. Aunque ellos no leer´n estas l´
o a ıneas por ser en espa˜ol,
n
quiero dejar claro que sin su ayuda no hubiese sabido resolver tantos proble-
mas t´cnicos. Gracias a Kent Beck y Lasse Koskela por sus libros, que han
e
sido para m´ fuente de inspiraci´n.
ı o
Aprovecho para felicitar a Roberto Canales por su libro, Inform´tica a
Profesional[13]. Es una pena que me haya puesto a leerlo cuando ya ten´ ıa
escrito este libro, a pocos d´ de terminar el proyecto. Si lo hubiese le´ en
ıas ıdo
octubre, cuando Leo me lo regal´, me hubiese ahorrado bastantes p´rrafos
o a
de la parte te´rica. Es un pedazo de libro que recomiendo a todo el mundo.
o
Gracias Roberto por brindarnos un libro tan brillante. Un libro, un amigo.
Gracias a Angel Medinilla, Juan Palacio, Xavi Albaladejo y Rodrigo Co-
rral, por entrenar a tantos equipos ´giles en nuestro pa´ Angel adem´s me
a ıs. a
regala muy buenos consejos en mi nueva etapa en iExpertos.
Por ultimo no quiero dejar de decirle a mi familia que sin ellos esto
´
15

16. Agradecimientos
no ser´ posible. A D´cil de nuevo por todo lo much´
ıa a ısimo que me aporta
diariamente. A mis padres por traerme al mundo y ense˜arme tantas cosas.
n
A mis hermanas por querer tanto a su hermano mayor. A mis primos. A
mi t´ Tina por acogerme en su casa durante mis a˜os de universidad y
ıa n
darme la oportunidad de estudiar una carrera, ya que mis padres no pod´ ıan
costearmelo. Ella me ayuda siempre que lo necesito. A mis abuelos por estar
siempre ah´ como mis segundos padres.
ı,
16

17. Autores del libro
Carlos Bl´ Jurado
e Nac´ en C´rdoba en 1981, hijo de cordobeses
ı o
pero cuando ten´ 4 a˜os emigramos a Lanza-
ıa n
rote y, salvo algunos a˜os intercalados en los
n
que viv´ en C´rdoba, la mayor parte de mi vida
ı o
la he pasado en Canarias. Primero en Lanzarote
y despu´s en Tenerife.
e
Mi primer apellido significa trigo en franc´s. Lo
e
trajo un franc´s al pueblo cordob´s de La Vic-
e e
toria en tiempos de Carlos III.
Cuando ten´ 6 a˜os mi padre trajo a casa un
ıa n
8086 y aquello me fascin´ tanto que supe que
o
me quer´ dedicar a trabajar con ordenadores
ıa
desde entonces. He tenido tambi´n Amiga 500,
e
Amiga 1200, y luego unos cuantos PC, desde el
AMD K6 hasta el Intel Core Duo de hoy.
Soy ingeniero t´cnico en inform´tica de sistemas. Para m´ el t´
e a ı ıtulo no
es ninguna garant´ de profesionalidad, m´s bien hago un balance negativo
ıa a
de mi paso por la Universidad, pero quer´ ponerlo aqu´ para que los que
ıa ı
padecen de titulitis vean que el que escribe es titulado.
La primera vez que gan´ dinero con un desarrollo de software fue en
e
2001. Poco despu´s de que instalase Debian GNU/Linux en mi PC. En 2003
e
entr´ de lleno en el mercado laboral. Al principio trabaj´ administrando sis-
e e
temas adem´s de programar.
a
En 2005 se me ocurri´ la genial idea de montar una empresa de desarrollo
o
de software a medida con mis colegas. Sin tener suficiente experiencia como
desarrollador y ninguna experiencia como empresario ni comercial, fue toda
17

18. Autores del libro
una aventura sobrevivir durante los dos a˜os que permanec´ en la empresa.
n ı
Fueron dos a˜os equivalentes a cuatro o cinco trabajando en otro sitio. Ver
n
el negocio del software desde todos los puntos de vista, me brind´ la opor-
o
tunidad de darme cuenta de muchas cosas y valorar cuestionas que antes
no valoraba. Aprend´ que no pod´ tratar al cliente como si fuera un tester.
ı ıa
No pod´ limitarme a probar las aplicaciones 10 minutos a mano antes de
ıa
entregarlas y pensar que estaban hechas. Aprend´ que la venta era m´s deci-
ı a
siva que el propio software. Tambi´n aprend´ cosas feas como que Hacienda
e ı
no somos todos, que los concursos p´blicos se ama˜an, que el notario da
u n
m´s miedo que el dentista, que el pez grande se come al peque˜o y muchas
a n
otras. Al final me d´ cuenta de que la odisea me sobrepasaba y no era capaz
ı
de llevar la empresa a una posici´n de estabilidad donde por f´ dejase de
o ın
amanecerme sentado frente a la pantalla. Cansado de los morosos y de que la
administraci´n p´blica nos tuviera sin cobrar meses y meses, mientras estaba
o u
con el agua al cuello, en 2007 me mand´ a mudar a Irlanda para trabajar
e
como desarrollador. Aprend´ lo importante que era tener un equipo de QA1 y
ı
me volqu´ con los tests automatizados. Llegu´ a vivir el boom de los sueldos
e e
en Dublin, cobrando 5000 euros mensuales y sin hacer ni una sola hora extra.
En 2008 regres´ a Tenerife.
e
En la actualidad he vuelto a emprender. Desarrollo software profesional-
mente de manera vocacional. Mi esp´ ıritu emprendedor me lleva a poner en
marcha nuevas ideas en la nube. Adem´s me dedico a formar a desarrolladores
a
impartiendo cursos sobre TDD, c´digo limpio, metodolog´ y herramientas
o ıa
de programaci´n. En lugar de intentar trabajar en mi empresa, trabajo para
o
la empresa2 , cuya web es www.iExpertos.com
Habitualmente escribo en www.carlosble.com y en el blog de iExpertos.
He escrito la mayor parte del libro con la excepci´n de los fragmentos
o
que nos han regalado los dem´s autores.
a
1
Quality Assurance
2
El matiz viene del libro, El Mito del Emprendedor, de Michael E. Gerber
18

19. Autores del libro
Jose Manuel Beas En 2008 decidi´ aprovechar sus circunstancias
o
personales para tomarse un respiro, mirar atr´s,
a
a los lados y, sobre todo, hacia adelante. Y as´ ı,
aprovech´ ese tiempo para mejorar su forma-
o
ci´n en temas como Scrum asistiendo al cur-
o
so de Angel Medinilla. Pero tambi´n quiso po-
e
ner su peque˜o granito de arena en el desarro-
n
llo y la difusi´n de Concordion, una herramien-
o
ta de c´digo abierto para realizar pruebas de
o
aceptaci´n, y rellenar su “caja de herramientas”
o
con cosas como Groovy y Grails. Pero sobre to-
do vi´ que merec´ la pena poner parte de su
o ıa
energ´ en revitalizar una vieja iniciativa llama-
ıa
da Agile Spain y buscar a todos aquellos que, co-
mo ´l, estuvieran buscando maneras mejores de
e
hacer software. Y vaya que si los encontr´. Ac-
o
tualmente es el Presidente de la asociaci´n Agi-
o
le Spain, que representa a la comunidad agilista
en Espa˜a y organizadora de los Agile Open
n
Spain y las Conferencias Agile Spain. Tambi´n e
participa en la elaboraci´n de los podcasts de
o
Podgramando.es, una iniciativa de “agilismo.es
powered by iExpertos.com”. Puedes localizar-
lo f´cilmente a trav´s del portal agilismo.es, en
a e
la lista de correo de Agile Spain o en su blog
personal http://jmbeas.iexpertos.com.
19

20. Autores del libro
Juan Guti´rrez
e Escribir, he escrito poco, pero aprender,
Plaza much´ ısimo. He intentado hacer algo con sen-
tido con mi oxidado Python en el cap´ ıtulo 11
aunque m´s que escribir, ha sido discutir y re-
a
discutir con Carlos sobre cual era la mejor forma
de hacer esto y aquello (siempre ha ganado ´l).e
Tambi´n he sacado del ba´l de los recuerdos mi
e u
LaTeX y he revisado mucho. Cuando no estoy
discutiendo con la gente de Agile Spain, trabajo
como “Agile Coach” en F-Secure donde intento
ayudar a equipos de Finlandia, Malasia, Rusia
y Francia en su transici´n a las metodolog´
o ıas
a
´giles (tanto en gesti´n como en pr´cticas de
o a
software entre las que se incluye, por supues-
to, TDD). ¿Pero c´mo he llegado hasta aqu´
o ı?
Mi devoci´n los ordenadores me llev´ a estu-
o o
diar la carrera de ingenier´ en inform´tica en
ıa a
la UPM de Madrid. Trabaj´ en Espa˜a por un
e n
tiempo antes de decidir mudarme a Finlandia
en el 2004 para trabajar en Nokia. En las lar-
gas y oscuras “tardes” del invierno Finland´s e
estudi´ un master en “industrial management”
e
antes de cambiar a F-Secure. Cuando el tiempo
lo permite, escribo en http://agilizar.es
Fran Reyes Perdo- Soy un apasionado desarrollador de software in-
mo teresado en “pr´cticas ´giles”. Llevo cerca de
a a
4 a˜os trabajando para la r´
n ıgida Administra-
ci´n p´blica con un fantastico equipo. Conoc´ a
o u ı
Carlos Bl´ en un provechoso curso de TDD que
e
imparti´ para un grupo de compa˜eros. Entre
o n
cervezas (una fase importante para asimilar lo
aprendido), compartimos ideas y experiencias
del mundo del software, y me habl´ adem´s
o a
del proyecto en el que se encontraba embar-
cado, en el cual me brind´ la oportunidad de
o
participar con un peque˜o ap´ndice sobre inte-
n e
graci´n continua. Una pr´ctica, que intentamos,
o a
forme parte del d´ a d´ en nuestros proyectos.
ıa ıa
http://es.linkedin.com/in/franreyesperdomo
20

21. Autores del libro
Gregorio Mena Mi corta vida profesional ha sido sufi-
ciente para dar sentido a la frase de Ho-
racio “Ning´n hombre ha llegado a la
u
excelencia en arte o profesi´n alguna,
o
sin haber pasado por el lento y doloroso
proceso de estudio y preparaci´n”. Aun-
o
que en mi caso el camino no es doloro-
so, sino apasionante. Siguiendo esta fi-
losof´ intento formarme y fomentar la
ıa,
formaci´n, por lo que he organizado un
o
curso de TDD impartido con gran acier-
to por Carlos Ble y voy a participar en
futuras ediciones. Trabajo desde iExper-
tos para que entre todos hagamos posi-
ble el primer curso de Scrum en Cana-
rias, pues tambi´n colaboro con la plata-
e
forma ScrumManager. Ha sido esta for-
ma de ver nuestra profesi´n la que me
o
llev´ a colaborar con Carlos en este li-
o
bro. Pensaba aportar algo, pero lo cier-
to es que lo que haya podido aportar no
tiene comparaci´n con lo que he tenido
o
la suerte de recibir. Por ello debo dar
a Carlos las gracias por ofrecerme esta
oportunidad y por el esfuerzo que ha he-
cho para que este libro sea una realidad
para todos los que vemos en la formaci´n
o
continua el camino al ´xito.
e
Habitualmente escribo en
http://eclijava.blogspot.com.
21

22. Autores del libro
22

23. Convenciones y Estructura
Este libro contiene numerosos bloques de c´digo fuente en varios len-
o
guajes de programaci´n. Para hacerlos m´s legibles se incluyen dentro de
o a
rect´ngulos que los separan del resto del texto. Cuando se citan elementos
a
de dichos bloques o sentencias del lenguaje, se usa este tipo de letra.
A lo largo del texto aparecen referencias a sitios web en el pie de p´gina.
a
Todas ellas aparecen recopiladas en la p´gina web del libro.
a
Las referencias bibliogr´ficas tienen un formato como este:[3]. Las ultimas
a ´
p´ginas del libro contienen la bibliograf´ detallada correspondiente a todas
a ıa
estas referencias.
Otros libros de divulgaci´n repiten determinadas ideas a lo largo de varios
o
cap´ıtulos con el fin de reforzar los conceptos. En la era de la infoxicaci´n3
o
tal repetici´n sobra. He intentado minimizar las repeticiones de conceptos
o
para que el libro se pueda revisar r´pidamente, por lo que es recomendable
a
una segunda lectura del mismo para quienes desean profundizar en la materia.
Ser´ como ver una pel´
a ıcula dos veces: en el segundo pase uno aprecia muchos
detalles que en el primero no vio y su impresi´n sobre el contenido puede
o
variar. En realidad, es que soy tan mal escritor que, si no lee el libro dos
veces no lo va a entender. H´gase a la idea de que tiene 600 p´ginas en lugar
a a
de 300.
Sobre los paquetes de c´digo fuente que acompa˜an a este libro (listo
o n
para descarga en la web), el escrito en C# es un proyecto de Microsoft
Visual Studio 2008 (Express Edition) y el escrito en Python es una carpeta
de ficheros.
3
http://es.wiktionary.org/wiki/infoxicaci %C3 %B3n
23

24. Convenciones y Estructura
24

25. La Libertad del Conocimiento
El conocimiento ha sido transmitido de individuo a individuo desde el
comienzo mismo de la vida en el planeta. Gracias a la libre circulaci´n del
o
conocimiento hemos llegado a donde estamos hoy, no s´lo en lo referente al
o
avance cient´ıfico y tecnol´gico, sino en todos los campos del saber.
o
Afortunadamente, el conocimiento no es propiedad de nadie sino que
es como la energ´ simplemente fluye, se transforma y nos transforma. De
ıa;
hecho no pertenece a las personas, no tiene due˜o, es de todos los seres.
n
Observando a los animales podemos ver c´mo los padres ense˜an a su prole
o n
las t´cnicas que necesitar´n para desenvolverse en la vida.
e a
El conocimiento contenido en este libro no pertenece al autor. No perte-
nece a nadie en concreto. La intenci´n es hacerlo llegar a toda persona que
o
desee aprovecharlo.
En Internet existe mucha documentaci´n sobre la libertad del conocimien-
o
to, empezando por la entrada de la Wikipedia4 . Este argumento es uno de los
principales pilares del software libre5 , al que tanto tengo que agradecer. Las
principales herramientas que utilizaremos en este libro est´n basadas en soft-
a
ware libre: frameworks xUnit, sistemas de control de versiones y frameworks
para desarrollo de software. Personalmente me he convertido en usuario de
la tecnolog´ Microsoft .Net gracias al framework Mono6 , desarrollado por
ıa
Novell con licencia libre. De no haber sido por Mono probablemente no hu-
biera conocido C#.
El libro ha sido maquetado usando LTEX, concretamente con teTex y Mik-
A
TeX(software libre) y ha requerido de multitud de paquetes libres desarro-
4
http://es.wikipedia.org/wiki/Conocimiento libre
5
http://es.wikipedia.org/wiki/C´digo libre
o
6
http://www.mono-project.com
25

26. La Libertad del Conocimiento
llados por la comunidad. Para la edici´n del texto se ha usado Texmaker,
o
Dokuwiki, Vim y Emacs. El versionado de los ficheros de texto se ha llevado
a cabo con Subversion. Los diagramas de clases los ha generado SharpDe-
velop, con el cual tambi´n he editado c´digo. Estoy muy agradecido a todos
e o
los que han escrito todas estas piezas. En la web del libro se encuentra el
esqueleto con el que se ha maquetado para que, quien quiera, lo use para sus
propias publicaciones.
Pese a mi simpat´ por el software de fuente abierta, este libro va m´s all´ de
ıa a a
la dicotom´ software libre/software propietario y se centra en t´cnicas apli-
ıa e
cables a cualquier lenguaje de programaci´n en cualquier entorno. Uno de los
o
peores enemigos del software libre es el fanatismo radical de algunos de sus
evangelizadores, que raya en la mala educaci´n y empa˜a el buen hacer de
o n
los verdaderos profesionales. Es mi deseo aclarar que mi posici´n personal no
o
es ni a favor ni en contra del software propietario, simplemente me mantengo
al margen de esa contienda.
26

27. La Web del Libro
Los enlaces a sitios web de Internet permanecen menos tiempo activos
en la red que en las p´ginas de un libro impreso; la lista de referencias se
a
mantendr´ actualizada en un sitio web dedicado al libro:
a
http://www.dirigidoportests.com
Si el lector desea participar informando de enlaces rotos, podr´ hacerlo diri-
a
gi´ndose a la web del libro o bien mediante correo electr´nico al autor:
e o
carlos[Arroba]iExpertos[Punto]com
El c´digo fuente que acompa˜a al libro se podr´ descargar en la misma
o n a
web.
Si bien es cierto que escribir el libro ha sido un placer, tambi´n es cierto
e
que ha sido duro en ocasiones. Ha supuesto casi a˜o y medio de trabajo
n
y, dado que el libro es gratis y ni siquiera su venta en formato papel se
traducir´ en algo de beneficio, en la web es posible hacer donaciones. Si el
a
libro le gusta y le ayuda, le invito a que haga una donaci´n para que en el
o
futuro puedan haber m´s libros libres como este.
a
27

28. La Web del Libro
28

29. ¿Cu´l es el Objetivo del Libro?
a
El objetivo fundamental del libro es traer a nuestro idioma, el espa˜ol,
n
conocimiento t´cnico que lleva a˜os circulando por pa´ de habla inglesa.
e n ıses
No cabe duda de que los que inventaron la computaci´n y el software nos
o
siguen llevando ventaja en cuanto a conocimiento se refiere. En mi opini´n, o
es una cuesti´n cultural en su mayor parte pero, sea como fuere, no pode-
o
mos perder la oportunidad de subirnos al carro de las nuevas t´cnicas de
e
desarrollo y difundir el conocimiento proporcionado por nuestros compa˜eros
n
angloparlantes. S´lo as´ competiremos en igualdad de condiciones, porque a
o ı
d´ de hoy cada vez m´s clientes apuestan por el outsourcing. Conocimiento
ıa a
es poder.
A d´ de hoy, por suerte o por desgracia, no nos queda m´s remedio
ıa a
que dominar el ingl´s, al menos el ingl´s t´cnico escrito, y es conveniente
e e e
leer mucho en ese idioma. Se aprende much´ ısimo porque no s´lo lo usan
o
los nativos de habla inglesa sino que se ha convertido en el idioma universal
en cuanto a tecnolog´ Sin embargo, reconozco que yo mismo hace unos
ıa.
a˜os era muy reacio a leer textos en ingl´s. He tenido que hacer un gran
n e
esfuerzo y leer mucho con el diccionario en la mano hasta llegar al punto
en que no me cuesta trabajo leer en ingl´s (adem´s de vivir una temporada
e a
fuera de Espa˜a). Conozco a pocos compa˜eros que hagan este esfuerzo. Es
n n
comprensible y normal que la mayor´ se limite a leer lo que est´ documentado
ıa a
en espa˜ol. Al fin y al cabo es de los idiomas m´s hablados del planeta. Por
n a
eso concluyo que hay que traer la informaci´n a nuestro idioma para llegar
o
a m´s gente, aunque el buen profesional deber´ tener presente las m´ltiples
a a u
ventajas que le aportar´ el dominio del ingl´s escrito. Cuando no dominamos
a e
el ingl´s nos perdemos muchos matices que son significativos7 .
e
Apenas hay libros sobre agilismo en espa˜ol. Los unicos libros novedosos
n ´
que se editan en nuestra lengua relacionados con el mundo del software,
7
http://jmbeas.iexpertos.com/hablar-ingles-es-facil-si-sabes-como/
29

30. ¿Cu´l es el objetivo del libro?
a
tratan sobre tecnolog´ muy espec´
ıas ıficas que hoy valen y ma˜ana quiz´s no.
n a
Est´ muy bien que haya libros sobre Java, sobre .Net o sobre Ruby, pero no
a
tenemos que limitarnos a ello. El unico libro sobre agilismo que hay a d´ de
´ ıa
hoy es el de Scrum, de Juan Palacio[15]. Por otro lado, Angel Medinilla ha
traducido el libro de Henrik Kniberg[8], Scrum y XP desde las Trincheras y
Leo Antol´ ha traducido The Scrum Primer. Estos regalos son de agradecer.
ı
Ahora que existen editoriales en la red tales como Lulu.com, ya no hay
excusa para no publicar contenidos t´cnicos. Personalmente me daba reparo
e
afrontar este proyecto sin saber si alguna editorial querr´ publicarlo pero
ıa
ya no es necesario que las editoriales consideren el producto comercialmente
v´lido para lanzarlo a todos los p´blicos. Otro objetivo del libro es animar a
a u
los muchos talentos hispanoparlantes que gustan de compartir con los dem´s, a
a que nos deleiten con su conocimiento y sus dotes docentes. ¿Qui´n se anima
e
con un libro sobre Programaci´n Extrema?.
o
No me cabe duda de que las ideas planteadas en este libro pueden re-
sultarles controvertidas y desafiantes a algunas personas. El lector no tiene
por qu´ coincidir conmigo en todo lo que se expone; tan s´lo le invito a que
e o
explore con una mente abierta las t´cnicas aqu´ recogidas, que las ponga en
e ı
pr´ctica y despu´s decida si le resultan o no valiosas.
a e
30

31. Parte I
Base Te´rica
o
31

33. Cap´tulo
ı 1
El Agilismo
Para definir qu´ es el agilismo, probablemente basten un par de l´
e ıneas. Ya
veremos m´s adelante, en este mismo cap´
a ıtulo, que el concepto es realmente
simple y queda plasmado en cuatro postulados muy sencillos. Pero creo que
llegar a comprenderlo requiere un poco m´s de esfuerzo y, seguramente, la
a
mejor manera sea haciendo un repaso a la historia del desarrollo de software,
para al final ver como el agilismo no es m´s que una respuesta l´gica a los
a o
problemas que la evoluci´n social y tecnol´gica han ido planteando.
o o
Ya desde el punto de partida es necesario hacer una reflexi´n. Al otear la
o
historia nos damos cuenta de que el origen del desarrollo de software est´ a a
unas pocas d´cadas de nosotros. Para llegar al momento en el que el primer
e
computador que almacenaba programas digitalmente corri´ exitosamente su
o
primer programa, s´lo tenemos que remontarnos al verano de 19481 . Esto nos
o
hace reflexionar sobre el hecho de que nos encontramos ante una disciplina
que es apenas una reci´n nacida frente a otras centenarias con una base de
e
conocimiento s´lida y estable. Por nuestra propia naturaleza nos oponemos
o
al cambio, pero debemos entender que casi no ha transcurrido tiempo como
para que exijamos estabilidad.
Siguiendo la ley de Moore2 , los componentes hardware acaban duplicando
su capacidad cada a˜o. Con lo que, en muy poco tiempo, aparecen m´qui-
n a
nas muy potentes capaces de procesar miles de millones de operaciones en
segundos. A la vez, los computadores van reduciendo su tama˜o considera-
n
blemente, se reducen los costes de producci´n del hardware y avanzan las
o
comunicaciones entre los sistemas. Todo esto tiene una consecuencia eviden-
te: los computadores ya no s´lo se encuentran en ´mbitos muy restringidos,
o a
como el militar o el cient´ıfico.
1
http://en.wikipedia.org/wiki/Tom Kilburn
2
http://en.wikipedia.org/wiki/Moore %27s Law
33

34. Cap´
ıtulo 1
Al extenderse el ´mbito de aplicaci´n del hardware (ordenadores perso-
a o
nales, juegos, relojes, ...), se ofrecen soluciones a sistemas cada vez m´s a
complejos y se plantean nuevas necesidades a una velocidad vertiginosa que
implican a los desarrolladores de Software. Sin informaci´n y conocimien-
o
to suficiente, unos pocos “aventureros” empiezan a desarrollar las primeras
aplicaciones que dan respuesta a las nuevas necesidades pero es un reto muy
complejo que no llega a ser resuelto con la inmediatez y la precisi´n necesa-
o
rias. Los proyectos no llegan a buen puerto, o lo hacen muy tarde.
En la d´cada de los cincuenta nos encontramos con otro hito impor-
e
tante. En el ´mbito militar, surge la necesidad de profesionalizar la gesti´n
a o
de proyectos para poder abordar el desarrollo de complejos sistemas que re-
quer´ coordinar el trabajo conjunto de equipos y disciplinas diferentes en la
ıan
construcci´n de sistemas unicos. Posteriormente, la industria del autom´vil
o ´ o
sigui´ estos pasos. Esta nueva disciplina se basa en la planificaci´n, ejecuci´n
o o o
y seguimiento a trav´s de procesos sistem´ticos y repetibles.
e a
Hasta este punto, hemos hablado s´lo de desarrollo de software y no de
o
ingenier´ de software, ya que es en 1968 cuando se acu˜a este t´rmino en
ıa n e
la NATO Software Engineering Conference3 .En esta conferencia tambi´n se e
acu˜a el t´rmino crisis del software para definir los problemas que estaban
n e
surgiendo en el desarrollo y que hemos comentado anteriormente.
Los esfuerzos realizados producen tres ´reas de conocimiento que se re-
a
velaron como estrat´gicas para hacer frente a la crisis del software4 :
e
Ingenier´ del software: este t´rmino fue acu˜ado para definir la ne-
ıa e n
cesidad de una disciplina cient´
ıfica que, como ocurre en otras ´reas,
a
permita aplicar un enfoque sistem´tico, disciplinado y cuantificable al
a
desarrollo, operaci´n y mantenimiento del software.
o
Gesti´n Predictiva de proyectos: es una disciplina formal de gesti´n,
o o
basada en la planificaci´n, ejecuci´n y seguimiento a trav´s de procesos
o o e
sistem´ticos y repetibles.
a
Producci´n basada en procesos: se crean modelos de procesos basa-
o
dos en el principio de Pareto5 , empleado con buenos resultados en
la producci´n industrial. Dicho principio nos indica que la calidad del
o
resultado depende b´sicamente de la calidad de los procesos.
a
En este punto, con el breve recorrido hecho, podemos sacar conclusiones
reveladoras que luego nos llevar´n a la mejor comprensi´n del agilismo. Por
a o
un lado, la gesti´n predictiva de proyectos establece como criterios de ´xito
o e
3
http://en.wikipedia.org/wiki/Software engineering
4
http://www.navegapolis.net/files/Flexibilidad con Scrum.pdf
5
http://es.wikipedia.org/wiki/Principio de Pareto
34

35. Cap´
ıtulo 1 1.1. Modelo en cascada
obtener el producto definido en el tiempo previsto y con el coste estimado.
Para ello, se asume que el proyecto se desarrolla en un entorno estable y
predecible. Por otro, se empiezan a emular modelos industriales e ingenieriles
que surgieron en otros ´mbitos y con otros desencadenantes.
a
Debemos tener en cuenta que, al principio, el tiempo de vida de un
producto acabado era muy largo; durante este tiempo, generaba beneficios
a las empresas, para las que era m´s rentable este producto que las posibles
a
novedades pero, a partir de los ochenta, esta situaci´n empieza a cambiar.
o
La vida de los productos es cada vez m´s corta y una vez en el mercado, son
a
novedad apenas unos meses, quedando fuera de ´l enseguida. Esto obliga a
e
cambiar la filosof´ de las empresas, que se deben adaptar a este cambio cons-
ıa
tante y basar su sistema de producci´n en la capacidad de ofrecer novedades
o
de forma permanente.
Lo cierto es que ni los productos de software se pueden definir por com-
pleto a priori, ni son totalmente predecibles, ni son inmutables. Adem´s, los
a
procesos aplicados a la producci´n industrial no tienen el mismo efecto que
o
en desarrollo de software, ya que en un caso se aplican sobre m´quinas y en
a
otro, sobre personas. Estas particularidades tan caracter´ısticas del software
no tuvieron cabida en la elaboraci´n del modelo m´s ampliamente segui-
o a
do hasta el momento: El modelo en cascada. En el siguiente punto de este
cap´ıtulo veremos una breve descripci´n de dicho modelo, para entender su
o
funcionamiento y poder concluir por qu´ en determinados entornos era pre-
e
ciso un cambio. Como ya comentaba al principio, el objetivo es ver que el
agilismo es la respuesta a una necesidad.
1.1. Modelo en cascada
Este es el m´s b´sico de todos los modelos6 y ha servido como bloque de
a a
construcci´n para los dem´s paradigmas de ciclo de vida. Est´ basado en el
o a a
ciclo convencional de una ingenier´ y su visi´n es muy simple: el desarrollo de
ıa o
software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene
un conjunto de metas bien definidas y las actividades dentro de cada una
contribuyen a la satisfacci´n de metas de esa fase o quiz´s a una subsecuencia
o a
de metas de la misma. El arquetipo del ciclo de vida abarca las siguientes
actividades:
Ingenier´ y An´lisis del Sistema: Debido a que el software es siempre
ıa a
parte de un sistema mayor, el trabajo comienza estableciendo los re-
quisitos de todos los elementos del sistema y luego asignando alg´n
u
subconjunto de estos requisitos al software.
6
Bennington[4], Pag. 26-30
35

36. 1.1. Modelo en cascada Cap´
ıtulo 1
An´lisis de los requisitos del software: el proceso de recopilaci´n de
a o
los requisitos se centra e intensifica especialmente en el software. El
ingeniero de software debe comprender el ´mbito de la informaci´n del
a o
software as´ como la funci´n, el rendimiento y las interfaces requeridas.
ı o
Dise˜o: el dise˜o del software se enfoca en cuatro atributos distintos
n n
del programa; la estructura de los datos, la arquitectura del software,
el detalle procedimental y la caracterizaci´n de la interfaz. El proceso
o
de dise˜o traduce los requisitos en una representaci´n del software con
n o
la calidad requerida antes de que comience la codificaci´n.o
Codificaci´n: el dise˜o debe traducirse en una forma legible para la
o n
maquina. Si el dise˜o se realiza de una manera detallada, la codificaci´n
n o
puede realizarse mec´nicamente.
a
Prueba: una vez que se ha generado el c´digo comienza la prueba del
o
programa. La prueba se centra en la l´gica interna del software y en
o
las funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.
Mantenimiento: el software sufrir´ cambios despu´s de que se entrega
a e
al cliente. Los cambios ocurrir´n debidos a que se haya encontrado
a
errores, a que el software deba adaptarse a cambios del entorno externo
(sistema operativo o dispositivos perif´ricos) o a que el cliente requiera
e
ampliaciones funcionales o del rendimiento.
En el modelo vemos una ventaja evidente y radica en su sencillez, ya que
sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Pero
el modelo se aplica en un contexto, as´ que debemos atender tambi´n a ´l y
ı e e
saber que:
Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo. Siempre hay iteraciones y se crean problemas en la aplicaci´n
o
del paradigma.
Normalmente, al principio, es dif´ para el cliente establecer todos los
ıcil
requisitos expl´
ıcitamente. El ciclo de vida cl´sico lo requiere y tiene
a
dificultades en acomodar posibles incertidumbres que pueden existir al
comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto no estar´ disponible una versi´n operativa del programa. Un
a o
error importante que no pueda ser detectado hasta que el programa
est´ funcionando, puede ser desastroso.
e
36

37. Cap´
ıtulo 1 1.2. Hablemos de cifras
1.2. Hablemos de cifras
Quiz´s nos encontremos en un buen punto para dejar de lado los datos
a
te´ricos y centrarnos en cifras reales que nos indiquen la magnitud del pro-
o
blema que pretendemos describir. Para ello nos basaremos en los estudios
realizados por un conjunto de profesionales de Massachussets que se uni´ eno
1985 bajo el nombre de Standish Group7 . El objetivo de estos profesionales era
obtener informaci´n de los proyectos fallidos en tecnolog´ de la informaci´n
o ıas o
(IT) y as´ poder encontrar y combatir las causas de los fracasos. El buen
ı
hacer de este grupo lo ha convertido en un referente, a nivel mundial, sobre
los factores que inciden en el ´xito o fracaso de los proyectos de IT. Factores
e
que se centran, fundamentalmente, en los proyectos de software y se aplican
tanto a los desarrollos como a la implementaci´n de paquetes (SAP, Oracle,
o
Microsoft, etc.)
A lo largo del tiempo, el Standish Group revel´ 50.000 proyectos fallidos
o
y en 1994 se obtuvieron los siguientes resultados:
Porcentaje de proyectos que son cancelados: 31 %
Porcentaje de proyectos problem´ticos: 53 %
a
Porcentaje de proyectos exitosos: 16 % (pero estos s´lo cumplieron, en
o
promedio, con el 61 % de la funcionalidad prometida)
Atendiendo a estos resultados poco esperanzadores, durante los ultimos
´
diez a˜os, la industria invirti´ varios miles de millones de d´lares en el desa-
n o o
rrollo y perfeccionamiento de metodolog´ y tecnolog´ (PMI, CMMI, ITIL,
ıas ıas
etc.). Sin embargo, en 2004 los resultados segu´ sin ser alentadores:
ıan
Porcentaje de proyectos exitosos: crece hasta el 29 %.
Porcentaje de proyectos fracasados: 71 %.
Seg´n el informe de Standish, las diez causas principales de los fracasos, por
u
orden de importancia, son:
Escasa participaci´n de los usuarios
o
Requerimientos y especificaciones incompletas
Cambios frecuentes en los requerimientos y especificaciones
Falta de soporte ejecutivo
Incompetencia tecnol´gica
o
7
http://www.standishgroup.com
37

38. 1.3. El manifiesto ´gil
a Cap´
ıtulo 1
Falta de recursos
Expectativas no realistas
Objetivos poco claros
Cronogramas irreales
Nuevas tecnolog´
ıas
Cabe destacar de estos resultados que siete de los factores nombrados, son
factores humanos. Las cifras evidencian la existencia de un problema, al que,
como veremos a continuaci´n, el agilismo intenta dar respuesta.
o
En el libro de Roberto Canales[13] existe m´s informaci´n sobre los m´to-
a o e
dos en cascada, las metodolog´ ´giles y la gesti´n de proyectos.
ıas a o
1.3. El manifiesto ´gil
a
Hasta ahora hemos visto que quiz´s para algunos proyectos se est´ rea-
a e
lizando un esfuerzo vano e incluso peligroso: intentar aplicar pr´cticas de
a
estimaci´n, planificaci´n e ingenier´ de requisitos. No es conveniente pensar
o o ıa
que estas pr´cticas son malas en s´ mismas o que los fracasos se deben a una
a ı
mala aplicaci´n de estas, sino que deber´
o ıamos recapacitar sobre si estamos
aplicando las pr´cticas adecuadas.
a
En 2001, 17 representantes de nuevas metodolog´ y cr´
ıas ıticos de los mo-
delos de mejora basados en procesos se reunieron, convocados por Kent Beck,
para discutir sobre el desarrollo de software. Fue un grito de ¡basta ya! a las
pr´cticas tradicionales. Estos profesionales, con una dilatada experiencia co-
a
mo aval, llevaban ya alrededor de una d´cada utilizando t´cnicas que les
e e
fueron posicionando como l´ ıderes de la industria del desarrollo software. Co-
noc´ perfectamente las desventajas del cl´sico modelo en cascada donde
ıan a
primero se analiza, luego se dise˜a, despu´s se implementa y, por ultimo (en
n e ´
algunos casos), se escriben algunos tests autom´ticos y se martiriza a un
a
grupo de personas para que ejecuten manualmente el software, una y otra
vez hasta la saciedad. El manifiesto ´gil8 se compone de cuatro principios.
a
Es peque˜o pero bien cargado de significado:
n
8
La traducci´n del
o manifiesto es de Agile Spain http://www.agile-
spain.com/manifiesto agil
38

39. Cap´
ıtulo 1 1.3. El manifiesto ´gil
a
' $
Estamos descubriendo mejores maneras de desarrollar software
tanto por nuestra propia experiencia como ayudando a terceros.
A trav´s de esta experiencia hemos aprendido a valorar:
e
Individuos e interacciones sobre procesos y herramien-
tas
Software que funciona sobre documentaci´n exhaustiva
o
Colaboraci´n con el cliente sobre negociaci´n de con-
o o
tratos
Responder ante el cambio sobre seguimiento de un
plan
Esto es, aunque los elementos a la derecha tienen valor, nosotros
valoramos por encima de ellos los que est´n a la izquierda.
a
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,
& %
Dave Thomas.
Tras este manifiesto se encuentran 12 principios de vital importancia para
entender su filosof´ 9 :
ıa
Nuestra m´xima prioridad es satisfacer al cliente a trav´s de entregas
a e
tempranas y continuas de software valioso.
Los requisitos cambiantes son bienvenidos, incluso en las etapas finales
del desarrollo. Los procesos ´giles aprovechan al cambio para ofrecer
a
una ventaja competitiva al cliente.
Entregamos software que funciona frecuentemente, entre un par de
semanas y un par de meses. De hecho es com´n entregar cada tres o
u
cuatro semanas.
Las personas del negocio y los desarrolladores deben trabajar juntos
diariamente a lo largo de todo el proyecto.
Construimos proyectos entorno a individuos motivados. D´ndoles el
a
lugar y el apoyo que necesitan y confiando en ellos para hacer el trabajo.
El m´todo m´s eficiente y efectivo de comunicar la informaci´n hacia
e a o
y entre un equipo de desarrollo es la conversaci´n cara a cara.
o
9
Traducci´n
o libre de los principios publicados en
http://www.agilemanifesto.org/principles.html
39

40. 1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico
e a Cap´
ıtulo 1
La principal medida de avance es el software que funciona.
Los procesos ´giles promueven el desarrollo sostenible. Los patroci-
a
nadores, desarrolladores y usuarios deben poder mantener un ritmo
constante.
La atenci´n continua a la excelencia t´cnica y el buen dise˜o mejora
o e n
la agilidad.
La simplicidad, es esencial.
Las mejores arquitecturas, requisitos y dise˜os emergen de la auto-
n
organizaci´n de los equipos.
o
A intervalos regulares, el equipo reflexiona sobre c´mo ser m´s eficaces,
o a
a continuaci´n mejoran y ajustan su comportamiento en consecuencia.
o
Este libro no pretende abarcar el vasto conjunto de t´cnicas y metodo-
e
log´ del agilismo pero, considerando la poca literatura en castellano que
ıas
existe actualmente sobre este tema, merece la pena publicar el manifiesto.
1.4. ¿En qu´ consiste el agilismo?: Un enfoque
e
pr´ctico
a
El agilismo es una respuesta a los fracasos y las frustraciones del modelo
en cascada. A d´ de hoy, las metodolog´ ´giles de desarrollo de software
ıa ıas a
est´n en boca de todos y adquieren cada vez m´s presencia en el mundo
a a
hispano, si bien llevan siendo usadas m´s de una d´cada en otros pa´
a e ıses. El
abanico de metodolog´ ´giles es amplio, existiendo m´todos para organizar
ıas a e
equipos y t´cnicas para escribir y mantener el software. Personalmente, me
e
inclino hacia la Programaci´n Extrema (eXtreme Programming, XP) como
o
forma de atacar la implementaci´n del producto y hacia Scrum como forma
o
de gestionar el proyecto, pero el estudio de ambas en su totalidad queda fuera
del alcance de este libro.
Por ilustrarlo a modo de alternativa al modelo en cascada: podemos ges-
tionar el proyecto con Scrum y codificar con t´cnicas de XP; concretamente
e
TDD10 y Programaci´n por Parejas11 , sin olvidar la propiedad colectiva del
o
c´digo y la Integraci´n Continua12 .
o o
10
Test Driven Development o Desarrollo Dirigido por Test
11
Pair Programming o Programaci´n por Parejas, es otra de las t´cnicas que com-
o e
ponen XP y que no vamos a estudiar en detalle en este libro. V´anse en la bibliograf´
e ıa
los textos relacionados con XP para mayor informaci´no
12
V´ase el ap´ndice sobre Integraci´n Continua al final del libro
e e o
40