Diseo gil con TDD

Carlos Bl Jurado y colaboradores.Prologo de Jos Manuel Beas

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

2

ndice general

I Base Terica 27

1. El Agilismo 281.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . 301.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . . . . . 321.3. El manifiesto gil . . . . . . . . . . . . . . . . . . . . . . . 331.4. En qu consiste el agilismo?: Un enfoque prctico . . . 361.5. La situacin actual . . . . . . . . . . . . . . . . . . . . . . 401.6. gil parece, pltano es . . . . . . . . . . . . . . . . . . . . 421.7. Los roles dentro del equipo . . . . . . . . . . . . . . . . . 431.8. Por qu nos cuesta comenzar a ser giles? . . . . . . . 46

2. Qu es el Desarrollo Dirigido por Tests? (TDD) 482.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . . 51

2.1.1. Escribir la especificacin primero . . . . . . . . . . 522.1.2. Implementar el cdigo que hace funcionar el ejem-

plo . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . . 53

2.2. Consideraciones y recomendaciones . . . . . . . . . . . . 552.2.1. Ventajas del desarrollador experto frente al junior . 552.2.2. TDD con una tecnologa desconocida . . . . . . . 562.2.3. TDD en medio de un proyecto . . . . . . . . . . . 56

3. Desarrollo Dirigido por Tests de Aceptacin (ATDD) 583.1. Las historias de usuario . . . . . . . . . . . . . . . . . . . 593.2. Qu y no Cmo . . . . . . . . . . . . . . . . . . . . . . . . 633.3. Est hecho o no? . . . . . . . . . . . . . . . . . . . . . . 663.4. El contexto es esencial . . . . . . . . . . . . . . . . . . . . 67

3

NDICE GENERAL NDICE GENERAL

4. Tipos de test y su importancia 684.1. Terminologa en la comunidad TDD . . . . . . . . . . . . 69

4.1.1. Tests de Aceptacin . . . . . . . . . . . . . . . . . 704.1.2. Tests Funcionales . . . . . . . . . . . . . . . . . . 714.1.3. Tests de Sistema . . . . . . . . . . . . . . . . . . . 714.1.4. Tests Unitarios . . . . . . . . . . . . . . . . . . . . 744.1.5. Tests de Integracin . . . . . . . . . . . . . . . . . 75

5. Tests unitarios y frameworks xUnit 775.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . . 78

6. Mocks y otros dobles de prueba 886.1. Cundo usar un objeto real, un stub o un mock . . . . . . 906.2. La metfora Record/Replay . . . . . . . . . . . . . . . . . 101

7. Diseo Orientado a Objetos 1047.1. Diseo Orientado a Objetos (OOD) . . . . . . . . . . . . . 1047.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . 105

7.2.1. Single Responsibility Principle (SRP) . . . . . . . 1067.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . 1077.2.3. Liskov Substitution Principle (LSP) . . . . . . . . . 1077.2.4. Interface Segregation Principle (ISP) . . . . . . . . 1087.2.5. Dependency Inversin Principle (DIP) . . . . . . . 108

7.3. Inversin del Control (IoC) . . . . . . . . . . . . . . . . . . 109

II Ejercicios Prcticos 1118. Inicio del proyecto - Test Unitarios 112

9. Continuacin del proyecto - Test Unitarios 148

10.Fin del proyecto - Test de Integracin 22210.1.La frontera entre tests unitarios y tests de integracin . . 22410.2.Diseo emergente con un ORM . . . . . . . . . . . . . . . 235

10.2.1. Diseando relaciones entre modelos . . . . . . . . 23710.3.La unificacin de las piezas del sistema . . . . . . . . . . 238

11.La solucin en versin Python 240

12.Antipatrones y Errores comunes 281

4

NDICE GENERAL NDICE GENERAL

A. Integracin Continua (CI) 288A.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 288A.2. Prcticas de integracin continua . . . . . . . . . . . . . . 291

A.2.1. Automatizar la construccin . . . . . . . . . . . . . 291A.2.2. Los test forman parte de la construccin . . . . . . 292A.2.3. Subir los cambios de manera frecuente . . . . . . 293A.2.4. Construir en una mquina de integracin . . . . . 294A.2.5. Todo el mundo puede ver lo que est pasando . . 294A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . 295

A.3. IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . 296A.4. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . 297

5

A la memoria de nuestro querido gatito Lito, que vivi con totalatencin y entrega cada instante de su vida

6

Prlogo

rase una vez que se era, un lejano pas donde vivan dos cerditos,Pablo y Adrin que, adems, eran hermanos. Ambos eran los cerditosms listos de la granja y, por eso, el gallo Ivn (el gerente de la mis-ma) organiz una reunin en el establo, donde les encarg desarrollarun programa de ordenador para controlar el almacn de piensos. Lesexplic qu quera saber en todo momento: cuntos sacos de granohaba y quin meta y sacaba sacos de grano del almacn. Para elloslo tenan un mes pero les advirti que, en una semana, quera ya veralgo funcionando. Al final de esa primera semana, eliminara a uno delos dos.

Adrin, que era el ms joven e impulsivo, inmediatamente se pusomanos a la obra. No hay tiempo que perder!, deca. Y empez rpida-mente a escribir lneas y lneas de cdigo. Algunas eran de un recienteprograma que haba ayudado a escribir para la guardera de la vacaPaca. Adrin pens que no eran muy diferentes un almacn de granoy una guardera. En el primero se guardan sacos y en el segundo, pe-queos animalitos. De acuerdo, tena que retocar algunas cosillas paraque aquello le sirviera pero bueno, esto del software va de reutilizar loque ya funciona, no?

Pablo, sin embargo, antes de escribir una sola lnea de cdigo co-menz acordando con Ivn dos cosas: qu era exactamente lo quepodra ver dentro de una semana y cmo sabra que, efectivamente,estaba terminada cada cosa. Ivn quera conocer, tan rpido como fue-ra posible, cuntos sacos de grano haba en cada parte del almacnporque sospechaba que, en algunas partes del mismo, se estaban acu-mulando sacos sin control y se estaban estropeando. Como los sacosentraban y salan constantemente, no poda saber cuntos haba y dn-de estaban en cada instante, as que acordaron ir contabilizndolos por

7

Prlogo

zonas y apuntando a qu parte iba o de qu parte vena, cada vez queentrara o saliera un saco. As, en poco tiempo podran tener una ideaclara del uso que se estaba dando a las distintas zonas del almacn.

Mientras Adrin adelantaba a Pablo escribiendo muchas lneas decdigo, Pablo escriba primero las pruebas automatizadas. A Adrin esole pareca una prdida de tiempo. Slo tenan una semana para con-vencer a Ivn!

Al final de la primera semana, la demo de Adrin fue espectacu-lar, tena un control de usuarios muy completo, hizo la demostracindesde un mvil y ense, adems, las posibilidades de un generadorde informes muy potente que haba desarrollado para otra granja ante-riormente. Durante la demostracin hubo dos o tres problemillas y tuvoque arrancar de nuevo el programa pero, salvo eso, todo fue genial. Lademostracin de Pablo fue mucho ms modesta, pero cumpli con lasexpectativas de Ivn y el programa no fall en ningn momento. Claro,todo lo que ense lo haba probado muchsimas veces antes gracias aque haba automatizado las pruebas. Pablo haca TDD, es decir, nuncaescriba una lnea de cdigo sin antes tener una prueba que le indicaraun error. Adrin no poda creer que Pablo hubiera gastado ms de lamitad de su tiempo en aquellas pruebas que no hacan ms que retra-sarle a la hora de escribir las funcionalidades que haba pedido Ivn.El programa de Adrin tena muchos botones y muchsimas opciones,probablemente muchas ms de las que jams seran necesarias paralo que haba pedido Ivn, pero tena un aspecto muy profesional.

Ivn no supo qu hacer. La propuesta de Pablo era muy robusta yhaca justo lo que haban acordado. La propuesta de Adrin tena cosi-llas que pulir, pero era muy prometedora. Haba hecho la demostracindesde un mvil! As que les propuso el siguiente trato: Os pagar un50 % ms de lo que inicialmente habamos presupuestado, pero sloa aquel de los dos que me haga el mejor proyecto. Al otro no le darnada.. Era una oferta complicada porque, por un lado, el que ganabase llevaba mucho ms de lo previsto. Muy tentador. Pero, por el otro la-do, corran el riesgo de trabajar durante un mes completamente gratis.Mmmmm.

Adrin, tan impulsivo y arrogante como siempre, no dud ni un ins-tante. Trato hecho!, dijo. Pablo explic que aceptara slo si Ivn secomprometa a colaborar como lo haba hecho durante la primera se-mana. A Ivn le pareci razonable y les convoc a ambos para que leensearan el resultado final en tres semanas.

Adrin se march pitando y llam a su primo Sixto, que saba muchoy le asegurara la victoria, aunque tuviera que darle parte de las ganan-

8

Prlogo

cias. Ambos se pusieron rpidamente manos a la obra. Mientras Adrinarreglaba los defectillos encontrados durante la demo, Sixto se encar-g de disear una arquitectura que permitiera enviar mensajes desdeel mvil hasta un webservice que permita encolar cualquier operacinpara ser procesada en paralelo por varios servidores y as garantizarque el sistema estara en disposicin de dar servicio 24 horas al da los7 das de la semana.

Mientras tanto, Pablo se reuni con Ivn y Bernardo (el encargadodel almacn) para ver cules deberan ser las siguientes funcionalida-des a desarrollar. Les pidi que le explicaran, para cada peticin, qubeneficio obtena la granja con cada nueva funcionalidad. Y as, pocoa poco, fueron elaborando una lista de funcionalidades priorizadas yresumidas en una serie de tarjetas. A continuacin, Pablo fue, tarjetaa tarjeta, discutiendo con Ivn y Bernardo cunto tiempo podra tardaren terminarlas. De paso, aprovech para anotar algunos criterios queluego serviran para considerar que esa funcionalidad estara comple-tamente terminada y eliminar alguna ambigedad que fuera surgiendo.Cuando Pablo pens que, por su experiencia, no podra hacer ms tra-bajo que el que ya haban discutido, dio por concluida la reunin y sedispuso a trabajar. Antes que nada, resolvi un par de defectos que ha-ban surgido durante la demostracin y le pidi a Ivn que lo validara.A continuacin, se march a casa a descansar. Al da siguiente, cogila primera de las tarjetas y, como ya haba hecho durante la semanaanterior, comenz a automatizar los criterios de aceptacin acordadoscon Ivn y Bernardo. Y luego, fue escribiendo la parte del programaque haca que se cumplieran esos criterios de aceptacin. Pablo le ha-ba pedido ayuda a su amigo Hudson, un coyote vegetariano que habavenido desde Amrica a pasar el invierno. Hudson no saba programar,pero era muy rpido haciendo cosas sencillas. Pablo le encarg quecomprobara constantemente los criterios de aceptacin que l habaautomatizado. As, cada vez que Pablo haca algn cambio en su pro-grama, avisaba a Hudson y este haca, una tras otra, todas las pruebasde aceptacin que Pablo iba escribiendo. Y cada vez haba ms. EsteHudson era realmente veloz e incansable!

