SlideShare una empresa de Scribd logo
Dise˜o Agil con TDD
      n

Carlos Bl´ Jurado y colaboradores.
         e
  Prologo de Jos´ Manuel Beas
                 e
Primera Edici´n, Enero de 2010
               o
www.iExpertos.com
El libro se ha publicado bajo la Licencia Creative Commons




                                2
´
Indice general


I   Base Te´rica
           o                                                                             31

1. El Agilismo                                                                           33
   1.1. Modelo en cascada . . . . . . . . . . . . . . . . .          .   .   .   .   .   35
   1.2. Hablemos de cifras . . . . . . . . . . . . . . . . .         .   .   .   .   .   37
   1.3. El manifiesto ´gil . . . . . . . . . . . . . . . . . .
                      a                                              .   .   .   .   .   38
   1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico
               e                                      a              .   .   .   .   .   40
   1.5. La situaci´n actual . . . . . . . . . . . . . . . . .
                  o                                                  .   .   .   .   .   44
        ´
   1.6. Agil parece, pl´tano es . . . . . . . . . . . . . . .
                       a                                             .   .   .   .   .   46
   1.7. Los roles dentro del equipo . . . . . . . . . . . . .        .   .   .   .   .   47
   1.8. ¿Por qu´ nos cuesta comenzar a ser ´giles? . . . .
                e                            a                       .   .   .   .   .   49

2. ¿Qu´ es el Desarrollo Dirigido por Tests? (TDD)
       e                                                                                 53
   2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . .                   56
        2.1.1. Escribir la especificaci´n primero . . . . . . . . . . .
                                      o                                                  56
        2.1.2. Implementar el c´digo que hace funcionar el ejemplo
                                 o                                                       57
        2.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . .                  58
   2.2. Consideraciones y recomendaciones . . . . . . . . . . . . . .                    60
        2.2.1. Ventajas del desarrollador experto frente al junior . .                   60
        2.2.2. TDD con una tecnolog´ desconocida . . . . . . . .
                                       ıa                                                60
        2.2.3. TDD en medio de un proyecto . . . . . . . . . . . .                       61

3. Desarrollo Dirigido por Tests     de    Aceptaci´no     (ATDD)                        63
   3.1. Las historias de usuario .   . .   . . . . . . .   . . . . . .   .   .   .   .   64
   3.2. Qu´ y no C´mo . . . . .
           e        o                . .   . . . . . . .   . . . . . .   .   .   .   .   68
   3.3. ¿Est´ hecho o no? . . . .
             a                       . .   . . . . . . .   . . . . . .   .   .   .   .   70
   3.4. El contexto es esencial .    . .   . . . . . . .   . . . . . .   .   .   .   .   71




                                      3
´
INDICE GENERAL                                                  ´
                                                                INDICE GENERAL


4. Tipos de test y su importancia                                                                    73
   4.1. Terminolog´ en la comunidad TDD
                  ıa                            .   .   .   .   .   .   .   .   .   .   .   .   .    74
        4.1.1. Tests de Aceptaci´n . . . . .
                                 o              .   .   .   .   .   .   .   .   .   .   .   .   .    75
        4.1.2. Tests Funcionales . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .    76
        4.1.3. Tests de Sistema . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .    76
        4.1.4. Tests Unitarios . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .    78
        4.1.5. Tests de Integraci´n . . . . .
                                 o              .   .   .   .   .   .   .   .   .   .   .   .   .    80

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

6. Mocks y otros dobles de prueba                                      95
   6.1. Cu´ndo usar un objeto real, un stub o un mock . . . . . . . 97
          a
   6.2. La met´fora Record/Replay . . . . . . . . . . . . . . . . . . 108
              a

7. Dise˜o Orientado a Objetos
        n                                                                                           111
   7.1. Dise˜o Orientado a Objetos (OOD) . . . . .
             n                                                      .   .   .   .   .   .   .   .   111
   7.2. Principios S.O.L.I.D . . . . . . . . . . . . . .            .   .   .   .   .   .   .   .   112
         7.2.1. Single Responsibility Principle (SRP) .             .   .   .   .   .   .   .   .   113
         7.2.2. Open-Closed Principle (OCP) . . . . .               .   .   .   .   .   .   .   .   113
         7.2.3. Liskov Substitution Principle (LSP) .               .   .   .   .   .   .   .   .   114
         7.2.4. Interface Segregation Principle (ISP) .             .   .   .   .   .   .   .   .   114
         7.2.5. Dependency Inversi´n Principle (DIP)
                                    o                               .   .   .   .   .   .   .   .   115
   7.3. Inversi´n del Control (IoC) . . . . . . . . . .
               o                                                    .   .   .   .   .   .   .   .   116


II   Ejercicios Pr´cticos
                  a                                                                                 119

8. Inicio del proyecto - Test Unitarios                                                             121

9. Continuaci´n del proyecto - Test Unitarios
             o                                                                                      157

10.Fin del proyecto - Test de Integraci´n   o                                                       231
   10.1. La frontera entre tests unitarios y tests de integraci´n
                                                               o                    .   .   .   .   233
   10.2. Dise˜o emergente con un ORM . . . . . . . . . . . .
             n                                                                      .   .   .   .   243
         10.2.1. Dise˜ando relaciones entre modelos . . . . .
                     n                                                              .   .   .   .   246
   10.3. La unificaci´n de las piezas del sistema . . . . . . . .
                     o                                                              .   .   .   .   247

11.La soluci´n en versi´n Python
            o          o                                                                            249

12.Antipatrones y Errores comunes                                                                   289




                                      4
´
INDICE GENERAL                                          ´
                                                        INDICE GENERAL


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




                                      5
´
INDICE GENERAL       ´
                     INDICE GENERAL




                 6
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
Pr´logo
  o


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


                                         9
Pr´logo
                                                                                       o


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


                                              10
Pr´logo
  o


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


                                            11
Pr´logo
                                                                         o


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




                                      12
Agradecimientos


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


                                      13
Agradecimientos


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


                                        14
Agradecimientos


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


                                       15
Agradecimientos


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




                                    16
Autores del libro



