Dise˜o Agil Con TDD n

8/14/2019 Diseo Agil Con TDD n

1/309

Diseno Agil con TDD

Carlos Ble Jurado y colaboradores.

Prologo de Jose Manuel Beas


2/309

Primera Edicion, Enero de 2010www.iExpertos.comEl libro se ha publicado bajo la Licencia Creative Commons

2


3/309

Indice general

I Base Teorica 31

1. El Agilismo 331.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . . 351.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . . . . . 371.3. El maniesto agil . . . . . . . . . . . . . . . . . . . . . . . 381.4. En que consiste el agilismo?: Un enfoque practico . . . . . 40

1.5. La situacion actual . . . . . . . . . . . . . . . . . . . . . . 441.6. Agil parece, platano es . . . . . . . . . . . . . . . . . . . . 461.7. Los roles dentro del equipo . . . . . . . . . . . . . . . . . . 471.8. Por que nos cuesta comenzar a ser agiles? . . . . . . . . . 49

2. Que es el Desarrollo Dirigido por Tests? (TDD) 532.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . . 56

2.1.1. Escribir la especicacion primero . . . . . . . . . . . 562.1.2. Implementar el codigo que hace funcionar el ejemplo 572.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . . 58

2.2. Consideraciones y recomendaciones . . . . . . . . . . . . . . 602.2.1. Ventajas del desarrollador experto frente al junior . . 602.2.2. TDD con una tecnologa desconocida . . . . . . . . 602.2.3. TDD en medio de un proyecto . . . . . . . . . . . . 61

3. Desarrollo Dirigido por Tests de Aceptaci on (ATDD) 633.1. Las historias de usuario . . . . . . . . . . . . . . . . . . . . 64

3.2. Que y no Como . . . . . . . . . . . . . . . . . . . . . . . . 683.3. Esta hecho o no? . . . . . . . . . . . . . . . . . . . . . . . 703.4. El contexto es esencial . . . . . . . . . . . . . . . . . . . . 71

3


4/309

INDICE GENERAL INDICE GENERAL

4. Tipos de test y su importancia 734.1. Terminologa en la comunidad TDD . . . . . . . . . . . . . 74

4.1.1. Tests de Aceptacion . . . . . . . . . . . . . . . . . . 754.1.2. Tests Funcionales . . . . . . . . . . . . . . . . . . . 764.1.3. Tests de Sistema . . . . . . . . . . . . . . . . . . . 764.1.4. Tests Unitarios . . . . . . . . . . . . . . . . . . . . 784.1.5. Tests de Integracion . . . . . . . . . . . . . . . . . . 80

5. Tests unitarios y frameworks xUnit 835.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . . . 84

6. Mocks y otros dobles de prueba 95

6.1. Cuando usar un objeto real, un stub o un mock . . . . . . . 976.2. La metafora Record/Replay . . . . . . . . . . . . . . . . . . 108

7. Dise no Orientado a Objetos 1117.1. Diseno Orientado a Objetos (OOD) . . . . . . . . . . . . . 1117.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . . 112

7.2.1. Single Responsibility Principle (SRP) . . . . . . . . . 1137.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . . 1137.2.3. Liskov Substitution Principle (LSP) . . . . . . . . . 1147.2.4. Interface Segregation Principle (ISP) . . . . . . . . . 1147.2.5. Dependency Inversion Principle (DIP) . . . . . . . . 115

7.3. Inversion del Control (IoC) . . . . . . . . . . . . . . . . . . 116

II Ejercicios Practicos 119

8. Inicio del proyecto - Test Unitarios 121

9. Continuacion del proyecto - Test Unitarios 157

10.Fin del proyecto - Test de Integraci on 23110.1. La frontera entre tests unitarios y tests de integraci on . . . . 23310.2. Diseno emergente con un ORM . . . . . . . . . . . . . . . . 243

10.2.1. Disenando relaciones entre modelos . . . . . . . . . 24610.3. La unicacion de las piezas del sistema . . . . . . . . . . . . 247

11.La soluci on en versi on Python 249

12.Antipatrones y Errores comunes 289

4


5/309


A. Integracion Continua (CI) 297A.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . 297A.2. Practicas de integracion continua . . . . . . . . . . . . . . . 299

A.2.1. Automatizar la construcci on . . . . . . . . . . . . . 299A.2.2. Los test forman parte de la construccion . . . . . . . 300A.2.3. Subir los cambios de manera frecuente . . . . . . . . 302A.2.4. Construir en una maquina de integraci on . . . . . . . 302A.2.5. Todo el mundo puede ver lo que esta pasando . . . . 303A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . . 304

A.3. IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . . 304A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

5


6/309


6


7/309

A la memoria de nuestro querido gatito Lito, que vivi o con total atenci on y

entrega cada instante de su vida

7


8/309

8


9/309

Prologo

Erase una vez que se era, un lejano pas donde vivan dos cerditos, Pabloy Adrian que, ademas, eran hermanos. Ambos eran los cerditos mas listosde la granja y, por eso, el gallo Ivan (el gerente de la misma) organizo unareunion en el establo, donde les encargo desarrollar un programa de ordenadorpara controlar el almacen de piensos. Les explico que quera saber en todomomento: cuantos sacos de grano haba y quien meta y sacaba sacos degrano del almacen. Para ello s olo tenan un mes pero les advirtio que, en

una semana, quera ya ver algo funcionando. Al nal de esa primera semana,eliminara a uno de los dos.

Adrian, que era el mas joven e impulsivo, inmediatamente se puso manosa la obra. No hay tiempo que perder!, deca. Y empezo rapidamente aescribir lneas y lneas de codigo. Algunas eran de un reciente programa quehaba ayudado a escribir para la guardera de la vaca Paca. Adrian pens o queno eran muy diferentes un almacen de grano y una guardera. En el primerose guardan sacos y en el segundo, pequenos animalitos. De acuerdo, tena

que retocar algunas cosillas para que aquello le sirviera pero bueno, esto delsoftware va de reutilizar lo que ya funciona, no?Pablo, sin embargo, antes de escribir una sola lnea de codigo comenzo acor-

dando con Ivan dos cosas: que era exactamente lo que podra ver dentro deuna semana y como sabra que, efectivamente, estaba terminada cada cosa.Ivan quera conocer, tan rapido como fuera posible, cuantos sacos de granohaba en cada parte del almacen porque sospechaba que, en algunas partes delmismo, se estaban acumulando sacos sin control y se estaban estropeando.

Como los sacos entraban y salan constantemente, no poda saber cuantoshaba y d onde estaban en cada instante, as que acordaron ir contabilizando-los por zonas y apuntando a que parte iba o de que parte vena, cada vezque entrara o saliera un saco. As, en poco tiempo podran tener una ideaclara del uso que se estaba dando a las distintas zonas del almacen.

9


10/309

Pr ologo

Mientras Adrian adelantaba a Pablo escribiendo muchas lneas de codigo,Pablo escriba primero las pruebas automatizadas. A Adrian eso le parecauna perdida de tiempo. S olo tenan una semana para convencer a Ivan!

Al nal de la primera semana, la demo de Adrian fue espectacular, tenaun control de usuarios muy completo, hizo la demostracion desde un movil yenseno, ademas, las posibilidades de un generador de informes muy potenteque haba desarrollado para otra granja anteriormente. Durante la demostra-cion hubo dos o tres problemillas y tuvo que arrancar de nuevo el programapero, salvo eso, todo fue genial. La demostracion de Pablo fue mucho masmodesta, pero cumplio con las expectativas de Ivan y el programa no fallo enningun momento. Claro, todo lo que enseno lo haba probado muchsimasveces antes gracias a que haba automatizado las pruebas. Pablo haca TDD,es decir, nunca escriba una lnea de c odigo sin antes tener una prueba que leindicara un error. Adrian no poda creer que Pablo hubiera gastado mas de lamitad de su tiempo en aquellas pruebas que no hacan mas que retrasarle ala hora de escribir las funcionalidades que haba pedido Ivan. El programa deAdrian tena muchos botones y muchsimas opciones, probablemente muchasmas de las que jamas seran necesarias para lo que haba pedido Ivan, perotena un aspecto muy profesional.

Ivan no supo que hacer. La propuesta de Pablo era muy robusta y haca

justo lo que haban acordado. La propuesta de Adrian tena cosillas que pulir,pero era muy prometedora. Haba hecho la demostraci on desde un movil!As que les propuso el siguiente trato: Os pagare un 50 % mas de lo queinicialmente habamos presupuestado, pero solo a aquel de los dos que mehaga el mejor proyecto. Al otro no le dare nada.. Era una oferta complicadaporque, por un lado, el que ganaba se llevaba mucho mas de lo previsto. Muytentador. Pero, por el otro lado, corran el riesgo de trabajar durante un mescompletamente gratis. Mmmmm.

Adrian, tan impulsivo y arrogante como siempre, no dudo ni un instante.Trato hecho!, dijo. Pablo explic o que aceptara s olo si Ivan se compro-meta a colaborar como lo haba hecho durante la primera semana. A Ivan leparecio razonable y les convoco a ambos para que le ensenaran el resultadonal en tres semanas.

Adrian se march o pitando y llamo a su primo Sixto, que saba muchoy le asegurara la victoria, aunque tuviera que darle parte de las ganancias.Ambos se pusieron rapidamente manos a la obra. Mientras Adrian arreglaba

los defectillos encontrados durante la demo, Sixto se encargo de disenar unaarquitectura que permitiera enviar mensajes desde el m ovil hasta un webser-vice que permita encolar cualquier operacion para ser procesada en paralelopor varios servidores y as garantizar que el sistema estara en disposicion dedar servicio 24 horas al da los 7 das de la semana.

10


11/309

Pr ologo

Mientras tanto, Pablo se reuni o con Ivan y Bernardo (el encargado delalmacen) para ver cuales deberan ser las siguientes funcionalidades a desarro-llar. Les pidio que le explicaran, para cada peticion, que benecio obtena lagranja con cada nueva funcionalidad. Y as, poco a poco, fueron elaborandouna lista de funcionalidades priorizadas y resumidas en una serie de tarjetas.A continuacion, Pablo fue, tarjeta a tarjeta, discutiendo con Ivan y Bernardocuanto tiempo podra tardar en terminarlas. De paso, aprovech o para anotaralgunos criterios que luego serviran para considerar que esa funcionalidadestara completamente terminada y eliminar alguna ambiguedad que fuerasurgiendo. Cuando Pablo penso que, por su experiencia, no podra hacer mastrabajo que el que ya haban discutido, dio por concluida la reunion y sedispuso a trabajar. Antes que nada, resolvi o un par de defectos que habansurgido durante la demostraci on y le pidio a Ivan que lo validara. A conti-nuacion, se marcho a casa a descansar. Al da siguiente, cogio la primera delas tarjetas y, como ya haba hecho durante la semana anterior, comenzo aautomatizar los criterios de aceptaci on acordados con Ivan y Bernardo. Y lue-go, fue escribiendo la parte del programa que haca que se cumplieran esoscriterios de aceptacion. Pablo le haba pedido ayuda a su amigo Hudson, uncoyote vegetariano que haba venido desde America a pasar el invierno. Hud-son no saba programar, pero era muy rapido haciendo cosas sencillas. Pablo