A medida que iba pasando el tiempo, Adrin y Sixto tenan cada vezms problemas. Terminaron culpando a todo el mundo. A Ivn, porqueno les haba explicado detalles importantsimos para el xito del pro-yecto. A la vaca Paca, porque haba incluido una serie de cambios enel programa de la guardera que haca que no pudieran reutilizar casinada. A los inventores de los SMS y los webservices, porque no te-nan ni idea de cmo funciona una granja. Eran tantos los frentes que

9

Prlogo

tenan abiertos que tuvieron que prescindir del envo de SMS y busca-ron un generador de pginas web que les permitiera dibujar el flujo denavegacin en un grfico y, a partir de ah, generar el esqueleto de laaplicacin. Eso seguro que les ahorrara mucho tiempo! Al poco, Six-to, harto de ver que Adrin no valoraba sus aportaciones y que ya nose iban a usar sus ideas para enviar y recibir los SMS, decidi que semarchaba, an renunciando a su parte de los beneficios. Total, l ya nocrea que fueran a ser capaces de ganar la competicin.

Mientras tanto, Pablo le pidi un par de veces a Ivn y a Bernardoque le validaran si lo que llevaba hecho hasta aquel momento era desu agrado y les hizo un par de demostraciones durante aquellas 3 se-manas, lo que sirvi para corregir algunos defectos y cambiar algunasprioridades. Ivn y Bernardo estaban francamente contentos con el tra-bajo de Pablo. Sin embargo, entre ellos comentaron ms de una vez:Qu estar haciendo Adrin? Cmo lo llevar?.

Cuando se acercaba la fecha final para entregar el programa, Adrinse qued sin dormir un par de noches para as poder entregar su pro-grama. Pero eran tantos los defectos que haba ido acumulando que,cada vez que arreglaba una cosa, le fallaba otra. De hecho, cuando lle-g la hora de la demostracin, Adrin slo pudo ensear el programainstalado en su porttil (el nico sitio donde, a duras penas, funcionaba)y fue todo un desastre: mensajes de error por todos sitios, comporta-mientos inesperados... y lo peor de todo: el programa no haca lo quehaban acordado con Ivn.

Pablo, sin embargo, no tuvo ningn problema en ensear lo quellevaba funcionando desde haca mucho tiempo y que tantas veces ha-ba probado. Por si acaso, dos das antes de la entrega, Pablo habadejado de introducir nuevas caractersticas al programa porque queracentrarse en dar un buen manual de usuario, que Ivn haba olvidadomencionar en las primeras reuniones porque daba por sentado que selo entregaran. Claro, Adrin no haba tenido tiempo para nada de eso.

Moraleja:Adems de toda una serie de buenas prcticas y un proceso de

desarrollo gil, Pablo hizo algo que Adrin despreci: acord con Ivn(el cliente) y con Bernardo (el usuario) los criterios mediante los cu-les se comprobara que cada una de las funcionalidades estara bienacabada. A eso que solemos llamar criterios de aceptacin, Pablo leaadi la posibilidad de automatizar su ejecucin e incorporarlos en unproceso de integracin continua (que es lo que representa su amigoHudson en este cuento). De esta manera, Pablo estaba siempre tran-quilo de que no estaba estropeando nada viejo con cada nueva modifi-

10

Prlogo

cacin. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo erams eficiente. En el corto plazo, las diferencias entre ambos enfoquesno parecen significativas, pero en el medio y largo plazo, es evidenteque escribir las pruebas antes de desarrollar la solucin es mucho mseficaz y eficiente.

En este libro que ahora tienes entre tus manos, y despus de esteinusual prlogo, te invito a leer cmo Carlos explica bien clarito cmoguiar el desarrollo de software mediante la tcnica de escribir antes laspruebas (ms conocido como TDD).

11

Agradecimientos

Una vez o a un maestro zen decir que la gratitud que expresa unapersona denota su estado momentneo de bienestar consigo misma.Estoy muy contento de ver que este proyecto que se empez hace casiao y medio, ha concluido con un resultado tan gratificante.

Tengo que agradecer cosas a miles de personas pero para no ex-tenderme demasiado, lo har hacia los que han tenido una relacin msdirecta con el libro.

En primer lugar tengo que agradecer a Dcil Casanova que hayasido la responsable de calidad nmero uno en el proyecto. Sin ella estelibro no se hubiera escrito de esta forma y en este momento. Quizs nose hubiese escrito nunca. No slo tengo que agradecer todo lo much-simo que me aporta en lo personal sino que adems me anim cons-tantemente a no publicar el libro hasta que estuviera hecho lo mejorposible. Ha revisado mi redaccin corrigiendo mil faltas de ortografa ysignos de puntuacin.

El toque de calidad que dan los dems coautores al libro, es tam-bin un detallazo. Adems de escribir texto han sido buenos revisores.Estoy profundamente agradecido a Juan Gutirrez Plaza por haber es-crito el captulo 11 y por haber hecho correcciones desde la primerarevisin del libro hasta la ltima. Ha sido un placer discutir juntos tan-tos detalles tcnicos. Gracias a Fran Reyes Perdomo tenemos un granapndice sobre Integracin Contnua que de no haber sido por l noestara en el libro, con lo importante que es esta prctica. Mil graciasFran. Gregorio Mena es el responsable de que el captulo 1 no sea uncompleto desastre. Ha sido para m el ms difcil de escribir de todo ellibro y a ningn revisor le acababa de convencer. Gregorio ha refacto-rizado medio captulo dndole un toque mucho ms serio. Espero quesigamos trabajando juntos Gregorio :-) Para terminar con los coautores

12

Agradecimientos

quiero agradecer a Jos Manuel Beas que haya escrito el prlogo dellibro a pesar de lo muy ocupado que est liderando la comunidad gilespaola y haciendo de padre de familia. Un bonito detalle JM ;-D

A continuacin quiero agradecer a la decena de personas que hanledo las revisiones del libro previas a la publicacin y que han apor-tado correcciones, palabras de nimo e incluso texto. Agradecimientosespeciales a Esteban Manchado Velzquez que tiene muchsimo quever con la calidad de la redaccin y que ha sido uno de los revisoresms constantes. Yeray Darias adems de revisar, escribi el captuloque le ped sobre DDD, aunque finalmente queda para un libro futuro.Mi buen amigo Eladio Lpez de Luis ha dejado algn comentario encada revisin que he ido enviando. Alberto Rodrguez Lozano ha sidouna de las personas ms influyentes en las correcciones del captulo 9,aportando comentarios tcnicos de calidad. No puedo olvidar al restode revisores que han seguido el libro en distintas etapas aportando tam-bin comentarios muy brillantes: Nstor Bethencourt, Juan Jorge PrezLpez, Pablo Rodrguez Snchez, Jos Ramn Daz, Jose M. Rodr-guez de la Rosa, Vctor Roldn y Nstor Salceda. Tambin agradezcoa todas las personas que han ledo alguna de estas revisiones previasy me han enviado emails personales de agradecimiento.

Hadi Hariri me influenci mucho para que partiese el libro en dos ydejase para ste, solo aquellos temas de relacin directa con TDD.

Ahora, ms all de los que han tenido relacin directa con el libro,quiero agradecer a Rodrigo Trujillo, ex director de la Oficina de SoftwareLibre de la Universidad de La Laguna (ULL), que me diera la oportuni-dad de dirigir un proyecto y carta blanca para aplicar TDD desde elprimer da, porque durante el ao que trabaj ah aprend toneladas decosas. Rodrigo es una de las personas que ms se mueve en la ULL;no deja de intentar abrir puertas a los estudiantes que estn terminadoni de preocuparse por la calidad de su universidad.

Gracias tambin a Jos Lus Roda, Pedro Gonzlez Yanes y JessAlberto Gonzlez por abrirme las puertas de la facultad de informticay tambin por permitirme que impartiese mi primer curso completo deTDD. De la facultad tengo tambin que agradecer a Marcos Colebrookque me diese el empujn que necesitaba para terminar la carrera, quela tena casi abandonada. Sin Marcos y Goyo, el cambio de plan hubierahecho que abandonase la idea de terminar la carrera.

A Esteban Abeledo y al resto del Colegio de Informaticos de Cana-rias les agradezco mucho hayan homologado nuestros cursos de TDD.

Los alumnos de mis cursos de TDD tienen mucho que ver con elresultado final del libro ya que he volcado en l muchas de sus dudas

13

Agradecimientos

y comentarios tpicos. Gracias a los dos grupos que he tenido en Te-nerife y al de Sevilla, todos en 2009. Mencin especial a las personasque ayudaron a que saliesen adelante: lvaro Lobato y los ya citadosGregorio, Pedro y Roda.

Gracias a todos los que estn promoviendo XP en Espaa. A sa-ber: Alfredo Casado, Xavier Gost, Leo Antol, Agustn Yage, Eric Mig-not, Jorge Jimmez, Ivn Prraga, Jorge Uriarte, Jess Prez, DavidEsmerodes, Luismi Cavall, David Calavera, Ricardo Roldn y tantosotros profesionales de la comunida Agile Spain, entre los cuales estnlos coautores y revisores de este libro. Y tambin a los que estn pro-moviendo XP en Latinoamrica: Fabin Figueredo, Carlos Peix, AngelLpez, Carlos Lone y tantos otros. Y al pibe que vos viste nos rrre-ayuda traer el Agile Open a Espaa, Xavier Quesada ;-)

Alfredo Casado adems 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 apren-dido algo. Gracias a los que me han apoyado y gracias tambin a losque me han querido tapar, porque de todos he aprendido cosas. Ha si-do tremendamente enriquecedor cambiar de empresa y de proyectos.Thank you all guys at Buy4Now in Dublin during my year over there in2007. Tambin he aprendido mucho de todos aquellos desarrolladorescon los que he trabajado en proyectos open source, en mi tiempo libre.

A quienes han confiado en m para impartir cursos de materias di-versas, porque han sido claves para que desarrolle mi capacidad do-cente; Agustn Benito, Academia ESETEC, Armando Fumero, Innova7y Rodrigo Trujillo.

Agradecimientos tambin a Pedro Gracia Fajardo, una de las men-tes ms brillantes que he conocido. Un visionario. Pedro fue quin mehabl por primera vez de XP en 2004. En aquel entonces nos creamosque ramos giles aunque en realidad lo estbamos haciendo fatal. Laexperiencia sirvi para que yo continuase investigando sobre el tema.

Gracias a la comunidad TDD internacional que se presenta en ungrupo de discusin de Yahoo. Aunque ellos no leern estas lneas porser en espaol, quiero dejar claro que sin su ayuda no hubiese sabi-do resolver tantos problemas tcnicos. Gracias a Kent Beck y LasseKoskela por sus libros, que han sido para m fuente de inspiracin.