Carlos Bl´ Jurado
         e                Nac´ en C´rdoba en 1981, hijo de cordobeses
                              ı        o
                          pero cuando ten´ 4 a˜os emigramos a Lanza-
                                              ıa n
                          rote y, salvo algunos a˜os intercalados en los
                                                  n
                          que viv´ en C´rdoba, la mayor parte de mi vida
                                  ı        o
                          la he pasado en Canarias. Primero en Lanzarote
                          y despu´s en Tenerife.
                                   e
                          Mi primer apellido significa trigo en franc´s. Lo
                                                                    e
                          trajo un franc´s al pueblo cordob´s de La Vic-
                                            e                e
                          toria en tiempos de Carlos III.
                          Cuando ten´ 6 a˜os mi padre trajo a casa un
                                         ıa    n
                          8086 y aquello me fascin´ tanto que supe que
                                                    o
                          me quer´ dedicar a trabajar con ordenadores
                                    ıa
                          desde entonces. He tenido tambi´n Amiga 500,
                                                           e
                          Amiga 1200, y luego unos cuantos PC, desde el
                          AMD K6 hasta el Intel Core Duo de hoy.


    Soy ingeniero t´cnico en inform´tica de sistemas. Para m´ el t´
                     e               a                         ı     ıtulo no
es ninguna garant´ de profesionalidad, m´s bien hago un balance negativo
                   ıa                      a
de mi paso por la Universidad, pero quer´ ponerlo aqu´ para que los que
                                           ıa               ı
padecen de titulitis vean que el que escribe es titulado.
    La primera vez que gan´ dinero con un desarrollo de software fue en
                             e
2001. Poco despu´s de que instalase Debian GNU/Linux en mi PC. En 2003
                  e
entr´ de lleno en el mercado laboral. Al principio trabaj´ administrando sis-
    e                                                     e
temas adem´s de programar.
             a
    En 2005 se me ocurri´ la genial idea de montar una empresa de desarrollo
                         o
de software a medida con mis colegas. Sin tener suficiente experiencia como
desarrollador y ninguna experiencia como empresario ni comercial, fue toda


                                     17
Autores del libro


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




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


                                          18
Autores del libro




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




                              19
Autores del libro


Juan    Guti´rrez
            e       Escribir, he escrito poco, pero aprender,
Plaza               much´ ısimo. He intentado hacer algo con sen-
                    tido con mi oxidado Python en el cap´     ıtulo 11
                    aunque m´s que escribir, ha sido discutir y re-
                               a
                    discutir con Carlos sobre cual era la mejor forma
                    de hacer esto y aquello (siempre ha ganado ´l).e
                    Tambi´n he sacado del ba´l de los recuerdos mi
                           e                   u
                    LaTeX y he revisado mucho. Cuando no estoy
                    discutiendo con la gente de Agile Spain, trabajo
                    como “Agile Coach” en F-Secure donde intento
                    ayudar a equipos de Finlandia, Malasia, Rusia
                    y Francia en su transici´n a las metodolog´
                                              o                     ıas
                    a
                    ´giles (tanto en gesti´n como en pr´cticas de
                                           o               a
                    software entre las que se incluye, por supues-
                    to, TDD). ¿Pero c´mo he llegado hasta aqu´
                                        o                            ı?
                    Mi devoci´n los ordenadores me llev´ a estu-
                               o                            o
                    diar la carrera de ingenier´ en inform´tica en
                                                ıa            a
                    la UPM de Madrid. Trabaj´ en Espa˜a por un
                                                 e         n
                    tiempo antes de decidir mudarme a Finlandia
                    en el 2004 para trabajar en Nokia. En las lar-
                    gas y oscuras “tardes” del invierno Finland´s    e
                    estudi´ un master en “industrial management”
                           e
                    antes de cambiar a F-Secure. Cuando el tiempo
                    lo permite, escribo en http://agilizar.es


Fran Reyes Perdo-   Soy un apasionado desarrollador de software in-
mo                  teresado en “pr´cticas ´giles”. Llevo cerca de
                                     a      a
                    4 a˜os trabajando para la r´
                        n                         ıgida Administra-
                    ci´n p´blica con un fantastico equipo. Conoc´ a
                      o u                                       ı
                    Carlos Bl´ en un provechoso curso de TDD que
                              e
                    imparti´ para un grupo de compa˜eros. Entre
                            o                           n
                    cervezas (una fase importante para asimilar lo
                    aprendido), compartimos ideas y experiencias
                    del mundo del software, y me habl´ adem´s
                                                          o      a
                    del proyecto en el que se encontraba embar-
                    cado, en el cual me brind´ la oportunidad de
                                               o
                    participar con un peque˜o ap´ndice sobre inte-
                                             n     e
                    graci´n continua. Una pr´ctica, que intentamos,
                          o                  a
                    forme parte del d´ a d´ en nuestros proyectos.
                                      ıa   ıa
                    http://es.linkedin.com/in/franreyesperdomo



                              20
Autores del libro




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




                      21
Autores del libro




22
Convenciones y Estructura


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




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


                                         23
Convenciones y Estructura




24
La Libertad del Conocimiento


    El conocimiento ha sido transmitido de individuo a individuo desde el
comienzo mismo de la vida en el planeta. Gracias a la libre circulaci´n del
                                                                     o
conocimiento hemos llegado a donde estamos hoy, no s´lo en lo referente al
                                                        o
avance cient´ıfico y tecnol´gico, sino en todos los campos del saber.
                          o
    Afortunadamente, el conocimiento no es propiedad de nadie sino que
es como la energ´ simplemente fluye, se transforma y nos transforma. De
                  ıa;
hecho no pertenece a las personas, no tiene due˜o, es de todos los seres.
                                                   n
Observando a los animales podemos ver c´mo los padres ense˜an a su prole
                                           o                  n
las t´cnicas que necesitar´n para desenvolverse en la vida.
     e                    a

El conocimiento contenido en este libro no pertenece al autor. No perte-
nece a nadie en concreto. La intenci´n es hacerlo llegar a toda persona que
                                        o
desee aprovecharlo.
    En Internet existe mucha documentaci´n sobre la libertad del conocimien-
                                              o
to, empezando por la entrada de la Wikipedia4 . Este argumento es uno de los
principales pilares del software libre5 , al que tanto tengo que agradecer. Las
principales herramientas que utilizaremos en este libro est´n basadas en soft-
                                                             a
ware libre: frameworks xUnit, sistemas de control de versiones y frameworks
para desarrollo de software. Personalmente me he convertido en usuario de
la tecnolog´ Microsoft .Net gracias al framework Mono6 , desarrollado por
            ıa
Novell con licencia libre. De no haber sido por Mono probablemente no hu-
biera conocido C#.

El libro ha sido maquetado usando LTEX, concretamente con teTex y Mik-
                                   A
TeX(software libre) y ha requerido de multitud de paquetes libres desarro-
  4
    http://es.wikipedia.org/wiki/Conocimiento libre
  5
    http://es.wikipedia.org/wiki/C´digo libre
                                  o
  6
    http://www.mono-project.com



                                        25
La Libertad del Conocimiento


llados por la comunidad. Para la edici´n del texto se ha usado Texmaker,
                                       o
