Diseño Agil con TDD - Enero 2010

1,189 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,189
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diseño Agil con TDD - Enero 2010

  1. 1. Dise˜o Agil con TDD nCarlos Bl´ Jurado y colaboradores. e Prologo de Jos´ Manuel Beas e
  2. 2. Primera Edici´n, Enero de 2010 owww.iExpertos.comEl libro se ha publicado bajo la Licencia Creative Commons 2
  3. 3. ´Indice generalI Base Te´rica o 311. El Agilismo 33 1.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . . 35 1.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . . . . . 37 1.3. El manifiesto ´gil . . . . . . . . . . . . . . . . . . a . . . . . 38 1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico e a . . . . . 40 1.5. La situaci´n actual . . . . . . . . . . . . . . . . . o . . . . . 44 ´ 1.6. Agil parece, pl´tano es . . . . . . . . . . . . . . . a . . . . . 46 1.7. Los roles dentro del equipo . . . . . . . . . . . . . . . . . . 47 1.8. ¿Por qu´ nos cuesta comenzar a ser ´giles? . . . . e a . . . . . 492. ¿Qu´ es el Desarrollo Dirigido por Tests? (TDD) e 53 2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . . 56 2.1.1. Escribir la especificaci´n primero . . . . . . . . . . . o 56 2.1.2. Implementar el c´digo que hace funcionar el ejemplo o 57 2.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . . 58 2.2. Consideraciones y recomendaciones . . . . . . . . . . . . . . 60 2.2.1. Ventajas del desarrollador experto frente al junior . . 60 2.2.2. TDD con una tecnolog´ desconocida . . . . . . . . ıa 60 2.2.3. TDD en medio de un proyecto . . . . . . . . . . . . 613. Desarrollo Dirigido por Tests de Aceptaci´no (ATDD) 63 3.1. Las historias de usuario . . . . . . . . . . . . . . . . . . . . 64 3.2. Qu´ y no C´mo . . . . . e o . . . . . . . . . . . . . . . . . . . 68 3.3. ¿Est´ hecho o no? . . . . a . . . . . . . . . . . . . . . . . . . 70 3.4. El contexto es esencial . . . . . . . . . . . . . . . . . . . . 71 3
  4. 4. ´INDICE GENERAL ´ INDICE GENERAL4. Tipos de test y su importancia 73 4.1. Terminolog´ en la comunidad TDD ıa . . . . . . . . . . . . . 74 4.1.1. Tests de Aceptaci´n . . . . . o . . . . . . . . . . . . . 75 4.1.2. Tests Funcionales . . . . . . . . . . . . . . . . . . . 76 4.1.3. Tests de Sistema . . . . . . . . . . . . . . . . . . . 76 4.1.4. Tests Unitarios . . . . . . . . . . . . . . . . . . . . 78 4.1.5. Tests de Integraci´n . . . . . o . . . . . . . . . . . . . 805. Tests unitarios y frameworks xUnit 83 5.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . . . 846. Mocks y otros dobles de prueba 95 6.1. Cu´ndo usar un objeto real, un stub o un mock . . . . . . . 97 a 6.2. La met´fora Record/Replay . . . . . . . . . . . . . . . . . . 108 a7. Dise˜o Orientado a Objetos n 111 7.1. Dise˜o Orientado a Objetos (OOD) . . . . . n . . . . . . . . 111 7.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . . 112 7.2.1. Single Responsibility Principle (SRP) . . . . . . . . . 113 7.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . . 113 7.2.3. Liskov Substitution Principle (LSP) . . . . . . . . . 114 7.2.4. Interface Segregation Principle (ISP) . . . . . . . . . 114 7.2.5. Dependency Inversi´n Principle (DIP) o . . . . . . . . 115 7.3. Inversi´n del Control (IoC) . . . . . . . . . . o . . . . . . . . 116II Ejercicios Pr´cticos a 1198. Inicio del proyecto - Test Unitarios 1219. Continuaci´n del proyecto - Test Unitarios o 15710.Fin del proyecto - Test de Integraci´n o 231 10.1. La frontera entre tests unitarios y tests de integraci´n o . . . . 233 10.2. Dise˜o emergente con un ORM . . . . . . . . . . . . n . . . . 243 10.2.1. Dise˜ando relaciones entre modelos . . . . . n . . . . 246 10.3. La unificaci´n de las piezas del sistema . . . . . . . . o . . . . 24711.La soluci´n en versi´n Python o o 24912.Antipatrones y Errores comunes 289 4
  5. 5. ´INDICE GENERAL ´ INDICE GENERALA. Integraci´n Continua (CI) o 297 A.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . o . . . . 297 A.2. Pr´cticas de integraci´n continua . . . . . . . . . . . a o . . . . 299 A.2.1. Automatizar la construcci´n . . . . . . . . . o . . . . 299 A.2.2. Los test forman parte de la construcci´n . . . o . . . . 300 A.2.3. Subir los cambios de manera frecuente . . . . . . . . 302 A.2.4. Construir en una m´quina de integraci´n . . . a o . . . . 302 A.2.5. Todo el mundo puede ver lo que est´ pasando a . . . . 303 A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . . 304 A.3. IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . . 304 A.4. Conclusi´n . . . . . . . . . . . . . . . . . . . . . . . o . . . . 305 5
  6. 6. ´INDICE GENERAL ´ INDICE GENERAL 6
  7. 7. A la memoria de nuestro querido gatito Lito, que vivi´ con total atenci´n y o o entrega cada instante de su vida 7
  8. 8. 8
  9. 9. Pr´logo o ´ Erase una vez que se era, un lejano pa´ donde viv´ dos cerditos, Pablo ıs ıany Adri´n que, adem´s, eran hermanos. Ambos eran los cerditos m´s listos a a ade la granja y, por eso, el gallo Iv´n (el gerente de la misma) organiz´ una a oreuni´n en el establo, donde les encarg´ desarrollar un programa de ordenador o opara controlar el almac´n de piensos. Les explic´ qu´ quer´ saber en todo e o e ıamomento: cu´ntos sacos de grano hab´ y qui´n met´ y sacaba sacos de a ıa e ıagrano del almac´n. Para ello s´lo ten´ un mes pero les advirti´ que, en e o ıan ouna semana, quer´ ya ver algo funcionando. Al final de esa primera semana, ıaeliminar´ a uno de los dos. ıa Adri´n, que era el m´s joven e impulsivo, inmediatamente se puso manos a aa la obra. “¡No hay tiempo que perder!”, dec´ Y empez´ r´pidamente a ıa. o aescribir l´ıneas y l´ ıneas de c´digo. Algunas eran de un reciente programa que ohab´ ayudado a escribir para la guarder´ de la vaca Paca. Adri´n pens´ que ıa ıa a ono eran muy diferentes un almac´n de grano y una guarder´ En el primero e ıa.se guardan sacos y en el segundo, peque˜os animalitos. De acuerdo, ten´ n ıaque 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 l´ ınea de c´digo comenz´ acor- o odando con Iv´n dos cosas: qu´ era exactamente lo que podr´ ver dentro de a e ıauna semana y c´mo sabr´ que, efectivamente, estaba terminada cada cosa. o ıaIv´n quer´ conocer, tan r´pido como fuera posible, cu´ntos sacos de grano a ıa a ahab´ en cada parte del almac´n porque sospechaba que, en algunas partes del ıa emismo, se estaban acumulando sacos sin control y se estaban estropeando.Como los sacos entraban y sal´ constantemente, no pod´ saber cu´ntos ıan ıa ahab´ y d´nde estaban en cada instante, as´ que acordaron ir contabiliz´ndo- ıa o ı alos por zonas y apuntando a qu´ parte iba o de qu´ parte ven´ cada vez e e ıa,que entrara o saliera un saco. As´ en poco tiempo podr´ tener una idea ı, ıanclara del uso que se estaba dando a las distintas zonas del almac´n. e 9
  10. 10. Pr´logo o Mientras Adri´n adelantaba a Pablo escribiendo muchas l´ a ıneas de c´digo, oPablo escrib´ primero las pruebas automatizadas. A Adri´n eso le parec´ ıa a ıauna p´rdida de tiempo. ¡S´lo ten´ una semana para convencer a Iv´n! e o ıan a Al final de la primera semana, la demo de Adri´n fue espectacular, ten´ a ıaun control de usuarios muy completo, hizo la demostraci´n desde un m´vil y o oense˜o, adem´s, las posibilidades de un generador de informes muy potente n´ aque hab´ desarrollado para otra granja anteriormente. Durante la demostra- ıaci´n hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa opero, salvo eso, todo fue genial. La demostraci´n de Pablo fue mucho m´s o amodesta, pero cumpli´ con las expectativas de Iv´n y el programa no fall´ en o a oning´n momento. Claro, todo lo que ense˜o lo hab´ probado much´ u n´ ıa ısimasveces antes gracias a que hab´ automatizado las pruebas. Pablo hac´ TDD, ıa ıaes decir, nunca escrib´ una l´ ıa ınea de c´digo sin antes tener una prueba que le oindicara un error. Adri´n no pod´ creer que Pablo hubiera gastado m´s de la a ıa amitad de su tiempo en aquellas pruebas que no hac´ m´s que retrasarle a ıan ala hora de escribir las funcionalidades que hab´ pedido Iv´n. El programa de ıa aAdri´n ten´ muchos botones y much´ a ıa ısimas opciones, probablemente muchasm´s de las que jam´s ser´ necesarias para lo que hab´ pedido Iv´n, pero a a ıan ıa aten´ un aspecto “muy profesional”. ıa Iv´n no supo qu´ hacer. La propuesta de Pablo era muy robusta y hac´ a e ıajusto lo que hab´ acordado. La propuesta de Adri´n ten´ cosillas que pulir, ıan a ıapero era muy prometedora. ¡Hab´ hecho la demostraci´n desde un m´vil! ıa o oAs´ que les propuso el siguiente trato: “Os pagar´ un 50 % m´s de lo que ı e ainicialmente hab´ ıamos presupuestado, pero s´lo a aquel de los dos que me ohaga el mejor proyecto. Al otro no le dar´ nada.”. Era una oferta complicada eporque, por un lado, el que ganaba se llevaba mucho m´s de lo previsto. Muy atentador. Pero, por el otro lado, corr´ el riesgo de trabajar durante un mes ıancompletamente gratis. Mmmmm. Adri´n, tan impulsivo y arrogante como siempre, no dud´ ni un instante. a o“¡Trato hecho!”, dijo. Pablo explic´ que aceptar´ s´lo si Iv´n se compro- o ıa o amet´ a colaborar como lo hab´ hecho durante la primera semana. A Iv´n le ıa ıa apareci´ razonable y les convoc´ a ambos para que le ense˜aran el resultado o o nfinal en tres semanas. Adri´n se march´ pitando y llam´ a su primo Sixto, que sab´ mucho a o o ıay le asegurar´ la victoria, aunque tuviera que darle parte de las ganancias. ıaAmbos se pusieron r´pidamente manos a la obra. Mientras Adri´n arreglaba a alos defectillos encontrados durante la demo, Sixto se encarg´ de dise˜ar unao narquitectura que permitiera enviar mensajes desde el m´vil hasta un webser- ovice que permit´ encolar cualquier operaci´n para ser procesada en paralelo ıa opor varios servidores y as´ garantizar que el sistema estar´ en disposici´n de ı ıa odar servicio 24 horas al d´ los 7 d´ de la semana. ıa ıas 10
  11. 11. Pr´logo o Mientras tanto, Pablo se reuni´ con Iv´n y Bernardo (el encargado del o aalmac´n) para ver cu´les deber´ ser las siguientes funcionalidades a desarro- e a ıanllar. Les pidi´ que le explicaran, para cada petici´n, qu´ beneficio obten´ la o o e ıagranja con cada nueva funcionalidad. Y as´ poco a poco, fueron elaborando ı,una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas.A continuaci´n, Pablo fue, tarjeta a tarjeta, discutiendo con Iv´n y Bernardo o acu´nto tiempo podr´ tardar en terminarlas. De paso, aprovech´ para anotar a ıa oalgunos criterios que luego servir´ para considerar que esa funcionalidad ıanestar´ completamente terminada y eliminar alguna ambig¨edad que fuera ıa usurgiendo. Cuando Pablo pens´ que, por su experiencia, no podr´ hacer m´s o ıa atrabajo que el que ya hab´ discutido, dio por concluida la reuni´n y se ıan odispuso a trabajar. Antes que nada, resolvi´ un par de defectos que hab´ o ıansurgido durante la demostraci´n y le pidi´ a Iv´n que lo validara. A conti- o o anuaci´n, se march´ a casa a descansar. Al d´ siguiente, cogi´ la primera de o o ıa olas tarjetas y, como ya hab´ hecho durante la semana anterior, comenz´ a ıa oautomatizar los criterios de aceptaci´n acordados con Iv´n y Bernardo. Y lue- o ago, fue escribiendo la parte del programa que hac´ que se cumplieran esos ıacriterios de aceptaci´n. Pablo le hab´ pedido ayuda a su amigo Hudson, un o ıacoyote vegetariano que hab´ venido desde Am´rica a pasar el invierno. Hud- ıa eson no sab´ programar, pero era muy r´pido haciendo cosas sencillas. Pablo ıa ale encarg´ que comprobara constantemente los criterios de aceptaci´n que o o´l hab´ automatizado. As´ cada vez que Pablo hac´ alg´n cambio en sue ıa ı, ıa uprograma, avisaba a Hudson y este hac´ una tras otra, todas las pruebas de ıa,aceptaci´n que Pablo iba escribiendo. Y cada vez hab´ m´s. ¡Este Hudson o ıa aera realmente veloz e incansable! A medida que iba pasando el tiempo, Adri´n y Sixto ten´ cada vez a ıanm´s problemas. Terminaron culpando a todo el mundo. A Iv´n, porque no a ales hab´ explicado detalles important´ ıa ısimos para el ´xito del proyecto. A la evaca Paca, porque hab´ incluido una serie de cambios en el programa de la ıaguarder´ que hac´ que no pudieran reutilizar casi nada. A los inventores de ıa ıalos SMS y los webservices, porque no ten´ ni idea de c´mo funciona una ıan ogranja. Eran tantos los frentes que ten´ abiertos que tuvieron que prescindir ıandel env´ de SMS y buscaron un generador de p´ginas web que les permitiera ıo adibujar el flujo de navegaci´n en un gr´fico y, a partir de ah´ generar el o a ı,esqueleto de la aplicaci´n. ¡Eso seguro que les ahorrar´ mucho tiempo! Al o ıapoco, Sixto, harto de ver que Adri´n no valoraba sus aportaciones y que ya ano se iban a usar sus ideas para enviar y recibir los SMS, decidi´ que se omarchaba, a´n renunciando a su parte de los beneficios. Total, ´l ya no cre´ u e ıaque fueran a ser capaces de ganar la competici´n. o Mientras tanto, Pablo le pidi´ un par de veces a Iv´n y a Bernardo que le o avalidaran si lo que llevaba hecho hasta aquel momento era de su agrado y les 11
  12. 12. Pr´logo ohizo un par de demostraciones durante aquellas 3 semanas, lo que sirvi´ para ocorregir algunos defectos y cambiar algunas prioridades. Iv´n y Bernardo aestaban francamente contentos con el trabajo de Pablo. Sin embargo, entreellos comentaron m´s de una vez: “¿Qu´ estar´ haciendo Adri´n? ¿C´mo lo a e a a ollevar´?”. a Cuando se acercaba la fecha final para entregar el programa, Adri´n se aqued´ sin dormir un par de noches para as´ poder entregar su programa. o ıPero eran tantos los defectos que hab´ ido acumulando que, cada vez que ıaarreglaba una cosa, le fallaba otra. De hecho, cuando lleg´ la hora de la odemostraci´n, Adri´n s´lo pudo ense˜ar el programa instalado en su port´til o a o n a(el unico sitio donde, a duras penas, funcionaba) y fue todo un desastre: ´mensajes de error por todos sitios, comportamientos inesperados... y lo peorde todo: el programa no hac´ lo que hab´ acordado con Iv´n. ıa ıan a Pablo, sin embargo, no tuvo ning´n problema en ense˜ar lo que llevaba u nfuncionando desde hac´ mucho tiempo y que tantas veces hab´ probado. Por ıa ıasi acaso, dos d´ antes de la entrega, Pablo hab´ dejado de introducir nuevas ıas ıacaracter´ısticas al programa porque quer´ centrarse en dar un buen manual de ıausuario, que Iv´n hab´ olvidado mencionar en las primeras reuniones porque a ıadaba por sentado que se lo entregar´ Claro, Adri´n no hab´ tenido tiempo ıan. a ıapara nada de eso. Moraleja: Adem´s de toda una serie de buenas pr´cticas y un proceso de desarrollo a a´gil, Pablo hizo algo que Adri´n despreci´: acord´ con Iv´n (el cliente) y cona a o o aBernardo (el usuario) los criterios mediante los cu´les se comprobar´ que a ıacada una de las funcionalidades estar´ bien acabada. A eso que solemos lla- ıamar “criterios de aceptaci´n”, Pablo le a˜adi´ la posibilidad de automatizar o n osu ejecuci´n e incorporarlos en un proceso de integraci´n continua (que es o olo que representa su amigo Hudson en este cuento). De esta manera, Pabloestaba siempre tranquilo de que no estaba estropeando nada viejo con cadanueva modificaci´n. Al evitar volver a trabajar sobre asuntos ya acabados, oPablo era m´s eficiente. En el corto plazo, las diferencias entre ambos en- afoques no parecen significativas, pero en el medio y largo plazo, es evidenteque escribir las pruebas antes de desarrollar la soluci´n es mucho m´s eficaz o ay eficiente. En este libro que ahora tienes entre tus manos, y despu´s de este inusual epr´logo, te invito a leer c´mo Carlos explica bien clarito c´mo guiar el desa- o o orrollo de software mediante la t´cnica de escribir antes las pruebas (m´s e aconocido como TDD). 12
  13. 13. Agradecimientos Una vez o´ a un maestro zen decir que la gratitud que expresa una per- ısona denota su estado moment´neo de bienestar consigo misma. Estoy muy acontento de ver que este proyecto que se empez´ hace casi a˜o y medio, ha o nconcluido con un resultado tan gratificante. Tengo que agradecer cosas a miles de personas pero para no extendermedemasiado, lo har´ hacia los que han tenido una relaci´n m´s directa con el e o alibro. En primer lugar tengo que agradecer a D´cil Casanova que haya sido ala responsable de calidad n´mero uno en el proyecto. Sin ella este libro no use hubiera escrito de esta forma y en este momento. Quiz´s no se hubiese aescrito nunca. No s´lo tengo que agradecer todo lo much´ o ısimo que me aportaen lo personal sino que adem´s me anim´ constantemente a no publicar el a olibro hasta que estuviera hecho lo mejor posible. Ha revisado mi redacci´n ocorrigiendo mil faltas de ortograf´ y signos de puntuaci´n. ıa o El toque de calidad que dan los dem´s coautores al libro, es tambi´n un a edetallazo. Adem´s de escribir texto han sido buenos revisores. Estoy profun- adamente agradecido a Juan Guti´rrez Plaza por haber escrito el cap´ e ıtulo 11y por haber hecho correcciones desde la primera revisi´n del libro hasta la oultima. Ha sido un placer discutir juntos tantos detalles t´cnicos. Gracias a´ eFran Reyes Perdomo tenemos un gran ap´ndice sobre Integraci´n Cont´ e o ınuaque de no haber sido por ´l no estar´ en el libro, con lo importante que es e ıaesta pr´ctica. Mil gracias Fran. Gregorio Mena es el responsable de que el acap´ıtulo 1 no sea un completo desastre. Ha sido para m´ el m´s dif´ de ı a ıcilescribir de todo el libro y a ning´n revisor le acababa de convencer. Gregorio uha refactorizado medio cap´ ıtulo d´ndole un toque mucho m´s serio. Espero a aque sigamos trabajando juntos Gregorio :-) Para terminar con los coautoresquiero agradecer a Jos´ Manuel Beas que haya escrito el pr´logo del libro a e opesar de lo muy ocupado que est´ liderando la comunidad ´gil espa˜ola y a a n 13
  14. 14. Agradecimientoshaciendo de padre de familia. Un bonito detalle JM ;-D A continuaci´n quiero agradecer a la decena de personas que han le´ o ıdolas revisiones del libro previas a la publicaci´n y que han aportado correccio- ones, palabras de ´nimo e incluso texto. Agradecimientos especiales a Esteban aManchado Vel´zquez que tiene much´ a ısimo que ver con la calidad de la redac-ci´n y que ha sido uno de los revisores m´s constantes. Yeray Darias adem´s o a ade revisar, escribi´ el cap´ o ıtulo que le ped´ sobre DDD, aunque finalmente ıqueda para un libro futuro. Mi buen amigo Eladio L´pez de Luis ha dejado oalg´n comentario en cada revisi´n que he ido enviando. Alberto Rodr´ u o ıguezLozano ha sido una de las personas m´s influyentes en las correcciones del acap´ıtulo 9, aportando comentarios t´cnicos de calidad. No puedo olvidar al eresto de revisores que han seguido el libro en distintas etapas aportandotambi´n comentarios muy brillantes: N´stor Bethencourt, Juan Jorge P´rez e e eL´pez, Pablo Rodr´ o ıguez S´nchez, Jos´ Ram´n D´ Jose M. Rodr´ a e o ıaz, ıguez dela Rosa, V´ ıctor Rold´n y N´stor Salceda. Tambi´n agradezco a todas las a e epersonas que han le´ alguna de estas revisiones previas y me han enviado ıdoemails personales de agradecimiento. Hadi Hariri me influenci´ mucho para que partiese el libro en dos y dejase opara ´ste, solo aquellos temas de relaci´n directa con TDD. e o Ahora, m´s all´ de los que han tenido relaci´n directa con el libro, quiero a a oagradecer a Rodrigo Trujillo, ex director de la Oficina 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 d´ porque ıa,durante el a˜o que trabaj´ ah´ aprend´ toneladas de cosas. Rodrigo es una de n e ı ılas personas que m´s se mueve en la ULL; no deja de intentar abrir puertas aa los estudiantes que est´n terminado ni de preocuparse por la calidad de su auniversidad. Gracias tambi´n a Jos´ Lu´ Roda, Pedro Gonz´lez Yanes y Jes´s Alberto e e ıs a uGonz´lez por abrirme las puertas de la facultad de inform´tica y tambi´n por a a epermitirme que impartiese mi primer curso completo de TDD. De la facultadtengo tambi´n que agradecer a Marcos Colebrook que me diese el empuj´n e oque necesitaba para terminar la carrera, que la ten´ casi abandonada. Sin ıaMarcos 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 resultadofinal del libro ya que he volcado en ´l muchas de sus dudas y comentarios et´ ıpicos. Gracias a los dos grupos que he tenido en Tenerife y al de Sevilla,todos en 2009. Menci´n especial a las personas que ayudaron a que saliesen o ´adelante: Alvaro Lobato y los ya citados Gregorio, Pedro y Roda. 14
  15. 15. Agradecimientos Gracias a todos los que est´n promoviendo XP en Espa˜a. A saber: Al- a nfredo Casado, Xavier Gost, Leo Antol´ Agust´ Yag¨e, Eric Mignot, Jorge ı, ın uJim´mez, Iv´n P´rraga, Jorge Uriarte, Jes´s P´rez, David Esmerodes, Luismi e a a u eCavall´, David Calavera, Ricardo Rold´n y tantos otros profesionales de la e acomunida Agile Spain, entre los cuales est´n los coautores y revisores de este alibro. Y tambi´n a los que est´n promoviendo XP en Latinoam´rica: Fabi´n e a e aFigueredo, Carlos Peix, Angel L´pez, Carlos Lone y tantos otros. Y al pibe oque vos viste nos rrre-ayud´ a traer el Agile Open a Espa˜a, Xavier Quesada o n;-) Alfredo Casado adem´s ha escrito la sinopsis del libro. a Quiero saludar a todas las personas con las que he trabajado en mi pasopor las muchas empresas en que he estado. De todos he aprendido algo. Gra-cias a los que me han apoyado y gracias tambi´n a los que me han querido etapar, 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. Tambi´n he aprendido mucho ede todos aquellos desarrolladores con los que he trabajado en proyectos opensource, en mi tiempo libre. A quienes han confiado en m´ para impartir cursos de materias diversas, ıporque han sido claves para que desarrolle mi capacidad docente; Agust´ ınBenito, Academia ESETEC, Armando Fumero, Innova7 y Rodrigo Trujillo. Agradecimientos tambi´n a Pedro Gracia Fajardo, una de las mentes em´s brillantes que he conocido. Un visionario. Pedro fue qui´n me habl´ por a e oprimera vez de XP en 2004. En aquel entonces nos cre´ ıamos que ´ramos ´giles e aaunque en realidad lo est´bamos haciendo fatal. La experiencia sirvi´ para a oque yo continuase investigando sobre el tema. Gracias a la comunidad TDD internacional que se presenta en un grupode discusi´n de Yahoo. Aunque ellos no leer´n estas l´ o a ıneas por ser en espa˜ol, nquiero dejar claro que sin su ayuda no hubiese sabido resolver tantos proble-mas t´cnicos. Gracias a Kent Beck y Lasse Koskela por sus libros, que han esido para m´ fuente de inspiraci´n. ı o Aprovecho para felicitar a Roberto Canales por su libro, Inform´tica aProfesional[13]. Es una pena que me haya puesto a leerlo cuando ya ten´ ıaescrito este libro, a pocos d´ de terminar el proyecto. Si lo hubiese le´ en ıas ıdooctubre, cuando Leo me lo regal´, me hubiese ahorrado bastantes p´rrafos o ade la parte te´rica. Es un pedazo de libro que recomiendo a todo el mundo. oGracias Roberto por brindarnos un libro tan brillante. Un libro, un amigo. Gracias a Angel Medinilla, Juan Palacio, Xavi Albaladejo y Rodrigo Co-rral, por entrenar a tantos equipos ´giles en nuestro pa´ Angel adem´s me a ıs. aregala 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. 16. Agradecimientosno ser´ posible. A D´cil de nuevo por todo lo much´ ıa a ısimo que me aportadiariamente. A mis padres por traerme al mundo y ense˜arme tantas cosas. nA mis hermanas por querer tanto a su hermano mayor. A mis primos. Ami t´ Tina por acogerme en su casa durante mis a˜os de universidad y ıa ndarme la oportunidad de estudiar una carrera, ya que mis padres no pod´ ıancostearmelo. Ella me ayuda siempre que lo necesito. A mis abuelos por estarsiempre ah´ como mis segundos padres. ı, 16
  17. 17. Autores del libroCarlos Bl´ Jurado e Nac´ en C´rdoba en 1981, hijo de cordobeses ı o pero cuando ten´ 4 a˜os emigramos a Lanza- ıa n rote y, salvo algunos a˜os intercalados en los n que viv´ en C´rdoba, la mayor parte de mi vida ı o la he pasado en Canarias. Primero en Lanzarote y despu´s en Tenerife. e Mi primer apellido significa trigo en franc´s. Lo e trajo un franc´s al pueblo cordob´s de La Vic- e e toria en tiempos de Carlos III. Cuando ten´ 6 a˜os mi padre trajo a casa un ıa n 8086 y aquello me fascin´ tanto que supe que o me quer´ dedicar a trabajar con ordenadores ıa desde entonces. He tenido tambi´n Amiga 500, e Amiga 1200, y luego unos cuantos PC, desde el AMD K6 hasta el Intel Core Duo de hoy. Soy ingeniero t´cnico en inform´tica de sistemas. Para m´ el t´ e a ı ıtulo noes ninguna garant´ de profesionalidad, m´s bien hago un balance negativo ıa ade mi paso por la Universidad, pero quer´ ponerlo aqu´ para que los que ıa ıpadecen de titulitis vean que el que escribe es titulado. La primera vez que gan´ dinero con un desarrollo de software fue en e2001. Poco despu´s de que instalase Debian GNU/Linux en mi PC. En 2003 eentr´ de lleno en el mercado laboral. Al principio trabaj´ administrando sis- e etemas adem´s de programar. a En 2005 se me ocurri´ la genial idea de montar una empresa de desarrollo ode software a medida con mis colegas. Sin tener suficiente experiencia comodesarrollador y ninguna experiencia como empresario ni comercial, fue toda 17
  18. 18. Autores del librouna aventura sobrevivir durante los dos a˜os que permanec´ en la empresa. n ıFueron dos a˜os equivalentes a cuatro o cinco trabajando en otro sitio. Ver nel negocio del software desde todos los puntos de vista, me brind´ la opor- otunidad de darme cuenta de muchas cosas y valorar cuestionas que antesno valoraba. Aprend´ que no pod´ tratar al cliente como si fuera un tester. ı ıaNo pod´ limitarme a probar las aplicaciones 10 minutos a mano antes de ıaentregarlas y pensar que estaban hechas. Aprend´ que la venta era m´s deci- ı asiva que el propio software. Tambi´n aprend´ cosas feas como que Hacienda e ıno somos todos, que los concursos p´blicos se ama˜an, que el notario da u nm´s miedo que el dentista, que el pez grande se come al peque˜o y muchas a notras. Al final me d´ cuenta de que la odisea me sobrepasaba y no era capaz ıde llevar la empresa a una posici´n de estabilidad donde por f´ dejase de o ınamanecerme sentado frente a la pantalla. Cansado de los morosos y de que laadministraci´n p´blica nos tuviera sin cobrar meses y meses, mientras estaba o ucon el agua al cuello, en 2007 me mand´ a mudar a Irlanda para trabajar ecomo desarrollador. Aprend´ lo importante que era tener un equipo de QA1 y ıme volqu´ con los tests automatizados. Llegu´ a vivir el boom de los sueldos e een Dublin, cobrando 5000 euros mensuales y sin hacer ni una sola hora extra.En 2008 regres´ a Tenerife. e En la actualidad he vuelto a emprender. Desarrollo software profesional-mente de manera vocacional. Mi esp´ ıritu emprendedor me lleva a poner enmarcha nuevas ideas en la nube. Adem´s me dedico a formar a desarrolladores aimpartiendo cursos sobre TDD, c´digo limpio, metodolog´ y herramientas o ıade programaci´n. En lugar de intentar trabajar en mi empresa, trabajo para ola empresa2 , cuya web es www.iExpertos.com Habitualmente escribo en www.carlosble.com y en el blog de iExpertos. He escrito la mayor parte del libro con la excepci´n de los fragmentos oque nos han regalado los dem´s autores. a 1 Quality Assurance 2 El matiz viene del libro, El Mito del Emprendedor, de Michael E. Gerber 18
  19. 19. Autores del libroJose Manuel Beas En 2008 decidi´ aprovechar sus circunstancias o personales para tomarse un respiro, mirar atr´s, a a los lados y, sobre todo, hacia adelante. Y as´ ı, aprovech´ ese tiempo para mejorar su forma- o ci´n en temas como Scrum asistiendo al cur- o so de Angel Medinilla. Pero tambi´n quiso po- e ner su peque˜o granito de arena en el desarro- n llo y la difusi´n de Concordion, una herramien- o ta de c´digo abierto para realizar pruebas de o aceptaci´n, y rellenar su “caja de herramientas” o con cosas como Groovy y Grails. Pero sobre to- do vi´ que merec´ la pena poner parte de su o ıa energ´ en revitalizar una vieja iniciativa llama- ıa da Agile Spain y buscar a todos aquellos que, co- mo ´l, estuvieran buscando maneras mejores de e hacer software. Y vaya que si los encontr´. Ac- o tualmente es el Presidente de la asociaci´n Agi- o le Spain, que representa a la comunidad agilista en Espa˜a y organizadora de los Agile Open n Spain y las Conferencias Agile Spain. Tambi´n e participa en la elaboraci´n de los podcasts de o Podgramando.es, una iniciativa de “agilismo.es powered by iExpertos.com”. Puedes localizar- lo f´cilmente a trav´s del portal agilismo.es, en a e la lista de correo de Agile Spain o en su blog personal http://jmbeas.iexpertos.com. 19
  20. 20. Autores del libroJuan Guti´rrez e Escribir, he escrito poco, pero aprender,Plaza much´ ısimo. He intentado hacer algo con sen- tido con mi oxidado Python en el cap´ ıtulo 11 aunque m´s que escribir, ha sido discutir y re- a discutir con Carlos sobre cual era la mejor forma de hacer esto y aquello (siempre ha ganado ´l).e Tambi´n he sacado del ba´l de los recuerdos mi e u LaTeX y he revisado mucho. Cuando no estoy discutiendo con la gente de Agile Spain, trabajo como “Agile Coach” en F-Secure donde intento ayudar a equipos de Finlandia, Malasia, Rusia y Francia en su transici´n a las metodolog´ o ıas a ´giles (tanto en gesti´n como en pr´cticas de o a software entre las que se incluye, por supues- to, TDD). ¿Pero c´mo he llegado hasta aqu´ o ı? Mi devoci´n los ordenadores me llev´ a estu- o o diar la carrera de ingenier´ en inform´tica en ıa a la UPM de Madrid. Trabaj´ en Espa˜a por un e n tiempo antes de decidir mudarme a Finlandia en el 2004 para trabajar en Nokia. En las lar- gas y oscuras “tardes” del invierno Finland´s e estudi´ un master en “industrial management” e antes de cambiar a F-Secure. Cuando el tiempo lo permite, escribo en http://agilizar.esFran Reyes Perdo- Soy un apasionado desarrollador de software in-mo teresado en “pr´cticas ´giles”. Llevo cerca de a a 4 a˜os trabajando para la r´ n ıgida Administra- ci´n p´blica con un fantastico equipo. Conoc´ a o u ı Carlos Bl´ en un provechoso curso de TDD que e imparti´ para un grupo de compa˜eros. Entre o n cervezas (una fase importante para asimilar lo aprendido), compartimos ideas y experiencias del mundo del software, y me habl´ adem´s o a del proyecto en el que se encontraba embar- cado, en el cual me brind´ la oportunidad de o participar con un peque˜o ap´ndice sobre inte- n e graci´n continua. Una pr´ctica, que intentamos, o a forme parte del d´ a d´ en nuestros proyectos. ıa ıa http://es.linkedin.com/in/franreyesperdomo 20
  21. 21. Autores del libroGregorio Mena Mi corta vida profesional ha sido sufi- ciente para dar sentido a la frase de Ho- racio “Ning´n hombre ha llegado a la u excelencia en arte o profesi´n alguna, o sin haber pasado por el lento y doloroso proceso de estudio y preparaci´n”. Aun- o que en mi caso el camino no es doloro- so, sino apasionante. Siguiendo esta fi- losof´ intento formarme y fomentar la ıa, formaci´n, por lo que he organizado un o curso de TDD impartido con gran acier- to por Carlos Ble y voy a participar en futuras ediciones. Trabajo desde iExper- tos para que entre todos hagamos posi- ble el primer curso de Scrum en Cana- rias, pues tambi´n colaboro con la plata- e forma ScrumManager. Ha sido esta for- ma de ver nuestra profesi´n la que me o llev´ a colaborar con Carlos en este li- o bro. Pensaba aportar algo, pero lo cier- to es que lo que haya podido aportar no tiene comparaci´n con lo que he tenido o la suerte de recibir. Por ello debo dar a Carlos las gracias por ofrecerme esta oportunidad y por el esfuerzo que ha he- cho para que este libro sea una realidad para todos los que vemos en la formaci´n o continua el camino al ´xito. e Habitualmente escribo en http://eclijava.blogspot.com. 21
  22. 22. Autores del libro22
  23. 23. Convenciones y Estructura Este libro contiene numerosos bloques de c´digo fuente en varios len- oguajes de programaci´n. Para hacerlos m´s legibles se incluyen dentro de o arect´ngulos que los separan del resto del texto. Cuando se citan elementos ade dichos bloques o sentencias del lenguaje, se usa este tipo de letra. A lo largo del texto aparecen referencias a sitios web en el pie de p´gina. aTodas ellas aparecen recopiladas en la p´gina web del libro. a Las referencias bibliogr´ficas tienen un formato como este:[3]. Las ultimas a ´p´ginas del libro contienen la bibliograf´ detallada correspondiente a todas a ıaestas referencias. Otros libros de divulgaci´n repiten determinadas ideas a lo largo de varios ocap´ıtulos con el fin de reforzar los conceptos. En la era de la infoxicaci´n3 otal repetici´n sobra. He intentado minimizar las repeticiones de conceptos opara que el libro se pueda revisar r´pidamente, por lo que es recomendable auna segunda lectura del mismo para quienes desean profundizar en la materia.Ser´ como ver una pel´ a ıcula dos veces: en el segundo pase uno aprecia muchosdetalles que en el primero no vio y su impresi´n sobre el contenido puede ovariar. En realidad, es que soy tan mal escritor que, si no lee el libro dosveces no lo va a entender. H´gase a la idea de que tiene 600 p´ginas en lugar a ade 300. Sobre los paquetes de c´digo fuente que acompa˜an a este libro (listo o npara descarga en la web), el escrito en C# es un proyecto de MicrosoftVisual Studio 2008 (Express Edition) y el escrito en Python es una carpetade ficheros. 3 http://es.wiktionary.org/wiki/infoxicaci %C3 %B3n 23
  24. 24. Convenciones y Estructura24
  25. 25. 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 circulaci´n del oconocimiento hemos llegado a donde estamos hoy, no s´lo en lo referente al oavance cient´ıfico y tecnol´gico, sino en todos los campos del saber. o Afortunadamente, el conocimiento no es propiedad de nadie sino quees como la energ´ simplemente fluye, se transforma y nos transforma. De ıa;hecho no pertenece a las personas, no tiene due˜o, es de todos los seres. nObservando a los animales podemos ver c´mo los padres ense˜an a su prole o nlas t´cnicas que necesitar´n para desenvolverse en la vida. e aEl conocimiento contenido en este libro no pertenece al autor. No perte-nece a nadie en concreto. La intenci´n es hacerlo llegar a toda persona que odesee aprovecharlo. En Internet existe mucha documentaci´n sobre la libertad del conocimien- oto, empezando por la entrada de la Wikipedia4 . Este argumento es uno de losprincipales pilares del software libre5 , al que tanto tengo que agradecer. Lasprincipales herramientas que utilizaremos en este libro est´n basadas en soft- aware libre: frameworks xUnit, sistemas de control de versiones y frameworkspara desarrollo de software. Personalmente me he convertido en usuario dela tecnolog´ Microsoft .Net gracias al framework Mono6 , desarrollado por ıaNovell con licencia libre. De no haber sido por Mono probablemente no hu-biera conocido C#.El libro ha sido maquetado usando LTEX, concretamente con teTex y Mik- ATeX(software libre) y ha requerido de multitud de paquetes libres desarro- 4 http://es.wikipedia.org/wiki/Conocimiento libre 5 http://es.wikipedia.org/wiki/C´digo libre o 6 http://www.mono-project.com 25
  26. 26. La Libertad del Conocimientollados por la comunidad. Para la edici´n del texto se ha usado Texmaker, oDokuwiki, Vim y Emacs. El versionado de los ficheros de texto se ha llevadoa cabo con Subversion. Los diagramas de clases los ha generado SharpDe-velop, con el cual tambi´n he editado c´digo. Estoy muy agradecido a todos e olos 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 simpat´ por el software de fuente abierta, este libro va m´s all´ de ıa a ala dicotom´ software libre/software propietario y se centra en t´cnicas apli- ıa ecables a cualquier lenguaje de programaci´n en cualquier entorno. Uno de los opeores enemigos del software libre es el fanatismo radical de algunos de susevangelizadores, que raya en la mala educaci´n y empa˜a el buen hacer de o nlos verdaderos profesionales. Es mi deseo aclarar que mi posici´n personal no oes ni a favor ni en contra del software propietario, simplemente me mantengoal margen de esa contienda. 26
  27. 27. La Web del Libro Los enlaces a sitios web de Internet permanecen menos tiempo activosen la red que en las p´ginas de un libro impreso; la lista de referencias se amantendr´ actualizada en un sitio web dedicado al libro: a http://www.dirigidoportests.comSi el lector desea participar informando de enlaces rotos, podr´ hacerlo diri- agi´ndose a la web del libro o bien mediante correo electr´nico al autor: e o carlos[Arroba]iExpertos[Punto]com El c´digo fuente que acompa˜a al libro se podr´ descargar en la misma o n aweb. Si bien es cierto que escribir el libro ha sido un placer, tambi´n es cierto eque ha sido duro en ocasiones. Ha supuesto casi a˜o y medio de trabajo ny, dado que el libro es gratis y ni siquiera su venta en formato papel setraducir´ en algo de beneficio, en la web es posible hacer donaciones. Si el alibro le gusta y le ayuda, le invito a que haga una donaci´n para que en el ofuturo puedan haber m´s libros libres como este. a 27
  28. 28. La Web del Libro28
  29. 29. ¿Cu´l es el Objetivo del Libro? a El objetivo fundamental del libro es traer a nuestro idioma, el espa˜ol, nconocimiento t´cnico que lleva a˜os circulando por pa´ de habla inglesa. e n ısesNo cabe duda de que los que inventaron la computaci´n y el software nos osiguen llevando ventaja en cuanto a conocimiento se refiere. En mi opini´n, oes una cuesti´n cultural en su mayor parte pero, sea como fuere, no pode- omos perder la oportunidad de subirnos al carro de las nuevas t´cnicas de edesarrollo y difundir el conocimiento proporcionado por nuestros compa˜eros nangloparlantes. S´lo as´ competiremos en igualdad de condiciones, porque a o ıd´ de hoy cada vez m´s clientes apuestan por el outsourcing. Conocimiento ıa aes poder. A d´ de hoy, por suerte o por desgracia, no nos queda m´s remedio ıa aque dominar el ingl´s, al menos el ingl´s t´cnico escrito, y es conveniente e e eleer mucho en ese idioma. Se aprende much´ ısimo porque no s´lo lo usan olos nativos de habla inglesa sino que se ha convertido en el idioma universalen cuanto a tecnolog´ Sin embargo, reconozco que yo mismo hace unos ıa.a˜os era muy reacio a leer textos en ingl´s. He tenido que hacer un gran n eesfuerzo y leer mucho con el diccionario en la mano hasta llegar al puntoen que no me cuesta trabajo leer en ingl´s (adem´s de vivir una temporada e afuera de Espa˜a). Conozco a pocos compa˜eros que hagan este esfuerzo. Es n ncomprensible y normal que la mayor´ se limite a leer lo que est´ documentado ıa aen espa˜ol. Al fin y al cabo es de los idiomas m´s hablados del planeta. Por n aeso concluyo que hay que traer la informaci´n a nuestro idioma para llegar oa m´s gente, aunque el buen profesional deber´ tener presente las m´ltiples a a uventajas que le aportar´ el dominio del ingl´s escrito. Cuando no dominamos a eel ingl´s nos perdemos muchos matices que son significativos7 . e Apenas hay libros sobre agilismo en espa˜ol. Los unicos libros novedosos n ´que se editan en nuestra lengua relacionados con el mundo del software, 7 http://jmbeas.iexpertos.com/hablar-ingles-es-facil-si-sabes-como/ 29
  30. 30. ¿Cu´l es el objetivo del libro? atratan sobre tecnolog´ muy espec´ ıas ıficas que hoy valen y ma˜ana quiz´s no. n aEst´ muy bien que haya libros sobre Java, sobre .Net o sobre Ruby, pero no atenemos que limitarnos a ello. El unico libro sobre agilismo que hay a d´ de ´ ıahoy 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 t´cnicos. Personalmente me daba reparo eafrontar este proyecto sin saber si alguna editorial querr´ publicarlo pero ıaya no es necesario que las editoriales consideren el producto comercialmentev´lido para lanzarlo a todos los p´blicos. Otro objetivo del libro es animar a a ulos muchos talentos hispanoparlantes que gustan de compartir con los dem´s, aa que nos deleiten con su conocimiento y sus dotes docentes. ¿Qui´n se anima econ un libro sobre Programaci´n Extrema?. o No me cabe duda de que las ideas planteadas en este libro pueden re-sultarles controvertidas y desafiantes a algunas personas. El lector no tienepor qu´ coincidir conmigo en todo lo que se expone; tan s´lo le invito a que e oexplore con una mente abierta las t´cnicas aqu´ recogidas, que las ponga en e ıpr´ctica y despu´s decida si le resultan o no valiosas. a e 30
  31. 31. Parte IBase Te´rica o 31
  32. 32. Cap´tulo ı 1El Agilismo Para definir qu´ es el agilismo, probablemente basten un par de l´ e ıneas. Yaveremos m´s adelante, en este mismo cap´ a ıtulo, que el concepto es realmentesimple y queda plasmado en cuatro postulados muy sencillos. Pero creo quellegar a comprenderlo requiere un poco m´s de esfuerzo y, seguramente, la amejor manera sea haciendo un repaso a la historia del desarrollo de software,para al final ver como el agilismo no es m´s que una respuesta l´gica a los a oproblemas que la evoluci´n social y tecnol´gica han ido planteando. o o Ya desde el punto de partida es necesario hacer una reflexi´n. Al otear la ohistoria nos damos cuenta de que el origen del desarrollo de software est´ a aunas pocas d´cadas de nosotros. Para llegar al momento en el que el primer ecomputador que almacenaba programas digitalmente corri´ exitosamente su oprimer programa, s´lo tenemos que remontarnos al verano de 19481 . Esto nos ohace reflexionar sobre el hecho de que nos encontramos ante una disciplinaque es apenas una reci´n nacida frente a otras centenarias con una base de econocimiento s´lida y estable. Por nuestra propia naturaleza nos oponemos oal 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˜o. Con lo que, en muy poco tiempo, aparecen m´qui- n anas muy potentes capaces de procesar miles de millones de operaciones ensegundos. A la vez, los computadores van reduciendo su tama˜o considera- nblemente, se reducen los costes de producci´n del hardware y avanzan las ocomunicaciones entre los sistemas. Todo esto tiene una consecuencia eviden-te: los computadores ya no s´lo se encuentran en ´mbitos muy restringidos, o acomo el militar o el cient´ıfico. 1 http://en.wikipedia.org/wiki/Tom Kilburn 2 http://en.wikipedia.org/wiki/Moore %27s Law 33
  33. 33. Cap´ ıtulo 1 Al extenderse el ´mbito de aplicaci´n del hardware (ordenadores perso- a onales, juegos, relojes, ...), se ofrecen soluciones a sistemas cada vez m´s acomplejos y se plantean nuevas necesidades a una velocidad vertiginosa queimplican a los desarrolladores de Software. Sin informaci´n y conocimien- oto suficiente, 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 precisi´n necesa- orias. Los proyectos no llegan a buen puerto, o lo hacen muy tarde. En la d´cada de los cincuenta nos encontramos con otro hito impor- etante. En el ´mbito militar, surge la necesidad de profesionalizar la gesti´n a ode proyectos para poder abordar el desarrollo de complejos sistemas que re-quer´ coordinar el trabajo conjunto de equipos y disciplinas diferentes en la ıanconstrucci´n de sistemas unicos. Posteriormente, la industria del autom´vil o ´ osigui´ estos pasos. Esta nueva disciplina se basa en la planificaci´n, ejecuci´n o o oy seguimiento a trav´s de procesos sistem´ticos y repetibles. e a Hasta este punto, hemos hablado s´lo de desarrollo de software y no de oingenier´ de software, ya que es en 1968 cuando se acu˜a este t´rmino en ıa n ela NATO Software Engineering Conference3 .En esta conferencia tambi´n se eacu˜a el t´rmino crisis del software para definir los problemas que estaban n esurgiendo en el desarrollo y que hemos comentado anteriormente. Los esfuerzos realizados producen tres ´reas de conocimiento que se re- avelaron como estrat´gicas para hacer frente a la crisis del software4 : e Ingenier´ del software: este t´rmino fue acu˜ado para definir la ne- ıa e n cesidad de una disciplina cient´ ıfica que, como ocurre en otras ´reas, a permita aplicar un enfoque sistem´tico, disciplinado y cuantificable al a desarrollo, operaci´n y mantenimiento del software. o Gesti´n Predictiva de proyectos: es una disciplina formal de gesti´n, o o basada en la planificaci´n, ejecuci´n y seguimiento a trav´s de procesos o o e sistem´ticos y repetibles. a Producci´n basada en procesos: se crean modelos de procesos basa- o dos en el principio de Pareto5 , empleado con buenos resultados en la producci´n industrial. Dicho principio nos indica que la calidad del o resultado depende b´sicamente de la calidad de los procesos. a En este punto, con el breve recorrido hecho, podemos sacar conclusionesreveladoras que luego nos llevar´n a la mejor comprensi´n del agilismo. Por a oun lado, la gesti´n predictiva de proyectos establece como criterios de ´xito o e 3 http://en.wikipedia.org/wiki/Software engineering 4 http://www.navegapolis.net/files/Flexibilidad con Scrum.pdf 5 http://es.wikipedia.org/wiki/Principio de Pareto 34
  34. 34. Cap´ ıtulo 1 1.1. Modelo en cascadaobtener el producto definido en el tiempo previsto y con el coste estimado.Para ello, se asume que el proyecto se desarrolla en un entorno estable ypredecible. Por otro, se empiezan a emular modelos industriales e ingenierilesque surgieron en otros ´mbitos y con otros desencadenantes. a Debemos tener en cuenta que, al principio, el tiempo de vida de unproducto acabado era muy largo; durante este tiempo, generaba beneficiosa las empresas, para las que era m´s rentable este producto que las posibles anovedades pero, a partir de los ochenta, esta situaci´n empieza a cambiar. oLa vida de los productos es cada vez m´s corta y una vez en el mercado, son anovedad apenas unos meses, quedando fuera de ´l enseguida. Esto obliga a ecambiar la filosof´ de las empresas, que se deben adaptar a este cambio cons- ıatante y basar su sistema de producci´n en la capacidad de ofrecer novedades ode forma permanente. Lo cierto es que ni los productos de software se pueden definir por com-pleto a priori, ni son totalmente predecibles, ni son inmutables. Adem´s, los aprocesos aplicados a la producci´n industrial no tienen el mismo efecto que oen desarrollo de software, ya que en un caso se aplican sobre m´quinas y en aotro, sobre personas. Estas particularidades tan caracter´ısticas del softwareno tuvieron cabida en la elaboraci´n del modelo m´s ampliamente segui- o ado hasta el momento: El modelo en cascada. En el siguiente punto de estecap´ıtulo veremos una breve descripci´n de dicho modelo, para entender su ofuncionamiento y poder concluir por qu´ en determinados entornos era pre- eciso 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 m´s b´sico de todos los modelos6 y ha servido como bloque de a aconstrucci´n para los dem´s paradigmas de ciclo de vida. Est´ basado en el o a aciclo convencional de una ingenier´ y su visi´n es muy simple: el desarrollo de ıa osoftware se debe realizar siguiendo una secuencia de fases. Cada etapa tieneun conjunto de metas bien definidas y las actividades dentro de cada unacontribuyen a la satisfacci´n de metas de esa fase o quiz´s a una subsecuencia o ade metas de la misma. El arquetipo del ciclo de vida abarca las siguientesactividades: Ingenier´ y An´lisis del Sistema: Debido a que el software es siempre ıa a parte de un sistema mayor, el trabajo comienza estableciendo los re- quisitos de todos los elementos del sistema y luego asignando alg´n u subconjunto de estos requisitos al software. 6 Bennington[4], Pag. 26-30 35
  35. 35. 1.1. Modelo en cascada Cap´ ıtulo 1 An´lisis de los requisitos del software: el proceso de recopilaci´n de a o los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ´mbito de la informaci´n del a o software as´ como la funci´n, el rendimiento y las interfaces requeridas. ı o Dise˜o: el dise˜o del software se enfoca en cuatro atributos distintos n n del programa; la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizaci´n de la interfaz. El proceso o de dise˜o traduce los requisitos en una representaci´n del software con n o la calidad requerida antes de que comience la codificaci´n.o Codificaci´n: el dise˜o debe traducirse en una forma legible para la o n maquina. Si el dise˜o se realiza de una manera detallada, la codificaci´n n o puede realizarse mec´nicamente. a Prueba: una vez que se ha generado el c´digo comienza la prueba del o programa. La prueba se centra en la l´gica interna del software y en o las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: el software sufrir´ cambios despu´s de que se entrega a e al cliente. Los cambios ocurrir´n debidos a que se haya encontrado a errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perif´ricos) o a que el cliente requiera e ampliaciones funcionales o del rendimiento. En el modelo vemos una ventaja evidente y radica en su sencillez, ya quesigue los pasos intuitivos necesarios a la hora de desarrollar el software. Peroel modelo se aplica en un contexto, as´ que debemos atender tambi´n a ´l y ı e esaber que: Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicaci´n o del paradigma. Normalmente, al principio, es dif´ para el cliente establecer todos los ıcil requisitos expl´ ıcitamente. El ciclo de vida cl´sico lo requiere y tiene a dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto no estar´ disponible una versi´n operativa del programa. Un a o error importante que no pueda ser detectado hasta que el programa est´ funcionando, puede ser desastroso. e 36
  36. 36. Cap´ ıtulo 1 1.2. Hablemos de cifras1.2. Hablemos de cifras Quiz´s nos encontremos en un buen punto para dejar de lado los datos ate´ricos y centrarnos en cifras reales que nos indiquen la magnitud del pro- oblema que pretendemos describir. Para ello nos basaremos en los estudiosrealizados por un conjunto de profesionales de Massachussets que se uni´ eno1985 bajo el nombre de Standish Group7 . El objetivo de estos profesionales eraobtener informaci´n de los proyectos fallidos en tecnolog´ de la informaci´n o ıas o(IT) y as´ poder encontrar y combatir las causas de los fracasos. El buen ıhacer de este grupo lo ha convertido en un referente, a nivel mundial, sobrelos factores que inciden en el ´xito o fracaso de los proyectos de IT. Factores eque se centran, fundamentalmente, en los proyectos de software y se aplicantanto a los desarrollos como a la implementaci´n de paquetes (SAP, Oracle, oMicrosoft, etc.) A lo largo del tiempo, el Standish Group revel´ 50.000 proyectos fallidos oy en 1994 se obtuvieron los siguientes resultados: Porcentaje de proyectos que son cancelados: 31 % Porcentaje de proyectos problem´ticos: 53 % a Porcentaje de proyectos exitosos: 16 % (pero estos s´lo cumplieron, en o promedio, con el 61 % de la funcionalidad prometida) Atendiendo a estos resultados poco esperanzadores, durante los ultimos ´diez a˜os, la industria invirti´ varios miles de millones de d´lares en el desa- n o orrollo y perfeccionamiento de metodolog´ y tecnolog´ (PMI, CMMI, ITIL, ıas ıasetc.). Sin embargo, en 2004 los resultados segu´ sin ser alentadores: ıan Porcentaje de proyectos exitosos: crece hasta el 29 %. Porcentaje de proyectos fracasados: 71 %.Seg´n el informe de Standish, las diez causas principales de los fracasos, por uorden de importancia, son: Escasa participaci´n de los usuarios o Requerimientos y especificaciones incompletas Cambios frecuentes en los requerimientos y especificaciones Falta de soporte ejecutivo Incompetencia tecnol´gica o 7 http://www.standishgroup.com 37
  37. 37. 1.3. El manifiesto ´gil a Cap´ ıtulo 1 Falta de recursos Expectativas no realistas Objetivos poco claros Cronogramas irreales Nuevas tecnolog´ ıasCabe 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 continuaci´n, el agilismo intenta dar respuesta. o En el libro de Roberto Canales[13] existe m´s informaci´n sobre los m´to- a o edos en cascada, las metodolog´ ´giles y la gesti´n de proyectos. ıas a o1.3. El manifiesto ´gil a Hasta ahora hemos visto que quiz´s para algunos proyectos se est´ rea- a elizando un esfuerzo vano e incluso peligroso: intentar aplicar pr´cticas de aestimaci´n, planificaci´n e ingenier´ de requisitos. No es conveniente pensar o o ıaque estas pr´cticas son malas en s´ mismas o que los fracasos se deben a una a ımala aplicaci´n de estas, sino que deber´ o ıamos recapacitar sobre si estamosaplicando las pr´cticas adecuadas. a En 2001, 17 representantes de nuevas metodolog´ y cr´ ıas ıticos de los mo-delos de mejora basados en procesos se reunieron, convocados por Kent Beck,para discutir sobre el desarrollo de software. Fue un grito de ¡basta ya! a laspr´cticas tradicionales. Estos profesionales, con una dilatada experiencia co- amo aval, llevaban ya alrededor de una d´cada utilizando t´cnicas que les e efueron posicionando como l´ ıderes de la industria del desarrollo software. Co-noc´ perfectamente las desventajas del cl´sico modelo en cascada donde ıan aprimero se analiza, luego se dise˜a, despu´s se implementa y, por ultimo (en n e ´algunos casos), se escriben algunos tests autom´ticos y se martiriza a un agrupo de personas para que ejecuten manualmente el software, una y otravez hasta la saciedad. El manifiesto ´gil8 se compone de cuatro principios. aEs peque˜o pero bien cargado de significado: n 8 La traducci´n del o manifiesto es de Agile Spain http://www.agile-spain.com/manifiesto agil 38
  38. 38. Cap´ ıtulo 1 1.3. El manifiesto ´gil a $ Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A trav´s de esta experiencia hemos aprendido a valorar: e Individuos e interacciones sobre procesos y herramien- tas Software que funciona sobre documentaci´n exhaustiva o Colaboraci´n con el cliente sobre negociaci´n de con- o o tratos Responder ante el cambio sobre seguimiento de un plan Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que est´n a la izquierda. a Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, & % Dave Thomas. Tras este manifiesto se encuentran 12 principios de vital importancia paraentender su filosof´ 9 : ıa Nuestra m´xima prioridad es satisfacer al cliente a trav´s de entregas a e tempranas y continuas de software valioso. Los requisitos cambiantes son bienvenidos, incluso en las etapas finales del desarrollo. Los procesos ´giles aprovechan al cambio para ofrecer a una ventaja competitiva al cliente. Entregamos software que funciona frecuentemente, entre un par de semanas y un par de meses. De hecho es com´n entregar cada tres o u cuatro semanas. Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto. Construimos proyectos entorno a individuos motivados. D´ndoles el a lugar y el apoyo que necesitan y confiando en ellos para hacer el trabajo. El m´todo m´s eficiente y efectivo de comunicar la informaci´n hacia e a o y entre un equipo de desarrollo es la conversaci´n cara a cara. o 9 Traducci´n o libre de los principios publicados enhttp://www.agilemanifesto.org/principles.html 39
  39. 39. 1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico e a Cap´ ıtulo 1 La principal medida de avance es el software que funciona. Los procesos ´giles promueven el desarrollo sostenible. Los patroci- a nadores, desarrolladores y usuarios deben poder mantener un ritmo constante. La atenci´n continua a la excelencia t´cnica y el buen dise˜o mejora o e n la agilidad. La simplicidad, es esencial. Las mejores arquitecturas, requisitos y dise˜os emergen de la auto- n organizaci´n de los equipos. o A intervalos regulares, el equipo reflexiona sobre c´mo ser m´s eficaces, o a a continuaci´n mejoran y ajustan su comportamiento en consecuencia. o Este libro no pretende abarcar el vasto conjunto de t´cnicas y metodo- elog´ del agilismo pero, considerando la poca literatura en castellano que ıasexiste actualmente sobre este tema, merece la pena publicar el manifiesto.1.4. ¿En qu´ consiste el agilismo?: Un enfoque e pr´ctico a El agilismo es una respuesta a los fracasos y las frustraciones del modeloen cascada. A d´ de hoy, las metodolog´ ´giles de desarrollo de software ıa ıas aest´n en boca de todos y adquieren cada vez m´s presencia en el mundo a ahispano, si bien llevan siendo usadas m´s de una d´cada en otros pa´ a e ıses. Elabanico de metodolog´ ´giles es amplio, existiendo m´todos para organizar ıas a eequipos y t´cnicas para escribir y mantener el software. Personalmente, me einclino hacia la Programaci´n Extrema (eXtreme Programming, XP) como oforma de atacar la implementaci´n del producto y hacia Scrum como forma ode 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 codificar con t´cnicas de XP; concretamente eTDD10 y Programaci´n por Parejas11 , sin olvidar la propiedad colectiva del oc´digo y la Integraci´n Continua12 . o o 10 Test Driven Development o Desarrollo Dirigido por Test 11 Pair Programming o Programaci´n por Parejas, es otra de las t´cnicas que com- o eponen XP y que no vamos a estudiar en detalle en este libro. V´anse en la bibliograf´ e ıalos textos relacionados con XP para mayor informaci´no 12 V´ase el ap´ndice sobre Integraci´n Continua al final del libro e e o 40

×