Aprovecho para felicitar a Roberto Canales por su libro, InformticaProfesional[13]. Es una pena que me haya puesto a leerlo cuando yatena escrito este libro, a pocos das de terminar el proyecto. Si lo hu-biese ledo en octubre, cuando Leo me lo regal, me hubiese ahorradobastantes prrafos de la parte terica. Es un pedazo de libro que reco-

14

Agradecimientos

miendo a todo el mundo. Gracias Roberto por brindarnos un libro tanbrillante. Un libro, un amigo.

Gracias a Angel Medinilla, Juan Palacio, Xavi Albaladejo y RodrigoCorral, por entrenar a tantos equipos giles en nuestro pas. Angel ade-ms me regala muy buenos consejos en mi nueva etapa en iExpertos.

Por ltimo no quiero dejar de decirle a mi familia que sin ellos esto nosera posible. A Dcil de nuevo por todo lo muchsimo que me aportadiariamente. A mis padres por traerme al mundo y ensearme tantascosas. A mis hermanas por querer tanto a su hermano mayor. A misprimos. A mi ta Tina por acogerme en su casa durante mis aos deuniversidad y darme la oportunidad de estudiar una carrera, ya que mispadres no podan costearmelo. Ella me ayuda siempre que lo necesito.A mis abuelos por estar siempre ah, como mis segundos padres.

15

Autores del libro

Carlos Bl Jurado Nac en Crdoba en 1981, hijo de cordobeses pe-ro cuando tena 4 aos emigramos a Lanzarote y,salvo algunos aos intercalados en los que viv enCrdoba, la mayor parte de mi vida la he pasado enCanarias. Primero en Lanzarote y despus en Tene-rife.Mi primer apellido significa trigo en francs. Lotrajo un francs al pueblo cordobs de La Victoriaen tiempos de Carlos III.Cuando tena 6 aos mi padre trajo a casa un 8086y aquello me fascin tanto que supe que me que-ra dedicar a trabajar con ordenadores desde enton-ces. He tenido tambin Amiga 500, Amiga 1200, yluego unos cuantos PC, desde el AMD K6 hasta elIntel Core Duo de hoy.

Soy ingeniero tcnico en informtica de sistemas. Para m el ttulono es ninguna garanta de profesionalidad, ms bien hago un balancenegativo de mi paso por la Universidad, pero quera ponerlo aqu paraque los que padecen de titulitis vean que el que escribe es titulado.

La primera vez que gan dinero con un desarrollo de software fueen 2001. Poco despus de que instalase Debian GNU/Linux en mi PC.En 2003 entr de lleno en el mercado laboral. Al principio trabaj admi-nistrando sistemas adems de programar.

En 2005 se me ocurri la genial idea de montar una empresa dedesarrollo de software a medida con mis colegas. Sin tener suficienteexperiencia como desarrollador y ninguna experiencia como empresa-

16

Autores del libro

rio ni comercial, fue toda una aventura sobrevivir durante los dos aosque permanec en la empresa. Fueron dos aos equivalentes a cuatroo cinco trabajando en otro sitio. Ver el negocio del software desde to-dos los puntos de vista, me brind la oportunidad de darme cuenta demuchas cosas y valorar cuestionas que antes no valoraba. Aprend queno poda tratar al cliente como si fuera un tester. No poda limitarme aprobar las aplicaciones 10 minutos a mano antes de entregarlas y pen-sar que estaban hechas. Aprend que la venta era ms decisiva que elpropio software. Tambin aprend cosas feas como que Hacienda nosomos todos, que los concursos pblicos se amaan, que el notario dams miedo que el dentista, que el pez grande se come al pequeo ymuchas otras. Al final me d cuenta de que la odisea me sobrepasaba yno era capaz de llevar la empresa a una posicin de estabilidad dondepor fn dejase de amanecerme sentado frente a la pantalla. Cansadode los morosos y de que la administracin pblica nos tuviera sin co-brar meses y meses, mientras estaba con el agua al cuello, en 2007 memand a mudar a Irlanda para trabajar como desarrollador. Aprend loimportante que era tener un equipo de QA1 y me volqu con los testsautomatizados. Llegu a vivir el boom de los sueldos en Dublin, cobran-do 5000 euros mensuales y sin hacer ni una sola hora extra. En 2008regres a Tenerife.

En la actualidad he vuelto a emprender. Desarrollo software pro-fesionalmente de manera vocacional. Mi espritu emprendedor me lle-va a poner en marcha nuevas ideas en la nube. Adems me dedicoa formar a desarrolladores impartiendo cursos sobre TDD, cdigo lim-pio, metodologa y herramientas de programacin. En lugar de inten-tar trabajar en mi empresa, trabajo para la empresa2, cuya web eswww.iExpertos.com

Habitualmente escribo en www.carlosble.com y en el blog de iEx-pertos.

He escrito la mayor parte del libro con la excepcin de los fragmen-tos que nos han regalado los dems autores.

1Quality Assurance2El matiz viene del libro, El Mito del Emprendedor, de Michael E. Gerber

17

Autores del libro

Jose Manuel Beas En 2008 decidi aprovechar sus circunstancias per-sonales para tomarse un respiro, mirar atrs, a loslados y, sobre todo, hacia adelante. Y as, aprove-ch ese tiempo para mejorar su formacin en temascomo Scrum asistiendo al curso de Angel Medini-lla. Pero tambin quiso poner su pequeo granitode arena en el desarrollo y la difusin de Concor-dion, una herramienta de cdigo abierto para rea-lizar pruebas de aceptacin, y rellenar su caja deherramientas con cosas como Groovy y Grails. Pe-ro sobre todo vi que mereca la pena poner partede su energa en revitalizar una vieja iniciativa lla-mada Agile Spain y buscar a todos aquellos que,como l, estuvieran buscando maneras mejores dehacer software. Y vaya que si los encontr. Actual-mente es el Presidente de la asociacin Agile Spain,que representa a la comunidad agilista en Espaa yorganizadora de los Agile Open Spain y las Confe-rencias Agile Spain. Tambin participa en la elabo-racin de los podcasts de Podgramando.es, una ini-ciativa de agilismo.es powered by iExpertos.com.Puedes localizarlo fcilmente a travs del portalagilismo.es, en la lista de correo de Agile Spain oen su blog personal http://jmbeas.iexpertos.com.

18

Autores del libro

Juan Gutirrez Plaza Escribir, he escrito poco, pero aprender, muchsi-mo. He intentado hacer algo con sentido con mioxidado Python en el captulo 11 aunque ms queescribir, ha sido discutir y re-discutir con Carlos so-bre cual era la mejor forma de hacer esto y aquello(siempre ha ganado l). Tambin he sacado del balde los recuerdos mi LaTeX y he revisado mucho.Cuando no estoy discutiendo con la gente de Agi-le Spain, trabajo como Agile Coach en F-Securedonde intento ayudar a equipos de Finlandia, Ma-lasia, Rusia y Francia en su transicin a las meto-dologas giles (tanto en gestin como en prcticasde software entre las que se incluye, por supuesto,TDD). Pero cmo he llegado hasta aqu? Mi devo-cin los ordenadores me llev a estudiar la carrerade ingeniera en informtica en la UPM de Madrid.Trabaj en Espaa por un tiempo antes de decidirmudarme a Finlandia en el 2004 para trabajar enNokia. En las largas y oscuras tardes del inviernoFinlands estudi un master en industrial mana-gement antes de cambiar a F-Secure. Cuando eltiempo lo permite, escribo en http://agilizar.es

Fran Reyes Perdomo Soy un apasionado desarrollador de software in-teresado en prcticas giles. Llevo cerca de 4aos trabajando para la rgida Administracin p-blica con un fantastico equipo. Conoc a Carlos Blen un provechoso curso de TDD que imparti paraun grupo de compaeros. Entre cervezas (una faseimportante para asimilar lo aprendido), comparti-mos ideas y experiencias del mundo del software,y me habl adems del proyecto en el que se en-contraba embarcado, en el cual me brind la opor-tunidad de participar con un pequeo apndice so-bre integracin continua. Una prctica, que intenta-mos, forme parte del da a da en nuestros proyec-tos. http://es.linkedin.com/in/franreyesperdomo

19

Autores del libro

Gregorio Mena Mi corta vida profesional ha sido suficientepara dar sentido a la frase de Horacio Nin-gn hombre ha llegado a la excelencia enarte o profesin alguna, sin haber pasadopor el lento y doloroso proceso de estudio ypreparacin. Aunque en mi caso el caminono es doloroso, sino apasionante. Siguiendoesta filosofa, intento formarme y fomentarla formacin, por lo que he organizado uncurso de TDD impartido con gran aciertopor Carlos Ble y voy a participar en futu-ras ediciones. Trabajo desde iExpertos paraque entre todos hagamos posible el primercurso de Scrum en Canarias, pues tambincolaboro con la plataforma ScrumManager.Ha sido esta forma de ver nuestra profe-sin la que me llev a colaborar con Carlosen este libro. Pensaba aportar algo, pero locierto es que lo que haya podido aportar notiene comparacin con lo que he tenido lasuerte de recibir. Por ello debo dar a Carloslas gracias por ofrecerme esta oportunidady por el esfuerzo que ha hecho para que es-te libro sea una realidad para todos los quevemos en la formacin continua el caminoal xito.Habitualmente escribo enhttp://eclijava.blogspot.com.

20

Convenciones y Estructura

Este libro contiene numerosos bloques de cdigo fuente en varioslenguajes de programacin. Para hacerlos ms legibles se incluyendentro de rectngulos que los separan del resto del texto. Cuando secitan elementos de dichos bloques o sentencias del lenguaje, se usaeste_tipo_de_letra.

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

Las referencias bibliogrficas tienen un formato como este:[3]. Lasltimas pginas del libro contienen la bibliografa detallada correspon-diente a todas estas referencias.

Otros libros de divulgacin repiten determinadas ideas a lo largo devarios captulos con el fin de reforzar los conceptos. En la era de la in-foxicacin3 tal repeticin sobra. He intentado minimizar las repeticionesde conceptos para que el libro se pueda revisar rpidamente, por lo quees recomendable una segunda lectura del mismo para quienes deseanprofundizar en la materia. Ser como ver una pelcula dos veces: en elsegundo pase uno aprecia muchos detalles que en el primero no vio ysu impresin sobre el contenido puede variar. En realidad, es que soytan mal escritor que, si no lee el libro dos veces no lo va a entender.Hgase a la idea de que tiene 600 pginas en lugar de 300.

Sobre los paquetes de cdigo fuente que acompaan a este libro(listo para descarga en la web), el escrito en C# es un proyecto deMicrosoft Visual Studio 2008 (Express Edition) y el escrito en Python esuna carpeta de ficheros.

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

21

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 circulacindel conocimiento hemos llegado a donde estamos hoy, no slo en loreferente al avance cientfico y tecnolgico, sino en todos los camposdel saber.

Afortunadamente, el conocimiento no es propiedad de nadie sinoque es como la energa; simplemente fluye, se transforma y nos trans-forma. De hecho no pertenece a las personas, no tiene dueo, es detodos los seres. Observando a los animales podemos ver cmo los pa-dres ensean a su prole las tcnicas que necesitarn para desenvol-verse en la vida.

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