Dokuwiki, Vim y Emacs. El versionado de los ficheros de texto se ha llevado
a cabo con Subversion. Los diagramas de clases los ha generado SharpDe-
velop, con el cual tambi´n he editado c´digo. Estoy muy agradecido a todos
                        e              o
los que han escrito todas estas piezas. En la web del libro se encuentra el
esqueleto con el que se ha maquetado para que, quien quiera, lo use para sus
propias publicaciones.

Pese a mi simpat´ por el software de fuente abierta, este libro va m´s all´ de
                   ıa                                               a     a
la dicotom´ software libre/software propietario y se centra en t´cnicas apli-
            ıa                                                    e
cables a cualquier lenguaje de programaci´n en cualquier entorno. Uno de los
                                           o
peores enemigos del software libre es el fanatismo radical de algunos de sus
evangelizadores, que raya en la mala educaci´n y empa˜a el buen hacer de
                                                o          n
los verdaderos profesionales. Es mi deseo aclarar que mi posici´n personal no
                                                                o
es ni a favor ni en contra del software propietario, simplemente me mantengo
al margen de esa contienda.




                                     26
La Web del Libro


    Los enlaces a sitios web de Internet permanecen menos tiempo activos
en la red que en las p´ginas de un libro impreso; la lista de referencias se
                       a
mantendr´ actualizada en un sitio web dedicado al libro:
         a

      http://www.dirigidoportests.com

Si el lector desea participar informando de enlaces rotos, podr´ hacerlo diri-
                                                               a
gi´ndose a la web del libro o bien mediante correo electr´nico al autor:
  e                                                       o

      carlos[Arroba]iExpertos[Punto]com

    El c´digo fuente que acompa˜a al libro se podr´ descargar en la misma
         o                         n                   a
web.
    Si bien es cierto que escribir el libro ha sido un placer, tambi´n es cierto
                                                                    e
que ha sido duro en ocasiones. Ha supuesto casi a˜o y medio de trabajo
                                                         n
y, dado que el libro es gratis y ni siquiera su venta en formato papel se
traducir´ en algo de beneficio, en la web es posible hacer donaciones. Si el
         a
libro le gusta y le ayuda, le invito a que haga una donaci´n para que en el
                                                              o
futuro puedan haber m´s libros libres como este.
                        a




                                      27
La Web del Libro




28
¿Cu´l es el Objetivo del Libro?
   a


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


                                           29
¿Cu´l es el objetivo del libro?
                                                a


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




                                     30
Parte I

Base Te´rica
       o




     31
Cap´tulo
   ı           1
El Agilismo

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


                                        33
Cap´
                                                                      ıtulo 1


    Al extenderse el ´mbito de aplicaci´n del hardware (ordenadores perso-
                      a                  o
nales, juegos, relojes, ...), se ofrecen soluciones a sistemas cada vez m´s   a
complejos y se plantean nuevas necesidades a una velocidad vertiginosa que
implican a los desarrolladores de Software. Sin informaci´n y conocimien-
                                                              o
to suficiente, unos pocos “aventureros” empiezan a desarrollar las primeras
aplicaciones que dan respuesta a las nuevas necesidades pero es un reto muy
complejo que no llega a ser resuelto con la inmediatez y la precisi´n necesa-
                                                                    o
rias. Los proyectos no llegan a buen puerto, o lo hacen muy tarde.
    En la d´cada de los cincuenta nos encontramos con otro hito impor-
              e
tante. En el ´mbito militar, surge la necesidad de profesionalizar la gesti´n
                a                                                            o
de proyectos para poder abordar el desarrollo de complejos sistemas que re-
quer´ coordinar el trabajo conjunto de equipos y disciplinas diferentes en la
     ıan
construcci´n de sistemas unicos. Posteriormente, la industria del autom´vil
            o               ´                                               o
sigui´ estos pasos. Esta nueva disciplina se basa en la planificaci´n, ejecuci´n
     o                                                            o          o
y seguimiento a trav´s de procesos sistem´ticos y repetibles.
                      e                     a
    Hasta este punto, hemos hablado s´lo de desarrollo de software y no de
                                         o
ingenier´ de software, ya que es en 1968 cuando se acu˜a este t´rmino en
         ıa                                                 n        e
la NATO Software Engineering Conference3 .En esta conferencia tambi´n se  e
acu˜a el t´rmino crisis del software para definir los problemas que estaban
    n       e
surgiendo en el desarrollo y que hemos comentado anteriormente.
    Los esfuerzos realizados producen tres ´reas de conocimiento que se re-
                                             a
velaron como estrat´gicas para hacer frente a la crisis del software4 :
                     e

      Ingenier´ del software: este t´rmino fue acu˜ado para definir la ne-
              ıa                    e               n
      cesidad de una disciplina cient´
                                     ıfica que, como ocurre en otras ´reas,
                                                                      a
      permita aplicar un enfoque sistem´tico, disciplinado y cuantificable al
                                        a
      desarrollo, operaci´n y mantenimiento del software.
                         o

      Gesti´n Predictiva de proyectos: es una disciplina formal de gesti´n,
           o                                                              o
      basada en la planificaci´n, ejecuci´n y seguimiento a trav´s de procesos
                             o          o                      e
      sistem´ticos y repetibles.
             a

      Producci´n basada en procesos: se crean modelos de procesos basa-
               o
      dos en el principio de Pareto5 , empleado con buenos resultados en
      la producci´n industrial. Dicho principio nos indica que la calidad del
                 o
      resultado depende b´sicamente de la calidad de los procesos.
                          a

    En este punto, con el breve recorrido hecho, podemos sacar conclusiones
reveladoras que luego nos llevar´n a la mejor comprensi´n del agilismo. Por
                                 a                      o
un lado, la gesti´n predictiva de proyectos establece como criterios de ´xito
                 o                                                      e
  3
    http://en.wikipedia.org/wiki/Software engineering
  4
    http://www.navegapolis.net/files/Flexibilidad con Scrum.pdf
  5
    http://es.wikipedia.org/wiki/Principio de Pareto


                                      34
Cap´
   ıtulo 1                                             1.1. Modelo en cascada


obtener el producto definido en el tiempo previsto y con el coste estimado.
Para ello, se asume que el proyecto se desarrolla en un entorno estable y
predecible. Por otro, se empiezan a emular modelos industriales e ingenieriles
que surgieron en otros ´mbitos y con otros desencadenantes.
                         a
    Debemos tener en cuenta que, al principio, el tiempo de vida de un
producto acabado era muy largo; durante este tiempo, generaba beneficios
a las empresas, para las que era m´s rentable este producto que las posibles
                                    a
novedades pero, a partir de los ochenta, esta situaci´n empieza a cambiar.
                                                        o