le encargo que comprobara constantemente los criterios de aceptacion queel haba automatizado. As, cada vez que Pablo haca alg un cambio en suprograma, avisaba a Hudson y este haca, una tras otra, todas las pruebas deaceptaci on que Pablo iba escribiendo. Y cada vez haba mas. Este Hudsonera realmente veloz e incansable!

A medida que iba pasando el tiempo, Adrian y Sixto tenan cada vezmas problemas. Terminaron culpando a todo el mundo. A Ivan, porque noles haba explicado detalles importantsimos para el exito del proyecto. A la

vaca Paca, porque haba incluido una serie de cambios en el programa de laguardera que haca que no pudieran reutilizar casi nada. A los inventores delos SMS y los webservices, porque no tenan ni idea de como funciona unagranja. Eran tantos los frentes que tenan abiertos que tuvieron que prescindirdel envo de SMS y buscaron un generador de paginas web que les permitieradibujar el ujo de navegacion en un graco y, a partir de ah, generar elesqueleto de la aplicacion. Eso seguro que les ahorrara mucho tiempo! Alpoco, Sixto, harto de ver que Adrian no valoraba sus aportaciones y que ya

no se iban a usar sus ideas para enviar y recibir los SMS, decidio que semarchaba, a un renunciando a su parte de los benecios. Total, el ya no creaque fueran a ser capaces de ganar la competicion.

Mientras tanto, Pablo le pidi o un par de veces a Ivan y a Bernardo que levalidaran si lo que llevaba hecho hasta aquel momento era de su agrado y les

11


12/309

Pr ologo

hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvio paracorregir algunos defectos y cambiar algunas prioridades. Ivan y Bernardoestaban francamente contentos con el trabajo de Pablo. Sin embargo, entreellos comentaron mas de una vez: Que estara haciendo Adrian? C omo lollevara?.

Cuando se acercaba la fecha nal para entregar el programa, Adrian sequedo sin dormir un par de noches para as poder entregar su programa.Pero eran tantos los defectos que haba ido acumulando que, cada vez quearreglaba una cosa, le fallaba otra. De hecho, cuando llego la hora de lademostracion, Adrian s olo pudo ensenar el programa instalado en su portatil(el unico sitio donde, a duras penas, funcionaba) y fue todo un desastre:mensajes de error por todos sitios, comportamientos inesperados... y lo peorde todo: el programa no haca lo que haban acordado con Ivan.

Pablo, sin embargo, no tuvo ningun problema en ensenar lo que llevabafuncionando desde haca mucho tiempo y que tantas veces haba probado. Porsi acaso, dos das antes de la entrega, Pablo haba dejado de introducir nuevascaractersticas al programa porque quera centrarse en dar un buen manual deusuario, que Ivan haba olvidado mencionar en las primeras reuniones porquedaba por sentado que se lo entregaran. Claro, Adrian no haba tenido tiempopara nada de eso.

Moraleja:Ademas de toda una serie de buenas practicas y un proceso de desarrollo

agil, Pablo hizo algo que Adrian despreci o: acordo con Ivan (el cliente) y conBernardo (el usuario) los criterios mediante los cuales se comprobara quecada una de las funcionalidades estara bien acabada. A eso que solemos lla-mar criterios de aceptaci on, Pablo le anadio la posibilidad de automatizarsu ejecucion e incorporarlos en un proceso de integracion continua (que eslo que representa su amigo Hudson en este cuento). De esta manera, Pablo

estaba siempre tranquilo de que no estaba estropeando nada viejo con cadanueva modicacion. Al evitar volver a trabajar sobre asuntos ya acabados,Pablo era mas eciente. En el corto plazo, las diferencias entre ambos en-foques no parecen signicativas, pero en el medio y largo plazo, es evidenteque escribir las pruebas antes de desarrollar la solucion es mucho mas ecazy eciente.

En este libro que ahora tienes entre tus manos, y despues de este inusualprologo, te invito a leer como Carlos explica bien clarito como guiar el desa-

rrollo de software mediante la tecnica de escribir antes las pruebas (masconocido como TDD).

12


13/309

Agradecimientos

Una vez o a un maestro zen decir que la gratitud que expresa una per-sona denota su estado momentaneo de bienestar consigo misma. Estoy muycontento de ver que este proyecto que se empezo hace casi ano y medio, haconcluido con un resultado tan graticante.

Tengo que agradecer cosas a miles de personas pero para no extendermedemasiado, lo hare hacia los que han tenido una relacion mas directa con ellibro.

En primer lugar tengo que agradecer a Dacil Casanova que haya sidola responsable de calidad numero uno en el proyecto. Sin ella este libro nose hubiera escrito de esta forma y en este momento. Quizas no se hubieseescrito nunca. No solo tengo que agradecer todo lo muchsimo que me aportaen lo personal sino que ademas me animo constantemente a no publicar ellibro hasta que estuviera hecho lo mejor posible. Ha revisado mi redaccioncorrigiendo mil faltas de ortografa y signos de puntuacion.

El toque de calidad que dan los demas coautores al libro, es tambien un

detallazo. Ademas de escribir texto han sido buenos revisores. Estoy profun-damente agradecido a Juan Gutierrez Plaza por haber escrito el captulo 11y por haber hecho correcciones desde la primera revision del libro hasta laultima. Ha sido un placer discutir juntos tantos detalles tecnicos. Gracias aFran Reyes Perdomo tenemos un gran apendice sobre Integraci on Contnuaque de no haber sido por el no estara en el libro, con lo importante que esesta practica. Mil gracias Fran. Gregorio Mena es el responsable de que elcaptulo 1 no sea un completo desastre. Ha sido para m el mas difcil deescribir de todo el libro y a ningun revisor le acababa de convencer. Gregorioha refactorizado medio captulo dandole un toque mucho mas serio. Esperoque sigamos trabajando juntos Gregorio :-) Para terminar con los coautoresquiero agradecer a Jose Manuel Beas que haya escrito el prologo del libro apesar de lo muy ocupado que esta liderando la comunidad agil espa nola y

13


14/309

Agradecimientos

haciendo de padre de familia. Un bonito detalle JM ;-DA continuacion quiero agradecer a la decena de personas que han ledo

las revisiones del libro previas a la publicacion y que han aportado correccio-nes, palabras de animo e incluso texto. Agradecimientos especiales a EstebanManchado Velazquez que tiene muchsimo que ver con la calidad de la redac-cion y que ha sido uno de los revisores mas constantes. Yeray Darias ademasde revisar, escribio el captulo que le ped sobre DDD, aunque nalmentequeda para un libro futuro. Mi buen amigo Eladio Lopez de Luis ha dejadoalgun comentario en cada revision que he ido enviando. Alberto RodrguezLozano ha sido una de las personas mas inuyentes en las correcciones delcaptulo 9, aportando comentarios tecnicos de calidad. No puedo olvidar alresto de revisores que han seguido el libro en distintas etapas aportandotambien comentarios muy brillantes: Nestor Bethencourt, Juan Jorge PerezLopez, Pablo Rodrguez Sanchez, Jose Ram on Daz, Jose M. Rodrguez dela Rosa, Vctor Roldan y Nestor Salceda. Tambien agradezco a todas laspersonas que han ledo alguna de estas revisiones previas y me han enviadoemails personales de agradecimiento.

Hadi Hariri me inuencio mucho para que partiese el libro en dos y dejasepara este, solo aquellos temas de relaci on directa con TDD.

Ahora, mas alla de los que han tenido relaci on directa con el libro, quiero

agradecer a Rodrigo Trujillo, ex director de la Ocina de Software Libre dela Universidad de La Laguna (ULL), que me diera la oportunidad de dirigirun proyecto y carta blanca para aplicar TDD desde el primer da, porquedurante el ano que trabaje ah aprend toneladas de cosas. Rodrigo es una delas personas que mas se mueve en la ULL; no deja de intentar abrir puertasa los estudiantes que estan terminado ni de preocuparse por la calidad de suuniversidad.

Gracias tambien a Jose Lus Roda, Pedro Gonzalez Yanes y Jesus Alberto

Gonzalez por abrirme las puertas de la facultad de informatica y tambien porpermitirme que impartiese mi primer curso completo de TDD. De la facultadtengo tambien que agradecer a Marcos Colebrook que me diese el empujonque necesitaba para terminar la carrera, que la tena casi abandonada. SinMarcos y Goyo, el cambio de plan hubiera hecho que abandonase la idea determinar la carrera.

A Esteban Abeledo y al resto del Colegio de Informaticos de Canarias lesagradezco mucho hayan homologado nuestros cursos de TDD.

Los alumnos de mis cursos de TDD tienen mucho que ver con el resultadonal del libro ya que he volcado en el muchas de sus dudas y comentariostpicos. Gracias a los dos grupos que he tenido en Tenerife y al de Sevilla,todos en 2009. Mencion especial a las personas que ayudaron a que saliesenadelante: Alvaro Lobato y los ya citados Gregorio, Pedro y Roda.

14


15/309

Agradecimientos

Gracias a todos los que estan promoviendo XP en Espana. A saber: Al-fredo Casado, Xavier Gost, Leo Antol, Agustn Yague, Eric Mignot, JorgeJimemez, Ivan Parraga, Jorge Uriarte, Jes us Perez, David Esmerodes, LuismiCavalle, David Calavera, Ricardo Roldan y tantos otros profesionales de lacomunida Agile Spain, entre los cuales estan los coautores y revisores de estelibro. Y tambien a los que estan promoviendo XP en Latinoamerica: FabianFigueredo, Carlos Peix, Angel Lopez, Carlos Lone y tantos otros. Y al pibeque vos viste nos rrre-ayudo a traer el Agile Open a Espana, Xavier Quesada;-)