En Internet existe mucha documentacin sobre la libertad del cono-cimiento, empezando por la entrada de la Wikipedia4. Este argumentoes uno de los principales pilares del software libre5, al que tanto tengoque agradecer. Las principales herramientas que utilizaremos en estelibro estn basadas en software libre: frameworks xUnit, sistemas decontrol de versiones y frameworks para desarrollo de software. Perso-nalmente me he convertido en usuario de la tecnologa Microsoft .Netgracias al framework Mono6, desarrollado por Novell con licencia libre.De no haber sido por Mono probablemente no hubiera conocido C#.

4http://es.wikipedia.org/wiki/Conocimiento_libre5http://es.wikipedia.org/wiki/Cdigo_libre6http://www.mono-project.com

22

La Libertad del Conocimiento

El libro ha sido maquetado usando LATEX, concretamente con teTex yMikTeX(software libre) y ha requerido de multitud de paquetes libresdesarrollados por la comunidad. Para la edicin del texto se ha usadoTexmaker, Dokuwiki, Vim y Emacs. El versionado de los ficheros de tex-to se ha llevado a cabo con Subversion. Los diagramas de clases los hagenerado SharpDevelop, con el cual tambin he editado cdigo. Estoymuy agradecido a todos los que han escrito todas estas piezas. En laweb del libro se encuentra el esqueleto con el que se ha maquetadopara que, quien quiera, lo use para sus propias publicaciones.

Pese a mi simpata por el software de fuente abierta, este libro va msall de la dicotoma software libre/software propietario y se centra entcnicas aplicables a cualquier lenguaje de programacin en cualquierentorno. Uno de los peores enemigos del software libre es el fanatismoradical de algunos de sus evangelizadores, que raya en la mala edu-cacin y empaa el buen hacer de los verdaderos profesionales. Es mideseo aclarar que mi posicin personal no es ni a favor ni en contradel software propietario, simplemente me mantengo al margen de esacontienda.

23

La Web del Libro

Los enlaces a sitios web de Internet permanecen menos tiempo ac-tivos en la red que en las pginas de un libro impreso; la lista de refe-rencias se mantendr actualizada en un sitio web dedicado al libro:

http://www.dirigidoportests.com

Si el lector desea participar informando de enlaces rotos, podr hacerlodirigindose a la web del libro o bien mediante correo electrnico alautor:

carlos[Arroba]iExpertos[Punto]comEl cdigo fuente que acompaa al libro se podr descargar en la

misma web.Si bien es cierto que escribir el libro ha sido un placer, tambin es

cierto que ha sido duro en ocasiones. Ha supuesto casi ao y medio detrabajo y, dado que el libro es gratis y ni siquiera su venta en formatopapel se traducir en algo de beneficio, en la web es posible hacerdonaciones. Si el libro le gusta y le ayuda, le invito a que haga unadonacin para que en el futuro puedan haber ms libros libres comoeste.

24

Cul es el Objetivo del Libro?

El objetivo fundamental del libro es traer a nuestro idioma, el espa-ol, conocimiento tcnico que lleva aos circulando por pases de hablainglesa. No cabe duda de que los que inventaron la computacin y elsoftware nos siguen llevando ventaja en cuanto a conocimiento se refie-re. En mi opinin, es una cuestin cultural en su mayor parte pero, seacomo fuere, no podemos perder la oportunidad de subirnos al carro delas nuevas tcnicas de desarrollo y difundir el conocimiento proporcio-nado por nuestros compaeros angloparlantes. Slo as competiremosen igualdad de condiciones, porque a da de hoy cada vez ms clientesapuestan por el outsourcing. Conocimiento es poder.

A da de hoy, por suerte o por desgracia, no nos queda ms re-medio que dominar el ingls, al menos el ingls tcnico escrito, y esconveniente leer mucho en ese idioma. Se aprende muchsimo porqueno slo lo usan los nativos de habla inglesa sino que se ha convertidoen el idioma universal en cuanto a tecnologa. Sin embargo, reconozcoque yo mismo hace unos aos era muy reacio a leer textos en ingls. Hetenido que hacer un gran esfuerzo y leer mucho con el diccionario en lamano hasta llegar al punto en que no me cuesta trabajo leer en ingls(adems de vivir una temporada fuera de Espaa). Conozco a pocoscompaeros que hagan este esfuerzo. Es comprensible y normal quela mayora se limite a leer lo que est documentado en espaol. Al fin yal cabo es de los idiomas ms hablados del planeta. Por eso concluyoque hay que traer la informacin a nuestro idioma para llegar a msgente, aunque el buen profesional deber tener presente las mltiplesventajas que le aportar el dominio del ingls escrito. Cuando no domi-namos el ingls nos perdemos muchos matices que son significativos7.

Apenas hay libros sobre agilismo en espaol. Los nicos libros no-7http://jmbeas.iexpertos.com/hablar-ingles-es-facil-si-sabes-como/

25

Cul es el objetivo del libro?

vedosos que se editan en nuestra lengua relacionados con el mundo delsoftware, tratan sobre tecnologas muy especficas que hoy valen y ma-ana quizs no. Est muy bien que haya libros sobre Java, sobre .Neto sobre Ruby, pero no tenemos que limitarnos a ello. El nico libro so-bre agilismo que hay a da de 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 ScrumPrimer. Estos regalos son de agradecer.

Ahora que existen editoriales en la red tales como Lulu.com, ya nohay excusa para no publicar contenidos tcnicos. Personalmente medaba reparo afrontar este proyecto sin saber si alguna editorial que-rra publicarlo pero ya no es necesario que las editoriales considerenel producto comercialmente vlido para lanzarlo a todos los pblicos.Otro objetivo del libro es animar a los muchos talentos hispanoparlan-tes que gustan de compartir con los dems, a que nos deleiten con suconocimiento y sus dotes docentes. Quin se anima con un libro sobreProgramacin Extrema?.

No me cabe duda de que las ideas planteadas en este libro puedenresultarles controvertidas y desafiantes a algunas personas. El lectorno tiene por qu coincidir conmigo en todo lo que se expone; tan slo leinvito a que explore con una mente abierta las tcnicas aqu recogidas,que las ponga en prctica y despus decida si le resultan o no valiosas.

26

Parte I

Base Terica

27

Captulo 1El Agilismo

Para definir qu es el agilismo, probablemente basten un par delneas. Ya veremos ms adelante, en este mismo captulo, que el con-cepto es realmente simple y queda plasmado en cuatro postulados muysencillos. Pero creo que llegar a comprenderlo requiere un poco ms deesfuerzo y, seguramente, la mejor manera sea haciendo un repaso a lahistoria del desarrollo de software, para al final ver como el agilismono es ms que una respuesta lgica a los problemas que la evolucinsocial y tecnolgica han ido planteando.

Ya desde el punto de partida es necesario hacer una reflexin. Alotear la historia nos damos cuenta de que el origen del desarrollo desoftware est a unas pocas dcadas de nosotros. Para llegar al mo-mento en el que el primer computador que almacenaba programas di-gitalmente corri exitosamente su primer programa, slo tenemos queremontarnos al verano de 19481. Esto nos hace reflexionar sobre el he-cho de que nos encontramos ante una disciplina que es apenas unarecin nacida frente a otras centenarias con una base de conocimientoslida y estable. Por nuestra propia naturaleza nos oponemos al cam-bio, pero debemos entender que casi no ha transcurrido tiempo comopara que exijamos estabilidad.

Siguiendo la ley de Moore2, los componentes hardware acaban du-plicando su capacidad cada ao. Con lo que, en muy poco tiempo, apa-recen mquinas muy potentes capaces de procesar miles de millonesde operaciones en segundos. A la vez, los computadores van reducien-do su tamao considerablemente, se reducen los costes de produccindel hardware y avanzan las comunicaciones entre los sistemas. Todo

1http://en.wikipedia.org/wiki/Tom_Kilburn2http://en.wikipedia.org/wiki/Moore %27s_Law

28

Captulo 1

esto tiene una consecuencia evidente: los computadores ya no slo seencuentran en mbitos muy restringidos, como el militar o el cientfico.

Al extenderse el mbito de aplicacin del hardware (ordenadorespersonales, juegos, relojes, ...), se ofrecen soluciones a sistemas cadavez ms complejos y se plantean nuevas necesidades a una velocidadvertiginosa que implican a los desarrolladores de Software. Sin infor-macin y conocimiento suficiente, unos pocos aventureros empiezana desarrollar las primeras aplicaciones que dan respuesta a las nuevasnecesidades pero es un reto muy complejo que no llega a ser resueltocon la inmediatez y la precisin necesarias. Los proyectos no llegan abuen puerto, o lo hacen muy tarde.

En la dcada de los cincuenta nos encontramos con otro hito im-portante. En el mbito militar, surge la necesidad de profesionalizar lagestin de proyectos para poder abordar el desarrollo de complejos sis-temas que requeran coordinar el trabajo conjunto de equipos y discipli-nas diferentes en la construccin de sistemas nicos. Posteriormente,la industria del automvil sigui estos pasos. Esta nueva disciplina sebasa en la planificacin, ejecucin y seguimiento a travs de procesossistemticos y repetibles.

Hasta este punto, hemos hablado slo de desarrollo de softwarey no de ingeniera de software, ya que es en 1968 cuando se acuaeste trmino en la NATO Software Engineering Conference3.En estaconferencia tambin se acua el trmino crisis del software para definirlos problemas que estaban surgiendo en el desarrollo y que hemoscomentado anteriormente.

Los esfuerzos realizados producen tres reas de conocimiento quese revelaron como estratgicas para hacer frente a la crisis del softwa-re4:

Ingeniera del software: este trmino fue acuado para definir lanecesidad de una disciplina cientfica que, como ocurre en otrasreas, permita aplicar un enfoque sistemtico, disciplinado y cuan-tificable al desarrollo, operacin y mantenimiento del software.

Gestin Predictiva de proyectos: es una disciplina formal de ges-tin, basada en la planificacin, ejecucin y seguimiento a travsde procesos sistemticos y repetibles.

Produccin basada en procesos: se crean modelos de procesosbasados en el principio de Pareto5, empleado con buenos resul-

3http://en.wikipedia.org/wiki/Software_engineering4http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf5http://es.wikipedia.org/wiki/Principio_de_Pareto

29

1.1. Modelo en cascada Captulo 1

tados en la produccin industrial. Dicho principio nos indica quela calidad del resultado depende bsicamente de la calidad de losprocesos.

En este punto, con el breve recorrido hecho, podemos sacar conclu-siones reveladoras que luego nos llevarn a la mejor comprensin delagilismo. Por un lado, la gestin predictiva de proyectos establece co-mo criterios de xito obtener el producto definido en el tiempo previsto ycon el coste estimado. Para ello, se asume que el proyecto se desarrollaen un entorno estable y predecible. Por otro, se empiezan a emular mo-delos industriales e ingenieriles que surgieron en otros mbitos y conotros desencadenantes.