La vida de los productos es cada vez m´s corta y una vez en el mercado, son
                                         a
novedad apenas unos meses, quedando fuera de ´l enseguida. Esto obliga a
                                                    e
cambiar la filosof´ de las empresas, que se deben adaptar a este cambio cons-
                   ıa
tante y basar su sistema de producci´n en la capacidad de ofrecer novedades
                                      o
de forma permanente.
    Lo cierto es que ni los productos de software se pueden definir por com-
pleto a priori, ni son totalmente predecibles, ni son inmutables. Adem´s, los
                                                                        a
procesos aplicados a la producci´n industrial no tienen el mismo efecto que
                                  o
en desarrollo de software, ya que en un caso se aplican sobre m´quinas y en
                                                                 a
otro, sobre personas. Estas particularidades tan caracter´ısticas del software
no tuvieron cabida en la elaboraci´n del modelo m´s ampliamente segui-
                                     o                  a
do hasta el momento: El modelo en cascada. En el siguiente punto de este
cap´ıtulo veremos una breve descripci´n de dicho modelo, para entender su
                                       o
funcionamiento y poder concluir por qu´ en determinados entornos era pre-
                                          e
ciso un cambio. Como ya comentaba al principio, el objetivo es ver que el
agilismo es la respuesta a una necesidad.


1.1.       Modelo en cascada
    Este es el m´s b´sico de todos los modelos6 y ha servido como bloque de
                a a
construcci´n para los dem´s paradigmas de ciclo de vida. Est´ basado en el
          o                 a                                   a
ciclo convencional de una ingenier´ y su visi´n es muy simple: el desarrollo de
                                  ıa         o
software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene
un conjunto de metas bien definidas y las actividades dentro de cada una
contribuyen a la satisfacci´n de metas de esa fase o quiz´s a una subsecuencia
                           o                             a
de metas de la misma. El arquetipo del ciclo de vida abarca las siguientes
actividades:

        Ingenier´ y An´lisis del Sistema: Debido a que el software es siempre
                ıa     a
        parte de un sistema mayor, el trabajo comienza estableciendo los re-
        quisitos de todos los elementos del sistema y luego asignando alg´n
                                                                          u
        subconjunto de estos requisitos al software.
  6
      Bennington[4], Pag. 26-30


                                      35
1.1. Modelo en cascada                                              Cap´
                                                                       ıtulo 1


      An´lisis de los requisitos del software: el proceso de recopilaci´n de
         a                                                               o
      los requisitos se centra e intensifica especialmente en el software. El
      ingeniero de software debe comprender el ´mbito de la informaci´n del
                                                 a                      o
      software as´ como la funci´n, el rendimiento y las interfaces requeridas.
                  ı             o

      Dise˜o: el dise˜o del software se enfoca en cuatro atributos distintos
           n         n
      del programa; la estructura de los datos, la arquitectura del software,
      el detalle procedimental y la caracterizaci´n de la interfaz. El proceso
                                                 o
      de dise˜o traduce los requisitos en una representaci´n del software con
              n                                           o
      la calidad requerida antes de que comience la codificaci´n.o

      Codificaci´n: el dise˜o debe traducirse en una forma legible para la
               o           n
      maquina. Si el dise˜o se realiza de una manera detallada, la codificaci´n
                         n                                                  o
      puede realizarse mec´nicamente.
                           a

      Prueba: una vez que se ha generado el c´digo comienza la prueba del
                                               o
      programa. La prueba se centra en la l´gica interna del software y en
                                             o
      las funciones externas, realizando pruebas que aseguren que la entrada
      definida produce los resultados que realmente se requieren.

      Mantenimiento: el software sufrir´ cambios despu´s de que se entrega
                                         a                e
      al cliente. Los cambios ocurrir´n debidos a que se haya encontrado
                                       a
      errores, a que el software deba adaptarse a cambios del entorno externo
      (sistema operativo o dispositivos perif´ricos) o a que el cliente requiera
                                             e
      ampliaciones funcionales o del rendimiento.

    En el modelo vemos una ventaja evidente y radica en su sencillez, ya que
sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Pero
el modelo se aplica en un contexto, as´ que debemos atender tambi´n a ´l y
                                         ı                             e     e
saber que:

      Los proyectos reales raramente siguen el flujo secuencial que propone el
      modelo. Siempre hay iteraciones y se crean problemas en la aplicaci´n
                                                                          o
      del paradigma.

      Normalmente, al principio, es dif´ para el cliente establecer todos los
                                       ıcil
      requisitos expl´
                     ıcitamente. El ciclo de vida cl´sico lo requiere y tiene
                                                    a
      dificultades en acomodar posibles incertidumbres que pueden existir al
      comienzo de muchos productos.

      El cliente debe tener paciencia. Hasta llegar a las etapas finales del
      proyecto no estar´ disponible una versi´n operativa del programa. Un
                       a                     o
      error importante que no pueda ser detectado hasta que el programa
      est´ funcionando, puede ser desastroso.
         e

                                      36
Cap´
   ıtulo 1                                              1.2. Hablemos de cifras


1.2.       Hablemos de cifras
    Quiz´s nos encontremos en un buen punto para dejar de lado los datos
         a
te´ricos y centrarnos en cifras reales que nos indiquen la magnitud del pro-
  o
blema que pretendemos describir. Para ello nos basaremos en los estudios
realizados por un conjunto de profesionales de Massachussets que se uni´ eno
1985 bajo el nombre de Standish Group7 . El objetivo de estos profesionales era
obtener informaci´n de los proyectos fallidos en tecnolog´ de la informaci´n
                  o                                        ıas               o
(IT) y as´ poder encontrar y combatir las causas de los fracasos. El buen
          ı
hacer de este grupo lo ha convertido en un referente, a nivel mundial, sobre
los factores que inciden en el ´xito o fracaso de los proyectos de IT. Factores
                               e
que se centran, fundamentalmente, en los proyectos de software y se aplican
tanto a los desarrollos como a la implementaci´n de paquetes (SAP, Oracle,
                                                 o
Microsoft, etc.)
    A lo largo del tiempo, el Standish Group revel´ 50.000 proyectos fallidos
                                                    o
y en 1994 se obtuvieron los siguientes resultados:
        Porcentaje de proyectos que son cancelados: 31 %

        Porcentaje de proyectos problem´ticos: 53 %
                                       a

        Porcentaje de proyectos exitosos: 16 % (pero estos s´lo cumplieron, en
                                                            o
        promedio, con el 61 % de la funcionalidad prometida)
     Atendiendo a estos resultados poco esperanzadores, durante los ultimos
                                                                        ´