Alfredo Casado ademas ha escrito la sinopsis del libro.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 tambien a los que me han queridotapar, porque de todos he aprendido cosas. Ha sido tremendamente enrique-cedor cambiar de empresa y de proyectos. Thank you all guys at Buy4Nowin Dublin during my year over there in 2007. Tambien he aprendido muchode todos aquellos desarrolladores con los que he trabajado en proyectos opensource, en mi tiempo libre.

A quienes han conado en m para impartir cursos de materias diversas,porque han sido claves para que desarrolle mi capacidad docente; Agustn

Benito, Academia ESETEC, Armando Fumero, Innova7 y Rodrigo Trujillo.Agradecimientos tambien a Pedro Gracia Fajardo, una de las mentes

mas brillantes que he conocido. Un visionario. Pedro fue quien me hablo porprimera vez de XP en 2004. En aquel entonces nos creamos que eramos agilesaunque en realidad lo estabamos haciendo fatal. La experiencia sirvio paraque yo continuase investigando sobre el tema.

Gracias a la comunidad TDD internacional que se presenta en un grupode discusion de Yahoo. Aunque ellos no leeran estas lneas por ser en espanol,

quiero dejar claro que sin su ayuda no hubiese sabido resolver tantos proble-mas tecnicos. Gracias a Kent Beck y Lasse Koskela por sus libros, que hansido para m fuente de inspiracion.

Aprovecho para felicitar a Roberto Canales por su libro, InformaticaProfesional[13]. Es una pena que me haya puesto a leerlo cuando ya tenaescrito este libro, a pocos das de terminar el proyecto. Si lo hubiese ledo enoctubre, cuando Leo me lo regalo, me hubiese ahorrado bastantes parrafosde la parte te orica. Es un pedazo de libro que recomiendo a todo el mundo.

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 agiles en nuestro pas. Angel ademas meregala 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/309

Agradecimientos

no sera posible. A Dacil de nuevo por todo lo muchsimo que me aportadiariamente. A mis padres por traerme al mundo y ensenarme tantas cosas.A mis hermanas por querer tanto a su hermano mayor. A mis primos. Ami ta Tina por acogerme en su casa durante mis a nos de universidad ydarme la oportunidad de estudiar una carrera, ya que mis padres no podancostearmelo. Ella me ayuda siempre que lo necesito. A mis abuelos por estarsiempre ah, como mis segundos padres.

16


17/309

Autores del libro

Carlos Ble Jurado Nac en Cordoba en 1981, hijo de cordobesespero cuando tena 4 a nos emigramos a Lanza-rote y, salvo algunos anos intercalados en losque viv en Cordoba, la mayor parte de mi vidala he pasado en Canarias. Primero en Lanzarotey despues en Tenerife.Mi primer apellido signica trigo en frances. Lotrajo un frances al pueblo cordobes de La Vic-toria en tiempos de Carlos III.Cuando tena 6 a nos mi padre trajo a casa un8086 y aquello me fascin o tanto que supe queme quera dedicar a trabajar con ordenadoresdesde entonces. He tenido tambien Amiga 500,Amiga 1200, y luego unos cuantos PC, desde elAMD K6 hasta el Intel Core Duo de hoy.

Soy ingeniero tecnico en informatica de sistemas. Para m el ttulo noes ninguna garanta de profesionalidad, mas bien hago un balance negativode mi paso por la Universidad, pero quera ponerlo aqu para que los quepadecen de titulitis vean que el que escribe es titulado.

La primera vez que gane dinero con un desarrollo de software fue en2001. Poco despues de que instalase Debian GNU/Linux en mi PC. En 2003

entre de lleno en el mercado laboral. Al principio trabaje administrando sis-temas ademas de programar.

En 2005 se me ocurrio la genial idea de montar una empresa de desarrollode software a medida con mis colegas. Sin tener suciente experiencia comodesarrollador y ninguna experiencia como empresario ni comercial, fue toda

17


18/309


19/309

Autores del libro

Jose Manuel Beas En 2008 decidi o aprovechar sus circunstanciaspersonales para tomarse un respiro, mirar atr as,a los lados y, sobre todo, hacia adelante. Y as,aprovech o ese tiempo para mejorar su forma-cion en temas como Scrum asistiendo al cur-so de Angel Medinilla. Pero tambien quiso po-ner su peque no granito de arena en el desarro-llo y la difusion de Concordion, una herramien-ta de c odigo abierto para realizar pruebas deaceptaci on, y rellenar su caja de herramientascon cosas como Groovy y Grails. Pero sobre to-do vio que mereca la pena poner parte de suenerga en revitalizar una vieja iniciativa llama-da Agile Spain y buscar a todos aquellos que, co-mo el, estuvieran buscando maneras mejores dehacer software. Y vaya que si los encontr o. Ac-tualmente es el Presidente de la asociaci on Agi-le Spain, que representa a la comunidad agilistaen Espa na y organizadora de los Agile OpenSpain y las Conferencias Agile Spain. Tambienparticipa en la elaboraci on de los podcasts dePodgramando.es, una iniciativa de agilismo.espowered by iExpertos.com. Puedes localizar-lo facilmente a traves del portal agilismo.es, enla lista de correo de Agile Spain o en su blogpersonal http://jmbeas.iexpertos.com .

19


20/309

Autores del libro

Juan GutierrezPlaza

Escribir, he escrito poco, pero aprender,muchsimo. He intentado hacer algo con sen-tido con mi oxidado Python en el captulo 11aunque m as que escribir, ha sido discutir y re-discutir con Carlos sobre cual era la mejor formade hacer esto y aquello (siempre ha ganado el).Tambien he sacado del ba ul de los recuerdos miLaTeX y he revisado mucho. Cuando no estoydiscutiendo con la gente de Agile Spain, trabajocomo Agile Coach en F-Secure donde intentoayudar a equipos de Finlandia, Malasia, Rusiay Francia en su transici on a las metodologasagiles (tanto en gestion como en pr acticas desoftware entre las que se incluye, por supues-to, TDD). Pero como he llegado hasta aqu?Mi devocion los ordenadores me llevo a estu-diar la carrera de ingeniera en inform atica enla UPM de Madrid. Trabaje en Espa na por untiempo antes de decidir mudarme a Finlandiaen el 2004 para trabajar en Nokia. En las lar-

gas y oscuras tardes del invierno Finlandesestudie un master en industrial managementantes de cambiar a F-Secure. Cuando el tiempolo permite, escribo en http://agilizar.es

Fran Reyes Perdo-mo

Soy un apasionado desarrollador de software in-teresado en practicas agiles. Llevo cerca de4 anos trabajando para la rgida Administra-cion publica con un fantastico equipo. Conoc aCarlos Ble en un provechoso curso de TDD queimpartio para un grupo de companeros. Entrecervezas (una fase importante para asimilar loaprendido), compartimos ideas y experienciasdel mundo del software, y me habl o ademasdel proyecto en el que se encontraba embar-cado, en el cual me brindo la oportunidad departicipar con un peque no apendice sobre inte-graci on continua. Una pr actica, que intentamos,forme parte del da a da en nuestros proyectos.http://es.linkedin.com/in/franreyesperdomo

20


21/309

Autores del libro

Gregorio Mena Mi corta vida profesional ha sido su-ciente para dar sentido a la frase de Ho-racio Ning un hombre ha llegado a laexcelencia en arte o profesion alguna,sin haber pasado por el lento y dolorosoproceso de estudio y preparaci on. Aun-que en mi caso el camino no es doloro-so, sino apasionante. Siguiendo esta -losofa, intento formarme y fomentar laformaci on, por lo que he organizado uncurso de TDD impartido con gran acier-to por Carlos Ble y voy a participar enfuturas ediciones. Trabajo desde iExper-tos para que entre todos hagamos posi-ble el primer curso de Scrum en Cana-rias, pues tambien colaboro con la plata-forma ScrumManager. Ha sido esta for-ma de ver nuestra profesion la que mellevo a colaborar con Carlos en este li-bro. Pensaba aportar algo, pero lo cier-to es que lo que haya podido aportar notiene comparacion con lo que he tenidola suerte de recibir. Por ello debo dara Carlos las gracias por ofrecerme estaoportunidad y por el esfuerzo que ha he-cho para que este libro sea una realidadpara todos los que vemos en la formacioncontinua el camino al exito.Habitualmente escribo enhttp://eclijava.blogspot.com .

21


22/309

Autores del libro

22


23/309

Convenciones y Estructura

Este libro contiene numerosos bloques de codigo fuente en varios len-guajes de programacion. Para hacerlos mas legibles se incluyen dentro derectangulos que los separan del resto del texto. Cuando se citan elementosde dichos bloques o sentencias del lenguaje, se usaeste tipo de letra .

A lo largo del texto aparecen referencias a sitios web en el pie de pagina.Todas ellas aparecen recopiladas en la pagina web del libro.

Las referencias bibliogracas tienen un formato como este:[3]. Las ultimas

paginas del libro contienen la bibliografa detallada correspondiente a todasestas referencias.Otros libros de divulgacion repiten determinadas ideas a lo largo de varios

captulos con el n de reforzar los conceptos. En la era de la infoxicacion3

tal repeticion sobra. He intentado minimizar las repeticiones de conceptospara que el libro se pueda revisar rapidamente, por lo que es recomendableuna segunda lectura del mismo para quienes desean profundizar en la materia.Sera como ver una pelcula dos veces: en el segundo pase uno aprecia muchos

detalles que en el primero no vio y su impresion sobre el contenido puedevariar. En realidad, es que soy tan mal escritor que, si no lee el libro dosveces no lo va a entender. Hagase a la idea de que tiene 600 paginas en lugarde 300.