Debemos tener en cuenta que, al principio, el tiempo de vida de unproducto acabado era muy largo; durante este tiempo, generaba bene-ficios a las empresas, para las que era ms rentable este producto quelas posibles novedades pero, a partir de los ochenta, esta situacin em-pieza a cambiar. La vida de los productos es cada vez ms corta y unavez en el mercado, son novedad apenas unos meses, quedando fuerade l enseguida. Esto obliga a cambiar la filosofa de las empresas, quese deben adaptar a este cambio constante y basar su sistema de pro-duccin en la capacidad de ofrecer novedades de forma permanente.

Lo cierto es que ni los productos de software se pueden definir porcompleto a priori, ni son totalmente predecibles, ni son inmutables. Ade-ms, los procesos aplicados a la produccin industrial no tienen el mis-mo efecto que en desarrollo de software, ya que en un caso se apli-can sobre mquinas y en otro, sobre personas. Estas particularidadestan caractersticas del software no tuvieron cabida en la elaboracindel modelo ms ampliamente seguido hasta el momento: El modeloen cascada. En el siguiente punto de este captulo veremos una brevedescripcin de dicho modelo, para entender su funcionamiento y poderconcluir por qu en determinados entornos era preciso un cambio. Co-mo ya comentaba al principio, el objetivo es ver que el agilismo es larespuesta a una necesidad.

1.1. Modelo en cascada

Este es el ms bsico de todos los modelos6 y ha servido comobloque de construccin para los dems paradigmas de ciclo de vida.Est basado en el ciclo convencional de una ingeniera y su visin es

6Bennington[4], Pag. 26-30

30

Captulo 1 1.1. Modelo en cascada

muy simple: el desarrollo de software se debe realizar siguiendo unasecuencia de fases. Cada etapa tiene un conjunto de metas bien defini-das y las actividades dentro de cada una contribuyen a la satisfaccinde metas de esa fase o quizs a una subsecuencia de metas de lamisma. El arquetipo del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del Sistema: Debido a que el software essiempre parte de un sistema mayor, el trabajo comienza estable-ciendo los requisitos de todos los elementos del sistema y luegoasignando algn subconjunto de estos requisitos al software.Anlisis de los requisitos del software: el proceso de recopilacinde los requisitos se centra e intensifica especialmente en el soft-ware. El ingeniero de software debe comprender el mbito de lainformacin del software as como la funcin, el rendimiento y lasinterfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos dis-tintos del programa; la estructura de los datos, la arquitectura delsoftware, el detalle procedimental y la caracterizacin de la inter-faz. El proceso de diseo traduce los requisitos en una represen-tacin del software con la calidad requerida antes de que comien-ce la codificacin.

Codificacin: el diseo debe traducirse en una forma legible parala maquina. Si el diseo se realiza de una manera detallada, lacodificacin puede realizarse mecnicamente.

Prueba: una vez que se ha generado el cdigo comienza la prue-ba del programa. La prueba se centra en la lgica interna del soft-ware y en las funciones externas, realizando pruebas que asegu-ren que la entrada definida produce los resultados que realmentese requieren.

Mantenimiento: el software sufrir cambios despus de que seentrega al cliente. Los cambios ocurrirn debidos a que se hayaencontrado errores, a que el software deba adaptarse a cambiosdel entorno externo (sistema operativo o dispositivos perifricos)o a que el cliente requiera ampliaciones funcionales o del rendi-miento.

En el modelo vemos una ventaja evidente y radica en su sencillez,ya que sigue los pasos intuitivos necesarios a la hora de desarrollar elsoftware. Pero el modelo se aplica en un contexto, as que debemosatender tambin a l y saber que:

31

1.2. Hablemos de cifras Captulo 1

Los proyectos reales raramente siguen el flujo secuencial que pro-pone el modelo. Siempre hay iteraciones y se crean problemas enla aplicacin del paradigma.

Normalmente, al principio, es difcil para el cliente establecer to-dos los requisitos explcitamente. El ciclo de vida clsico lo re-quiere y tiene dificultades en acomodar posibles incertidumbresque pueden existir al comienzo de muchos productos.

El cliente debe tener paciencia. Hasta llegar a las etapas finalesdel proyecto no estar disponible una versin operativa del progra-ma. Un error importante que no pueda ser detectado hasta que elprograma est funcionando, puede ser desastroso.

1.2. Hablemos de cifras

Quizs nos encontremos en un buen punto para dejar de lado losdatos tericos y centrarnos en cifras reales que nos indiquen la magni-tud del problema que pretendemos describir. Para ello nos basaremosen los estudios realizados por un conjunto de profesionales de Massa-chussets que se uni en 1985 bajo el nombre de Standish Group7. Elobjetivo de estos profesionales era obtener informacin de los proyec-tos fallidos en tecnologas de la informacin (IT) y as poder encontrary combatir las causas de los fracasos. El buen hacer de este grupo loha convertido en un referente, a nivel mundial, sobre los factores queinciden en el xito o fracaso de los proyectos de IT. Factores que secentran, fundamentalmente, en los proyectos de software y se aplicantanto a los desarrollos como a la implementacin de paquetes (SAP,Oracle, Microsoft, etc.)

A lo largo del tiempo, el Standish Group revel 50.000 proyectosfallidos y en 1994 se obtuvieron los siguientes resultados:

Porcentaje de proyectos que son cancelados: 31 %Porcentaje de proyectos problemticos: 53 %Porcentaje de proyectos exitosos: 16 % (pero estos slo cumplie-ron, en promedio, con el 61 % de la funcionalidad prometida)

Atendiendo a estos resultados poco esperanzadores, durante losltimos diez aos, la industria invirti varios miles de millones de dla-res en el desarrollo y perfeccionamiento de metodologas y tecnologas

7http://www.standishgroup.com

32

Captulo 1 1.3. El manifiesto gil

(PMI, CMMI, ITIL, etc.). Sin embargo, en 2004 los resultados seguansin ser alentadores:

Porcentaje de proyectos exitosos: crece hasta el 29 %.Porcentaje de proyectos fracasados: 71 %.

Segn el informe de Standish, las diez causas principales de los fraca-sos, por orden de importancia, son:

Escasa participacin de los usuarios

Requerimientos y especificaciones incompletas

Cambios frecuentes en los requerimientos y especificaciones

Falta de soporte ejecutivoIncompetencia tecnolgica

Falta de recursos

Expectativas no realistas

Objetivos poco clarosCronogramas irreales

Nuevas tecnologas

Cabe destacar de estos resultados que siete de los factores nombra-dos, son factores humanos. Las cifras evidencian la existencia de unproblema, al que, como veremos a continuacin, el agilismo intenta darrespuesta.

En el libro de Roberto Canales[13] existe ms informacin sobre losmtodos en cascada, las metodologas giles y la gestin de proyectos.

1.3. El manifiesto gil

Hasta ahora hemos visto que quizs para algunos proyectos se estrealizando un esfuerzo vano e incluso peligroso: intentar aplicar prcti-cas de estimacin, planificacin e ingeniera de requisitos. No es con-veniente pensar que estas prcticas son malas en s mismas o que losfracasos se deben a una mala aplicacin de estas, sino que deberamosrecapacitar sobre si estamos aplicando las prcticas adecuadas.

33

1.3. El manifiesto gil Captulo 1

En 2001, 17 representantes de nuevas metodologas y crticos delos modelos de mejora basados en procesos se reunieron, convocadospor Kent Beck, para discutir sobre el desarrollo de software. Fue un gri-to de basta ya! a las prcticas tradicionales. Estos profesionales, conuna dilatada experiencia como aval, llevaban ya alrededor de una dca-da utilizando tcnicas que les fueron posicionando como lderes de laindustria del desarrollo software. Conocan perfectamente las desven-tajas del clsico modelo en cascada donde primero se analiza, luegose disea, despus se implementa y, por ltimo (en algunos casos), seescriben algunos tests automticos y se martiriza a un grupo de perso-nas para que ejecuten manualmente el software, una y otra vez hastala saciedad. El manifiesto gil8 se compone de cuatro principios. Espequeo pero bien cargado de significado:'

&

$

%

Estamos descubriendo mejores maneras de desarrollar soft-ware tanto por nuestra propia experiencia como ayudando aterceros. A travs de esta experiencia hemos aprendido a va-lorar:

Individuos e interacciones sobre procesos y herramien-tas

Software que funciona sobre documentacin exhaustiva

Colaboracin con el cliente sobre negociacin de contra-tos

Responder ante el cambio sobre seguimiento de un planEsto es, aunque los elementos a la derecha tienen valor, no-sotros valoramos por encima de ellos los que estn a la iz-quierda.Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunning-ham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Suther-land, Dave Thomas.

Tras este manifiesto se encuentran 12 principios de vital importanciapara entender su filosofa9:

Nuestra mxima prioridad es satisfacer al cliente a travs de en-tregas tempranas y continuas de software valioso.

8La traduccin del manifiesto es de Agile Spain http://www.agile-spain.com/manifiesto_agil9Traduccin libre de los principios publicados en http://www.agilemanifesto.org/principles.html

34

Captulo 1 1.3. El manifiesto gil

Los requisitos cambiantes son bienvenidos, incluso en las etapasfinales del desarrollo. Los procesos giles aprovechan al cambiopara ofrecer una ventaja competitiva al cliente.Entregamos software que funciona frecuentemente, entre un parde semanas y un par de meses. De hecho es comn entregarcada tres o cuatro semanas.

Las personas del negocio y los desarrolladores deben trabajarjuntos diariamente a lo largo de todo el proyecto.Construimos proyectos en torno a individuos motivados. Dndolesel lugar y el apoyo que necesitan y confiando en ellos para hacerel trabajo.El mtodo ms eficiente y efectivo de comunicar la informacinhacia y entre un equipo de desarrollo es la conversacin cara acara.

La principal medida de avance es el software que funciona.

Los procesos giles promueven el desarrollo sostenible. Los pa-trocinadores, desarrolladores y usuarios deben poder mantenerun ritmo constante.

La atencin continua a la excelencia tcnica y el buen diseo me-jora la agilidad.La simplicidad es esencial.

Las mejores arquitecturas, requisitos y diseos emergen de laauto-organizacin de los equipos.

A intervalos regulares, el equipo reflexiona sobre cmo ser mseficaces, a continuacin mejoran y ajustan su comportamiento enconsecuencia.

Este libro no pretende abarcar el vasto conjunto de tcnicas y me-todologas del agilismo pero, considerando la poca literatura en caste-llano que existe actualmente sobre este tema, merece la pena publicarel manifiesto.

35

1.4. En qu consiste el agilismo?: Un enfoque prctico Captulo 1

1.4. En qu consiste el agilismo?: Un enfoque prctico