diez a˜os, la industria invirti´ varios miles de millones de d´lares en el desa-
       n                       o                              o
rrollo y perfeccionamiento de metodolog´ y tecnolog´ (PMI, CMMI, ITIL,
                                           ıas           ıas
etc.). Sin embargo, en 2004 los resultados segu´ sin ser alentadores:
                                                  ıan
        Porcentaje de proyectos exitosos: crece hasta el 29 %.

        Porcentaje de proyectos fracasados: 71 %.
Seg´n el informe de Standish, las diez causas principales de los fracasos, por
   u
orden de importancia, son:
        Escasa participaci´n de los usuarios
                          o

        Requerimientos y especificaciones incompletas

        Cambios frecuentes en los requerimientos y especificaciones

        Falta de soporte ejecutivo

        Incompetencia tecnol´gica
                            o
  7
      http://www.standishgroup.com


                                       37
1.3. El manifiesto ´gil
                  a                                                    Cap´
                                                                          ıtulo 1


       Falta de recursos

       Expectativas no realistas

       Objetivos poco claros

       Cronogramas irreales

       Nuevas tecnolog´
                      ıas

Cabe destacar de estos resultados que siete de los factores nombrados, son
factores humanos. Las cifras evidencian la existencia de un problema, al que,
como veremos a continuaci´n, el agilismo intenta dar respuesta.
                            o
    En el libro de Roberto Canales[13] existe m´s informaci´n sobre los m´to-
                                               a           o             e
dos en cascada, las metodolog´ ´giles y la gesti´n de proyectos.
                               ıas a               o


1.3.      El manifiesto ´gil
                       a
     Hasta ahora hemos visto que quiz´s para algunos proyectos se est´ rea-
                                          a                                e
lizando un esfuerzo vano e incluso peligroso: intentar aplicar pr´cticas de
                                                                      a
estimaci´n, planificaci´n e ingenier´ de requisitos. No es conveniente pensar
         o             o              ıa
que estas pr´cticas son malas en s´ mismas o que los fracasos se deben a una
             a                      ı
mala aplicaci´n de estas, sino que deber´
               o                            ıamos recapacitar sobre si estamos
aplicando las pr´cticas adecuadas.
                 a
     En 2001, 17 representantes de nuevas metodolog´ y cr´
                                                        ıas    ıticos de los mo-
delos de mejora basados en procesos se reunieron, convocados por Kent Beck,
para discutir sobre el desarrollo de software. Fue un grito de ¡basta ya! a las
pr´cticas tradicionales. Estos profesionales, con una dilatada experiencia co-
   a
mo aval, llevaban ya alrededor de una d´cada utilizando t´cnicas que les
                                              e                  e
fueron posicionando como l´  ıderes de la industria del desarrollo software. Co-
noc´ perfectamente las desventajas del cl´sico modelo en cascada donde
     ıan                                        a
primero se analiza, luego se dise˜a, despu´s se implementa y, por ultimo (en
                                  n          e                        ´
algunos casos), se escriben algunos tests autom´ticos y se martiriza a un
                                                    a
grupo de personas para que ejecuten manualmente el software, una y otra
vez hasta la saciedad. El manifiesto ´gil8 se compone de cuatro principios.
                                         a
Es peque˜o pero bien cargado de significado:
          n
   8
     La traducci´n del
                o           manifiesto   es   de   Agile   Spain   http://www.agile-
spain.com/manifiesto agil




                                        38
Cap´
   ıtulo 1                                                         1.3. El manifiesto ´gil
                                                                                     a

  '                                                                                       $
      Estamos descubriendo mejores maneras de desarrollar software
      tanto por nuestra propia experiencia como ayudando a terceros.
      A trav´s de esta experiencia hemos aprendido a valorar:
            e
            Individuos e interacciones sobre procesos y herramien-
            tas

             Software que funciona sobre documentaci´n exhaustiva
                                                    o

             Colaboraci´n con el cliente sobre negociaci´n de con-
                       o                                o
             tratos

            Responder ante el cambio sobre seguimiento de un
            plan
      Esto es, aunque los elementos a la derecha tienen valor, nosotros
      valoramos por encima de ellos los que est´n a la izquierda.
                                               a
      Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
      Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
      Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,


  &                                                                                       %
      Dave Thomas.


    Tras este manifiesto se encuentran 12 principios de vital importancia para
entender su filosof´ 9 :
                  ıa
      Nuestra m´xima prioridad es satisfacer al cliente a trav´s de entregas
               a                                              e
      tempranas y continuas de software valioso.

      Los requisitos cambiantes son bienvenidos, incluso en las etapas finales
      del desarrollo. Los procesos ´giles aprovechan al cambio para ofrecer
                                   a
      una ventaja competitiva al cliente.

      Entregamos software que funciona frecuentemente, entre un par de
      semanas y un par de meses. De hecho es com´n entregar cada tres o
                                                u
      cuatro semanas.

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

      Construimos proyectos entorno a individuos motivados. D´ndoles el
                                                                    a
      lugar y el apoyo que necesitan y confiando en ellos para hacer el trabajo.

      El m´todo m´s eficiente y efectivo de comunicar la informaci´n hacia
           e       a                                                o
      y entre un equipo de desarrollo es la conversaci´n cara a cara.
                                                      o
   9
     Traducci´n
             o     libre       de       los           principios        publicados        en
http://www.agilemanifesto.org/principles.html


                                            39
1.4. ¿En qu´ consiste el agilismo?: Un enfoque pr´ctico
           e                                     a                       Cap´
                                                                            ıtulo 1


       La principal medida de avance es el software que funciona.

       Los procesos ´giles promueven el desarrollo sostenible. Los patroci-
                     a
       nadores, desarrolladores y usuarios deben poder mantener un ritmo
       constante.

       La atenci´n continua a la excelencia t´cnica y el buen dise˜o mejora
                 o                           e                    n
       la agilidad.

       La simplicidad, es esencial.

       Las mejores arquitecturas, requisitos y dise˜os emergen de la auto-
                                                   n
       organizaci´n de los equipos.
                 o

       A intervalos regulares, el equipo reflexiona sobre c´mo ser m´s eficaces,
                                                          o        a
       a continuaci´n mejoran y ajustan su comportamiento en consecuencia.
                    o

    Este libro no pretende abarcar el vasto conjunto de t´cnicas y metodo-
                                                         e
log´ del agilismo pero, considerando la poca literatura en castellano que
   ıas
existe actualmente sobre este tema, merece la pena publicar el manifiesto.


1.4.      ¿En qu´ consiste el agilismo?: Un enfoque
                 e
          pr´ctico
            a
    El agilismo es una respuesta a los fracasos y las frustraciones del modelo