Sobre los paquetes de codigo fuente que acompanan a este libro (listopara 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 carpetade cheros.

3 http://es.wiktionary.org/wiki/infoxicaci%C3 %B3n

23


24/309

Convenciones y Estructura

24


25/309

La Libertad del Conocimiento

El conocimiento ha sido transmitido de individuo a individuo desde elcomienzo mismo de la vida en el planeta. Gracias a la libre circulacion delconocimiento hemos llegado a donde estamos hoy, no solo en lo referente alavance cientco y tecnol ogico, sino en todos los campos del saber.

Afortunadamente, el conocimiento no es propiedad de nadie sino quees como la energa; simplemente uye, se transforma y nos transforma. Dehecho no pertenece a las personas, no tiene dueno, es de todos los seres.

Observando a los animales podemos ver como los padres ensenan a su prolelas tecnicas que necesitaran para desenvolverse en la vida.

El conocimiento contenido en este libro no pertenece al autor. No perte-nece a nadie en concreto. La intencion es hacerlo llegar a toda persona quedesee aprovecharlo.

En Internet existe mucha documentaci on sobre la libertad del conocimien-to, empezando por la entrada de la Wikipedia 4 . Este argumento es uno de los

principales pilares del software libre5

, al que tanto tengo que agradecer. Lasprincipales herramientas que utilizaremos en este libro estan basadas en soft-ware libre: frameworks xUnit, sistemas de control de versiones y frameworkspara desarrollo de software. Personalmente me he convertido en usuario dela tecnologa Microsoft .Net gracias al framework Mono6 , desarrollado porNovell con licencia libre. De no haber sido por Mono probablemente no hu-biera conocido C#.

El libro ha sido maquetado usando LATEX, concretamente con teTex y Mik-

TeX(software libre) y ha requerido de multitud de paquetes libres desarro-4 http://es.wikipedia.org/wiki/Conocimiento libre5 http://es.wikipedia.org/wiki/C odigo libre6 http://www.mono-project.com

25


26/309

La Libertad del Conocimiento

llados por la comunidad. Para la edicion del texto se ha usado Texmaker,Dokuwiki, Vim y Emacs. El versionado de los cheros de texto se ha llevadoa cabo con Subversion. Los diagramas de clases los ha generado SharpDe-velop, con el cual tambien he editado codigo. Estoy muy agradecido a todoslos que han escrito todas estas piezas. En la web del libro se encuentra elesqueleto con el que se ha maquetado para que, quien quiera, lo use para suspropias publicaciones.

Pese a mi simpata por el software de fuente abierta, este libro va mas alla dela dicotoma software libre/software propietario y se centra en tecnicas apli-cables a cualquier lenguaje de programacion en cualquier entorno. Uno de lospeores enemigos del software libre es el fanatismo radical de algunos de susevangelizadores, que raya en la mala educacion y empana el buen hacer delos verdaderos profesionales. Es mi deseo aclarar que mi posicion personal noes ni a favor ni en contra del software propietario, simplemente me mantengoal margen de esa contienda.

26


27/309

La Web del Libro

Los enlaces a sitios web de Internet permanecen menos tiempo activosen la red que en las paginas de un libro impreso; la lista de referencias semantendra actualizada en un sitio web dedicado al libro:

http://www.dirigidoportests.com

Si el lector desea participar informando de enlaces rotos, podra hacerlo diri-giendose a la web del libro o bien mediante correo electronico al autor:

carlos[Arroba]iExpertos[Punto]com

El codigo fuente que acompana al libro se podra descargar en la mismaweb.

Si bien es cierto que escribir el libro ha sido un placer, tambien es ciertoque ha sido duro en ocasiones. Ha supuesto casi ano y medio de trabajoy, dado que el libro es gratis y ni siquiera su venta en formato papel setraducira en algo de benecio, en la web es posible hacer donaciones. Si ellibro le gusta y le ayuda, le invito a que haga una donacion para que en elfuturo puedan haber mas libros libres como este.

27


28/309

La Web del Libro

28


29/309

Cual es el Objetivo del Libro?

El objetivo fundamental del libro es traer a nuestro idioma, el espanol,conocimiento tecnico que lleva anos circulando por pases de habla inglesa.No cabe duda de que los que inventaron la computacion y el software nossiguen llevando ventaja en cuanto a conocimiento se reere. En mi opinion,es una cuestion cultural en su mayor parte pero, sea como fuere, no pode-mos perder la oportunidad de subirnos al carro de las nuevas tecnicas dedesarrollo y difundir el conocimiento proporcionado por nuestros companeros

angloparlantes. S olo as competiremos en igualdad de condiciones, porque ada de hoy cada vez mas clientes apuestan por el outsourcing. Conocimientoes poder.

A da de hoy, por suerte o por desgracia, no nos queda mas remedioque dominar el ingles, al menos el ingles tecnico escrito, y es convenienteleer mucho en ese idioma. Se aprende muchsimo porque no solo lo usanlos nativos de habla inglesa sino que se ha convertido en el idioma universalen cuanto a tecnologa. Sin embargo, reconozco que yo mismo hace unos

anos era muy reacio a leer textos en ingles. He tenido que hacer un granesfuerzo y leer mucho con el diccionario en la mano hasta llegar al puntoen que no me cuesta trabajo leer en ingles (ademas de vivir una temporadafuera de Espana). Conozco a pocos companeros que hagan este esfuerzo. Escomprensible y normal que la mayora se limite a leer lo que esta documentadoen espanol. Al n y al cabo es de los idiomas mas hablados del planeta. Poreso concluyo que hay que traer la informacion a nuestro idioma para llegara mas gente, aunque el buen profesional debera tener presente las multiplesventajas que le aportara el dominio del ingles escrito. Cuando no dominamosel ingles nos perdemos muchos matices que son signicativos7 .

Apenas hay libros sobre agilismo en espanol. Los unicos libros novedososque 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/309

Cu al es el objetivo del libro?

tratan sobre tecnologas muy especcas que hoy valen y ma nana quizas no.Esta muy bien que haya libros sobre Java, sobre .Net o sobre Ruby, pero notenemos que limitarnos a ello. El unico libro sobre agilismo que hay a da dehoy es el de Scrum, de Juan Palacio[15]. Por otro lado, Angel Medinilla hatraducido el libro de Henrik Kniberg[8],Scrum y XP desde las Trincheras yLeo Antol ha traducido The Scrum Primer . Estos regalos son de agradecer.

Ahora que existen editoriales en la red tales como Lulu.com, ya no hayexcusa para no publicar contenidos tecnicos. Personalmente me daba reparoafrontar este proyecto sin saber si alguna editorial querra publicarlo peroya no es necesario que las editoriales consideren el producto comercialmentevalido para lanzarlo a todos los publicos. Otro objetivo del libro es animar alos muchos talentos hispanoparlantes que gustan de compartir con los demas,a que nos deleiten con su conocimiento y sus dotes docentes. Quien se animacon un libro sobre Programacion Extrema?.

No me cabe duda de que las ideas planteadas en este libro pueden re-sultarles controvertidas y desaantes a algunas personas. El lector no tienepor que coincidir conmigo en todo lo que se expone; tan solo le invito a queexplore con una mente abierta las tecnicas aqu recogidas, que las ponga enpractica y despues decida si le resultan o no valiosas.

30


31/309

Parte I

Base Te orica

31


32/309


33/309

Captulo 1El Agilismo

Para denir que es el agilismo, probablemente basten un par de lneas. Yaveremos mas adelante, en este mismo captulo, que el concepto es realmentesimple y queda plasmado en cuatro postulados muy sencillos. Pero creo quellegar a comprenderlo requiere un poco mas de esfuerzo y, seguramente, lamejor manera sea haciendo un repaso a la historia del desarrollo de software,para al nal ver como el agilismo no es mas que una respuesta logica a losproblemas que la evolucion social y tecnologica han ido planteando.

Ya desde el punto de partida es necesario hacer una reexion. Al otear lahistoria nos damos cuenta de que el origen del desarrollo de software esta aunas pocas decadas de nosotros. Para llegar al momento en el que el primercomputador que almacenaba programas digitalmente corrio exitosamente suprimer programa, solo tenemos que remontarnos al verano de 19481 . Esto noshace reexionar sobre el hecho de que nos encontramos ante una disciplinaque es apenas una recien nacida frente a otras centenarias con una base deconocimiento solida y estable. Por nuestra propia naturaleza nos oponemosal cambio, pero debemos entender que casi no ha transcurrido tiempo comopara que exijamos estabilidad.

Siguiendo la ley de Moore2 , los componentes hardware acaban duplicandosu capacidad cada a no. Con lo que, en muy poco tiempo, aparecen maqui-nas muy potentes capaces de procesar miles de millones de operaciones ensegundos. A la vez, los computadores van reduciendo su tamano considera-blemente, se reducen los costes de produccion del hardware y avanzan lascomunicaciones entre los sistemas. Todo esto tiene una consecuencia eviden-te: los computadores ya no solo se encuentran en ambitos muy restringidos,como el militar o el cientco.

1 http://en.wikipedia.org/wiki/Tom Kilburn2 http://en.wikipedia.org/wiki/Moore %27s Law

33


34/309

Captulo 1

Al extenderse el ambito de aplicacion del hardware (ordenadores perso-nales, juegos, relojes, ...), se ofrecen soluciones a sistemas cada vez mascomplejos y se plantean nuevas necesidades a una velocidad vertiginosa queimplican a los desarrolladores de Software. Sin informacion y conocimien-to suciente, unos pocos aventureros empiezan a desarrollar las primerasaplicaciones que dan respuesta a las nuevas necesidades pero es un reto muycomplejo que no llega a ser resuelto con la inmediatez y la precision necesa-rias. Los proyectos no llegan a buen puerto, o lo hacen muy tarde.

En la decada de los cincuenta nos encontramos con otro hito impor-tante. En el ambito militar, surge la necesidad de profesionalizar la gesti onde proyectos para poder abordar el desarrollo de complejos sistemas que re-queran coordinar el trabajo conjunto de equipos y disciplinas diferentes en laconstruccion de sistemas unicos. Posteriormente, la industria del automovilsiguio estos pasos. Esta nueva disciplina se basa en la planicacion, ejecuciony seguimiento a traves de procesos sistematicos y repetibles.

Hasta este punto, hemos hablado s olo de desarrollo de software y no deingeniera de software, ya que es en 1968 cuando se acuna este termino enla NATO Software Engineering Conference3 .En esta conferencia tambien seacuna el termino crisis del software para denir los problemas que estabansurgiendo en el desarrollo y que hemos comentado anteriormente.

Los esfuerzos realizados producen tres areas de conocimiento que se re-velaron como estrategicas para hacer frente a la crisis del software4 :

Ingeniera del software: este termino fue acu nado para denir la ne-cesidad de una disciplina cientca que, como ocurre en otras areas,permita aplicar un enfoque sistematico, disciplinado y cuanticable aldesarrollo, operacion y mantenimiento del software.

Gestion Predictiva de proyectos: es una disciplina formal de gestion,basada en la planicacion, ejecucion y seguimiento a traves de procesossistematicos y repetibles.

Producci on basada en procesos: se crean modelos de procesos basa-dos en el principio de Pareto5 , empleado con buenos resultados enla produccion industrial. Dicho principio nos indica que la calidad delresultado depende basicamente de la calidad de los procesos.

En este punto, con el breve recorrido hecho, podemos sacar conclusionesreveladoras que luego nos llevaran a la mejor comprension del agilismo. Porun lado, la gestion predictiva de proyectos establece como criterios de exito

3 http://en.wikipedia.org/wiki/Software engineering4 http://www.navegapolis.net/les/Flexibilidad con Scrum.pdf 5 http://es.wikipedia.org/wiki/Principio de Pareto

34


35/309

Captulo 1 1.1. Modelo en cascada

obtener el producto denido en el tiempo previsto y con el coste estimado.Para ello, se asume que el proyecto se desarrolla en un entorno estable ypredecible. Por otro, se empiezan a emular modelos industriales e ingenierilesque surgieron en otros ambitos y con otros desencadenantes.

Debemos tener en cuenta que, al principio, el tiempo de vida de unproducto acabado era muy largo; durante este tiempo, generaba beneciosa las empresas, para las que era mas rentable este producto que las posiblesnovedades pero, a partir de los ochenta, esta situaci on empieza a cambiar.La vida de los productos es cada vez mas corta y una vez en el mercado, sonnovedad apenas unos meses, quedando fuera de el enseguida. Esto obliga acambiar la losofa de las empresas, que se deben adaptar a este cambio cons-tante y basar su sistema de producci on en la capacidad de ofrecer novedadesde forma permanente.

Lo cierto es que ni los productos de software se pueden denir por com-pleto a priori, ni son totalmente predecibles, ni son inmutables. Ademas, losprocesos aplicados a la produccion industrial no tienen el mismo efecto queen desarrollo de software, ya que en un caso se aplican sobre maquinas y enotro, sobre personas. Estas particularidades tan caractersticas del softwareno tuvieron cabida en la elaboracion del modelo mas ampliamente segui-do hasta el momento: El modelo en cascada. En el siguiente punto de este

captulo veremos una breve descripcion de dicho modelo, para entender sufuncionamiento y poder concluir por que en determinados entornos era pre-ciso un cambio. Como ya comentaba al principio, el objetivo es ver que elagilismo es la respuesta a una necesidad.

1.1. Modelo en cascada

Este es el mas basico de todos los modelos6 y ha servido como bloque deconstruccion para los demas paradigmas de ciclo de vida. Esta basado en elciclo convencional de una ingeniera y su vision es muy simple: el desarrollo desoftware se debe realizar siguiendo una secuencia de fases. Cada etapa tieneun conjunto de metas bien denidas y las actividades dentro de cada unacontribuyen a la satisfaccion de metas de esa fase o quizas a una subsecuenciade metas de la misma. El arquetipo del ciclo de vida abarca las siguientesactividades:

Ingeniera y Analisis del Sistema: Debido a que el software es siempreparte de un sistema mayor, el trabajo comienza estableciendo los re-quisitos de todos los elementos del sistema y luego asignando algunsubconjunto de estos requisitos al software.

6 Bennington[4], Pag. 26-30

35


36/309

1.1. Modelo en cascada Captulo 1

Analisis de los requisitos del software: el proceso de recopilacion delos requisitos se centra e intensica especialmente en el software. Elingeniero de software debe comprender el ambito de la informacion delsoftware as como la funcion, el rendimiento y las interfaces requeridas.

Diseno: el diseno del software se enfoca en cuatro atributos distintosdel programa; la estructura de los datos, la arquitectura del software,el detalle procedimental y la caracterizacion de la interfaz. El procesode diseno traduce los requisitos en una representacion del software conla calidad requerida antes de que comience la codicacion.

Codicacion: el diseno debe traducirse en una forma legible para lamaquina. Si el diseno se realiza de una manera detallada, la codicacionpuede realizarse mecanicamente.

Prueba: una vez que se ha generado el codigo comienza la prueba delprograma. La prueba se centra en la logica interna del software y enlas funciones externas, realizando pruebas que aseguren que la entradadenida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrira cambios despues de que se entrega

al cliente. Los cambios ocurriran debidos a que se haya encontradoerrores, a que el software deba adaptarse a cambios del entorno externo(sistema operativo o dispositivos perifericos) o a que el cliente requieraampliaciones funcionales o del rendimiento.

En el modelo vemos una ventaja evidente y radica en su sencillez, ya quesigue los pasos intuitivos necesarios a la hora de desarrollar el software. Peroel modelo se aplica en un contexto, as que debemos atender tambien a el ysaber que:

Los proyectos reales raramente siguen el ujo secuencial que propone elmodelo. Siempre hay iteraciones y se crean problemas en la aplicaciondel paradigma.

Normalmente, al principio, es difcil para el cliente establecer todos losrequisitos explcitamente. El ciclo de vida clasico lo requiere y tienedicultades en acomodar posibles incertidumbres que pueden existir alcomienzo de muchos productos.

El cliente debe tener paciencia. Hasta llegar a las etapas nales delproyecto no estara disponible una versi on operativa del programa. Unerror importante que no pueda ser detectado hasta que el programaeste funcionando, puede ser desastroso.

36


37/309

Captulo 1 1.2. Hablemos de cifras

1.2. Hablemos de cifras

Quizas nos encontremos en un buen punto para dejar de lado los datosteoricos y centrarnos en cifras reales que nos indiquen la magnitud del pro-blema que pretendemos describir. Para ello nos basaremos en los estudiosrealizados por un conjunto de profesionales de Massachussets que se unio en1985 bajo el nombre de Standish Group7 . El objetivo de estos profesionales eraobtener informacion de los proyectos fallidos en tecnologas de la informacion(IT) y as poder encontrar y combatir las causas de los fracasos. El buenhacer de este grupo lo ha convertido en un referente, a nivel mundial, sobrelos factores que inciden en el exito o fracaso de los proyectos de IT. Factoresque se centran, fundamentalmente, en los proyectos de software y se aplican

tanto a los desarrollos como a la implementacion de paquetes (SAP, Oracle,Microsoft, etc.)

A lo largo del tiempo, el Standish Group revelo 50.000 proyectos fallidosy en 1994 se obtuvieron los siguientes resultados:

Porcentaje de proyectos que son cancelados: 31 %

Porcentaje de proyectos problematicos: 53 %

Porcentaje de proyectos exitosos: 16 % (pero estos solo cumplieron, enpromedio, con el 61 % de la funcionalidad prometida)

Atendiendo a estos resultados poco esperanzadores, durante los ultimosdiez anos, la industria invirtio varios miles de millones de dolares en el desa-rrollo y perfeccionamiento de metodologas y tecnologas (PMI, CMMI, ITIL,etc.). Sin embargo, en 2004 los resultados seguan sin ser alentadores:

Porcentaje de proyectos exitosos: crece hasta el 29 %.

Porcentaje de proyectos fracasados: 71 %.

Segun el informe de Standish, las diez causas principales de los fracasos, pororden de importancia, son:

Escasa participacion de los usuarios

Requerimientos y especicaciones incompletas

Cambios frecuentes en los requerimientos y especicacionesFalta de soporte ejecutivo

Incompetencia tecnol ogica7 http://www.standishgroup.com

37


38/309

1.3. El maniesto agil Captulo 1

Falta de recursos

Expectativas no realistas

Objetivos poco clarosCronogramas irreales

Nuevas tecnologas

Cabe destacar de estos resultados que siete de los factores nombrados, sonfactores humanos. Las cifras evidencian la existencia de un problema, al que,como veremos a continuacion, el agilismo intenta dar respuesta.

En el libro de Roberto Canales[13] existe mas informacion sobre los meto-dos en cascada, las metodologas agiles y la gesti on de proyectos.

1.3. El maniesto agil

Hasta ahora hemos visto que quizas para algunos proyectos se este rea-lizando un esfuerzo vano e incluso peligroso: intentar aplicar practicas deestimacion, planicacion e ingeniera de requisitos. No es conveniente pensar

que estas practicas son malas en s mismas o que los fracasos se deben a unamala aplicacion de estas, sino que deberamos recapacitar sobre si estamosaplicando las practicas adecuadas.

En 2001, 17 representantes de nuevas metodologas y crticos 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 laspracticas tradicionales. Estos profesionales, con una dilatada experiencia co-mo aval, llevaban ya alrededor de una decada utilizando tecnicas que les

fueron posicionando como lderes de la industria del desarrollo software. Co-nocan perfectamente las desventajas del clasico modelo en cascada dondeprimero se analiza, luego se disena, despues se implementa y, por ultimo (enalgunos casos), se escriben algunos tests automaticos y se martiriza a ungrupo de personas para que ejecuten manualmente el software, una y otravez hasta la saciedad. El maniesto agil8 se compone de cuatro principios.Es pequeno pero bien cargado de signicado:

8 La traducci on del maniesto es de Agile Spain http://www.agile-

spain.com/maniesto agil

38


39/309

Captulo 1 1.3. El maniesto agil

'

&

$

%

Estamos descubriendo mejores maneras de desarrollar softwaretanto por nuestra propia experiencia como ayudando a terceros.A traves de esta experiencia hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramien-tas

Software que funciona sobre documentaci on exhaustiva

Colaboraci on con el cliente sobre negociaci on de con-tratos

Responder ante el cambio sobre seguimiento de un

planEsto es, aunque los elementos a la derecha tienen valor, nosotrosvaloramos por encima de ellos los que estan a la izquierda.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 maniesto se encuentran 12 principios de vital importancia paraentender su losofa 9 :

Nuestra maxima prioridad es satisfacer al cliente a traves de entregastempranas y continuas de software valioso.

Los requisitos cambiantes son bienvenidos, incluso en las etapas nalesdel desarrollo. Los procesos agiles aprovechan al cambio para ofreceruna ventaja competitiva al cliente.

Entregamos software que funciona frecuentemente, entre un par desemanas y un par de meses. De hecho es comun entregar cada tres ocuatro semanas.

Las personas del negocio y los desarrolladores deben trabajar juntosdiariamente a lo largo de todo el proyecto.

Construimos proyectos entorno a individuos motivados. Dandoles ellugar y el apoyo que necesitan y conando en ellos para hacer el trabajo.

El metodo mas eciente y efectivo de comunicar la informacion haciay entre un equipo de desarrollo es la conversacion cara a cara.

9 Traduccion libre de los principios publicados enhttp://www.agilemanifesto.org/principles.html

39


40/309

1.4. En que consiste el agilismo?: Un enfoque pr actico Captulo 1

La principal medida de avance es el software que funciona.

Los procesos agiles promueven el desarrollo sostenible. Los patroci-nadores, desarrolladores y usuarios deben poder mantener un ritmo

constante.

La atencion continua a la excelencia tecnica y el buen diseno mejorala agilidad.

La simplicidad, es esencial.

Las mejores arquitecturas, requisitos y disenos emergen de la auto-organizacion de los equipos.

A intervalos regulares, el equipo reexiona sobre como ser mas ecaces,a continuacion mejoran y ajustan su comportamiento en consecuencia.

Este libro no pretende abarcar el vasto conjunto de tecnicas y metodo-logas del agilismo pero, considerando la poca literatura en castellano queexiste actualmente sobre este tema, merece la pena publicar el maniesto.

1.4. En que consiste el agilismo?: Un enfoquepractico

El agilismo es una respuesta a los fracasos y las frustraciones del modeloen cascada. A da de hoy, las metodologas agiles de desarrollo de softwareestan en boca de todos y adquieren cada vez mas presencia en el mundohispano, si bien llevan siendo usadas mas de una decada en otros pases. Elabanico de metodologas agiles es amplio, existiendo metodos para organizar

equipos y tecnicas para escribir y mantener el software. Personalmente, meinclino hacia la Programacion Extrema (eXtreme Programming, XP) comoforma de atacar la implementaci on del producto y hacia Scrum como formade gestionar el proyecto, pero el estudio de ambas en su totalidad queda fueradel alcance de este libro.

Por ilustrarlo a modo de alternativa al modelo en cascada: podemos ges-tionar el proyecto con Scrum y codicar con tecnicas de XP; concretamenteTDD10 y Programacion por Parejas 11 , sin olvidar la propiedad colectiva delcodigo y la Integracion Continua12 .

10 Test Driven Development o Desarrollo Dirigido por Test11 Pair Programming o Programaci on por Parejas, es otra de las tecnicas que com-

ponen XP y que no vamos a estudiar en detalle en este libro. Veanse en la bibliografalos textos relacionados con XP para mayor informaci on

12 Vease el apendice sobre Integraci on Continua al nal del libro

40


41/309

Captulo 1 1.4. En que consiste el agilismo?: Un enfoque pr actico

Agilismo no es perfeccionismo, es mas, el agilista reconoce que el soft-ware es propenso a errores por la naturaleza de quienes lo fabrican y lo quehace es tomar medidas para minimizar sus efectos nocivos desde el principio.No busca desarrolladores perfectos sino que reconoce que los humanos nosequivocamos con frecuencia y propone tecnicas que nos aportan conanza apesar ello. La automatizacion de procesos es uno de sus pilares. La nalidadde los distintos metodos que componen el agilismo es reducir los problemasclasicos de los programas de ordenador, a la par que dar mas valor a laspersonas que componen el equipo de desarrollo del proyecto, satisfaciendo alcliente, al desarrollador y al analista de negocio.

El viejo modelo en cascada se transforma en una noria que, a cada vuel-ta (iteraci on), se alimenta con nuevos requerimientos o aproximaciones masrenadas de los ya abordados en iteraciones anteriores, puliendo ademas losdetalles tecnicos (no resolviendo defectos sino puliendo). Al igual que en elmodelo tradicional, existen fases de analisis, desarrollo y pruebas pero, enlugar de ser consecutivas, estan solapadas. Esta combinaci on de etapas seejecuta repetidas veces en lo que se denominan iteraciones. Las iteracionessuelen durar de dos a seis semanas y en cada una de ellas se habla con elcliente para analizar requerimientos, se escriben pruebas automatizadas, seescriben lneas de codigo nuevas y se mejora codigo existente. Al cliente se le

ensenan los resultados despues de cada iteraci on para comprobar su acepta-cion e incidir sobre los detalles que se estimen oportunos o incluso reajustarla planicacion. No es casual que hayamos situado las pruebas automaticasantes de la escritura de nuevo codigo ya que, como veremos en este libro,dentro del agilismo se contempla una tecnica en la que las pruebas son unaherramienta de diseno del codigo (TDD) y, por tanto, se escriben antes queel mismo. Llegado el caso las pruebas se consideran ejemplos, requerimien-tos que pueden ser conrmados (o validados) por una maquina (validaci on

automatizada).Todo el equipo trabaja unido, formando una pi na13 y el cliente es parte

de ella, ya no se le considera un oponente. La estrategia de juego ya noes el control sino la colaboracion y la conanza. Del control se encargaranlos procesos automaticos que nos avisaran de posibles problemas o puntos amejorar. La jerarqua clasica (director tecnico, analista de negocio, arquitecto,programador senior, junior ...) pierde sentido y los roles se disponen sobre uneje horizontal en lugar de vertical, donde cada cual cumple su cometido pero

sin estar por encima ni por debajo de los demas. En lugar de trabajar porhoras, trabajamos por objetivos y usamos el tiempo como un recurso mas yno como un n en s mismo (lo cual no quiere decir que no existan fechas de

13 de ah el nombre de Scrum, que se traduce por Mele, palabra del argot del Rugbyusada para designar la uni on de los jugadores en bloque

41


42/309

1.4. En que consiste el agilismo?: Un enfoque pr actico Captulo 1

entrega para cada iteraci on).La esencia del agilismo es la habilidad para adaptarse a los cambios.

Ejecutando las diversas tecnicas que engloba, con la debida disciplina, seobtienen resultados satisfactorios sin lugar para el caos.

En cualquier metodo agil, los equipos deben ser peque nos, tpicamentemenores de siete personas. Cuando los proyectos son muy grandes y hacefalta mas personal, se crean varios equipos. Nos encontramos ante el famosodivide y venceras.

El analisis no es exhaustivo ni se dilata indenidamente antes de empezarla codicacion, sino que se acota en el tiempo y se encuadra dentro de cadaiteracion y es el propio progreso de la implementacion el que nos ayuda aterminar de descubrir los pormenores. En el analisis buscamos cuales sonlas historias de usuario y, las ambiguedades que puedan surgir, se deshacencon ejemplos concisos en forma de tests automaticos. Hablaremos sobre lashistorias de usuario en el captulo de ATDD. Dichas historias contienen losrequisitos de negocio y se ordenan por prioridad segun las necesidades delcliente, a n de desarrollar antes unas u otras.

Cada requisito debe implementarse en un maximo de una semana paraque, al nal de la iteracion, el cliente pueda ver funcionalidad con valor denegocio.

El analista de negocio adoptara el rol de due no del producto cuando elcliente no pueda participar tan frecuentemente como nos gustara y cam-biara los cientos de paginas de documentacion en prosa por tests de acep-tacion14 lo sucientemente claros como para que el cliente los apruebe yla maquina los valide. Tambien se encargara de priorizar el orden de imple-mentacion de los requisitos acorde a lo que se hable en las reuniones con elcliente. Los desarrolladores estaran en contacto diario con los analistas pararesolver cualquier duda del ambito de negocio lo antes posible. La experiencia

ha demostrado que una buena proporci on podra ser 1:4, esto es, al menosun analista de negocio por cada cuatro desarrolladores 15 .

Los cambios en los requisitos se suman a la planicacion de las iteracionessiguientes y se priorizan junto con las demas tareas pendientes.

Los planes se hacen frecuentemente y se reajustan si hace falta. Siempreson planes de corta duracion, menores de seis meses, aunque la empresapueda tener una planicaci on a muy alto nivel que cubra mas tiempo.

El codigo pertenece a todo el equipo (propiedad colectiva) y cualquier

desarrollador esta en condiciones de modicar codigo escrito por otro. Evi-14 En el captulo sobre ATDD se describe este proceso15 Esta cifra puede ser relativa a las personas por grupo de trabajo, en los cuales

los analistas estar an asignados con tiempo m as reducido, es decir, estar an en m asgrupos. Por ejemplo con 16 desarrolladores y 2 analistas pueden hacerse 4 grupos de 4desarrolladores y un analista pero cada analista en 2 grupos

42


43/309

Captulo 1 1.4. En que consiste el agilismo?: Un enfoque pr actico

tamos las situaciones del tipo... esto s olo lo sabe tocar Manolo que llevameses trabajando en ello.

Todo el equipo se reune periodicamente, incluidos usuarios y analistas denegocio, a ser posible diariamente y si no, al menos una vez a la semana. Pornorma general, se admite que solo los desarrolladores se reunan diariamentey que la reunion con el cliente/analista sea s olo una vez a la semana, ya sesabe que no vivimos en un mundo ideal. De hecho, nos contentaremos conque el cliente acuda a las reuniones de comienzo de iteracion.

Las reuniones tienen hora de comienzo y de nal y son breves. Cuandosuena la alarma de n de la reunion, es como si sonase la campana deincendio en la central de bomberos: cada uno de vuelta a su puesto detrabajo inmediatamente.

La superacion de obstaculos imprevistos tiene prioridad sobre las con-venciones o reglas generales de trabajo preestablecidas. Es decir, si hay quesaltarse el protocolo de la empresa para resolver un problema que se nos haatravesado, se hace. Por protocolo nos referimos a la forma en que habi-tualmente cooperan unas personas con otras, o tal vez la manera en que selanzan nuevas versiones,...

Las grandes decisiones de arquitectura las toma todo el equipo, no sonimpuestas por el arquitecto. Sigue siendo recomendable utilizar patrones de

diseno y otras buenas practicas pero siempre dando maxima importancia yprioridad a los requisitos de negocio. Las arquitecturas agiles son evolutivas,no se disenan al completo antes de escribir el codigo de negocio. Este li-bro deende particularmente las arquitecturas que emergen de los requisitos;TDD habla de que la arquitectura se forja a base de iterar y refactorizar, enlugar de disenarla completamente de antemano.

La aplicacion se ensambla y se despliega en entornos de preproduccion adiario, de forma automatizada. Las bateras de tests se ejecutan varias veces

al da. La cobertura16

de los tests debe ser en torno al 60% o mayor. Enrealidad, se trata de tener en cada iteraci on una cobertura a un mayor que enla anterior, no hay que ser demasiado precisos con el porcentaje.

Los desarrolladores envan sus cambios al repositorio de codigo fuente almenos una vez al da (commit).

Cada vez que se termina de desarrollar una nueva funcion, esta pasa alequipo de calidad para que la valide aunque el resto todava no esten listas.

Partiendo de estas premisas, cada metodologa o tecnica agil detalla con

exactitud c omo se gestiona el proyecto y como es el proceso de desarrollodel codigo. A veces se pueden combinar varias metodologas aunque algunosautores recomiendan seguir al pie de la letra la metodologa en cuestion sin

16 La cobertura de c odigo mediante tests se reere al porcentaje de c odigo que tienetests asociados, considerando todos los cauces que puede tomar el ujo de ejecuci on

43


44/309


45/309

Captulo 1 1.5. La situaci on actual

una base y, en algunos casos, una autoconanza peligrosamente arrogante.La labor de nuestros profesores es fundamental y debemos estar agra-

decidos porque nos han ensenado las reglas de los lenguajes formales y noshan hablado de Alan Turing o del algoritmo de Edsger Dijkstra. No cabeduda de que, en esa etapa, hemos convertido el cerebro en un musculo bienentrenado. La tecnologa cambia a velocidad de vertigo, no podemos esperarque en la universidad nos ensenen continuamente lo ultimo que va saliendoporque en poco tiempo puede quedar obsoleto. Es mas difcil que el modelode la Maquina de Turing quede obsoleto. Recuerdo cuando me quejaba por-que en la ingeniera tecnica no haba visto nada de ciertas herramientas demoda y ahora resulta que estan extinguiendose, que realmente no las nece-sito. Desgraciadamente, hay materias que llevan a nos en uso y a las que seles augura larga vida pero que todava no han llegado a los temarios de losinstitutos ni de las universidades. Las cosas de palacio van despacio. Estoyconvencido de que llegaran pero no podemos esperar a que nos lo cuentenah para aplicarlos, porque el cliente nos esta pidiendo el producto ya. Ne-cesita software de calidad ahora. Por tanto, el mensaje de fondo no es quetodo lo aprendido durante nuestros a nos de estudiantes sea erroneo sino queel camino esta empezando.

Todo lo dicho es aplicable a nuestros mentores en la empresa privada.

Hoy da son muchas las empresas de tecnologa que estan compuestas porgente muy joven y con poca experiencia que no tiene mas remedio que lle-var la batuta como buenamente puede. La cuesti on es plantearse que quizasla manera en que se resuelven los problemas no es la mas apropiada. Porotro lado, es importante saber reconocer cuando estamos sacando el maximopartido a los metodos. Lo que pasa es que sin conocimiento, no podremosdiscernirlo. En cuanto a las empresas con personal experimentado, no estanlibres de caer en la autoreferencia y limitarse a reproducir lo que han hecho

durante a nos. Esta rutina en s misma no es negativa siempre que el clienteeste satisfecho y le estemos ofreciendo el mejor servicio y, al mismo tiem-po, el personal se sienta realizado. Entonces la cuestion es... Lo estamoshaciendo?.

La parte artesanal de los programas de ordenador se podra deber a quedesconocemos la totalidad de las variables de las que depende, porque si lasconociesemos de antemano, no sera una ingeniera tan distinta del resto.Desde un punto de vista muy ingenieril, podemos considerar que la artesana

es simplemente una forma de producir demasiado compleja como para sinte-tizarla y reproducirla mecanicamente. Este arte no se desarrolla estudiandoteora sino practicando, al igual que a andar se aprende andando.

En el mundo tecnologico los meses parecen das y los anos, meses. Lasoportunidades aparecen y se desvanecen fugazmente y nos vemos obligados

45


46/309

1.6. Agil parece, pl atano es Captulo 1

a tomar decisiones con presteza. Las decisiones tecnologicas han convertidoen multimillonarias a personas en cuestion de meses y han hundido impe-rios exactamente con la misma rapidez. Ahora nos esta comenzando a llegarla onda expansiva de un movimiento que pone en entredicho tecnicas quetenamos por buenas pero que con el paso de los anos se estan revelandoinsostenibles. Si bien hace poco gustabamos de disenar complejas arquitec-turas antes de escribir una sola lnea de codigo que atacase directamenteal problema del cliente, ahora, con la escasez de recursos economicos y lamayor exigencia de los usuarios, la palabra agilidad va adquiriendo valoresde ecacia, elegancia, simplicidad y sostenibilidad. Podemos beneciarnosde esta nueva corriente?. Saber adaptarse al cambio es esencial para la evo-lucion. Nos adaptaremos a los cambios del entorno a tiempo?. Todos esospases de los que hablabamos son competidores en realidad y lo seran cadavez mas dada la rapida expansion de Internet. No estaramos mejor si fuesensimplemente colegas?.

El software es una herramienta de presente y de futuro, creada para hacermas agradable la vida de los usuarios. Y, aunque tienda a olvidarse, tambienpuede ser muy graticante para los desarrolladores/analistas. Tendremos quevalernos de conanza y dedicacion junto con gusto por el trabajo para al-canzar esta meta pero... C omo podemos fomentar estas condiciones? Como

ven, zarpamos con preguntas hacia el fascinante mundo del desarrollo agil desoftware. Sera una travesa que nos ira descubriendo las claves de como hacermejor software al tiempo que nos sentimos mas satisfechos con nuestro tra-bajo. Es posible escribir software de mayor calidad con menos complicacionesy aportar mas a los negocios de las personas que lo utilizan.

Bienvenidos a bordo.

1.6.Agil parece, platano es

Se esta usando mucho la palabra agil 17 y, por desgracia, no siempreesta bien empleada. Algunos aprovechan el termino agil para referirse a cow-boy programming (programaci on a lo vaquero), es decir, hacer lo que lesviene en gana, como quieren y cuando quieren. Incluso hay empresas quecreen estar siguiendo metodos agiles pero que en realidad no lo hacen (y nosaben que no lo hacen). Existen mitos sobre el agilismo que dicen que nose documenta y que no se planica o analiza. Tambien se dice que no senecesitan arquitectos pero, no es cierto, lo que sucede es que las decisionesde arquitectura se toman en equipo.

El mal uso de la palabra agil causa malas y falsas ideas sobre lo que17 agile en ingles, pronunciada como ayail

46


47/309

Captulo 1 1.7. Los roles dentro del equipo

verdaderamente es. Llegado este punto, hay que mirar con lupa a quien diceque esta siguiendo un desarrollo agil, tal como pasa con quien dice que vendeproductos ecologicos. Hay quien cree que es agil porque habla mucho conel cliente. Quizas por eso aparecieron las certicaciones en determinadasmetodologas agiles aunque, como muchas otras certicaciones, son solo pa-peles que no garantizan la profesionalidad de la persona certicada(confo enque las certicaciones de la agricultura ecologica s sean autenticas). No nosdebemos ar de alguien que ha asistido dos das a un curso de Scrum y yadice ser un maestro, a no ser que tenga anos de experiencia que le avalen.

Adoptar una metodologa supone aprendizaje y disciplina, como todo loque esta bien hecho y, quienes realmente quieren subirse a este carro, ne-cesitaran la ayuda de personas expertas en la materia. En Internet existenmultitud de grupos y foros donde se ofrece ayuda desinteresadamente y tam-bien existen profesionales que ofrecen formacion y entrenamiento en estasareas y se desplazan a cualquier parte del mundo para trabajar con grupos.En ingles hay bastante literatura al respecto y es mas que recomendable leervarios libros, sobre todo aquellos cuyos autores rmaron el maniesto agil.

Sobre recursos en castellano, actualmente hay mucho movimiento y gran-des profesionales en Agile Spain (comunidad de ambito espanol) y en el ForoAgiles18 (la comunidad latinoamericana, muy extendida en Argentina), que

entre otras cosas, organiza el evento internacional anual Agiles, as comomultitud de openspaces bajo la marca Agile Open.

1.7. Los roles dentro del equipo

Saber distinguir las obligaciones y limitaciones de cada uno de los rolesdel equipo ayuda a que el trabajo lo realicen las personas mejor capacitadaspara ello, lo que se traduce en mayor calidad. Roles distintos no necesaria-mente signica personas distintas, sobre todo en equipos muy reducidos. Unapersona puede adoptar mas de un rol, puede ir adoptando distintos roles conel paso del tiempo, o rotar de rol a lo largo del da. Hagamos un repaso a lospapeles mas comunes en un proyecto software.

Dueno del producto

Cliente

Analista de negocio

Desarrolladores18 http://tech.groups.yahoo.com/group/foro-agiles

47


48/309


49/309

Captulo 1 1.8. Por que nos cuesta comenzar a ser agiles?

datos y sus consultas. No habamos quedado en que el dueno del productopide el que y no dice el como?. Si la persona que tiene el rol de analistatambien tiene el rol de desarrollador, entonces es comprensible que diseneuna interfaz de usuario pero entonces no debera pintarla con un programade diseno graco y endinarsela a otro, sino trabajar en ella. Las pantallasno se disenan al comienzo sino al nal, cuando los requisitos de negocio yase cumplen. Los requisitos son frases cortas en lenguaje natural que ejecutauna maquina automaticamente, ya que tienen forma de test, con lo que sesabe cuando se han implementado. Si las pantallas se disenan primero, secontamina la logica de negocio con la interpretacion que el disenador puedahacer de los requisitos y corremos el riesgo de escribir un codigo sujeto a laUI en lugar de a los requisitos, lo cual lo hace difcil de modicar ante cam-bios futuros en el negocio. El dueno del producto tampoco debe disenar lastablas de la base de datos a no ser que tambien adopte el rol de desarrolladorpero, incluso as, las tablas son de los ultimos19 elementos que aparecen enel proceso de implementacion del requisito, tal como ocurre con la interfazgraca. Es decir, vamos desde el test de aceptaci on a tests de desarrollo queacabaran en la capa de datos que pide persistencia. Pensamos en requisi-tos, implementamos objetos, luego bajamos a tablas en una base de datosrelacional y nalmente le ponemos una carcasa a la aplicacion que se llama

interfaz graca de usuario. No al reves.Si cada cual no se limita a ejercer su rol o roles, estaremos restringiendo a

aquellos que saben hacer su trabajo, limitandoles de modo que no les dejamoshacer lo mejor que saben.

1.8. Por que nos cuesta comenzar a ser agiles?

Si el agilismo tiene tantas ventajas, Por que no lo esta practicando yatodo el mundo? La resistencia al cambio es uno de los motivos fundamentales.Todava forma parte de nuestra cultura pensar que las cosas de toda lavida son las mejores. Ya se sabe... Si es de toda la vida, es como debeser. Si los ingenieros y los cientcos pensasemos as, entonces tendramosmaquinas de escribir en lugar de computadoras (en el mejor de los casos).Existen fuertes razones historicas para ser tan reticentes al cambio pero losque trabajamos con tecnologa podemos dar un paso al frente en favor deldesarrollo. Ojo! Podemos dejar nuestro lado conservador para otros aspectosno tecnologicos, que seguro nos aportara muchos benecios. No se trata deser progresista ni estamos hablando de poltica, limitemonos a cuestiones deciencia y tecnologa.

19 Cuando la logica de negocio es tan simple como guardar y recuperar un dato, esaceptable empezar por los datos.

49


50/309

1.8. Por que nos cuesta comenzar a ser agiles? Captulo 1

Estamos preparados para darle una oportunidad a la innovaci on o nosquedamos con lo de toda la vida, aunque solo tenga una vida de mediosiglo? (en el caso de programadores junior, solo un par de anos). Hemosaceptado una determinada forma de trabajar (en el mundo del software) y nosparece inmutable a un cuando esta industria todava esta en pa nales. Hemosllegado al punto en que la informatica ya no es una cuestion de matematicossino de especialistas en cada una de las muchas areas de la informatica. Nisiquiera se han jubilado aun los primeros expertos en software de la historia.

Cuando era nino no se me pasaba por la cabeza que todo el mundo llevaseun telefono m ovil encima y se comunicase desde cualquier lugar (hace solo15 anos). Hace poco no nos imaginabamos que compraramos por Internet nique las personas encontraran pareja a traves de la red. Los que han tenidoconanza en el cambio y han sabido crecer organicamente trabajan en loque les gusta y no tienen problemas para llegar a n de mes. Las nuevastecnologas son el tren de alta velocidad que une el presente con el futuro enun abrir y cerrar de ojos.

Ahora bien, aprender una nueva tecnica supone esfuerzo. Es natural quenos de pereza dar los primeros pasos hacia el cambio y por eso usamos milexcusas:

Que es antinatural...

Que esta todo al reves...

Que es un caos...

Que no tenemos tiempo ahora para aprender eso...

Que no tenemos los conocimientos previos para empezar...

Que no sabemos por donde empezar...

Manana empiezo...

Es que,... es que...

Nos comportamos como lo hara un fumador al que le dicen que deje defumar. La corriente popular en terminos de software no es capaz de evolu-cionar lo sucientemente rapido como para que sus teoras sean las mejores.Hay que plantearse si seguirla es buena idea o conviene cambiar de corriente.

Esto es,... Preere la pastilla azul o la roja?20

. No negaremos que hay que20 Celebre escena de la pelcula Matrix en que Morfeo ofrece a Neo la posibilidad

de despertar del sue no. Neo escoge la roja. En este caso despertar del sue no signicacambia a mejor, a diferencia de lo que sucede en esta pelcula de cci on. La PastillaRoja tambien es el ttulo de un libro sobre Software Libre escrito por Juan Tom asGarca(http://www.lapastillaroja.net/resumen ejecutivo.html)

50


51/309

Captulo 1 1.8. Por que nos cuesta comenzar a ser agiles?

hacer una inversion en tiempo y esfuerzo para aprender y poner en practicauna nueva forma de funcionar, la cuestion es que tal inversion se amortizarapidamente. Si esperamos a manana para que se den las condiciones per-fectas y empezar a ser agiles, quizas nunca llegue el da. Acaso piensa quealguna vez tendra tiempo y dinero de sobra para todo lo que quiera? El planes mas bien parecido al de echar monedas a la hucha para irse de vacaciones;pequenas inversiones poco a poco. No se interprete que podemos jugar conel dinero del cliente, aprender no signica jugar con su dinero, vale?.

Si aceptamos que el software siempre se puede mejorar, el siguiente pasoes admitir que es positivo mantener un cierto aire inconformista en nuestraactitud profesional. La autocrtica nos lleva a escribir codigo de mayor calidady a reconocer nuestros errores. El juicio sano sobre nuestro trabajo nos guaen la busqueda de mejoras estrategias y nos ayuda a superar la pereza quenos produce la idea del cambio. Todos los das aprendemos algo nuevo. Elda que deje de ser as habra que reexionar seriamente sobre si estamosejerciendo bien el puesto de ingenieros de software.

Este captulo ha sido compuesto a base de pinceladas procedentes diversostemas. No pretende ser completo, ya que se podra escribir un libro enterosobre metodologas, sino solo establecer un contexto de partida para el restode captulos.

51


52/309

1.8. Por que nos cuesta comenzar a ser agiles? Captulo 1

52


53/309

Captulo 2Que es el Desarrollo Dirigido porTests? (TDD)

El Desarrollo Dirigido por Tests (Test Driven Development), al cual mereferire como TDD , es una tecnica de dise no e implementacion de softwareincluida dentro de la metodologa XP. Coincido con Peter Provost 1 en que el

nombre es un tanto desafortunado; algo como Dise no Dirigido por Ejemplos hubiese sido quizas mas apropiado. TDD es una tecnica para disenar softwareque se centra en tres pilares fundamentales:

La implementacion de las funciones justas que el cliente necesita y nomas 2 .

La minimizacion del numero de defectos que llegan al software en fasede produccion.

La produccion de software modular, altamente reutilizable y preparadopara el cambio.

Cuando empezamos a leer sobre TDD creemos que se trata de una buenatecnica para que nuestro codigo tenga una cobertura de tests muy alta, algoque siempre es deseable, pero es realmente una herramienta de diseno queconvierte al programador en un ocial de primera. O, si no les gustan lasmetaforas, convierte al programador en desarrollador 3 . TDD es la respuestaa las grandes preguntas de:

1 http://www.youtube.com/watch?v=JMEO6T6gkAA2 Evitamos desarrollar funcionalidad que nunca ser a usada3 http://www.ericsink.com/No Programmers.html

53


54/309

Captulo 2

Como lo hago?, Por donde empiezo?, Como se que es lo quehay que implementar y lo que no?, Como escribir un codigo quese pueda modicar sin romper funcionalidad existente?

No se trata de escribir pruebas a granel como locos, sino de disenar adecua-damente segun los requisitos.

Pasamos, de pensar en implementar tareas, a pensar en ejemplos certerosque eliminen la ambiguedad creada por la prosa en lenguaje natural (nuestroidioma). Hasta ahora estabamos acostumbrados a que las tareas, o los casosde uso, eran las unidades de trabajo mas peque nas sobre las que ponerse adesarrollar codigo. Con TDD intentamos traducir el caso de uso o tarea en X ejemplos, hasta que el numero de ejemplos sea suciente como para describir

la tarea sin lugar a malinterpretaciones de ningun tipo.En otras metodologas de software, primero nos preocupamos de denircomo va a ser nuestra arquitectura. Pensamos en las clases de infraestruc-tura que van a homogeneizar la forma de trabajar en todos y cada uno delos casos, pensamos si vamos a usar un patron Facade4 y otro Singleton5

y una comunicacion mediante eventos, o DTOs, y una clase central que vaa hacer esto y aquello... Y si luego resulta que no necesitamos todo eso?Cuanto vamos a tardar en darnos cuenta de ello? Cuanto dinero vamos

a malgastar? En TDD dejamos que la propia implementaci on de pequenosejemplos, en constantes iteraciones, hagan emerger la arquitectura que nece-sitamos usar. Ni mas ni menos. No es que nos despreocupemos por completode las caractersticas tecnicas de la aplicacion a priori, es decir, logicamentetendremos que saber si el desarrollo sera para un telefono m ovil, para unaweb o para un pc de escritorio; mas que nada porque tenemos que elegirunas herramientas de desarrollo conformes a las exigencias del guion. Sinembargo, nos limitamos a escoger el framework correspondiente y a usar su

arquitectura como base. Por ejemplo, si escogesemos Django6

o ASP.NETMVC7 , ya tendramos denida buena parte de la base antes de empezar aescribir una sola lnea de codigo. No es que trabajemos sin arquitectura, logi-camente, si en los requisitos esta la interoperabilidad en las comunicaciones,tendremos que usar servicios web o servicios REST, lo cual ya propicia undeterminado soporte. Lo que eliminamos son las arquitecturas encima de esasarquitecturas, las que intentan que todo se haga siempre igual y tal como sele ocurrio al genio de la empresa. A ser posible, esas que nos obligan a mo-dicar siete cheros para cambiar una cadena de texto. TDD produce unaarquitectura que emerge de la no-ambig uedad de los tests automatizados,

4 Facade: http://es.wikipedia.org/wiki/Facade (patr on de dise no)5 Singleton: http://es.wikipedia.org/wiki/Singleton6 http://www.djangoproject.com7 http://www.asp.net/mvc/

54


55/309

Captulo 2

lo cual no exime de las revisiones de codigo entre companeros ni de hacerpreguntas a los desarrolladores mas veteranos del equipo.

Las primeras paginas del libro de Kent Beck [3] (uno de los padres dela metodologa XP) dan unos argumentos muy claros y directos sobre porque merece la pena darle unos cuantos tragos a TDD, o mejor, por que esbenecioso convertirla en nuestra herramienta de diseno principal. Estas sonalgunas de las razones que da Kent junto con otras destacadas guras de laindustria:

La calidad del software aumenta (y veremos por que).

Conseguimos codigo altamente reutilizable.

El trabajo en equipo se hace mas facil, une a las personas.

Nos permite conar en nuestros companeros aunque tengan menosexperiencia.

Multiplica la comunicacion entre los miembros del equipo.

Las personas encargadas de la garanta de calidad adquieren un rol masinteligente e interesante.

Escribir el ejemplo (test) antes que el codigo nos obliga a escribir elmnimo de funcionalidad necesaria, evitando sobredisenar.

Cuando revisamos un proyecto desarrollado mediante TDD, nos damoscuenta de que los tests son la mejor documentaci on tecnica que pode-mos consultar a la hora de entender que misi on cumple cada pieza delpuzzle.

Personalmente, a nadira lo siguiente:Incrementa la productividad.

Nos hace descubrir y afrontar mas casos de uso en tiempo de diseno.

La jornada se hace mucho mas amena.

Uno se marcha a casa con la reconfortante sensacion de que el trabajoesta bien hecho.

Ahora bien, como cualquier tecnica, no es una varita magica y no dara elmismo resultado a un experto arquitecto de software que a un programador junior que esta empezando. Sin embargo, es util para ambos y para todo elrango de integrantes del equipo que hay entre uno y otro. Para el arquitecto es

55


56/309

2.1. El algoritmo TDD Captulo 2

su mano derecha, una gua que le hace claricar el dominio de negocio a cadatest y que le permite conar en su equipo aunque tenga menos experiencia.Frecuentemente, nos encontramos con gente muy desc

Date post:	30-May-2018
Category:	Documents
Upload:	carlosble
View:	225 times
Download:	0 times

Dise˜o Agil Con TDD n

Documents