El agilismo es una respuesta a los fracasos y las frustraciones delmodelo en cascada. A da de hoy, las metodologas giles de desa-rrollo de software estn en boca de todos y adquieren cada vez mspresencia en el mundo hispano, si bien llevan siendo usadas ms deuna dcada en otros pases. El abanico de metodologas giles es am-plio, existiendo mtodos para organizar equipos y tcnicas para escribiry mantener el software. Personalmente, me inclino hacia la Programa-cin Extrema (eXtreme Programming, XP) como forma de atacar la im-plementacin del producto y hacia Scrum como forma de gestionar elproyecto, pero el estudio de ambas en su totalidad queda fuera del al-cance de este libro.

Por ilustrarlo a modo de alternativa al modelo en cascada: podemosgestionar el proyecto con Scrum y codificar con tcnicas de XP; concre-tamente TDD10 y Programacin por Parejas11, sin olvidar la propiedadcolectiva del cdigo y la Integracin Continua12.

Agilismo no es perfeccionismo, es ms, el agilista reconoce que elsoftware es propenso a errores por la naturaleza de quienes lo fabricany lo que hace es tomar medidas para minimizar sus efectos nocivos des-de el principio. No busca desarrolladores perfectos sino que reconoceque los humanos nos equivocamos con frecuencia y propone tcnicasque nos aportan confianza a pesar ello. La automatizacin de procesoses uno de sus pilares. La finalidad de los distintos mtodos que compo-nen el agilismo es reducir los problemas clsicos de los programas deordenador, a la par que dar ms valor a las personas que componen elequipo de desarrollo del proyecto, satisfaciendo al cliente, al desarrolla-dor y al analista de negocio.

El viejo modelo en cascada se transforma en una noria que, a ca-da vuelta (iteracin), se alimenta con nuevos requerimientos o aproxi-maciones ms refinadas de los ya abordados en iteraciones anteriores,puliendo adems los detalles tcnicos (no resolviendo defectos sino pu-liendo). Al igual que en el modelo tradicional, existen fases de anlisis,desarrollo y pruebas pero, en lugar de ser consecutivas, estn solapa-das. Esta combinacin de etapas se ejecuta repetidas veces en lo quese denominan iteraciones. Las iteraciones suelen durar de dos a seis

10Test Driven Development o Desarrollo Dirigido por Test11Pair Programming o Programacin por Parejas, es otra de las tcnicas que componen XP y

que no vamos a estudiar en detalle en este libro. Vanse en la bibliografa los textos relacionadoscon XP para mayor informacin

12Vase el apndice sobre Integracin Continua al final del libro

36

Captulo 1 1.4. En qu consiste el agilismo?: Un enfoque prctico

semanas y en cada una de ellas se habla con el cliente para analizarrequerimientos, se escriben pruebas automatizadas, se escriben lneasde cdigo nuevas y se mejora cdigo existente. Al cliente se le enseanlos resultados despus de cada iteracin para comprobar su aceptacine incidir sobre los detalles que se estimen oportunos o incluso reajustarla planificacin. No es casual que hayamos situado las pruebas auto-mticas antes de la escritura de nuevo cdigo ya que, como veremosen este libro, dentro del agilismo se contempla una tcnica en la quelas pruebas son una herramienta de diseo del cdigo (TDD) y, portanto, se escriben antes que el mismo. Llegado el caso las pruebas seconsideran ejemplos, requerimientos que pueden ser confirmados (ovalidados) por una mquina (validacin automatizada).

Todo el equipo trabaja unido, formando una pia13 y el cliente esparte de ella, ya no se le considera un oponente. La estrategia de jue-go ya no es el control sino la colaboracin y la confianza. Del controlse encargarn los procesos automticos que nos avisarn de posiblesproblemas o puntos a mejorar. La jerarqua clsica (director tcnico,analista de negocio, arquitecto, programador senior, junior ...) pierdesentido y los roles se disponen sobre un eje horizontal en lugar de ver-tical, donde cada cual cumple su cometido pero sin estar por encima nipor debajo de los dems. En lugar de trabajar por horas, trabajamos porobjetivos y usamos el tiempo como un recurso ms y no como un fin ens mismo (lo cual no quiere decir que no existan fechas de entrega paracada iteracin).

La esencia del agilismo es la habilidad para adaptarse a los cam-bios. Ejecutando las diversas tcnicas que engloba, con la debida dis-ciplina, se obtienen resultados satisfactorios sin lugar para el caos.

En cualquier mtodo gil, los equipos deben ser pequeos, tpica-mente menores de siete personas. Cuando los proyectos son muy gran-des y hace falta ms personal, se crean varios equipos. Nos encontra-mos ante el famoso divide y vencers.

El anlisis no es exhaustivo ni se dilata indefinidamente antes deempezar la codificacin, sino que se acota en el tiempo y se encuadradentro de cada iteracin y es el propio progreso de la implementacinel que nos ayuda a terminar de descubrir los pormenores. En el an-lisis buscamos cules son las historias de usuario y, las ambigedadesque puedan surgir, se deshacen con ejemplos concisos en forma detests automticos. Hablaremos sobre las historias de usuario en el ca-ptulo de ATDD. Dichas historias contienen los requisitos de negocio y

13de ah el nombre de Scrum, que se traduce por Mel, palabra del argot del Rugby usada paradesignar la unin de los jugadores en bloque

37

1.4. En qu consiste el agilismo?: Un enfoque prctico Captulo 1

se ordenan por prioridad segn las necesidades del cliente, a fin dedesarrollar antes unas u otras.

Cada requisito debe implementarse en un mximo de una semanapara que, al final de la iteracin, el cliente pueda ver funcionalidad convalor de negocio.

El analista de negocio adoptar el rol de dueo del producto cuandoel cliente no pueda participar tan frecuentemente como nos gustara ycambiar los cientos de pginas de documentacin en prosa por testsde aceptacin14 lo suficientemente claros como para que el cliente losapruebe y la mquina los valide. Tambin se encargar de priorizar elorden de implementacin de los requisitos acorde a lo que se hable enlas reuniones con el cliente. Los desarrolladores estarn en contactodiario con los analistas para resolver cualquier duda del mbito de ne-gocio lo antes posible. La experiencia ha demostrado que una buenaproporcin podra ser 1:4, esto es, al menos un analista de negocio porcada cuatro desarrolladores15.

Los cambios en los requisitos se suman a la planificacin de lasiteraciones siguientes y se priorizan junto con las dems tareas pen-dientes.

Los planes se hacen frecuentemente y se reajustan si hace falta.Siempre son planes de corta duracin, menores de seis meses, aunquela empresa pueda tener una planificacin a muy alto nivel que cubrams tiempo.

El cdigo pertenece a todo el equipo (propiedad colectiva) y cual-quier desarrollador est en condiciones de modificar cdigo escrito porotro. Evitamos las situaciones del tipo... esto slo lo sabe tocar Manoloque lleva meses trabajando en ello.

Todo el equipo se rene peridicamente, incluidos usuarios y ana-listas de negocio, a ser posible diariamente y si no, al menos una vez ala semana. Por norma general, se admite que slo los desarrolladoresse renan diariamente y que la reunin con el cliente/analista sea slouna vez a la semana, ya se sabe que no vivimos en un mundo ideal. Dehecho, nos contentaremos con que el cliente acuda a las reuniones decomienzo de iteracin.

Las reuniones tienen hora de comienzo y de final y son breves.Cuando suena la alarma de fin de la reunin, es como si sonase la

14En el captulo sobre ATDD se describe este proceso15Esta cifra puede ser relativa a las personas por grupo de trabajo, en los cuales los analistas

estarn asignados con tiempo ms reducido, es decir, estarn en ms grupos. Por ejemplo con16 desarrolladores y 2 analistas pueden hacerse 4 grupos de 4 desarrolladores y un analista perocada analista en 2 grupos

38

Captulo 1 1.4. En qu consiste el agilismo?: Un enfoque prctico

campana de incendio en la central de bomberos: cada uno de vuelta asu puesto de trabajo inmediatamente.

La superacin de obstculos imprevistos tiene prioridad sobre lasconvenciones o reglas generales de trabajo preestablecidas. Es decir, sihay que saltarse el protocolo de la empresa para resolver un problemaque se nos ha atravesado, se hace. Por protocolo nos referimos a laforma en que habitualmente cooperan unas personas con otras, o talvez la manera en que se lanzan nuevas versiones,...

Las grandes decisiones de arquitectura las toma todo el equipo, noson impuestas por el arquitecto. Sigue siendo recomendable utilizar pa-trones de diseo y otras buenas prcticas pero siempre dando mximaimportancia y prioridad a los requisitos de negocio. Las arquitecturasgiles son evolutivas, no se disean al completo antes de escribir el c-digo de negocio. Este libro defiende particularmente las arquitecturasque emergen de los requisitos; TDD habla de que la arquitectura se for-ja a base de iterar y refactorizar, en lugar de disearla completamentede antemano.

La aplicacin se ensambla y se despliega en entornos de preproduc-cin a diario, de forma automatizada. Las bateras de tests se ejecutanvarias veces al da. La cobertura16 de los tests debe ser en torno al 60 %o mayor. En realidad, se trata de tener en cada iteracin una coberturaan mayor que en la anterior, no hay que ser demasiado precisos conel porcentaje.

Los desarrolladores envan sus cambios al repositorio de cdigofuente al menos una vez al da (commit).

Cada vez que se termina de desarrollar una nueva funcin, estapasa al equipo de calidad para que la valide aunque el resto todava noestn listas.

Partiendo de estas premisas, cada metodologa o tcnica gil de-talla con exactitud cmo se gestiona el proyecto y cmo es el procesode desarrollo del cdigo. A veces se pueden combinar varias metodo-logas aunque algunos autores recomiendan seguir al pie de la letra lametodologa en cuestin sin mezclar ni salirse del camino en ningnmomento.

No podemos negar que las metodologas son a menudo disciplinasy que implantarlas no es sencillo, todo tiene su coste y tenemos que po-ner en la balanza las dificultades y los beneficios para determinar qudecisin tomamos frente a cada problema. En el libro de Canales[13]se habla precisamente de la implantacin y puesta en marcha de meto-

16La cobertura de cdigo mediante tests se refiere al porcentaje de cdigo que tiene testsasociados, considerando todos los cauces que puede tomar el flujo de ejecucin

39

1.5. La situacin actual Captulo 1

dologas en la empresa.Esperemos que en el futuro cercano contemos con literatura en cas-

tellano sobre cada una de las metodologas giles ms populares.

1.5. La situacin actual

Son muchos los que se han dado cuenta de la necesidad de uncambio y, guiados por aquellos que ya lo han emprendido, han modifi-cado el proceso de desarrollo para reaccionar ante esta crisis. La mayorparte de los que lo han hecho viven en el mundo anglosajn, en lugarescomo Norte Amrica o Reino Unido o bien siguen su corriente, comolas grandes potencias en expansin, India y China, que copian lo mejordel sistema anglosajn. Sin olvidar el pas de la tecnologa, Japn, queadems de copiar marca tendencias. Por qu estamos tardando tantoen apuntarnos a este movimiento?