en cascada. A d´ de hoy, las metodolog´ ´giles de desarrollo de software
                  ıa                        ıas a
est´n en boca de todos y adquieren cada vez m´s presencia en el mundo
   a                                                a
hispano, si bien llevan siendo usadas m´s de una d´cada en otros pa´
                                          a           e                 ıses. El
abanico de metodolog´ ´giles es amplio, existiendo m´todos para organizar
                        ıas a                            e
equipos y t´cnicas para escribir y mantener el software. Personalmente, me
             e
inclino hacia la Programaci´n Extrema (eXtreme Programming, XP) como
                              o
forma de atacar la implementaci´n del producto y hacia Scrum como forma
                                   o
de gestionar el proyecto, pero el estudio de ambas en su totalidad queda fuera
del alcance de este libro.
    Por ilustrarlo a modo de alternativa al modelo en cascada: podemos ges-
tionar el proyecto con Scrum y codificar con t´cnicas de XP; concretamente
                                                  e
TDD10 y Programaci´n por Parejas11 , sin olvidar la propiedad colectiva del
                       o
c´digo y la Integraci´n Continua12 .
 o                    o
  10
     Test Driven Development o Desarrollo Dirigido por Test
  11
     Pair Programming o Programaci´n por Parejas, es otra de las t´cnicas que com-
                                      o                             e
ponen XP y que no vamos a estudiar en detalle en este libro. V´anse en la bibliograf´
                                                                e                   ıa
los textos relacionados con XP para mayor informaci´no
  12
     V´ase el ap´ndice sobre Integraci´n Continua al final del libro
      e          e                    o


                                         40
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD
Diseño Agil con TDD

Más contenido relacionado

La actualidad más candente

Teoria mef
Teoria mefTeoria mef
Teoria mef
Nezta Miranda
 
Tesis de grado
Tesis de gradoTesis de grado
Tutorial algoritmosgeneticos
Tutorial algoritmosgeneticosTutorial algoritmosgeneticos
Tutorial algoritmosgeneticos
ELL Xavi
 
Intr a la matematica discreta
Intr a la matematica discretaIntr a la matematica discreta
Intr a la matematica discreta
royvelarde
 
Plan de mantenimiento de una desalinizadora
Plan de mantenimiento de una desalinizadoraPlan de mantenimiento de una desalinizadora
Plan de mantenimiento de una desalinizadora
Eduardo Romero López
 
Aislación sísmica de un edificio de oficinas
Aislación sísmica de un edificio de oficinasAislación sísmica de un edificio de oficinas
Aislación sísmica de un edificio de oficinas
jules_meza
 
Muestreo y reconstruccion UPTC 2011
Muestreo y reconstruccion UPTC 2011Muestreo y reconstruccion UPTC 2011
Muestreo y reconstruccion UPTC 2011
buxtehude04
 
Exp algoritmos
Exp algoritmosExp algoritmos
Linux benchmarking como
Linux benchmarking comoLinux benchmarking como
Linux benchmarking como
Instituto Tecnologico De Pachuca
 
Volantesde inercia
Volantesde inerciaVolantesde inercia
Volantesde inercia
MARLENYMEDINAROMERO
 
sistemas dinamicos lineales oscar duarte
sistemas dinamicos lineales oscar duartesistemas dinamicos lineales oscar duarte
sistemas dinamicos lineales oscar duarte
vlado1884
 
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
Eduardo Romero López
 
Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1
intoducion a la educacion
 
Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1
Zully Carvache
 
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
Gina Santos
 
Diseño Robusto y Multiobjetivos de Sistemas
Diseño Robusto y Multiobjetivos de SistemasDiseño Robusto y Multiobjetivos de Sistemas
Diseño Robusto y Multiobjetivos de Sistemas
William Colmenares
 
CONTRASTACIÓN IMPORTANTE
CONTRASTACIÓN IMPORTANTECONTRASTACIÓN IMPORTANTE
CONTRASTACIÓN IMPORTANTE
UNT VJ
 

La actualidad más candente (17)

Teoria mef
Teoria mefTeoria mef
Teoria mef
 
Tesis de grado
Tesis de gradoTesis de grado
Tesis de grado
 
Tutorial algoritmosgeneticos
Tutorial algoritmosgeneticosTutorial algoritmosgeneticos
Tutorial algoritmosgeneticos
 
Intr a la matematica discreta
Intr a la matematica discretaIntr a la matematica discreta
Intr a la matematica discreta
 
Plan de mantenimiento de una desalinizadora
Plan de mantenimiento de una desalinizadoraPlan de mantenimiento de una desalinizadora
Plan de mantenimiento de una desalinizadora
 
Aislación sísmica de un edificio de oficinas
Aislación sísmica de un edificio de oficinasAislación sísmica de un edificio de oficinas
Aislación sísmica de un edificio de oficinas
 
Muestreo y reconstruccion UPTC 2011
Muestreo y reconstruccion UPTC 2011Muestreo y reconstruccion UPTC 2011
Muestreo y reconstruccion UPTC 2011
 
Exp algoritmos
Exp algoritmosExp algoritmos
Exp algoritmos
 
Linux benchmarking como
Linux benchmarking comoLinux benchmarking como
Linux benchmarking como
 
Volantesde inercia
Volantesde inerciaVolantesde inercia
Volantesde inercia
 
sistemas dinamicos lineales oscar duarte
sistemas dinamicos lineales oscar duartesistemas dinamicos lineales oscar duarte
sistemas dinamicos lineales oscar duarte
 
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
Estudio de mejora del mantenimiento mediante la aplicación de la distribución...
 
Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1
 
Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1Desarrollo de habilidades del pensamiento. leccion 1
Desarrollo de habilidades del pensamiento. leccion 1
 
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
Desarrollodehabilidadesdelpensamiento leccion1-130415213326-phpapp02
 
Diseño Robusto y Multiobjetivos de Sistemas
Diseño Robusto y Multiobjetivos de SistemasDiseño Robusto y Multiobjetivos de Sistemas
Diseño Robusto y Multiobjetivos de Sistemas
 
CONTRASTACIÓN IMPORTANTE
CONTRASTACIÓN IMPORTANTECONTRASTACIÓN IMPORTANTE
CONTRASTACIÓN IMPORTANTE
 

Similar a Diseño Agil con TDD

Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdfLibro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
Javier Perez
 
Introduccion poo con_java
Introduccion poo con_javaIntroduccion poo con_java
Introduccion poo con_java
Robert Wolf
 
TFM_MJVillanueva
TFM_MJVillanuevaTFM_MJVillanueva
TFM_MJVillanueva
Maria Jose Villanueva
 
Desarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-javaDesarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-java
Victor Basurto Alonso
 