En Espaa, el objetivo de las universidades es la formacin integraldel alumno. No se pretende capacitarles para afrontar problemas con-cretos en circunstancias concretas, sino hacer que sean profesionalescapacitados para afrontar con xito su cometido sea cual sea la tenden-cia que les toque vivir. En definitiva, el objetivo principal es la creacin,desarrollo, transmisin, difusin y crtica de la ciencia, la tcnica, el ar-te y la cultura, promoviendo una visin integral del conocimiento. En elcaso concreto de la informtica, esto hace que no se imponga comorequisito que los profesores sean profesionales que se dediquen o sehayan dedicado profesionalmente a construir software.

Esto no es bueno ni malo, cada cual cumple su funcin en las distin-tas etapas por las que pasamos, lo que es negativo es que aceptemos,sin la menor duda ni crtica, que lo que nos han enseado es la nicamanera de sacar adelante los proyectos. Que ya no hay que apren-der nada ms. Es ciertamente dramtico que, a pesar de esta realidad,miremos con tanto escepticismo las nuevas tcnicas de gestin de pro-yectos software. Los grandes libros sobre software escritos en inglsen las ltimas dos dcadas, no estn escritos por profesores de univer-sidad sino por lderes de la industria con treinta aos de batalla sobresus espaldas. No pretendo abrir un debate sobre cul es el objetivode la universidad ni de la formacin profesional, sino abrir un debateinterior en cada uno de los que ya han salido de su largo periodo deformacin y piensan que aquello que han aprendido es el nico caminoposible, todo lo que tienen que aplicar, cuando en realidad lo que hanadquirido es tan slo una base y, en algunos casos, una autoconfianza

40

Captulo 1 1.5. La situacin actual

peligrosamente arrogante.La labor de nuestros profesores es fundamental y debemos estar

agradecidos porque nos han enseado las reglas de los lenguajes for-males y nos han hablado de Alan Turing o del algoritmo de EdsgerDijkstra. No cabe duda de que, en esa etapa, hemos convertido el ce-rebro en un msculo bien entrenado. La tecnologa cambia a velocidadde vrtigo, no podemos esperar que en la universidad nos enseencontinuamente lo ltimo que va saliendo porque en poco tiempo puedequedar obsoleto. Es ms difcil que el modelo de la Mquina de Turingquede obsoleto. Recuerdo cuando me quejaba porque en la ingenieratcnica no haba visto nada de ciertas herramientas de moda y ahoraresulta que estn extinguindose, que realmente no las necesito. Des-graciadamente, hay materias que llevan aos en uso y a las que se lesaugura larga vida pero que todava no han llegado a los temarios delos institutos ni de las universidades. Las cosas de palacio van despa-cio. Estoy convencido de que llegarn pero no podemos esperar a quenos lo cuenten ah para aplicarlos, porque el cliente nos est pidiendoel producto ya. Necesita software de calidad ahora. Por tanto, el men-saje de fondo no es que todo lo aprendido durante nuestros aos deestudiantes sea errneo sino que el camino est empezando.

Todo lo dicho es aplicable a nuestros mentores en la empresa pri-vada. Hoy da son muchas las empresas de tecnologa que estn com-puestas por gente muy joven y con poca experiencia que no tiene msremedio que llevar la batuta como buenamente puede. La cuestin esplantearse que quizs la manera en que se resuelven los problemasno es la ms apropiada. Por otro lado, es importante saber reconocercuando estamos sacando el mximo partido a los mtodos. Lo que pa-sa es que sin conocimiento, no podremos discernirlo. En cuanto a lasempresas con personal experimentado, no estn libres de caer en laautoreferencia y limitarse a reproducir lo que han hecho durante aos.Esta rutina en s misma no es negativa siempre que el cliente est sa-tisfecho y le estemos ofreciendo el mejor servicio y, al mismo tiempo,el personal se sienta realizado. Entonces la cuestin es... Lo estamoshaciendo?.

La parte artesanal de los programas de ordenador se podra debera que desconocemos la totalidad de las variables de las que depende,porque si las conocisemos de antemano, no sera una ingeniera tandistinta del resto. Desde un punto de vista muy ingenieril, podemos con-siderar que la artesana es simplemente una forma de producir dema-siado compleja como para sintetizarla y reproducirla mecnicamente.Este arte no se desarrolla estudiando teora sino practicando, al igual

41

1.6. gil parece, pltano es Captulo 1

que a andar se aprende andando.En el mundo tecnolgico los meses parecen das y los aos, me-

ses. Las oportunidades aparecen y se desvanecen fugazmente y nosvemos obligados a tomar decisiones con presteza. Las decisiones tec-nolgicas han convertido en multimillonarias a personas en cuestin demeses y han hundido imperios exactamente con la misma rapidez. Aho-ra nos est comenzando a llegar la onda expansiva de un movimientoque pone en entredicho tcnicas que tenamos por buenas pero quecon el paso de los aos se estn revelando insostenibles. Si bien hacepoco gustbamos de disear complejas arquitecturas antes de escri-bir una sola lnea de cdigo que atacase directamente al problema delcliente, ahora, con la escasez de recursos econmicos y la mayor exi-gencia de los usuarios, la palabra agilidad va adquiriendo valores deeficacia, elegancia, simplicidad y sostenibilidad. Podemos beneficiar-nos de esta nueva corriente?. Saber adaptarse al cambio es esencialpara la evolucin. Nos adaptaremos a los cambios del entorno a tiem-po?. Todos esos pases de los que hablbamos son competidores enrealidad y lo sern cada vez ms dada la rpida expansin de Internet.No estaramos mejor si fuesen simplemente colegas?.

El software es una herramienta de presente y de futuro, creada parahacer ms agradable la vida de los usuarios. Y, aunque tienda a olvi-darse, tambin puede ser muy gratificante para los desarrolladores/a-nalistas. Tendremos que valernos de confianza y dedicacin junto congusto por el trabajo para alcanzar esta meta pero... Cmo podemos fo-mentar estas condiciones? Como ven, zarpamos con preguntas haciael fascinante mundo del desarrollo gil de software. Ser una travesaque nos ir descubriendo las claves de cmo hacer mejor software altiempo que nos sentimos ms satisfechos con nuestro trabajo. Es po-sible escribir software de mayor calidad con menos complicaciones yaportar ms a los negocios de las personas que lo utilizan.

Bienvenidos a bordo.

1.6. gil parece, pltano esSe est usando mucho la palabra gil17 y, por desgracia, no siempre

est bien empleada. Algunos aprovechan el trmino gil para referirsea cowboy programming (programacin a lo vaquero), es decir, hacer loque les viene en gana, como quieren y cuando quieren. Incluso hay em-presas que creen estar siguiendo mtodos giles pero que en realidad

17agile en ingls, pronunciada como yail

42

Captulo 1 1.7. Los roles dentro del equipo

no lo hacen (y no saben que no lo hacen). Existen mitos sobre el agi-lismo que dicen que no se documenta y que no se planifica o analiza.Tambin se dice que no se necesitan arquitectos pero, no es cierto, loque sucede es que las decisiones de arquitectura se toman en equipo.

El mal uso de la palabra gil causa malas y falsas ideas sobre lo queverdaderamente es. Llegado este punto, hay que mirar con lupa a quiendice que est siguiendo un desarrollo gil, tal como pasa con quien di-ce que vende productos ecolgicos. Hay quien cree que es gil porquehabla mucho con el cliente. Quizs por eso aparecieron las certifi-caciones en determinadas metodologas giles aunque, como muchasotras certificaciones, son slo papeles que no garantizan la profesiona-lidad de la persona certificada(confo en que las certificaciones de laagricultura ecolgica s sean autnticas). No nos debemos fiar de al-guien que ha asistido dos das a un curso de Scrum y ya dice ser unmaestro, a no ser que tenga aos de experiencia que le avalen.

Adoptar una metodologa supone aprendizaje y disciplina, como to-do lo que est bien hecho y, quienes realmente quieren subirse a es-te carro, necesitarn la ayuda de personas expertas en la materia. EnInternet existen multitud de grupos y foros donde se ofrece ayuda de-sinteresadamente y tambin existen profesionales que ofrecen forma-cin y entrenamiento en estas reas y se desplazan a cualquier partedel mundo para trabajar con grupos. En ingls hay bastante literaturaal respecto y es ms que recomendable leer varios libros, sobre todoaquellos cuyos autores firmaron el manifiesto gil.

Sobre recursos en castellano, actualmente hay mucho movimientoy grandes profesionales en Agile Spain (comunidad de mbito espaol)y en el Foro Agiles18 (la comunidad latinoamericana, muy extendidaen Argentina), que entre otras cosas, organiza el evento internacionalanual Agiles, as como multitud de openspaces bajo la marca AgileOpen.

1.7. Los roles dentro del equipo

Saber distinguir las obligaciones y limitaciones de cada uno de losroles del equipo ayuda a que el trabajo lo realicen las personas mejorcapacitadas para ello, lo que se traduce en mayor calidad. Roles distin-tos no necesariamente significa personas distintas, sobre todo en equi-pos muy reducidos. Una persona puede adoptar ms de un rol, puedeir adoptando distintos roles con el paso del tiempo, o rotar de rol a lo

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

43

1.7. Los roles dentro del equipo Captulo 1

largo del da. Hagamos un repaso a los papeles ms comunes en unproyecto software.

Dueo del producto

Cliente

Analista de negocio

Desarrolladores

Arquitectos

Administradores de Sistemas

Dueo del producto: Su misin es pedir lo que necesita (no el cmo,sino el qu) y aceptar o pedir correcciones sobre lo que se le entrega.

Cliente: Es el dueo del producto y el usuario final.Analista de negocio: Tambin es el dueo del producto porque tra-

baja codo a codo con el cliente y traduce los requisitos en tests deaceptacin para que los desarrolladores los entiendan, es decir, les ex-plica qu hay que hacer y resuelve sus dudas.

Desarrolladores: Toman la informacin del analista de negocio y de-ciden cmo lo van a resolver adems de implementar la solucin. Apar-te de escribir cdigo, los desarrolladores deben tener conocimientosavanzados sobre usabilidad y diseo de interfaces de usuario, aunquees conveniente contar con una persona experimentada para asistir encasos particulares. Lo mismo para la accesibilidad.

Administradores de sistemas: Se encargan de velar por los servido-res y servicios que necesitan los desarrolladores.

En el mundo anglosajn se habla mucho del arquitecto del software.El arquitecto es la persona capaz de tomar decisiones de diseo peroadems se le supone la capacidad de poder hablar directamente con elcliente y entender los requisitos de negocio. En lugar de un rol, es unapersona que adopta varios roles. En el agilismo todos los desarrollado-res son arquitectos en el sentido de que se les permite tomar decisio-nes de arquitectura conforme se va escribiendo o refactorizando cdigo.Hay que resaltar que se hacen revisiones de cdigo entre compaeros.Adems, ante decisiones complejas se pide opinin a desarrolladoresms experimentados. Recordemos que existe propiedad colectiva delcdigo y fluidez de conocimiento dentro del equipo.