Libro javacontapa
Libro javacontapaLibro javacontapa
Libro javacontapa
Tabu Carlos
 
Libro javacontapa
Libro javacontapaLibro javacontapa
Libro javacontapa
Robert Wolf
 
Pensar en cpp
Pensar en cpp Pensar en cpp
Pensar en cpp
JuliocMendieta
 
Matemáticas Computacionales
Matemáticas ComputacionalesMatemáticas Computacionales
Matemáticas Computacionales
Juan Romero
 
pensar_en_cpp-vol1.pdf
pensar_en_cpp-vol1.pdfpensar_en_cpp-vol1.pdf
pensar_en_cpp-vol1.pdf
macario17
 
Desarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-javaDesarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-java
Freddy Quina
 
Rarepaso
RarepasoRarepaso
Rarepaso
Henry Jinete
 
Teoria de la medida
Teoria de la medidaTeoria de la medida
Teoria de la medida
jhorkham
 
Pensar enc++
Pensar enc++Pensar enc++
Teoriapto
TeoriaptoTeoriapto
Teoriapto
Yhurhy Lhimhachi
 
Vba excel mnumericos1
Vba excel mnumericos1Vba excel mnumericos1
Vba excel mnumericos1
Alejandra Regalado
 
Vba excel numericos
Vba excel numericosVba excel numericos
Vba excel numericos
JOHN BONILLA
 
Vba excel mnumericos
Vba excel mnumericosVba excel mnumericos
Vba excel mnumericos
aprendiendocpp
 
Serie aprender a investigar 5
Serie aprender a investigar 5Serie aprender a investigar 5
Serie aprender a investigar 5
JCASTINI
 
Serie aprender a investigar 5
Serie aprender a investigar 5Serie aprender a investigar 5
Serie aprender a investigar 5
JCASTINI
 
Del Docente Presencial Al Docente Virtual
Del Docente Presencial Al Docente VirtualDel Docente Presencial Al Docente Virtual
Del Docente Presencial Al Docente Virtual
marlonint45
 

Similar a Diseño Agil con TDD (20)

Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdfLibro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
Libro Fundamentos-de-la-programacion O.O-Ruiz-Rodriguez-Ricardo.pdf
 
Introduccion poo con_java
Introduccion poo con_javaIntroduccion poo con_java
Introduccion poo con_java
 
TFM_MJVillanueva
TFM_MJVillanuevaTFM_MJVillanueva
TFM_MJVillanueva
 
Desarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-javaDesarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-java
 
Libro javacontapa
Libro javacontapaLibro javacontapa
Libro javacontapa
 
Libro javacontapa
Libro javacontapaLibro javacontapa
Libro javacontapa
 
Pensar en cpp
Pensar en cpp Pensar en cpp
Pensar en cpp
 
Matemáticas Computacionales
Matemáticas ComputacionalesMatemáticas Computacionales
Matemáticas Computacionales
 
pensar_en_cpp-vol1.pdf
pensar_en_cpp-vol1.pdfpensar_en_cpp-vol1.pdf
pensar_en_cpp-vol1.pdf
 
Desarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-javaDesarrollo proyectos-informaticos-con-java
Desarrollo proyectos-informaticos-con-java
 
Rarepaso
RarepasoRarepaso
Rarepaso
 
Teoria de la medida
Teoria de la medidaTeoria de la medida
Teoria de la medida
 
Pensar enc++
Pensar enc++Pensar enc++
Pensar enc++
 
Teoriapto
TeoriaptoTeoriapto
Teoriapto
 
Vba excel mnumericos1
Vba excel mnumericos1Vba excel mnumericos1
Vba excel mnumericos1
 
Vba excel numericos
Vba excel numericosVba excel numericos
Vba excel numericos
 
Vba excel mnumericos
Vba excel mnumericosVba excel mnumericos
Vba excel mnumericos
 
Serie aprender a investigar 5
Serie aprender a investigar 5Serie aprender a investigar 5
Serie aprender a investigar 5
 
Serie aprender a investigar 5
Serie aprender a investigar 5Serie aprender a investigar 5
Serie aprender a investigar 5
 
Del Docente Presencial Al Docente Virtual
Del Docente Presencial Al Docente VirtualDel Docente Presencial Al Docente Virtual
Del Docente Presencial Al Docente Virtual
 

Más de David Motta Baldarrago

Galaxy S II: samsung publica una guía para la actualización a Android ICS
Galaxy S II: samsung publica una guía para la actualización a Android ICSGalaxy S II: samsung publica una guía para la actualización a Android ICS
Galaxy S II: samsung publica una guía para la actualización a Android ICS
David Motta Baldarrago
 
Android web services - Spring Android
Android web services - Spring AndroidAndroid web services - Spring Android
Android web services - Spring Android
David Motta Baldarrago
 
Repositorio SVN Google Code
Repositorio SVN Google CodeRepositorio SVN Google Code
Repositorio SVN Google Code
David Motta Baldarrago
 
Lo nuevo en Spring 3.0
Lo nuevo  en Spring 3.0Lo nuevo  en Spring 3.0
Lo nuevo en Spring 3.0
David Motta Baldarrago
 
Simple Jdbc With Spring 2.5
Simple Jdbc With Spring 2.5Simple Jdbc With Spring 2.5
Simple Jdbc With Spring 2.5
David Motta Baldarrago
 
Scjp Sun Certified Programmer For Java 6 Exam 310 065
Scjp Sun Certified Programmer For Java 6 Exam 310 065Scjp Sun Certified Programmer For Java 6 Exam 310 065
Scjp Sun Certified Programmer For Java 6 Exam 310 065
David Motta Baldarrago
 
Modelo Del Negocio con RUP y UML Parte 3
Modelo Del Negocio con RUP y UML Parte 3Modelo Del Negocio con RUP y UML Parte 3
Modelo Del Negocio con RUP y UML Parte 3
David Motta Baldarrago
 
Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2
David Motta Baldarrago
 
Modelo Del Negocio con RUP y UML Parte 1
Modelo Del Negocio con RUP y UML Parte 1Modelo Del Negocio con RUP y UML Parte 1
Modelo Del Negocio con RUP y UML Parte 1
David Motta Baldarrago
 
Documentacion De Los Procesos
Documentacion De Los ProcesosDocumentacion De Los Procesos
Documentacion De Los Procesos
David Motta Baldarrago
 
Upgrade Zaptel to DAHDI
Upgrade Zaptel to DAHDIUpgrade Zaptel to DAHDI
Upgrade Zaptel to DAHDI
David Motta Baldarrago
 
Instalacion de Elastix
Instalacion de ElastixInstalacion de Elastix
Instalacion de Elastix
David Motta Baldarrago
 