Parece que no son tan complicados los roles... sin embargo, los con-fundimos a menudo. En nuestra industria del software hemos llegado alextremo de el que el cliente nos dice a nosotros, los ingenieros, cmo

44

Captulo 1 1.7. Los roles dentro del equipo

tenemos que hacer las cosas. Nos dice que quiere una pantalla contal botn y tales mens, que las tablas de la base de datos tienen ta-les columnas, que la base de datos tiene que ser Oracle... y nosotroslo aceptamos!. Sabemos que la escasez de profesionalidad ha tenidomucho que ver con esto y, el hecho de no tener claro cules son losroles de cada uno, hace que no seamos capaces de ponernos en nues-tro sitio. Quien dice el cliente, dice el dueo del producto o, llegado elcaso, el analista. De hecho, a menudo nos encontramos con analis-tas de negocio que, cuando hacen el anlisis, entregan al equipo dedesarrollo interfaces de usuario (pantallas dibujadas con Photoshop ocon cualquier otro diseador) adems de las tablas que creen que llevala base de datos y sus consultas. No habamos quedado en que eldueo del producto pide el qu y no dice el cmo?. Si la persona quetiene el rol de analista tambin tiene el rol de desarrollador, entonceses comprensible que disee una interfaz de usuario pero entonces nodebera pintarla con un programa de diseo grfico y endirsela a otro,sino trabajar en ella. Las pantallas no se disean al comienzo sino alfinal, cuando los requisitos de negocio ya se cumplen. Los requisitosson frases cortas en lenguaje natural que ejecuta una mquina auto-mticamente, ya que tienen forma de test, con lo que se sabe cundose han implementado. Si las pantallas se disean primero, se contami-na la lgica de negocio con la interpretacin que el diseador puedahacer de los requisitos y corremos el riesgo de escribir un cdigo sujetoa la UI en lugar de a los requisitos, lo cual lo hace difcil de modificarante cambios futuros en el negocio. El dueo del producto tampoco de-be disear las tablas de la base de datos a no ser que tambin adopteel rol de desarrollador pero, incluso as, las tablas son de los ltimos19elementos que aparecen en el proceso de implementacin del requi-sito, tal como ocurre con la interfaz grfica. Es decir, vamos desde eltest de aceptacin a tests de desarrollo que acabarn en la capa dedatos que pide persistencia. Pensamos en requisitos, implementamosobjetos, luego bajamos a tablas en una base de datos relacional y fi-nalmente le ponemos una carcasa a la aplicacin que se llama interfazgrfica de usuario. No al revs.

Si cada cual no se limita a ejercer su rol o roles, estaremos restrin-giendo a aquellos que saben hacer su trabajo, limitndoles de modoque no les dejamos hacer lo mejor que saben.

19Cuando la lgica de negocio es tan simple como guardar y recuperar un dato, es aceptableempezar por los datos.

45

1.8. Por qu nos cuesta comenzar a ser giles? Captulo 1

1.8. Por qu nos cuesta comenzar a ser giles?

Si el agilismo tiene tantas ventajas, Por qu no lo est practicandoya todo el mundo? La resistencia al cambio es uno de los motivos funda-mentales. Todava forma parte de nuestra cultura pensar que las cosasde toda la vida son las mejores. Ya se sabe... Si es de toda la vida,es como debe ser. Si los ingenieros y los cientficos penssemos as,entonces tendramos mquinas de escribir en lugar de computadoras(en el mejor de los casos). Existen fuertes razones histricas para sertan reticentes al cambio pero los que trabajamos con tecnologa pode-mos dar un paso al frente en favor del desarrollo. Ojo! Podemos dejarnuestro lado conservador para otros aspectos no tecnolgicos, que se-guro nos aportar muchos beneficios. No se trata de ser progresista niestamos hablando de poltica, limitmonos a cuestiones de ciencia ytecnologa.

Estamos preparados para darle una oportunidad a la innovacin onos quedamos con lo de toda la vida, aunque slo tenga una vida demedio siglo? (en el caso de programadores junior, slo un par de aos).Hemos aceptado una determinada forma de trabajar (en el mundo delsoftware) y nos parece inmutable an cuando esta industria todavaest en paales. Hemos llegado al punto en que la informtica ya noes una cuestin de matemticos sino de especialistas en cada una delas muchas reas de la informtica. Ni siquiera se han jubilado an losprimeros expertos en software de la historia.

Cuando era nio no se me pasaba por la cabeza que todo el mundollevase un telfono mvil encima y se comunicase desde cualquier lugar(hace slo 15 aos). Hace poco no nos imaginbamos que comprara-mos por Internet ni que las personas encontraran pareja a travs dela red. Los que han tenido confianza en el cambio y han sabido crecerorgnicamente trabajan en lo que les gusta y no tienen problemas parallegar a fin de mes. Las nuevas tecnologas son el tren de alta velocidadque une el presente con el futuro en un abrir y cerrar de ojos.

Ahora bien, aprender una nueva tcnica supone esfuerzo. Es naturalque nos d pereza dar los primeros pasos hacia el cambio y por esousamos mil excusas:

Que es antinatural...

Que est todo al revs...

Que es un caos...

Que no tenemos tiempo ahora para aprender eso...

46

Captulo 1 1.8. Por qu nos cuesta comenzar a ser giles?

Que no tenemos los conocimientos previos para empezar...

Que no sabemos por dnde empezar...

Maana empiezo...

Es que,... es que...

Nos comportamos como lo hara un fumador al que le dicen quedeje de fumar. La corriente popular en trminos de software no es ca-paz de evolucionar lo suficientemente rpido como para que sus teo-ras sean las mejores. Hay que plantearse si seguirla es buena idea oconviene cambiar de corriente. Esto es,... Prefiere la pastilla azul o laroja?20. No negaremos que hay que hacer una inversin en tiempo y es-fuerzo para aprender y poner en prctica una nueva forma de funcionar,la cuestin es que tal inversin se amortiza rpidamente. Si esperamosa maana para que se den las condiciones perfectas y empezar a sergiles, quizs nunca llegue el da. Acaso piensa que alguna vez ten-dr tiempo y dinero de sobra para todo lo que quiera? El plan es msbien parecido al de echar monedas a la hucha para irse de vacaciones;pequeas inversiones poco a poco. No se interprete que podemos ju-gar con el dinero del cliente, aprender no significa jugar con su dinero,vale?.

Si aceptamos que el software siempre se puede mejorar, el siguien-te paso es admitir que es positivo mantener un cierto aire inconformistaen nuestra actitud profesional. La autocrtica nos lleva a escribir cdigode mayor calidad y a reconocer nuestros errores. El juicio sano sobrenuestro trabajo nos gua en la bsqueda de mejoras estrategias y nosayuda a superar la pereza que nos produce la idea del cambio. Todoslos das aprendemos algo nuevo. El da que deje de ser as habr quereflexionar seriamente sobre si estamos ejerciendo bien el puesto deingenieros de software.

Este captulo ha sido compuesto a base de pinceladas procedentesdiversos temas. No pretende ser completo, ya que se podra escribirun libro entero sobre metodologas, sino solo establecer un contexto departida para el resto de captulos.

20Clebre escena de la pelcula Matrix en que Morfeo ofrece a Neo la posibilidad dedespertar del sueo. Neo escoge la roja. En este caso despertar del sueo significa cam-bia a mejor, a diferencia de lo que sucede en esta pelcula de ficcin. La Pastilla Ro-ja tambin es el ttulo de un libro sobre Software Libre escrito por Juan Toms Gar-ca(http://www.lapastillaroja.net/resumen_ejecutivo.html)

47

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

El Desarrollo Dirigido por Tests (Test Driven Development), al cualme referir como TDD, es una tcnica de diseo e implementacin desoftware incluida dentro de la metodologa XP. Coincido con Peter Pro-vost1 en que el nombre es un tanto desafortunado; algo como DiseoDirigido por Ejemplos hubiese sido quizs mas apropiado. TDD es unatcnica para disear software que se centra en tres pilares fundamen-tales:

La implementacin de las funciones justas que el cliente necesitay no ms2.

La minimizacin del nmero de defectos que llegan al software enfase de produccin.

La produccin de software modular, altamente reutilizable y pre-parado para el cambio.

Cuando empezamos a leer sobre TDD creemos que se trata de unabuena tcnica para que nuestro cdigo tenga una cobertura de testsmuy alta, algo que siempre es deseable, pero es realmente una herra-mienta de diseo que convierte al programador en un oficial de pri-mera. O, si no les gustan las metforas, convierte al programador endesarrollador3. TDD es la respuesta a las grandes preguntas de:

1http://www.youtube.com/watch?v=JMEO6T6gkAA2Evitamos desarrollar funcionalidad que nunca ser usada3http://www.ericsink.com/No_Programmers.html

48

Captulo 2

Cmo lo hago?, Por dnde empiezo?, Cmo s qu eslo que hay que implementar y lo que no?, Cmo escribirun cdigo que se pueda modificar sin romper funcionalidadexistente?

No se trata de escribir pruebas a granel como locos, sino de disearadecuadamente segn los requisitos.

Pasamos de pensar en implementar tareas, a pensar en ejemploscerteros que eliminen la ambigedad creada por la prosa en lenguajenatural (nuestro idioma). Hasta ahora estbamos acostumbrados a quelas tareas, o los casos de uso, eran las unidades de trabajo ms peque-as sobre las que ponerse a desarrollar cdigo. Con TDD intentamostraducir el caso de uso o tarea en X ejemplos, hasta que el nmero deejemplos sea suficiente como para describir la tarea sin lugar a malin-terpretaciones de ningn tipo.

En otras metodologas de software, primero nos preocupamos dedefinir cmo va a ser nuestra arquitectura. Pensamos en las clases deinfraestructura que van a homogeneizar la forma de trabajar en todos ycada uno de los casos, pensamos si vamos a usar un patrn Facade4y otro Singleton5 y una comunicacin mediante eventos, o DTOs, y unaclase central que va a hacer esto y aquello... Y si luego resulta queno necesitamos todo eso? Cunto vamos a tardar en darnos cuen-ta de ello? Cunto dinero vamos a malgastar? En TDD dejamos quela propia implementacin de pequeos ejemplos, en constantes itera-ciones, haga emerger la arquitectura que necesitamos usar. Ni ms nimenos. No es que nos despreocupemos por completo de las caracters-ticas tcnicas de la aplicacin a priori, es decir, lgicamente tendremosque saber si el desarrollo ser para un telfono mvil, para una webo para un pc de escritorio; ms que nada porque tenemos que elegirunas herramientas de desarrollo conformes a las exigencias del guin.Sin embargo, nos limitamos a escoger el framework correspondiente ya usar su arquitectura como base. Por ejemplo, si escogesemos Djan-go6 o ASP.NET MVC7, ya tendramos definida buena parte de la baseantes de empezar a escribir una sola lnea de cdigo. No es que tra-bajemos sin arquitectura, lgicamente, si en los requisitos est la in-teroperabilidad en las comunicaciones, tendremos q