Los mejores trucos de Asterisk
Los mejores trucos de AsteriskLos mejores trucos de Asterisk
Los mejores trucos de Asterisk
David Motta Baldarrago
 
Instalacion Debian + Asterisk + FreePbx + A2Billing
Instalacion Debian + Asterisk + FreePbx + A2BillingInstalacion Debian + Asterisk + FreePbx + A2Billing
Instalacion Debian + Asterisk + FreePbx + A2Billing
David Motta Baldarrago
 

Más de David Motta Baldarrago (15)

Galaxy S II: samsung publica una guía para la actualización a Android ICS
Galaxy S II: samsung publica una guía para la actualización a Android ICSGalaxy S II: samsung publica una guía para la actualización a Android ICS
Galaxy S II: samsung publica una guía para la actualización a Android ICS
 
Android web services - Spring Android
Android web services - Spring AndroidAndroid web services - Spring Android
Android web services - Spring Android
 
Repositorio SVN Google Code
Repositorio SVN Google CodeRepositorio SVN Google Code
Repositorio SVN Google Code
 
Lo nuevo en Spring 3.0
Lo nuevo  en Spring 3.0Lo nuevo  en Spring 3.0
Lo nuevo en Spring 3.0
 
Simple Jdbc With Spring 2.5
Simple Jdbc With Spring 2.5Simple Jdbc With Spring 2.5
Simple Jdbc With Spring 2.5
 
Scjp Sun Certified Programmer For Java 6 Exam 310 065
Scjp Sun Certified Programmer For Java 6 Exam 310 065Scjp Sun Certified Programmer For Java 6 Exam 310 065
Scjp Sun Certified Programmer For Java 6 Exam 310 065
 
Modelo Del Negocio con RUP y UML Parte 3
Modelo Del Negocio con RUP y UML Parte 3Modelo Del Negocio con RUP y UML Parte 3
Modelo Del Negocio con RUP y UML Parte 3
 
Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2
 
Modelo Del Negocio con RUP y UML Parte 1
Modelo Del Negocio con RUP y UML Parte 1Modelo Del Negocio con RUP y UML Parte 1
Modelo Del Negocio con RUP y UML Parte 1
 
Documentacion De Los Procesos
Documentacion De Los ProcesosDocumentacion De Los Procesos
Documentacion De Los Procesos
 
Upgrade Zaptel to DAHDI
Upgrade Zaptel to DAHDIUpgrade Zaptel to DAHDI
Upgrade Zaptel to DAHDI
 
Instalacion de Elastix
Instalacion de ElastixInstalacion de Elastix
Instalacion de Elastix
 
Elastix Without Tears
Elastix Without TearsElastix Without Tears
Elastix Without Tears
 
Los mejores trucos de Asterisk
Los mejores trucos de AsteriskLos mejores trucos de Asterisk
Los mejores trucos de Asterisk
 
Instalacion Debian + Asterisk + FreePbx + A2Billing
Instalacion Debian + Asterisk + FreePbx + A2BillingInstalacion Debian + Asterisk + FreePbx + A2Billing
Instalacion Debian + Asterisk + FreePbx + A2Billing
 

Último

Manual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputosManual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputos
cbtechchihuahua
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
renzocruz180310
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
jgvanessa23
 
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdktrabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
KukiiSanchez
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
leia ereni
 
El uso de las TIC por Cecilia Pozos S..pptx
El uso de las TIC  por Cecilia Pozos S..pptxEl uso de las TIC  por Cecilia Pozos S..pptx
El uso de las TIC por Cecilia Pozos S..pptx
cecypozos703
 
Manual de soporte y mantenimiento de equipo de cómputo
Manual de soporte y mantenimiento de equipo de cómputoManual de soporte y mantenimiento de equipo de cómputo
Manual de soporte y mantenimiento de equipo de cómputo
doctorsoluciones34
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
KukiiSanchez
 
Presentación de Tic en educación y sobre blogger
Presentación de Tic en educación y sobre bloggerPresentación de Tic en educación y sobre blogger
Presentación de Tic en educación y sobre blogger
larapalaciosmonzon28
 
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
larapalaciosmonzon28
 
Uso de las Tics en la vida cotidiana.pptx
Uso de las Tics en la vida cotidiana.pptxUso de las Tics en la vida cotidiana.pptx
Uso de las Tics en la vida cotidiana.pptx
231485414
 
625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf
yuberpalma
 
El uso de las TIC's en la vida cotidiana
El uso de las TIC's en la vida cotidianaEl uso de las TIC's en la vida cotidiana
El uso de las TIC's en la vida cotidiana
231458066
 
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdfPresentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
giampierdiaz5
 
Nuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsadNuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsad
larapalaciosmonzon28
 
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMAUML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
martinezluis17
 
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdfCURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
LagsSolucSoporteTecn
 
Flows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos FeaturesFlows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos Features
Paola De la Torre
 
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANOREVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
gisellearanguren1
 
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajasSlideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
AdrianaRengifo14
 

Último (20)

Manual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputosManual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputos
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
 
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdktrabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
trabajo práctico kuikikiikkidfsmdklfskdnfklsdnfknsdk
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
 
El uso de las TIC por Cecilia Pozos S..pptx
El uso de las TIC  por Cecilia Pozos S..pptxEl uso de las TIC  por Cecilia Pozos S..pptx
El uso de las TIC por Cecilia Pozos S..pptx
 
Manual de soporte y mantenimiento de equipo de cómputo
Manual de soporte y mantenimiento de equipo de cómputoManual de soporte y mantenimiento de equipo de cómputo
Manual de soporte y mantenimiento de equipo de cómputo
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
 
Presentación de Tic en educación y sobre blogger
Presentación de Tic en educación y sobre bloggerPresentación de Tic en educación y sobre blogger
Presentación de Tic en educación y sobre blogger
 
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
 
Uso de las Tics en la vida cotidiana.pptx
Uso de las Tics en la vida cotidiana.pptxUso de las Tics en la vida cotidiana.pptx
Uso de las Tics en la vida cotidiana.pptx
 
625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf
 
El uso de las TIC's en la vida cotidiana
El uso de las TIC's en la vida cotidianaEl uso de las TIC's en la vida cotidiana
El uso de las TIC's en la vida cotidiana
 
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdfPresentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
 
Nuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsadNuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsad
 
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMAUML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
UML_clase_02_UML_casos_de_uso_05 EN DIAGRAMA
 
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdfCURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
CURSO CAMARAS DE SEGURIDAD 2023 FINAL .pdf
 
Flows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos FeaturesFlows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos Features
 
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANOREVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
 
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajasSlideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
 

Diseño Agil con TDD

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