Planificar la próxima iteración

LA HISTORIA - REUNIÓN DE LANZAMIENTO 181
Vas a cometer errores: no te preocupes
Una vez estaba trabajando en una historia impresa para este proyecto de construcción, y tomé
la ruta del guerrero espartano (entregando la implementación básica). Tan pronto como lo
demostré, podría decir que al cliente simplemente no le gustó.
Eran demasiado educados para decir algo, pero podía sentirlo, y sabía que no era mi mejor
trabajo.
En ese momento, tuve que aguantar y preguntarles si podía intentarlo de nuevo. Ellos dijeron
que si.
Si no hubiera estado entregando durante siete semanas antes de esto, podrían haberme dado
una respuesta diferente. Pero cuando su cliente lo vea reventando su joroba todas las
semanas, lo perdonarán y le dejarán un poco de holgura por el tiempo ocasional que lo
fastidia.
Por lo tanto, no tengas miedo de probar cosas. Intentar y fracasar y tomar la iniciativa es parte
del juego.
A veces descubrirás una historia más grande de lo que pensabas. Está bien. Simplemente divídalo para que
encaje en una sola iteración, actualice el plan y continúe. La buena noticia es que esto funciona en ambos
sentidos (también encontramos que algunas historias son más pequeñas de lo que pensábamos).
No encontrará SPM cubiertos en ningún método ágil formal. Son solo un mecanismo que yo y otros hemos
encontrado útiles para evitar el desperdicio que proviene de comenzar una iteración con una historia sin
analizar.
Pero esa es la belleza de ágil. No hay una sola forma de hacer esto. Si necesita algo, créelo o hágalo usted
mismo (a pesar de lo que diga cualquier autor o libro).
Otra cosa que querrá hacer en cada iteración es obtener comentarios de los clientes.
Informe errata
Descargar desde Wow! eBook <www.wowebook.com>
esta copia es ( Impresión P1.0, septiembre de 2010)
EL CASO 182
10.3 El escaparate
Mostrar algo de IPM Escaparate

valor! Planificar la próxima iteración
Mini-retrospectiva
Iteración (n)
Demuestre las historias de esta iteración
Obtenga comentarios de los clientes
¡Lo hiciste! Entregaste algo de valor. ¿Sabes cuántos proyectos duran semanas, meses y, a veces, años sin
entregar nada de valor? Mucho.
los escaparate es su oportunidad de mostrarle al mundo el gran trabajo que usted y el equipo han estado
haciendo y obtener comentarios reales de su clientela.
Durante un escaparate, usted y todo el equipo muestran las historias de la última iteración. Eso significa
mostrar código real en vivo implementado en un servidor de prueba. No son imágenes bonitas o mejores
intenciones. Es el material con el que podrías ir a la batalla y desplegarte hoy si realmente tuvieras que
hacerlo. Se hace.
Las vitrinas están destinadas a ser divertidas y son una excelente manera de cerrar el trabajo de la última
iteración. ¡Celebrar! Trae bocadillos o dulces. Presumir. Obtenga comentarios Deje que su cliente maneje la
demostración y vea cómo usan el software.
Veamos ahora los métodos ágiles para reuniones como Scrum y XP que recomendamos: la reunión de
planificación de iteración (IPM).
10.4 Planifique la próxima iteración
Escaparate
¡Establezca las expectativas
IPM Planifica la próxima iteración
de la próxima semana!
Mini retrospectiva
Iteración (n)
Verifique la salud del proyecto Revise la
velocidad del equipo Regístrese para historias
y comprométase
Informe errata
P LAN LA TERACIÓN EXT EXT 183
El IPM es donde se reúne con su cliente y planifica el trabajo de la próxima iteración. Usted revisa la
velocidad de su equipo, revisa las próximas historias y luego determina colectivamente cuánto pueden
comprometerse usted y el equipo para el trabajo de la próxima iteración.
Los MIP también son un buen momento para hacer una verificación del estado del mini proyecto.
Cielos despejados Pocas nubes, posibilidad de lluvia Gran tormenta
- Viento en popa - Estamos entregando - Houston, tenemos un problema

- Nada nos frena - Experimentando algunas turbulencias - Grandes desafíos por delante
- Las cosas no podrían ser mejores - Pero nada que no podamos manejar - ¡Necesitamos ayuda!
Aquí puede dar un pronóstico del tiempo rápido sobre cómo va el proyecto. Si hay algo que necesita o hay
un problema particularmente difícil que le gustaría discutir, esta es su oportunidad para plantear el
problema, presentar algunas opciones y hacer algunas recomendaciones sobre cómo le gustaría proceder.
Cuando se trata de hablar sobre fechas, use su cuadro de quemado. Es brutalmente honesto y, de una
manera muy poco emotiva, le dirá a usted y a su cliente cuán realistas son sus citas.
Esfuerzo
restante
Nuevas historias
Ve Ve
l lo cid
oc
id ad
ad rea
es l
tim
ad
a
Iteraciones Hora
¿Qué debemos hacer con
estos?
Informe errata
¿CÓMO HACERSE INI- R ETROSPECTIVA? 184
Cómo dar retroalimentación constructiva
Hay dos formas de dar retroalimentación. Puedes servirlo recto y frío:
• "Suzy, noté que hiciste un gran trabajo en la última iteración del módulo de impresión, pero
sus pruebas unitarias eran realmente deficientes ". O puede agregar una gota de miel y
endulzarla un poco:
• “Suzy, trabajo increíble en el módulo de impresión. Aplique el mismo nivel de detalle a

sus pruebas unitarias, y pronto será de clase mundial ".
¿Ver la diferencia? Al evitar el uso de la palabra pero, Puedes cambiar totalmente el tono y la
entrega del mensaje. No digo que debas cubrir todo con azúcar. Pero cambiando el mensaje a
veces, puede recorrer un largo camino para cambiar el comportamiento.
Para obtener el alcance completo sobre cómo comunicarse de manera efectiva, lea el clásico
de Dale Carnegie Cómo ganar amigos e influir en las personas [ Coche90 ]
Esta es la parte de visibilidad de ágil. Queremos ser lo más transparentes posible con nuestros clientes y
partes interesadas. Malas noticias temprano es el camino ágil.
Lo último que queremos hacer antes de dejar cualquier iteración es preguntarnos si hay algo que podríamos
estar haciendo mejor.
10.5 Cómo alojar una mini retrospectiva
Principio ágil
A intervalos regulares, el equipo reflexiona sobre cómo volverse
más efectivo y luego ajusta y ajusta su comportamiento en
consecuencia.
Las retrospectivas pueden ser grandes, elegantes, asuntos de todo el día que se llevan a cabo al final de un
lanzamiento importante o cerca del final de un proyecto. Eso no es de lo que estoy hablando aquí.
Informe errata
¿CÓMO HACERSE INI- R ETROSPECTIVA? 185
Estas retrospectivas son discusiones rápidas, enfocadas de diez a quince minutos, donde usted y su equipo
se reúnen regularmente y hablan sobre dónde están pateando el trasero y dónde deben mejorar.
La primera regla general para organizar una buena retrospectiva es asegurarse de que todos se sientan
seguros. Si crees que tienes un problema con la seguridad, saca la directiva principal retrospectiva y
recuerda a la gente de qué se trata.
La directiva principal retrospectiva
Independientemente de lo que descubramos, entendemos y realmente

creemos que todos hicieron el mejor trabajo que pudieron, dado lo que
sabían en ese momento, sus habilidades y capacidades, los recursos
disponibles y la situación en cuestión.
En otras palabras, no es una caza de brujas.
Entonces puedes calentar a la gente haciendo la primera pregunta retrospectiva.
1. ¿Qué estamos haciendo realmente bien?
"Jimmy, buen trabajo en esas pruebas unitarias, amigo".
"Suzy. Fue increíble cómo creaste esa guía de estilo y refactorizaste las hojas de estilo para que podamos
mantener fácilmente una apariencia constante en nuestra aplicación ".
Llamar a un buen comportamiento y dar apoyo a las personas que merecen ser reconocidas puede hacer
que las personas se sientan mal y alentar más el tipo de comportamiento que nos gusta ver en nuestros
proyectos.
El otro lado de la ecuación está hablando de dónde podemos mejorar.
2. ¿Dónde necesitamos ser mejores?
“Equipo, muchos errores pasaron ese último lote de historias. Reduzcamos la velocidad, ajustemos las cosas
y asegurémonos de que estamos haciendo suficientes pruebas unitarias ”.
“Estamos viendo mucha duplicación en la base del código. Recuerde tomarse el tiempo y refactorizar el
código a medida que avanza ".
Informe errata
H OW N OT TO H OST AD T ADYY TAND-UP 186
“He arruinado completamente esa historia impresa. Lo siento. Permítanme darle otra oportunidad en esta
iteración, y les prometo que la próxima versión será mucho mejor ".
Cualquiera sea el problema, celebrar una retrospectiva y compartir ideas con los compañeros de equipo es
una excelente manera de reenfocar y energizar al equipo en las áreas que necesitan para apuntalar. Luego,
puede crear un tema para las próximas iteraciones y resaltar y realizar un seguimiento de las áreas que
desea mejorar.
Para obtener la guía definitiva para realizar retrospectivas, consulte Retrospectivas ágiles: hacer buenos
equipos buenos [ DL06 ]
Buen material. Terminemos repasando una excelente manera de alinear rápidamente a todos al comienzo
del día: el stand-up diario.
10.6 Cómo no organizar un stand-up diario
Sincronización diaria rápida para llegar a la misma página
Iteración (n)
Stand-ups diarios
Coordina actividades con el resto del equipo Corto (<10 min)

Sin estar sentado
El stand-up diario se trata de compartir información importante con su equipo rápidamente. Es la reunión
para finalizar todas las reuniones. Tiene una duración de cinco a diez minutos, no se requieren sillas (para
recordarles a las personas que lo mantengan breve), y básicamente brinda una actualización sobre lo que
está trabajando y comparte todo lo que cree que el resto del equipo necesita saber.
Ahora, la mayoría de los libros de texto ágiles le dirán que cuando hace una parada diaria, debe pararse en
un círculo y hacer que todos en el equipo le digan a todos lo siguiente:
• Lo que hicieron ayer
• Lo que están haciendo hoy
• Si hay algo que los frena
Informe errata
HACER LO QUE FUNCIONE PARA USTED 187
Buena información. Simplemente no es muy inspirador o cambia el comportamiento.
En su lugar, intente reunirse con su equipo al comienzo de cada día y, en su lugar, dígales lo siguiente:
• Lo que hiciste para cambiar el mundo ayer
• Cómo vas a aplastarlo hoy
• Cómo vas a atravesar cualquier obstáculo lo suficientemente desafortunado como para estar en tu
camino
Responder este tipo de preguntas cambia por completo la dinámica del stand-up. En lugar de solo pararte
allí y dar una actualización, ahora estás poniendo toda la línea y declarando tu intención al universo.
Cuando haces esto, una de dos cosas va a suceder. O vas a seguir adelante y cumplir o no. Depende
completamente de usted.
Pero puedo decirte esto: si apareces todos los días y declaras públicamente a tus compañeros lo que estás
comprometido personalmente a hacer ese día, aumenta dramáticamente las posibilidades de que lo hagas.
10.7 Haz lo que sea que funcione para ti
Ahora, en caso de que se pregunte si todos estos deben ser reuniones separadas o si puede agruparlos en
uno solo ... depende completamente de usted.
Para reducir al mínimo el número de reuniones, a algunos equipos les gusta combinar el escaparate, la
planificación de la próxima iteración y retroceder todo en uno y hacerlo en una hora (esa es mi preferencia,
y eso es lo que he presentado aquí bajo un IPM )
Otros prefieren separar la planificación de las vitrinas y hacer lo retro como una actividad divertida cerca del
final de la semana.
Y algunos equipos tienen un contacto tan bueno con sus clientes que no necesitan reuniones dedicadas de
planificación de historias (SPM). Simplemente hablan todos los días y tienen una sesión de diseño cuando
lo necesitan.
Recuerde, no hay una sola forma de hacer esto. Si algo no agrega valor, suéltelo. Pruebe diferentes cosas y
vea lo que funciona para usted.
Solo asegúrese de que en algún momento durante su iteración se ponga delante de su cliente, muéstrele un
software que funcione, establezca expectativas y busque formas de mejorar.
Informe errata
UH oh. Parece que Master Sensei quiere ver si estás recogiendo algo de esto. Mejor pase al dojo y vea si
algo de esto tiene sentido. ¡Buena suerte!
Maestro Sensei
y el aspirante a
guerrero
Bienvenido de nuevo, estudiante. He preparado tres lecciones para probar su temple en varios escenarios
mecánicos de iteración de la vida real. Lea cada uno detenidamente antes de responder.
Escenario # 1: La historia incompleta
MAESTRO: Un día, durante un IPM, se hizo evidente que una historia solo estaba medio completa.
Queriendo mostrar el progreso, el joven gerente de proyecto quería contar la mitad de los puntos de la
historia hacia la velocidad del equipo de esta iteración y luego contar la otra mitad cuando la historia se
completó la próxima iteración. ¿Es esta una buena idea?
ESTUDIANTE: Bueno, si la historia está realmente hecha a medias, no veo ningún daño en reflejar con
precisión el estado de la historia contando la mitad de los puntos de la historia hacia la velocidad de esta
iteración y trasladando la otra mitad a la siguiente iteración.
MAESTRO: ¿Es eso así? Contéstame esto. ¿Puede un granjero transportar su arroz?
en un carro con una rueda? ¿Puede un hombre comer con un solo palillo? ¿Puede un cliente entrar en
producción con la mitad de una función?
ESTUDIANTE: ¿No, sensei?
MAESTRO: Para el guerrero ágil no hay 1/2, 3/4 hecho o 4/5 hecho para una historia de usuario. La historia
está completa, o no lo está. Por esa razón, el guerrero solo cuenta historias completamente probadas y
completadas hacia la velocidad de su iteración. Cualquier historia incompleta se transfiere.
Informe errata
Escenario n. ° 2: los enfrentamientos diarios no están agregando valor
MAESTRO: Una vez hubo un equipo luchando para que los miembros asistieran a sus stand-ups diarios.
Los miembros del equipo pensaron que las reuniones no agregaban mucho valor y que podrían estar mejor
trabajando y hablando entre sí cuando sea necesario. ¿Qué debe hacer el equipo?
ESTUDIANTE: El líder del equipo debe recordar a todos la importancia de mantener a todos en la misma
página y el importante papel que juega el stand-up diario para lograrlo.
MAESTRO: Si. El equipo podría revisar los objetivos del stand-up diario y por qué se creó en primer lugar.
Pero, ¿qué pasa si, a pesar de eso, el equipo todavía siente que las reuniones son innecesarias?
ESTUDIANTE: No te estoy siguiendo, Sensei. ¿Cómo podría traer cada

uno juntos rápidamente todos los días, y poner a todos al día en el proyecto, ¿alguna vez se considera una
pérdida de tiempo?
MAESTRO: A pesar de todos los beneficios que provienen de una buena posición diaria, no es la única
forma. Si un equipo está ubicado conjuntamente, es pequeño y trabaja en estrecha colaboración entre sí y
con sus clientes de manera continua durante todo el día, puede que no siempre se requiera un stand-up
diario.
ESTUDIANTE: ¿Estás diciendo que algunos equipos no necesitan stand-ups diarios?
MAESTRO: Estoy diciendo que los equipos deben mantener esas prácticas que agregan
valor. Deben modificar o descartar los que no lo hacen.
Escenario # 3: La iteración donde no se produjo nada de valor
MAESTRO: Hubo una vez un equipo que realizó una iteración completa sin
ser capaz de entregar cualquier cosa de valor. El fracaso fue totalmente de su propia creación. No
planificaron, comenzaron tarde y, en general, eran flojos. Sabiendo que esto iba a ser un mensaje difícil de
entregar, cancelaron el escaparate con su cliente. ¿Fue esto sabio?
ESTUDIANTE: Aunque parte de mí siente que el equipo debería enfrentar la música por no entregar nada
de valor, supongo que si no tienen nada que mostrar, sería aceptable cancelar el escaparate. Sin embargo,
prefiero que sean honestos en cuanto a por qué.
MAESTRO: Ah ... te estás volviendo sabio, estudiante. No entregar nada de valor sucede de vez en
cuando, pero generalmente no por diseño o por falta de esfuerzo. ¿Cómo puede el equipo corregir esta
pereza en el comportamiento?
Informe errata
ESTUDIANTE: ¿Estás sugiriendo que se queden con el escaparate, Maestro? ¿Y enfrentar a sus clientes
sin tener nada de valor que mostrar?
MAESTRO: Hai! A veces sentir el aguijón de la vergüenza es el mejor maestro. Enfrentarse a sus clientes y
no tener nada que mostrar puede ser una experiencia humillante. Una vez experimentado, no es algo que
los equipos quieran volver a hacer.
ESTUDIANTE: Gracias maestro. Contemplaré esto más.
No intente evitar situaciones desagradables en su proyecto. A veces son tu mejor maestro. Admite tus
errores, comparte lo que has aprendido con los demás y sigue adelante.
¿Que sigue?
Con un plan de comunicación en la mano y una buena comprensión de cómo funciona el desarrollo iterativo,
está en un buen lugar para ver cómo los mejores equipos ágiles lo convierten en un punto a la hora de
ejecutar con fi abilidad.
A continuación, aprenderá los secretos del espacio de trabajo visual y cómo aprovecharlo para mantenerlo a
usted y a su equipo con energía y concentración.
Informe errata
Capítulo 11
Configurar un espacio de trabajo visual
Las tablas de estado de vuelo son geniales. En un vistazo rápido puede ver lo que viene, lo que va y lo que
se ha cancelado por completo.
¿Por qué no hacer lo mismo para tu proyecto?
Al aprender a crear un espacio de trabajo visual, usted y el equipo nunca perderán qué hacer a continuación
o dónde pueden agregar el mayor valor. Esto no solo le permitirá trabajar con mayor claridad y enfoque,
sino que la mayor transparencia también lo ayudará a establecer expectativas con los poderes que existen.
Hablando de eso, aquí vienen ahora.
11.1 Uh-oh ... ¡Aquí vienen los Heavies!
Ha habido una gran sacudida en las empresas. Los presupuestos han sido recortados. Las líneas de tiempo
han sido cortadas. Y todo debe hacerse mejor, más rápido y más barato.

U H-OH ... H ERE C OME THE H EAVIES! 192
Como resultado, se le ha pedido que haga más con menos. La gerencia desea que entregue la misma
cantidad de funcionalidad, con la mitad del equipo, un mes antes de lo previsto. Si no.
Todo está cayendo duro y rápido, y mañana quieren concertar una reunión con usted para confirmar que
está de acuerdo con el nuevo plan.
¡Trago! ¿Qué haces? Lo que están pidiendo es completamente irracional. Tú lo sabes. El equipo lo sabe.
Parece que son los únicos que no lo hacen.
¿Qué podría hacer para demostrar que si bien no le gustaría nada más que poder ofrecer la misma cantidad
de funcionalidad con la mitad de los recursos, no va a suceder?
Llevando a los ejecutivos a la velocidad
En lugar de organizar una reunión formal y defender su caso en PowerPoint, invita a los ejecutivos a su área
de trabajo para ver primero y el estado del proyecto.
Comienzas llevándolos a través de la plataforma de inicio para tu proyecto, que convenientemente has
publicado en el muro.
¿Por qué Tono de Caja de

estamos aquí? ascensor producto
Conoce a los Mostrar

NO lista
vecinos solución
Que va a
Por la noche Dimensionarlo dar
¿Qué va a
tomar?
El mazo de inicio, usted explica, es una herramienta que usted y el equipo usan para asegurarse de que
nunca pierdan de vista el objetivo del proyecto. Al hacerlo visible,
Informe errata
siempre sabe quién es el cliente, qué busca y, lo más importante, por qué decidimos gastar dinero en este
proyecto en primer lugar.
Impresionados, los ejecutivos se acercan y le preguntan en qué parte del proyecto se encuentra. Para
responder eso, entonces diriges su atención a tu liberar la pared.
El muro de lanzamiento Cartas de historia restantes
I1 I2 I3 Iteración 4 Que hacer
Historias que
hemos hecho
Parece que estamos casi ½ camino
allí
El muro de lanzamiento es donde usted y el equipo realizan un seguimiento de lo que se ha hecho y lo que
queda. El lado izquierdo de la pared muestra las características que el cliente ha analizado, desarrollado,
probado y examinado completamente (están listas para ser enviadas). Y el lado derecho muestra esas
historias que aún deben desarrollarse.
En cuanto a lo que el equipo está trabajando en esta iteración, atrae la atención de la administración al
guión gráfico de esta iteración.
El storyboard
Iteración actual Estado de las historias de usuario de esta iteración
No empezado En progreso Listo para la prueba Hecho
En construcción Listo para revisar Bendecido y visto por

Análisis realizado
nuestro cliente
Informe errata
El guión gráfico rastrea el estado de las características de esta iteración (o lo que llamamos historias del
usuario). Las características aún por desarrollar viven a la izquierda, mientras que las que han sido
construidas y bendecidas por el cliente viven a la derecha. A medida que la historia se desarrolla más, se
mueve en todos los ámbitos de izquierda a derecha. Solo cuando está completamente desarrollado,
probado y examinado por el cliente, pasa a la columna Listo.
Mirando sus relojes, luego van al grano y preguntan cuándo tú

Espero que se haga.
Para responder eso, los lleva a los únicos dos cuadros en su muro que aún no los ha mostrado: la velocidad
de su equipo y el cuadro de quemado del proyecto.
Velocidad del equipo Proyecto quemado
V = 15 pts
Velocidad
(pts)
alimenta
Iteraciones Iteraciones
Qué tan rápido vamos Cuando esperamos terminar
Explica que la velocidad del equipo es lo más cercano que usted y el equipo tienen para medir el nivel de
productividad del equipo. Al medir cuánto hace el equipo cada semana y usarlo como base para planificar
en el futuro, el equipo puede predecir con precisión cuándo esperan que se haga. Esto se muestra en el
cuadro de quemado del proyecto.
El proyecto quema (ver arriba en la Sección 8.5 , La tabla de quemaduras,

en la página 148 ) toma la velocidad del equipo y extrapola la velocidad a la que el equipo se está
"quemando" a través de la lista de deseos del cliente. El proyecto se realiza cuando el equipo entrega todo
en la lista o el proyecto se queda sin dinero (lo que ocurra primero).
Con el escenario preparado, ahora señala con calma lo que ya debería ser obvio para todos en la sala.
Reducir a la mitad el equipo de desarrollo reduciría efectivamente la productividad del equipo a la mitad.
Informe errata
¿CÓMO CIFRAR EL ESPACIO DE TRABAJO AVISUAL? 195
Impresionados con su dominio de la situación, los ejecutivos le agradecen su tiempo y pasan a su próxima
reunión de proyecto.
Unas semanas más tarde, recibirá un correo electrónico explicando que debido a que la compañía se dirige
en una nueva dirección estratégica, su proyecto se cancelará (la vida es así a veces).
Sin embargo, la buena noticia es que estaban tan impresionados con la forma en que manejaste tu
proyecto, ¡quieren que juegues un papel principal en la nueva iniciativa!
Este es solo un ejemplo artificial de cómo un espacio de trabajo visual puede ayudarlo a establecer
expectativas con las partes interesadas y hacer que la realidad de una situación sea evidente. Pero donde
realmente brilla es en ayudarlo a usted y a su equipo a ejecutar y concentrarse.
Ahora repasemos algunas ideas para crear su propio espacio de trabajo visual.
11.2 Cómo crear un espacio de trabajo visual
Crear un buen espacio de trabajo visual es bastante sencillo. Para equipos nuevos a ágiles, generalmente
recomiendo comenzar con lo siguiente:
• Un muro
• Un muro de liberación
• Un gráfico de velocidad y quemado
• Una cubierta de inicio, si tienen la habitación
El mazo de inicio es bueno porque le recuerda al equipo por qué están allí y de qué se trata realmente (que
puede ser fácil perder de vista cuando su cabeza está enterrada en su proyecto).
El muro de la historia es genial porque cualquier mañana cualquiera puede entrar y saber exactamente lo que
debe hacerse a continuación.
Informe errata
¿CÓMO CIFRAR EL ESPACIO DE TRABAJO AVISUAL? 196
Muro de la historia
No empezado
Complemento
de Twitter
Error crítico de la
misión
El muro de la historia también le mostrará los cuellos de botella que tiene en el sistema y hacia dónde
querrá dirigir los recursos.
El storyboard
Iteración actual
No empezado En progreso Listo para la prueba Hecho
El desarrollador ágil
¡Recursos necesarios aquí!
La pared de lanzamiento es algo hermoso, porque cualquiera puede entrar a su habitación y ver el estado
de su proyecto de un vistazo. Esto es lo que se hace. Esto es lo que queda. No se requieren matemáticas
sofisticadas ni hojas de cálculo de Excel.
Y como hablamos extensamente en la planificación ágil, nada establece las expectativas mejor que un buen
cuadro de quemado. Mantenga a uno de estos bebés en su pared, y siempre sabrá cuán realistas son sus
citas y qué tendencias tiene.
Informe errata
S CÓMO NUESTRO I NTENT 197
Y, por supuesto, esto es solo el comienzo. Si tiene otras imágenes, maquetas o diagramas que lo ayuden a
usted y a su equipo a ejecutar, péguelos allí y haga que sean visibles para todos.
Aquí hay algunas otras ideas para crear su espacio de trabajo visual.
11.3 Muestra tu intención
Los acuerdos de trabajo consisten en poner una estaca en el suelo como equipo y decir: "Así es como a
nosotros como equipo nos gusta trabajar". Es una forma de establecer expectativas con todos los miembros
del equipo sobre cómo va a funcionar su equipo y qué se espera de las personas si se unen a usted en este
viaje.
Los valores compartidos son los mismos, solo que más sensibles. Si el equipo se ha quemado en el pasado
porque se vieron obligados a comprometer la calidad y ya no quieren ser conocidos como ese equipo que
corta las esquinas y escribe software malo, pueden publicar sus valores compartidos y darlo a conocer.
Acuerdos de trabajo Valores compartidos
* *Horas principales de 9 a.m. a 4 p.m. * * No cortamos esquinas
* * Levántate a diario a las 10 en punto * * Sin ventanas rotas
* * Hecho incluye pruebas * *Está bien no estar de acuerdo
* *Respeta la construcción * * Podemos manejar la verdad
* * Cuando alguien te pida ayuda, di * * No asumas, pregunta
"sí" * * En caso de duda, escriba una prueba
* * Demo semanal martes 11am * * Ansia comentarios
* * Cliente disponible 1-3 pm * * Compruebe su ego en la puerta
La otra cosa que desea asegurarse de compartir en su proyecto es el idioma.
Informe errata
C REAR Y COMPARTIR AC OMMON D OMAIN LENGUAJE 198
11.4 Crear y compartir un idioma de dominio común
Nuestro idioma de dominio
Ubicación: Dispositivo:
Medidor: Punto de medición:
Cuando las palabras utilizadas en su software no coinciden con las utilizadas por las empresas, puede
meterse en todo tipo de problemas.
• Las abstracciones incorrectas se integran en el software (las empresas pensarán ubicación significa
una cosa, mientras que los desarrolladores lo interpretarán como algo diferente).
• El software se vuelve más difícil de cambiar (porque las palabras que aparecen en la pantalla no
coinciden con las utilizadas para almacenarlo en la base de datos).
• Termina con más errores y mayores costos de mantenimiento (porque el equipo tiene que trabajar
más duro al hacer cambios en el software).
Informe errata
MIRAR LAS MANGUERAS 199
Para evitar esta disfunción, cree un lenguaje común que usted y la empresa compartan y úselo
implacablemente en sus historias de usuario, modelos, imágenes y código.
Por ejemplo, si hay algunas palabras clave que usted y su cliente usan cuando habla sobre el sistema,
escríbalas, presente definiciones claras sobre el significado de estas palabras y luego asegúrese de que
coinciden con esas definiciones en el software (que es decir, pantallas, código y columnas de la base de
datos).
Hacer esto no solo minimizará los errores y el reprocesamiento, sino que también hará que sea más fácil
hablar con su cliente porque su código siempre estará al tanto de cómo hablan sobre su negocio.
No tenemos el tiempo ni el espacio para hacer justicia a este tema. Pero hay un excelente libro sobre el
tema de Eric Evans: Diseño basado en dominios: abordar la complejidad en el corazón del software. [ Eva03 ]
Vale la pena leerlo.
Finalmente, cuida tus errores.
11.5 Mira esos errores
# # de errores Demasiados errores ... ataque!
hora
Informe errata
Para asegurarse de que usted y su equipo no se vean abrumados por un ataque sorpresa de errores justo
antes de pasar a la producción, realice un seguimiento y mantenga su cuenta regresiva desde el primer día de
su proyecto.
Si ayuda, dedique el 10 por ciento de cada iteración a la corrección de errores y al pago de la deuda
técnica. Simplemente aplasta a esos insectores en el acto y no dejes que ese recuento de insectos se te
escape.
Maestro Sensei
y el aspirante a
guerrero
ESTUDIANTE: Maestro, ¿qué pasa si mi lugar de trabajo no me permite crear un espacio de trabajo visual?
¿Qué tengo que hacer?
MAESTRO: Es cierto que algunos entornos de trabajo de oficina resisten el proyecto

equipos que colocan sus artefactos de trabajo en la pared. Cuando se enfrente con esta resistencia, acepte
que está allí y decida cómo proceder.
ESTUDIANTE: Si señor. ¿Pero debería luchar por el espacio de trabajo visual? ¿O simplemente aceptar que no
puedo tener uno?
MAESTRO: Eso depende de ti. Puedes comprometerte. Puedes consentir. O puedes confrontar. Hay un
tiempo y lugar para cada uno. Busca en tu corazón, busca aliados y decide si esta batalla vale la pena.
ESTUDIANTE: Si esta es realmente una práctica importante, ¿qué se puede hacer para
¿compromiso?
MAESTRO: Cuando se enfrentan a situaciones como estas, algunos guerreros han encontrado que crear
guiones gráficos plegables es útil para mantener limpio el lugar de trabajo, al tiempo que permite al equipo
comunicarse abiertamente durante el día. Otros han utilizado herramientas en línea y guiones gráficos
virtuales para compartir información importante, así como para mantener al equipo sincronizado.
ESTUDIANTE: Entonces, mi espacio de trabajo visual no siempre tiene que ser

¿físico?
MAESTRO: No. Lo físico es lo mejor, pero a veces no siempre es posible.
Informe errata
ESTUDIANTE: ¿Qué pasa si elijo confrontar? ¿Que debería hacer entonces?
MAESTRO: Puede comenzar simplemente creando un espacio de trabajo visual, usarlo diariamente para su
proyecto y esperar que, a través del diálogo y la educación, los beneficios se hagan evidentes.
ESTUDIANTE: ¿Y si no lo hacen?
MAESTRO: Entonces, la causa raíz suele ser una basada en la emoción. Puede haber fuerzas
diametralmente opuestas a lo que está tratando de lograr. Trata de empatizar y comprender el espíritu
detrás de esas fuerzas que están en tu contra. Quizás a través del diálogo podrá encontrar una solución que
funcione para ambas partes. El tiempo y la paciencia pueden ser tus mejores aliados aquí.
¿Que sigue?
Tu viaje está casi completo. Tienes a todos en el autobús (Capítulo 3 , Cómo subir a todos en el autobús, en
la página 48 ), tienes el plan (Capítulo 8 , Planificación ágil: lidiar con la realidad, en la página 130 ), y sabes lo
que se necesita para ejecutar.
La siguiente parte del libro, "Ingeniería de software ágil", se centra en las prácticas básicas de ingeniería de
software ágil que usted y su equipo necesitarán para hacer que todo esto sea ágil.
Es una lectura obligada si corta el código, pero también se recomienda si alguna vez planea liderar un
proyecto ágil. Ninguna de estas cosas ágiles funciona a menos que esté respaldada por algunas prácticas
técnicas realmente sólidas, y aunque cada uno de los siguientes cuatro capítulos podría ser un libro en sí
mismo, los capítulos aquí le darán una idea suficiente para comprender cómo funcionan las prácticas y por
qué son importantes para la agilidad general de tu equipo.
Comenzaremos por echar un vistazo a uno de los mejores ahorradores de tiempo de cualquier proyecto de software: las
pruebas unitarias automatizadas.
Informe errata
Parte v
Crear software ágil

Capítulo 12
Prueba unitaria: saber que funciona
Durante todo el tiempo dedicado a la planificación y gestión de expectativas, los procesos ágiles no
funcionan a menos que estén respaldados por un conjunto sólido de prácticas de ingeniería de software.
Aunque algunas prácticas, como la programación de pares de XP, han sido controvertidas, otras, como las
pruebas unitarias automatizadas, han sido ampliamente aceptadas.
En los cuatro capítulos finales del libro, aprenderemos sobre lo que me gusta llamar los no-cerebros de la
ingeniería de software ágil:
• Examen de la unidad
• Refactorización
• Desarrollo basado en pruebas (TDD)
• Integración continua

¡BIENVENIDO A V EGAS, B ABY! 204 204
Cada uno de estos capítulos podría ser fácilmente un libro en sí mismo, pero al presentarle los conceptos
aquí, al menos tendrá una buena comprensión de lo que son y conocerá lo suficiente de la mecánica para
que usted y su equipo trabajen.
Todos los ejemplos están en Microsoft .NET C # (aunque los conceptos se pueden aplicar a todos los
lenguajes en general). Y no te preocupes si eres del tipo no técnico. Estas son cosas buenas para que
tengas en cuenta, y destacaré las cosas importantes a medida que avanzamos.
Comencemos con la práctica que sustenta la mayor parte de lo que hacemos cuando se trata de ingeniería
de software ágil: pruebas unitarias rigurosas y extensas.
12.1 ¡Bienvenido a Las Vegas, bebé!
Eres un perro con suerte! ¡Te acabas de unir a un equipo de desarrolladores de software que está creando un nuevo
simulador de Black Jack! Su primera tarea es diseñar una baraja de cartas.
Aquí está su primer corte del código en C # para una baraja completa de cartas:
Descargar tdd / src / Deck.cs
clase pública Cubierta {
solo lectura privada IList <Card> cards = nuevo Lista <Card> ();
público Cubierta () {
tarjetas.Add (Card.TWO_OF_CLUBS); cards.Add

(Card.THREE_OF_CLUBS);
// .. clubes restantes
cards.Add (Card.TWO_OF_DIAMONDS); cards.Add

(Card.THREE_OF_DIAMONDS);
// ... diamantes restantes
cards.Add (Card.TWO_OF_SPADES); cards.Add

(Card.THREE_OF_SPADES);
// ... espadas restantes
cards.Add (Card.TWO_OF_HEARTS); cards.Add

(Card.THREE_OF_HEARTS);
// ... diamantes restantes
// bufón
tarjetas.Add (Card.JOKER); }
Informe errata
¡BIENVENIDO A V EGAS, B ABY! 205
Escriba una prueba de unidad fallida antes de corregir el error
Cuando descubre un error en su software, es tentador saltar allí y solucionarlo. No lo hagas En

su lugar, primero capture el error en forma de una prueba de unidad que falla y luego corríjalo.
Hacer esto asegurará lo siguiente:
• Demuestra que entiendes la naturaleza del error
• Darte confianza la has fi jado
• Asegúrese de que el error nunca vuelva a entrar en su programa
Usted lo hace a través de la revisión por pares, todo se ve bien, y justo antes de que esté listo para entrar en
producción, QA encuentra un error. ¡No hay una carta de comodín en un mazo de Black Jack! Usted corrige el
error, le da al QA una nueva compilación y lo lanza a producción.
Luego, un par de semanas después, recibió un desagradable correo electrónico del gerente de control de
calidad informándole que hubo un error importante en la producción anoche. Debían reembolsarse decenas
de miles de dólares porque alguien puso un comodín en el Tarjeta ¡clase!
"¿Qué?" tu dices. "Imposible. Lo solucioné hace un par de semanas. Profundizando más, descubres que
una estudiante de verano a la que estabas orientado te tomó demasiado literalmente cuando le pediste que
se asegurara de que tu clase de baraja de cartas se comportara como una baraja física con la que le diste
una prueba.
Parece que, sin darse cuenta, agregó el comodín de nuevo a la cubierta, pensando que había encontrado un
error.
Avergonzado y avergonzado, el estudiante de verano se disculpa contigo y con el resto del equipo. Detrás
de puertas cerradas, ella le pregunta qué puede hacer para asegurarse de que algo así nunca vuelva a
suceder.
Que le dices ¿Qué podría haber hecho ella (o usted) para asegurarse de que el error del comodín no tuviera
ninguna posibilidad de volver a entrar en la base de código una vez que se haya corregido?
En este sentido, echemos un vistazo a la humilde prueba de la unidad.
Informe errata
ENTRE LA PRUEBA DE U NIT 206
12.2 Ingrese la prueba de la unidad
Las pruebas unitarias son pequeñas, las pruebas a nivel de método que los desarrolladores escriben cada vez que realizan un
cambio en el software para demostrar que los cambios que hicieron funcionan como se esperaba.
Por ejemplo, supongamos que queríamos verificar que nuestro mazo de cartas tuviera cincuenta y dos
cartas (y no cincuenta y tres). Podríamos escribir una prueba unitaria que se vería así:
Descargar tdd / test / DeckTest.cs
[Accesorio de prueba]
clase pública DeckTest {
[Prueba]
vacío público Verify_deck_contains_52_cards () {
var deck = nuevo Cubierta();

Assert.AreEqual (52, deck.Count ()); }
Para ser claros, el código anterior no es el código real que ejecutamos como parte de nuestro simulador Black
Jack en producción. Este es un código de prueba que verifica que nuestro código real funciona como se
esperaba.
Siempre que tengamos dudas sobre cómo se va a comportar nuestro código o si queremos verificar que está
haciendo lo que esperamos, escribimos una prueba unitaria (en este caso, una que verifique que nuestro mazo
tiene cincuenta y dos cartas).
Las pruebas unitarias son invaluables porque una vez que automatizamos y hacemos que sean fáciles de
ejecutar, podemos ejecutarlas cada vez que hacemos un cambio en nuestro software y sabemos
instantáneamente si rompimos algo (más sobre esto en el Capítulo 15 , Integración continua: Haciéndolo
listo para la producción, en la página 236 )
Por lo general, los proyectos ágiles tendrán cientos, si no miles, de pruebas unitarias. Recorrerán toda la
aplicación probando todo, desde la lógica comercial de nuestra aplicación hasta si podemos almacenar la
información de nuestros clientes en la base de datos.
Los beneficios de escribir muchos de estos contra su base de código son muchos:
• Te dan retroalimentación instantánea.
- Cuando realice cambios en su código y se rompa una prueba unitaria, lo sabrá al instante (no
tres semanas después de que haya entrado en producción).
Informe errata
Pruebe todo lo que posiblemente pueda romperse
Extreme Programming (XP) tiene un mantra llamado "probar todo lo que pueda romperse". Es
un recordatorio para los desarrolladores que si hay algo que creen que tiene una posibilidad
razonable de romper el sistema, entonces deberían escribir una prueba automatizada en su
contra.
Nunca podemos probar todo, pero la práctica captura el espíritu de cuán ágil quiere que los
equipos piensen en las pruebas. Pruebe todo lo que crea que necesita para asegurarse de que
su software funciona y utilice su criterio para determinar dónde puede obtener el máximo
rendimiento de su inversión. En el capitulo 14 , Desarrollo guiado por pruebas, en la página 225 ,
veremos cómo el desarrollo de la prueba de manejo puede ayudarlo a encontrar dónde
maximizar sus dólares de prueba, así como a encontrar el equilibrio adecuado entre tratar de
probar todo versus probar lo suficiente.
• Reducen drásticamente el costo de las pruebas de regresión.
- En lugar de tener que volver a probar todo manualmente cada vez que lanzamos una nueva
versión, nos ahorramos un montón de tiempo al automatizar las cosas fáciles para que
tengamos más tiempo para probar las cosas complicadas.
• Reducen enormemente el tiempo de depuración.
- Cuando falla una prueba unitaria, usted sabe exactamente dónde está el problema. No más
disparar al depurador y recorrer miles de líneas de código, buscando el fragmento de código
ofensivo. Las pruebas unitarias atraviesan la niebla como un láser y le muestran exactamente
dónde está el problema.
• Te permiten desplegar con confianza.
- Simplemente se siente bien en la producción sabiendo que tiene un conjunto de pruebas

automatizadas que lo respaldan. No son infalibles, pero te liberan para probar las otras partes
más interesantes / complicadas de tu sistema.
Piensa en las pruebas unitarias como la armadura que usas antes de entrar en batalla. Se convierten en una
forma de especificación ejecutable que vive para siempre en su código,
Informe errata
protegiéndote de misiles, dragones reales e imaginarios y, lo más importante, de nosotros mismos.
s
jo
vie ue
os le sq r
ich mp na
B si cio
sa
s fun
Co ría
n
be
de
mano
Error hu
Problemas de
configuración
Lógica básica
Advertencia: también se encontrará periódicamente con casos en los que escribir una prueba automatizada
es difícil. Por ejemplo, escribir una prueba para verificar que podríamos barajar nuestro mazo de cartas es
difícil (ya que la respuesta es aleatoria y cambiaría cada vez). Además, probar concurrencia y aplicaciones
multiproceso puede ser un desafío, por decir lo menos.
Cuando te encuentres con casos como estos, no te desesperes. Son la excepción más que la norma. En la
abrumadora cantidad de casos, podrá crear instancias de un objeto y hacer afirmaciones sobre los métodos
que llame. Esto es aún más posible con todos los marcos de prueba de unidades disponibles actualmente.
En esos raros casos en los que no puede probar algo fácilmente, puede ser un problema con su diseño
(consulte el Capítulo 14 , Desarrollo guiado por pruebas,
en la página 225 ) O tal vez has heredado un código heredado que es realmente difícil de probar.
Si este es el caso, que así sea. Acepta que no podrás probar todo. Asegúrate de cubrirlo con algunas
pruebas manuales y exploratorias realmente buenas, y sigue adelante.
Simplemente no te rindas! Siempre trate de automatizar esa porción de código, porque tener esa pequeña
armadura adicional realmente puede salvar su tocino cuando llegue esa solicitud de reparación de error de
emergencia y tenga que liberarlo rápidamente.
Informe errata
También puedes leer Michael Feathers ' Trabajando efectivamente con código heredado [ Fea04 ], que tiene
muchas sugerencias invaluables sobre cómo trabajar duro con el código heredado y hacerlo más abierto al
cambio.
Ahora tu intenta
Vamos a hacerte pensar como un probador. ¿Qué pruebas unitarias crees que podríamos escribir contra
nuestra clase de mazo de cartas dados los siguientes requisitos? ¿Cómo podríamos evitar que ese
desagradable error de comodín vuelva a aparecer?
Si sus pruebas se parecen a estas, está en el camino correcto. Queremos probar todo lo que pueda
romperse, por lo que si sospecha que algo podría salir mal, póngase cómodo y escriba una prueba.
Descargar tdd / test / DeckTest.cs
[Accesorio de prueba]
clase pública DeckTest2 {
[Prueba]
vacío público Verify_deck_contains_52_cards () {
var deck = nuevo Cubierta();

Assert.AreEqual (52, deck.Count ()); }
[Prueba]
vacío público Verify_deck_contains_thirteen_cards_for_each_suit () {
Var Deck = nuevo Cubierta();

Assert.AreEqual (13, Deck.NumberOfHearts ()); Assert.AreEqual (13,
Deck.NumberOfClubs ());
Informe errata
Assert.AreEqual (13, Deck.NumberOfDiamonds ()); Assert.AreEqual (13,

Deck.NumberOfSpades ()); }
[Prueba]
vacío público Verify_deck_contains_no_joker () {

Assert.IsFalse (Deck.Contains (Card.JOKER)); }
[Prueba]
vacío público Check_every_card_in_the_deck () {
Assert.IsTrue (Deck.Contains (Card.TWO_OF_CLUBS)); Assert.IsTrue (Deck.Contains

(Card.TWO_OF_DIAMONDS)); Assert.IsTrue (Deck.Contains (Card.TWO_OF_HEARTS));
Assert.IsTrue (Deck.Contains (Card.TWO_OF_SPADES));
Assert.IsTrue (Deck.Contains (Card.THREE_OF_CLUBS)); Assert.IsTrue (Deck.Contains

(Card.THREE_OF_DIAMONDS)); Assert.IsTrue (Deck.Contains (Card.THREE_OF_HEARTS));
Assert.IsTrue (Deck.Contains (Card.THREE_OF_SPADES));
// los demás
}
Para los que no son técnicos, el código anterior contiene pruebas unitarias que hacen lo siguiente:
• Comprueba que cada mazo tiene trece cartas para cada palo
• Asegúrese de que nuestro mazo no contenga comodines (este es el error que se deslizó antes)
• Comprueba todas las cartas del mazo (las cincuenta y dos)
¿Dónde puedo obtener más información?
Solo hemos arañado la superficie de las pruebas unitarias, y se puede decir mucho más sobre el tema.
Afortunadamente, las pruebas unitarias se están volviendo tan comunes en los proyectos de software que la
mayoría de los lenguajes modernos tienen marcos de pruebas unitarias (disponibles gratuitamente para
descargar) y tutoriales que le muestran cómo comenzar.
Informe errata
Un buen lugar para comenzar para cualquier desarrollador que busque comprender el espíritu de la práctica es
el clásico documento introductorio de Kent Beck. 1
También puedes consultar Prueba de unidad pragmática en C # con NUnit [ HT04 ] y Pruebas de unidades
pragmáticas en Java con JUnit [ HT03 ]
Maestro Sensei
y el aspirante a
guerrero
ESTUDIANTE: Maestro, ¿cómo las pruebas unitarias no ralentizan a los equipos? Quiero decir, estás
escribiendo el doble de la cantidad de código, ¿no?
MAESTRO: Si la programación fuera meramente teclear, eso sería cierto. los

las pruebas unitarias están ahí para confirmar que a medida que hacemos cambios en nuestro software, el universo
aún se desarrolla como se esperaba. Esto nos ahorra tiempo al no tener que hacer una prueba de regresión manual de
todo el sistema cada vez que hacemos un cambio.
PREGUNTA: Si señor. Pero, ¿escribir pruebas unitarias no hará que el código sea frágil? ¿Cómo me aseguro
de que mis pruebas unitarias no se rompan cada vez que realizo un cambio en mi código?
RESPONDER: Aunque ciertamente es posible escribir pruebas frágiles que se basan en datos codificados,
están estrechamente acopladas y están mal diseñadas, a medida que se acostumbra a dejar que las
pruebas dirijan su diseño (Capítulo 14 , Desarrollo impulsado por pruebas, en la página 225 ), encontrará que
sus pruebas no tienden a romperse y, de hecho, mejoran su diseño general. La mayoría de los entornos de
desarrollo integrado (IDE) modernos también facilitan el manejo de los cambios en el código y las pruebas.
Puede cambiar el nombre de un método en toda su base de código simplemente presionando algunas
teclas. Esto ayuda a mantener sus pruebas y producción en movimiento como una sola.
PREGUNTA: ¿Es el 100 por ciento de cobertura de prueba unitaria algo que yo y mi equipo
debe disparar para?
1) http://junit.sourceforge.net/doc/testinfected/testing.htm
Informe errata
RESPONDER: No. El objetivo de las pruebas unitarias no es la cobertura: se da a usted mismo y a su

equipo suficiente confianza para que su software sea sólido y esté listo para la producción.
PREGUNTA: Entonces, ¿cuánta cobertura de prueba unitaria deberíamos tener yo y mi equipo?
RESPONDER: Eso es para que usted y su equipo decidan. Algunos marcos e idiomas facilitan el logro de
una buena cobertura de prueba. Otros hacen que sea difícil lograr una buena cobertura. Si recién comienza,
no se preocupe demasiado por la cobertura. Simplemente escriba tantas de las mejores pruebas que
pueda.
¿Que sigue?
Buen trabajo. Ahora conoce uno de los fundamentos básicos sobre los que descansan todas nuestras otras
prácticas ágiles de ingeniería de software. Sin pruebas unitarias automatizadas de sonido, todo se
desmorona.
A continuación, veremos cómo construir sobre nuestras pruebas unitarias y hacer algo tan crítico que, de
alguna manera, omitir esta práctica, nuestro producto se convertiría en otro blob de código demasiado caro
e imposible de mantener resistente a todas las formas de cambio.
Veamos ahora la importante práctica de refactorización.
Informe errata
Capítulo 13
Refactorización:
Pagando su deuda técnica
Al igual que una casa con una hipoteca, el software tiene una deuda que también debe ser pagada
continuamente.
En este capítulo, analizaremos la práctica de la refactorización y veremos cómo, pagando regularmente la

deuda técnica, podemos mantener nuestro software ágil y flexible y nuestra casa una alegría para trabajar y
vivir.
Al final del capítulo, verá cómo la refactorización reducirá sus costos de mantenimiento, le dará un
vocabulario común para realizar mejoras en el código y le permitirá agregar nuevas funcionalidades a toda
velocidad.
Entremos ahora en el mundo de la refactorización y veamos qué se necesita para ganar un centavo.

T URNA SOBRE AD IME 214
13.1 Encienda una moneda de diez centavos
Parece que la competencia acaba de lanzar una versión "amigable para los niños" del producto Black Jack
en línea de su compañía, y se vende como pasteles calientes.
Para responder a esta nueva amenaza competitiva, usted y el equipo comienzan a trabajar de inmediato, y
por un tiempo todo va bien. Pero entonces algo extraño comienza a suceder. Lo que inicialmente parecía
una volcada ahora está empezando a parecer realmente difícil.
Por un lado, se ha copiado y pegado una gran cantidad de código en toda la base de código. Esto dificulta
agregar nuevas funcionalidades porque cada vez que realiza un cambio en un lugar, debe realizar el mismo
cambio en una docena de otros.
Además de eso, el código que usted y el equipo escribieron a toda prisa para cumplir con la última fecha
límite ahora ha vuelto para perseguirlo. Es realmente un desastre y es difícil trabajar con él. Para empeorar
las cosas, el programador que originalmente lo escribió ahora se ha ido.
Aquí hay solo una muestra del código ofensivo:
Descargar Refactorización / src / BlackJack.cs
bool público DealerWins (Mano mano1) {
var h1 = mano1; En t sum1 = 0;

para cada ( var c en h1) {
sum1 + = Valor (c. Valor, h1); }
var h2 = DealerManager.Hand; En t sum2 = 0;

para cada ( var c en h2) {
sum2 + = Valor (c. Valor, h2); }
Si ( sum2> = sum1) {
volver verdadero ;
}
más
falso retorno ;
falso retorno ;
}
No se preocupe si no puede entender este código (yo tampoco). Sin embargo, este es el código que
necesita cambiar. Este es el código que necesita mantener. Este es el código que (¡ack!) Introduces en
producción.
Informe errata
DEUDA TÉCNICA 215
Trabajar y realizar cambios en esta base de código llevará más tiempo y costará más de lo que pensaba
originalmente.
Rápidamente se hace evidente que para hacer esto bien, necesitará al menos dos semanas para limpiar la
base de código existente antes de que pueda comenzar a agregar la nueva funcionalidad.
Desafortunadamente, son dos semanas de tiempo que su jefe dice que no tiene.
¿Qué salió mal? ¿Cómo podría algo agradable, simple y fácil de trabajar transformarse en algo tan grande,
feo y difícil de trabajar?
Ahora estamos listos para echar un vistazo a un concepto llamado deuda técnica.
13.2 Deuda técnica
$ 100
¿Cambio? ¡Olvídalo!
$ 10
Deuda El cambio es dificil
técnica $1
El cambio es fácil do
iza
tor
ac
ref
no
digo
Có
do
factoriza
Código re
comienzo Hora Fin del proyecto.
La deuda técnica es la acumulación continua de atajos, hacks, duplicaciones y otros pecados que
cometemos regularmente contra nuestra base de código en nombre de la velocidad y el horario.
Siempre tendrá alguna deuda en su código (no tener ninguna significaría que no está probando cosas
innovadoras o diferentes), pero tendrá
Informe errata
M AKE P AYMENTOS A TRAVÉS DE R EFACTORING 216
La deuda técnica es más que un simple código
Si bien la mayor parte de nuestra deuda técnica está centrada en el código, también puede
tenerla en datos y archivos de compilación y configuración. Una vez fui parte de una reescritura a
gran escala para un sistema de fondo donde el nombre de una ciudad se deletreaba de dos
maneras diferentes. El costo de esta aparentemente pequeña diferencia fue enorme. En lugar de
no importarles cómo se deletreaba la ciudad, tuvieron que escribir y llevar este código y
complejidad adicionales mientras ese sistema permaneciera en producción, lo que para los
sistemas mainframe puede durar mucho tiempo.
sepa que ha acumulado demasiado cuando lo que solía ser divertido, fácil y simple ahora es doloroso, difícil
y complejo.
La deuda técnica puede tomar muchas formas (código de espagueti, complejidad excesiva, duplicación y
descuido general), pero lo que lo hace realmente peligroso es cómo te engaña. Cada transgresión realizada
inicialmente contra la base del código puede parecer pequeña o insignificante. Pero como todas las formas
de deuda, es el efecto acumulativo que se acumula con el tiempo lo que duele.
Lo que necesitamos es una forma de pagar sistemáticamente nuestra deuda técnica a medida que
avanzamos. Necesitamos una forma de mejorar y mantener gradualmente la integridad y el diseño de nuestro
software que nos permita cumplir con los objetivos de hoy y estar en una buena posición para manejar los
desafíos aún desconocidos que vendrán mañana.
En ágil, llamamos a esto refactorización.
13.3 Realizar pagos mediante refactorización
Refactorizar es la práctica de realizar continuamente mejoras de diseño pequeñas e incrementales en su

software sin cambiar el comportamiento externo general.
Informe errata
Cuando refactorizamos nuestro código, no estamos agregando nuevas funcionalidades o incluso corrigiendo
errores. En cambio, estamos mejorando la comprensión de nuestro código al hacer que sea más fácil de
comprender y más susceptible de cambiar.
Llamamos a uno de estos cambios un refactorización.
Por ejemplo, cada vez que cambia el nombre de un método o variable mal nombrados en un esfuerzo por
facilitar su lectura y comprensión, está refactorizando.
Refactorizaciones
sal decimal; salario decimal [Cambiar nombre de variable]
público decimal Calc () decimal público CalculateTotalTaxes () [Cambiar nombre de método]
A primera vista, las refactorizaciones como estas pueden parecer pequeñas e insignificantes. Pero cuando
se aplican de forma continua y agresiva contra una base de código, pueden tener un profundo impacto en la
calidad y la capacidad de mantenimiento del código.
Por ejemplo, eche un vistazo a estos fragmentos de código y pregúntese cuál requiere más esfuerzo para
leer y comprender:
if (Date.Before (SUMMER_START) || Date.After (SUMMER_END))

carga = cantidad * _winterRate + _winterServiceCharge; más
carga = cantidad * _summerRate;
O ... Refactorización: [ Método de extracción]
if (NotSummer (fecha))
carga = WinterCharge (cantidad); más
carga = SummerCharge (cantidad);
No tiene que ser desarrollador ni conocer C # para ver que el segundo ejemplo es mucho más fácil de leer y
comprender que el primero. Escribir código es muy parecido a escribir una buena prosa. Usted quiere que
sea claro, fácil de entender y que no requiera mucho esfuerzo para descubrir lo que está sucediendo.
La refactorización es la salsa secreta que los programadores orientados a objetos usan para hacer esto. Al
elegir métodos y variables bien nombrados y ocultar detalles innecesarios del lector, pueden comunicar su
intención muy claramente, haciendo que el código sea fácil de entender y fácil de cambiar.
Informe errata
Principio ágil
La atención continua a la excelencia técnica y al buen
diseño mejora la agilidad.
En esencia, de eso se trata la refactorización: recordarnos que el software está escrito y mantenido por
personas como usted y yo. Y si no podemos hacer que nuestro software sea fácil de cambiar y sea un
placer trabajar con él, no será muy divertido cada vez que necesitemos hacer cambios o agregar nuevas
funcionalidades.
Refactorizar duro: continuamente
Cuando refactoriza agresivamente, no disminuye la velocidad cerca del final de un proyecto, sino que
acelera. Eso es porque cuando ha mantenido su diseño en el tiempo, ha realizado la mayor parte del trabajo
pesado. Las nuevas características se basan en las más antiguas y bien diseñadas. Luego puede
aprovechar su arduo trabajo y cosechar las recompensas de mantener una casa en orden.
Refactorizar agresivamente significa no guardar todas sus refactorizaciones hasta el final de una iteración.
Esto es lo que quieres hacer continuamente durante todo el día.
Cuando se hace bien, la refactorización es casi invisible. Los pasos son tan pequeños y las mejoras tan
pequeñas que es casi imposible distinguir cuándo alguien está refactorizando el código y agregando nuevas
funciones.
demasiada acumulación de deuda
Deuda Refactor
Semanal
Diario
Minutos
quieres refactorizar aquí
Informe errata
Eso es suficiente teoría. Vamos a estirar al viejo cerebro y probar esto por nosotros mismos:
Ahora tu intenta
¿Qué mejoras podríamos hacer en la versión amigable para los niños de nuestro juego Black Jack que
vimos al comienzo del capítulo?
public bool DealerWins (Hand hand1) ÊÊÊÊÊÊ {ÊÊÊÊÊÊÊÊÊÊ
var h1 = mano1; int sum1 = 0; ÊÊÊÊÊÊÊÊÊÊÊ foreach alguna variable que podamos renombrar?
(var c en h1) ÊÊÊ Ê

{
sum1 + = Valor (c. Valor, h1); ÊÊÊ Ê
} ÊÊÊÊ
alguna duplicación en términos de
var h2 = DealerManager.Hand; int sum2 = 0; ÊÊÊÊ foreach (var c en
funcionalidad?
h2) ÊÊÊÊ {ÊÊÊÊ
sum2 + = Valor (c. Valor, h2); ÊÊÊÊ} ÊÊÊÊ
if (sum2> = sum1) ÊÊÊ Ê

{ÊÊÊÊ
devuelve verdadero;
ÊÊÊÊ} ÊÊÊÊ alguna lógica o código innecesario?
másÊÊÊÊÊÊÊÊ
devuelve falso; ÊÊÊÊ
falso retorno; }
Un buen lugar para comenzar al realizar cualquier refactorización es asegurarse de que todas nuestras variables y
nombres de métodos sean buenos. Entonces, ¿por qué no comenzamos limpiando esos primero?
public bool DealerWins (Hand playerHand) {
Refactorización: [ Cambiar nombre de variable]

int playerHandValue = 0;
foreach (tarjeta var en playerHand) { Refactorización: [ Método de cambio de nombre]
playerHandValue + = DetermineCardValue (card, playerHand); }
var dealerHand = DealerManager.Hand; int

dealerHandValue = 0;
foreach (tarjeta var en playerHand) {
dealerHandValue + = DetermineCardValue (card, dealerHand); }
return dealerHandValue> = playerHandValue;
}
Refactorización: Simplificó el código
Informe errata
Bueno, eso se ve un poco mejor. Es un poco más legible. Pero aún no hemos terminado. Todavía hay algo
más de duplicación allí. ¿Qué pasa si intentamos extraer alguna lógica de aspecto similar en su propio
método?
int playerHandValue = GetHandValue (playerHand); int dealerHandValue =

GetHandValue (DealerManager.Hand);
return dealerHandValue> = playerHandValue; } Refactorización: [ Método de extracción]
private int GetHandValue (Hand hand) {
int handValue = 0;
foreach (tarjeta var en mano) {
handValue + = DetermineCardValue (tarjeta, mano); }
return handValue; }
¡Guauu! Mira eso. Después de extraer el GetPlayerHandValue método, nuestro

DealerWins El método se redujo a solo tres líneas. Ahora podemos ver qué intentaba hacer ese método. Esto
es mucho más fácil de leer. Y si alguna vez queremos ver los detalles de cómo se calcula la mano del
jugador, siempre podemos desplegarnos en el GetPlayerHandValue método y eche un vistazo.
Este código es bastante claro. Si quisiéramos llevarlo al siguiente nivel, por supuesto, también podríamos
hacer algo como esto:
Refactorización: [ Variable en línea]

return GetHandValue (DealerManager.Hand)> = GetHandValue (playerHand); }
Con solo estas tres refactorizaciones simples:
• Renombrar variable / método
• Variable en línea
• Método de extracción
Informe errata
realmente puede mejorar la legibilidad y la facilidad de mantenimiento de su código.
Para cualquier gerente que lea esto, esto es importante porque ahora, cuando el equipo necesita hacer ese
error de emergencia o hacer ese cambio de misión crítica, podrán hacerlo mejor, más rápido y más barato
que antes.
En lugar de pasar innumerables horas tratando de averiguar qué está haciendo el código, pueden ir
directamente al trabajo y hacer el cambio.
Por esta razón, debe ser un gran defensor y animador para garantizar que los programadores de su equipo
estén refactorizando agresivamente y pagando continuamente cualquier deuda técnica.
Gran pregunta A veces necesitamos hacer cambios más grandes en nuestro software que simplemente cambiar
el nombre de algunas variables. Es posible que sea necesario reemplazar una biblioteca o un marco, una nueva
herramienta que deba integrarse, o creemos que la publicidad de marketing es demasiado y ahora necesitamos
reemplazar una herramienta en la que confiamos para un poco de trabajo pesado.
Cualquiera sea la razón, las grandes refactorizaciones surgen de vez en cuando, y necesitamos una forma
de manejarlas.
Si el cambio se impone desde fuera del equipo y es algo que solo debemos hacer, trate la refactorización
como cualquier otra historia de usuario. Estimarlo, priorizarlo, hacer visible el costo y mostrar el impacto que
tendrá en el proyecto.
Informe errata
La refactorización obtiene un nombre sucio
Una vez, al crear una aplicación de intercambio de energía, nuestro equipo se fue e hizo varias
refactorizaciones a gran escala en la base del código y no agregó mucho en cuanto a nuevas
funcionalidades durante varias semanas.
Bueno, no pasó mucho tiempo para que la gerencia despreciara la palabra refactorización porque
llegó a significar volver a trabajar y no agregar ninguna funcionalidad nueva), y pronto llegaron
los edictos desde arriba que no volverá a refactorizar.
No dejes que esto te pase a ti. Refactorizar continuamente a medida que avanza. Es mucho
más difícil pagar la deuda técnica más tarde, y lo último que quiere hacer es darle un nombre
sucio a la refactorización.
Migrar a un nuevo modelo de seguridad

corporativa
10 pts
gran refactorización
Los más difíciles de manejar son aquellos casos más subjetivos en los que podríamos pasar si seguimos
trabajando, pero la recompensa de hacer este cambio realmente podría pagar dividendos en el futuro.
Si su gran refactorización cae en esta área gris, hágase dos preguntas antes de decidir si continuar:
• ¿Estamos cerca del final del proyecto?
• ¿Se puede hacer de forma incremental?
Informe errata
Las grandes refactorizaciones al final del proyecto generalmente no valen la pena porque no tendrá tiempo
para cosechar las recompensas de su trabajo. Por lo tanto, generalmente es una buena idea aprobar si está
cerca del final de su proyecto.
Las refactorizaciones incrementales son más fáciles de vender a su cliente porque significa que usted y el
equipo no van a desaparecer en ellas. Continuarán viendo nuevas funcionalidades en su software mientras
usted elimina la refactorización de manera incremental.
Solo eche un vistazo a su situación. Mira lo que hay que hacer. Y si parece que le ahorrará mucho dolor,
hágalo, probablemente valga la pena hacerlo.
Solo hemos arañado la superficie sobre el tema muy importante de la refactorización, y este pequeño
capítulo no trata el tema en ninguna parte cerca de la justicia que merece.
El libro que realmente quieres leer es Martin Fowler Refactorización: Mejora del diseño de código existente [ FBB
+ 99 ]
Otro digno de leer es el de Michael Feathers Trabajando efectivamente con código heredado [ Fea04 ]
Maestro Sensei
y el aspirante a
guerrero
ESTUDIANTE: Maestro, ¿hay alguna vez que no debería refactorizar mi código?
MAESTRO: Salvo por las refactorizaciones a gran escala que ya discutimos, no. En general, desea
refactorizar su código cada vez que realice un cambio en el software.
ESTUDIANTE: ¿He fallado si alguna vez necesito una iteración dedicada a nada más que refactorizar?
Informe errata
MAESTRO: No, es menos que ideal. Esfuérzate por hacer tus refactorizaciones en pequeño para que no
necesites hacerlas en grande. No siempre tendrá éxito, y a veces se requieren grandes cambios. Pero trata
de hacer de ellos un último recurso. No es algo que haces regularmente.
¿Que sigue?
Buen material. Las pruebas unitarias y la refactorización juntas forman un poderoso golpe entre dos contra el
que la mayoría de los software mal diseñados no pueden resistir.
Pero hay otra práctica que debes conocer, una que no solo te ayuda con el diseño de tu software, sino que
también te ayuda a calcular cuánto debes probar.
Pase la página para descubrir el arte del desarrollo basado en pruebas y para ver cómo la escritura de pruebas nos
ayuda primero mientras observamos nuestro lienzo de código en blanco y nos preguntamos dónde debería comenzar
todo.
Informe errata
Capítulo 14
Desarrollo guiado por pruebas
Estas atorado. Perplejo. Has estado mirando un código en particular todo el día, y simplemente no sabes
cómo desglosarlo ni siquiera por dónde comenzar.
Desearías poder codificar como Eric.
Hay algo sobre su código. Simplemente parece funcionar. Cada vez que usas cualquiera de sus códigos, es
como si él hubiera leído tu mente. Todo lo que necesita está ahí, respaldado por un conjunto completo de
pruebas unitarias automatizadas.
¿Cómo lo hace? ¿Qué está haciendo que tú no eres?
Frustrado pero al darse cuenta de que necesita ayuda, finalmente reúne el coraje y se dirige al escritorio de
Eric. "¿Cómo se escribe un código tan bueno y limpio?"
"Fácil", responde. "Primero escribo las pruebas".

ESCRIBA SUS NUESTRAS PRUEBAS 226
14.1 Escriba sus pruebas primero
El desarrollo basado en pruebas (TDD) es una técnica de desarrollo de software que utiliza ciclos de
desarrollo realmente cortos para diseñar su software de forma incremental.
Así es como funciona:
1) Rojo: Antes de escribir cualquier código nuevo para el sistema, primero escriba
una prueba de unidad fallida, que muestra la intención de lo que le gustaría que hiciera el nuevo
código. Aquí estás pensando críticamente sobre el diseño.
2) Verde: Luego haces lo que sea necesario para que la prueba pase. Si tu
vea la implementación completa, agregue el nuevo código. Si no lo hace, haga lo suficiente para
aprobar el examen.
3) Refactor: Luego regresas y limpias cualquier código o pecado

comprometido al tratar de pasar la prueba. Aquí está eliminando la duplicación y asegurándose de
que todo sea sencillo, malo y lo más claro posible. Pa
se
lla
fa
sd
ba
ep
ue
ru
pr
eb
La
Círculo TDD
de vida
Refactor
Cuando se le pregunta cómo sabe cuándo detenerse, Eric responde que sigue repitiendo el proceso de
escribir pruebas, haciéndolas pasar y refactorizando hasta que esté seguro de que el código hace todo lo
que la historia del usuario requiere (generalmente esto significa pasar todos los criterios de aceptación de la
historia).
También tiene algunas reglas generales para ayudarse a sí mismo a mantenerse en el camino.
Informe errata
Regla n. ° 1: No escriba ningún código nuevo hasta que primero tenga una prueba fallida.
Eric admite fácilmente que no puede seguir esta regla el 100 por ciento del tiempo (algunas cosas son
realmente difíciles de probar primero, como las interfaces de usuario). Pero el espíritu de esto, explica, no
es escribir más código del que sea absolutamente necesario. Escribir una prueba primero nos obliga a
pensar en el valor de lo que estamos agregando y nos ayuda a evitar que diseñemos en exceso la solución.
Regla # 2: Pruebe todo lo que podría "posiblemente" romperse.
Seguir esta regla no significa que literalmente pruebes todo —Eso tomaría una eternidad. La palabra clave
aquí es posiblemente. Si existe una posibilidad plausible de que algo se rompa o si queremos mostrar
intención en cómo se comportará el programa bajo ciertas condiciones, escribimos una prueba para ello.
Eric te muestra un ejemplo de algo en lo que está trabajando actualmente.
Crear perfil de
cli ente Criterio de pru
eba
vos perfiles
en la espalda * * guardar nue
* * buscar du
plicados
* * validación
básica
"Como saben, tenemos algunos grandes apostadores aquí en Las Vegas", explica Eric. “Algo que a
nuestros muchachos del almacén de datos les gusta hacer es perfilar a los motores y agitadores. Calculan
sus gustos, disgustos, comidas favoritas, bebidas favoritas y cualquier otra cosa que pueda ayudarnos a
llevarlos de vuelta a nuestro casino.
“Ahora, ya tenemos un objeto de perfil de cliente en el sistema. Lo que necesito hacer es averiguar cómo
almacenar esa información de perfil en la base de datos ”.
Lo primero que hace Eric es escribir una prueba. Aquí se imagina que el código que necesita probar ya
existe, y simplemente está escribiendo una prueba para probarse a sí mismo que funciona:
Descargar tdd / test / CustomerPro fi leManagerTest.cs
[Prueba]
vacío público Create_Customer_Profile () {
// preparar
gestor var = nuevo CustomerProfileManager ();
Informe errata
// crea un nuevo perfil de cliente

perfil var = nuevo Perfil de cliente(" Scotty McLaren "," Hagis ");
// confirma que no existe en la base de datos

Assert.IsFalse (manager.Exists (profile.Id));
// agregarlo
En t uniqueId = manager.Add (perfil); // obtener id de la base de datos
profile.Id = uniqueId;
// confirma que se ha agregado

Assert.IsTrue (manager.Exists (uniqueId));
// limpiar
manager.Remove (uniqueId); }
Confiando en su prueba le dirá si puede agregar de manera segura un nuevo perfil de cliente, luego cambia
de marcha y ahora se enfoca en lograr que la prueba pase.
Aquí él ve claramente lo que hay que hacer (tomar la información del perfil del cliente y almacenarla en la
base de datos), por lo que continúa y agrega la nueva funcionalidad.
Descargar tdd / src / CustomerPro fi leManager.cs
clase pública CustomerProfileManager {
int público Agregar (perfil de perfil del cliente) {
// finge que este código almacenó el perfil // en la base de datos y devolvió una
identificación real
regreso 0; }
bool público Existe ( En t carné de identidad) {
// código para verificar si el cliente existe

}
vacío público Eliminar( En t carné de identidad) {
// código para eliminar un cliente de la base de datos

}}}
Ahora ejecuta la prueba y ve que pasa. ¡Hurra!
Informe errata
La refactorización es el tramo final de su viaje TDD. Ahora regresa y revisa todo (código de prueba, código
de producción, archivos de configuración y cualquier otra cosa que tocó para que la prueba pase) y lo
refactoriza todo realmente (Capítulo 13 , Refactorización: pagar su deuda técnica,
en la página 213 )
Después de refactorizar, regresa y se pregunta si ha probado todo lo que podría romperse. Para esta
historia, necesita verificar que no permitimos duplicados.
Entonces, repite el mismo proceso. Escriba una prueba reprobatoria, haga lo suficiente para aprobarla y luego
refactorice.
A veces tiene un pequeño problema con el huevo y la gallina (antes de que pueda probar si la inserción
funciona, necesita un código que le diga si el cliente ya existe).
Cuando eso sucede, simplemente pone su prueba actual en espera, agrega la nueva funcionalidad
(probando primero, por supuesto), y luego vuelve a lo que sea que estaba trabajando antes.
Agradeces a Eric por su demostración de TDD y regresas a tu escritorio con pensamientos de pruebas,
refactorización y códigos que te pasan por la cabeza.
¿Qué acaba de pasar aquí?
Detengámonos y reflexionemos por un segundo sobre lo que acaba de suceder aquí y por qué es
importante.
En TDD escribimos primero las pruebas y luego las hacemos pasar. Esto parece al revés. Definitivamente
no es lo que nos enseñaron en la escuela.
Pero piénsalo por un segundo. ¡Qué mejor manera de diseñar su software que imaginar que ya existe!
Eso es todo lo que estamos haciendo TDD. Los programadores escriben el código que necesitan como si ya
existiera y luego lo prueban para asegurarse de que funciona. Es una forma maravillosa de asegurarse de que
construye solo lo que necesita mientras prueba que funciona.
Ahora no se asuste si su equipo no toma de repente TDD como un pez al agua. Es una técnica de
codificación más avanzada que se basa en pruebas unitarias y refactorización. Y para estar seguros, habrá
momentos en los que no podrá hacer TDD y solo querrá sentarse y hackear para resolver las cosas.
Informe errata
UTILICE LAS PRUEBAS PARA COMER CON C OMPLEXIDAD 230
Pero una vez que tenga lo básico y experimente el ritmo y la potencia que proviene de escribir una pequeña
prueba, hacerla pasar y luego refactorizarla, le gustará la apariencia y las pruebas de su código.
14.2 Utilice las pruebas para lidiar con la complejidad
Los desarrolladores se enfrentan a una gran complejidad al escribir código. Mire cuántas decisiones tomó
Eric al desarrollar su interfaz de programación de aplicaciones (API) "Crear perfil de cliente".
clase de padres
nombre del método nombre de la variable de entrada
CustomerProfileRepository
x6 decisiones
public int Add (perfil del perfil del cliente)
de diseño
¡Por una sola línea de
código!
visibilidad del método tipo de retorno tipo de entrada
Cuentalos. Esas son seis decisiones de diseño, compensaciones y bifurcaciones en el camino en las que el
desarrollador debe pensar, ¡todo por una sola línea de código! No es de extrañar que las cosas se caigan
periódicamente.
Al escribir sus pruebas primero y asegurarse de que tiene una prueba reprobatoria antes de
agregando el nuevo código, TDD lo ayuda a luchar contra la gran cantidad de complejidad que usted y su
equipo enfrentarán al escribir código todos los días.
TDD también le ofrece una forma de diseñar con confianza. Al concentrarse en una sola prueba y hacerla
pasar, no tiene que tener mil cosas en su cabeza a la vez.
Puede enfocarse en un pequeño problema, aprender de manera incremental cómo abordarlo mejor y
obtener la retroalimentación instantánea que necesita para decirle si se dirige en la dirección correcta.
Informe errata
Otras razones para hacer la prueba primero incluyen las siguientes:
Menor costo total de

propiedad
Diseño más
Menos código
simple
Complejidad ¡Te obliga a

reducida pensar!
Calidad horneada desde

el principio
Todo esto facilita una base de código mucho más fácil de mantener y modificar. Con menos código viene
menos complejidad. Y con un diseño más simple, hacer cambios y modificaciones se vuelve mucho más
fácil.
Basta de hablar ya. Hagamos algunas pruebas y veamos cómo le va en la pista de prueba.
Ahora tu intenta
Eric te invita a emparejarte con él al escribir un código que compara el valor de dos cartas. Él piensa que la
funcionalidad debería ir en el Tarjeta clase y quisiera su ayuda para completar el examen.
Escriba el nombre del método que le gustaría ver en el Tarjeta clase que compara dos cartas y dice si una es
mayor que la otra.
lla
fa
ba
ue
pr
La
Círculo TDD
de vida
Informe errata
public void Compare_value_of_two_cards () {
Card twoOfClubs = Card.TWO_OF_CLUBS; Card threeOfDiamonds =

Card.THREE_OF_DIAMONDS; Escribe tu prueba aquí
Imagina que el código ya existe, ¡solo escríbelo!

}
Digamos que su diseño se parece a esto:
Descargar tdd / test / CardTest.cs
[Prueba]
vacío público Compare_value_of_two_cards () {
Card twoOfClubs = Card.TWO_OF_CLUBS; Card threeOfDiamonds =

Card.THREE_OF_DIAMONDS;
Assert.IsTrue (twoOfClubs.IsLessThan (threeOfDiamonds)); }
Entregándole el teclado, Eric le pregunta si puede pasar la prueba. Se te ocurre algo como esto:
Descargar tdd / src / Card.cs
bool público IsLessThan (Card newCard) {
En t thisCardValue = value;
En t newCardValue = newCard.value;
regreso thisCardValue <newCardValue; }
Pa
se
sd
ep
ru
eb
a
Círculo TDD
de vida
Informe errata
Después de pasar la prueba, Eric le pregunta si ve algo que le gustaría refactorizar. Tú lo haces. Después
de hacer algunos cambios en las pruebas y el método, su código ahora se ve así:
Descargar tdd / test / CardTest.cs
[Prueba]
vacío público Compare_value_of_two_card () {
Assert.IsTrue (Card.TWO_OF_CLUBS.IsLessThan (Card.THREE_OF_DIAMONDS)); }
Descargar tdd / src / Card.cs
bool público IsLessThan (Card newCard) {
regreso valor <newCard.value; }
Círculo TDD
de vida
Refactor
Después de completar un bucle del círculo TDD, Eric sonríe y dice: "¡Creo que lo tienes!" Deseoso de
probar esto en parte de su propio código, le agradece a Eric y vuelve a su escritorio para escribir algunas
pruebas propias.
Para realmente entender el espíritu de TDD, recomiendo el libro de Kent Beck Desarrollo guiado por
pruebas: por ejemplo [ Bec02 ], que tiene algunos buenos consejos y trucos sobre la mecánica más profunda
de TDD y cómo hacer que funcione para usted.
Informe errata
Maestro Sensei
y el aspirante a
guerrero
ESTUDIANTE: Maestro, estoy confundido acerca de TDD. ¿Cómo se supone que debo escribir pruebas para
código que ni siquiera existe?
MAESTRO: Escriba la prueba como si el código que necesitaba ya estuviera allí.
ESTUDIANTE: ¿Pero cómo sabré qué probar?
MAESTRO: Prueba lo que necesitas.
ESTUDIANTE: Entonces, estás diciendo que solo escribas pruebas para las cosas que necesito, y todo lo que el
sistema necesita aparecerá mágicamente.
MAESTRO: Si.
ESTUDIANTE: ¿Puedes explicar un poco cómo funciona exactamente toda esta magia?
MAESTRO: No hay magia Simplemente estás manifestando lo que

necesita en forma de prueba. Crear código de esta manera garantiza que cree solo lo que necesita. Simplemente
está utilizando las pruebas como una puerta de entrada para darse cuenta de su intención. Esta es la razón por la
que a menudo se hace referencia a TDD como una técnica de diseño y se trata menos de pruebas.
ESTUDIANTE: Entonces, ¿TDD se trata realmente de diseño y no de pruebas?
MAESTRO: Eso sería una simplificación excesiva. La prueba es una parte central de TDD, porque usamos
pruebas para probar que el código que producimos funciona. Pero no podemos completar las pruebas sin
primero hacer un diseño y mostrar nuestra intención a través del código.
ESTUDIANTE: Gracias maestro. Debo pensar más en esto.
¿Que sigue?
¿Puedes sentir cómo se desarrollan las prácticas? Las pruebas unitarias nos dan la confianza para saber lo que
hemos construido. La refactorización asegura que lo mantengamos sim-
Informe errata
ple, y TDD nos brinda una herramienta poderosa para lidiar con la complejidad y el diseño.
Todo lo que queda ahora es la única práctica para unirlos a todos y garantizar que su proyecto esté en un
estado continuo de preparación de producción.
¡Ahora concluyamos y aprovechemos el poder de la integración continua!
Informe errata
Capítulo 15
Integración continua:
Haciéndolo listo para la producción
Prepárese para un poco de bondad lista para la producción. Al aprender cómo integrar continuamente su
software, eliminará los errores de manera temprana, reducirá el costo de realizar cambios en su software y
podrá implementar con confianza.
¡Y parece que necesitas hacer exactamente eso ahora mismo!
15.1 Showtime
Primero las buenas noticias. Su director está trayendo algunos inversores influyentes para ver la última
versión de su producto insignia Black Jack. ¡La mala noticia es que estarán aquí en una hora!
Eso le deja menos de sesenta minutos para crear una compilación estable, insertarla en el servidor de
prueba y prepararse para la demostración.
¿Qué haces?

TIEMPO DE LA FUNCION 237
Antes de responder eso, pase dos minutos pensando en todas las cosas que pueden salir mal cada vez que
implementamos nuestro software.
Cosas que pueden salir mal al implementar software
Error humano / dedos gordos / errores Error de
comunicación con otros equipos
errores en los archivos de configuración
Diferencias en los entornos de implementación Errores /
Documentación desactualizada
Estas son las cosas que queremos eliminar, o al menos administrar, con nuestro proceso de integración
continua. Queremos crear una cultura de preparación para la producción y poder demostrar nuestro producto a
cualquier persona, en cualquier momento y en cualquier lugar.
Veamos dos formas en que podríamos hacer esto.
Escenario 1: La gran producción
¡Una hora! Eso no te deja mucho tiempo. Al presionar el botón de pánico, inmediatamente reúne al equipo
y, como una ametralladora, comienza a responder preguntas:
¿Quién tiene la última versión? ¿De quién es el

escritorio más estable?
¿Quién puede poner en marcha algo en el menor tiempo posible?
Sin confiar en que nadie haga esto correctamente, sino usted mismo, informa a todos que su caja se
convertirá en la caja de integración para la demostración y todos tienen quince minutos para fusionar sus
cambios en la rama de su código.
Informe errata
TIEMPO DE LA FUNCION 238
A medida que las personas comienzan a fusionar su código, surgen más problemas. Las interfaces en las
clases principales han cambiado. Los archivos de con fi guración han sido modificados. Los archivos del sistema
anterior se han reestructurado y faltan. Fusionar todos los cambios a la vez rápidamente se convierte en una
pesadilla de integración.
Maldiciendo silenciosamente al director por no darle suficiente tiempo, le dice a la gente que comente y
piratee cualquier cosa que les impida integrar su código.
Luego, con cinco minutos de sobra, verá un tenue rayo de esperanza: ¡se compila!
Pero luego desastre: los inversores se presentan cinco minutos antes. No hay tiempo para probar.
Cruzando los dedos, despliega el software, abre la aplicación para la demostración y ... se bloquea. Arregla
ese problema rápidamente y abre la aplicación, solo para que se bloquee nuevamente después de pasar
por la pantalla de presentación introductoria.
Ligeramente avergonzado y al ver que la demostración no está yendo como se esperaba, el director le
pregunta al equipo si tal vez podrían ver algunas maquetas.
Escenario 2: El No Evento
Sabiendo que tiene una hora completa antes de la demostración, le informa al equipo que pronto habrá una
demostración y les dice que si pudieran registrarse y concluir lo que sea que estén trabajando, sería
apreciado enormemente.
Una vez que se ha guardado el trabajo de todos, revisa la última versión del código, ejecuta todas las
pruebas y, viendo que todo funciona, empuja a prueba. El proceso está completamente automatizado y
toma aproximadamente cinco minutos.
Los inversores llegan temprano. La demo va genial. Y su jefe le agradece por poder presentar con tan poco
tiempo de aviso y le entrega algo que siempre quiso: las llaves del baño ejecutivo.
De acuerdo, tal vez no quieras las llaves del baño, pero entiendes el punto.
Prepararse para las demostraciones e introducir el código en la producción no tiene que ser un gran evento
estresante, laborioso y lleno de ansiedad.
Informe errata
AC ULTURE DE P RODUCTION R EADINESS 239
Desea que la creación, integración e implementación de su software no sea un acontecimiento. Y para

hacer eso, todo lo que necesita es un buen proceso de integración continua y una cultura de preparación
para la producción.
15.2 Una cultura de preparación para la producción
Hay un dicho en Extreme Programming de que la producción comienza el primer día del proyecto. Desde el
primer día que escribe una línea de código, trata el proyecto como si estuviera en producción y después de
eso, simplemente realiza cambios en un sistema en vivo.
Es una profunda diferencia en cómo ves tu código. En lugar de ver la producción y la implementación como
un evento en el futuro distante, imagina que usted y su equipo están en producción hoy y comienzan a
comportarse en consecuencia.
A los agilistas les gusta esta noción de preparación para la producción porque reconoce que el software
pasa mucho más tiempo en producción que en desarrollo, y acostumbra a los equipos a la idea de hacer
cambios en un sistema listo para la producción.
Sin embargo, mantener una cultura de preparación para la producción no es fácil ni gratuito. Se necesita
una disciplina extrema, y la tentación de retrasar la inversión en código de calidad de producción en nombre
del cronograma puede ser grande.
Pero aquellos que hacen la inversión temprano pueden convertir sus proyectos en un centavo. Se
despliegan con facilidad, realizan cambios en sus sistemas de forma regular y segura, y responden a las
necesidades de sus clientes más rápido que sus competidores.
Y algo que nos ayuda a hacer eso es la integración continua.
15.3 ¿Qué es la integración continua?
Base de
código único
Nueva caracteristica Lo hizo más rápido
Repositorio
de código
fuente
Corregido un error! Copia actualizada
Informe errata
¿QUÉ ES LA NTEGRACIÓN CONTINUA DE ISC? 240
La integración continua es el acto de tomar continuamente los cambios que los desarrolladores hacen en su
software e integrarlos todos juntos de manera continua durante el día.
Para utilizar una analogía de escritura de libros, imagine que usted y su coautor están trabajando juntos en
un capítulo, y deben fusionar sus cambios con los de ella. Combinar algunas ediciones simples para un par
de oraciones no es tan malo.
El zorro marrón salta sobre el perro perezoso.
Pedazo de pastel ...
El zorro marrón salta sobre el vago negro perro.
Es cuando no integramos nuestros cambios por largos períodos de tiempo cuando nos encontramos con
problemas.
El zorro marrón salta sobre el perro perezoso. ¡Pero entonces el perro

hizo algo completamente asombroso! Horneó un lote de galletas con
chispas de chocolate y procedió a entregarlas personalmente a todos
los que pasó por la calle. Los gatos, por supuesto, vieron esto, se
enojaron y decidieron contrarrestar la campaña de galletas de buena
voluntad del perro con una campaña propia: ¡tarta de queso con
chocolate!
¿Puedes ver las 7

diferencias?
El zorro marrón salta sobre el perro perezoso. ¡Pero entonces el

perro hizo algo completamente asombroso! Hizo un lote de muffins
de chispas de chocolate y procedió a entregarlos a todos los que
pasó por la avenida. Los gatos, por supuesto, vieron esto, se
enojaron y decidieron contrarrestar la campaña de magdalenas de
buena voluntad del perro con una campaña propia: ¡tarta de queso
de vainilla!
Escribir software es lo mismo. Cuanto más tiempo pase sin integrar sus cambios con sus compañeros de
equipo, más difícil será la combinación cuando lo haga.
Veamos ahora cómo funciona esto en la práctica.
Informe errata
¿COMO FUNCIONA? 241
Mantenlo rápido
Una vez estuve en un proyecto que tenía una gran herramienta de automatización de prueba de
grabación / reproducción. Fue tan bueno, de hecho, que todos comenzaron a usarlo para grabar todas
sus pruebas, y dejaron de escribir las pruebas unitarias más rápidas y de bajo nivel.
Esto estuvo bien por un tiempo, pero a medida que se acumularon más pruebas de grabación /
reproducción, nuestro tiempo de compilación automatizado pasó de unos diez minutos
relativamente buenos a poco más de tres horas. Esto nos mató. La gente dejó de ejecutar la
compilación. Comenzaron a revisar su trabajo con menos frecuencia, y las construcciones rotas se
convirtieron en la norma para el proyecto.
No cometas el error que cometimos al dejar que nuestras compilaciones sean demasiado largas. Vigila tu
tiempo de construcción. Cualquier cosa menos de diez minutos es una buena regla general. Los proyectos
más pequeños generalmente pueden mantenerlo por debajo de cinco.
15.4 ¿Cómo funciona?
Para configurar un sistema de integración continua, necesita algunas cosas:
• Un repositorio de código fuente
• Un proceso de check-in
• Una compilación automatizada
• Voluntad de trabajar en pequeños trozos.
Los repositorios de código fuente almacenan y versionan su software. Esto es en lo que su equipo de
desarrollo "registra" su código. Es el punto de integración de su proyecto y mantiene una copia maestra de
su código. Los repositorios de código abierto como Git o Subversion son tus amigos aquí.
Solo asegúrese de evitar el bloqueo pesimista (lo que significa que solo un desarrollador puede trabajar en
un archivo a la vez). Frustrará tu
Informe errata
E ESTABLECER P ROCESS DE AC 242
desarrolladores, reduzca la velocidad de su equipo y evite que su equipo posea colectivamente la base del
código.
Un buen proceso de registro es más interesante. Veamos cómo un equipo ágil típico podría hacer eso.
15.5 Establecer un proceso de registro
Un proceso de registro típico para los desarrolladores que trabajan en un equipo ágil se vería así:
Obtenga el último código fuente

1
Hacer cambios. Listo para registrarse?

2
3 Ejecute las pruebas (100% aprobado)
repositorio
Buscar actualizaciones
44 de código
fuente
55 Ejecute las pruebas nuevamente (100% aprobado)
Desarrollador
Registrarse
66
1. Obtenga la última fuente del repositorio.
Antes de comenzar cualquier trabajo nuevo, debe asegurarse de tener el último y mejor código del
repositorio. Aquí puede ver la última compilación y comenzar su trabajo con una pizarra limpia.
2. Hacer cambios.
Entonces haces tu trabajo. Agregue la nueva funcionalidad, corrija el error o haga cualquier trabajo que
deba hacerse.
3. Ejecute pruebas.
Para asegurarse de que los cambios que realizó no hayan roto algo más en la base del código, ejecute
todas sus pruebas para asegurarse de que todas pasen.
4. Verifique si hay más actualizaciones.
Si sus cambios están funcionando, obtendrá otra actualización del repositorio, en caso de que alguien más
haya realizado algunos cambios mientras realizaba su trabajo.
Informe errata
C REATE UN A UTOMADO B UILD 243
5. Ejecute las pruebas nuevamente.
Luego ejecuta las pruebas una vez más para asegurarse de que sus cambios funcionen con cualquier otro
cambio que otros hayan realizado desde que comenzó a trabajar.
6. Check-in.
Todos los sistemas van. Todo se construye. Todas las pruebas corren. Tenemos lo último. Es seguro
registrarse.
Además de este proceso de registro, hay un par de cosas que no se deben hacer en relación con una buena conducta de
construcción.
Dos No hacer
Buscar actualizaciones Romper la construcción

EL RESPETO
Ejecute todas las pruebas Regístrese sobre las
LA construcciones rotas
Registrarse regularmente
CONSTRUIR Comente las pruebas de
Hacer que arreglar una unidad que fallan
construcción rota sea una prioridad
Al final del día, se trata de respetar la construcción, garantizar que esté siempre en funcionamiento y
ayudarse mutuamente cuando la rompamos (lo que sucede de vez en cuando).
15.6 Crear una compilación automatizada
El siguiente paso es crear una compilación automatizada. Realmente forma la columna vertebral del
proceso de integración continua de su equipo.
Una buena compilación automatizada compila el código, ejecuta las pruebas y básicamente hace todo lo
que debe hacerse regularmente como parte del proceso de compilación del proyecto.
Los desarrolladores lo ejecutan todo el tiempo como parte del círculo de vida de TDD y crean agentes (como
CruiseControl 1) úselo para ejecutar la compilación cada vez que detecten un cambio en el repositorio de código
fuente.
1) http://cruisecontrol.sourceforge.net/
Informe errata
C REATE UN A UTOMADO B UILD 244
Desarrolladores
¡Uy! Olvidé un archivo

El agente de compilación escucha los cambios ...
compilación automatizada
Escuchando
compilación automatizada
Repositorio
Construcción automatizada
Compilación automatizada
X Error
Notificar
y notifica al equipo si hay un problema.
Las compilaciones automatizadas también pueden automatizar la implementación del software en

producción y eliminar gran parte del error humano de esa ecuación.
Ambientes
DEV
Compilar
Construcción automatizada Configurar PRUEBA

Implementar
PINCHAR
La clave de cualquier construcción es la automatización: cuanto menos participación humana, mejor.

También desea mantener su compilación rápida, ya que usted y su equipo estarán funcionando
constantemente, muchas veces al día (menos de diez minutos es una buena regla general).
La mayoría de los lenguajes modernos tienen sus propios marcos de compilación automatizados (Ant para
Java, NAnt o MS-Build para .NET y rake para Rails). Si el lenguaje que está utilizando no lo hace,
generalmente puede crear el suyo con archivos de DOS o scripts Unix.
Pero a pesar de lo buenos que son los procesos de registro y las compilaciones automatizadas, lo que realmente hace que
todo funcione es la voluntad de trabajar en pequeños fragmentos.
Informe errata
TRABAJAR EN PEQUEÑOS C HUNKS 245
15.7 Trabajo en trozos pequeños
Al igual que las pruebas con TDD, la integración del código es mucho más fácil cuando se realiza en pequeño.
demasiado dolor de integración
Nuevo código de integración
Semanal
Diario
Minutos
quieres integrarte continuamente aquí
Con demasiada frecuencia, los equipos pasan días o semanas sin integrar su trabajo, eso es demasiado
tiempo. Desea integrar su código cada diez a quince minutos más o menos (como mínimo por hora).
No te estreses si no puedes registrarte con tanta frecuencia. Solo comprenda que cuanto más lo haga, más
fácil será. Por lo tanto, combine su código temprano y con frecuencia para evitar el dolor de las grandes
integraciones.
La integración continua se ha convertido en una práctica tan común que puede encontrar casi todo lo que
necesitará en la Web.
Wikipedia tiene un buen resumen de la práctica, 2 y uno de los primeros artículos de integración continua se
puede encontrar en el sitio web de Martin Fowler. 3
2) http://en.wikipedia.org/wiki/Continuous_integration
3) http://martinfowler.com/articles/continuousIntegration.html
Informe errata
TRABAJAR EN PEQUEÑOS C HUNKS 246
Maestro Sensei
y el aspirante a
guerrero
ESTUDIANTE: Maestro, obviamente no podemos tener todo listo para la producción durante la primera
iteración. ¿Qué quieres decir realmente cuando dices "listo para producción"?
MAESTRO: La preparación para la producción es una actitud. Cuando escribes pro-

Código listo para ducción, usted prueba e integra su software hoy. Cuando ve un error, lo arregla ahora. No
lo barres debajo de la alfombra e imaginas llegar a él en algún momento distante en el futuro. Toma la
actitud de que este software tiene que funcionar hoy. No el lejano mañana. Sí, es posible que no tenga
todas las campanas y silbatos que le gustaría, y sí, puede optar por no implementar hasta que se agreguen
más funciones. Pero tener la opción de implementar y saber que su software funciona es aceptar que su
software pasará la mayor parte de su vida en producción (no en desarrollo) y lo acostumbrará a la idea de
hacer cambios en un sistema de producción en vivo.
ESTUDIANTE: ¿Qué sucede si no puedo construir todo el sistema porque mi proyecto es solo una pequeña
parte de la imagen más grande?
MAESTRO: Luego construya, pruebe e implemente lo que pueda. En algún momento, necesitarás integrar
tu pieza con todo lo demás. Haz tu mejor esfuerzo para asegurarte de que tu porción esté lista para que
puedas hacer los cambios necesarios cuando puedas. Pero no permita que el hecho de que sea una pieza
pequeña le impida automatizar su compilación o integrar continuamente su software.
¡Eso es todo amigos!
Entonces, ahí lo tienes. Nuestro tour de force de force de prácticas de ingeniería de software ágiles
esenciales:
• Pruebas unitarias: para demostrar que lo que construimos funciona
Informe errata
¿A DONDE VOY DESDE AQUI? 247
• Refactorización: el arte de simple y mantener el código limpio y una alegría de leer
• Desarrollo basado en pruebas (TDD): para diseñar y lidiar con la complejidad
• Integración continua: reunirlo todo regularmente y mantener un estado de preparación para la

producción
Sin estos, poco en nuestros proyectos ágiles funcionaría, y rápidamente volveríamos a nuestros días de
"código y arreglo".
15.8 ¿A dónde voy desde aquí?
¡Felicidades! Ahora está armado y es peligroso con el conocimiento y la experiencia para iniciar, planificar y
ejecutar su propio proyecto ágil.
Adónde va desde aquí depende totalmente de usted.
Si está comenzando un nuevo proyecto, tal vez quiera comenzar con un mazo de inicio (Capítulo 3 , Cómo
subir a todos en el autobús, en la página 48 ) Haga que todos suban al autobús y se dirijan en la dirección
correcta haciendo las preguntas difíciles justo al comienzo del proyecto.
O, si ya está en medio de un proyecto (y su plan es claramente incorrecto), tal vez presione el botón de
reinicio organizando un taller de recopilación de historias (Sección 6.4 , Cómo organizar un taller de
recopilación de historias, en la página 108 ), seleccionando algunas historias realmente importantes y viendo
si puedes entregar algunas de ellas cada semana. Luego construya un nuevo plan basado en eso.
O, si está sufriendo por el lado de la ingeniería, tal vez comience mirando algunas de sus prácticas de
ingeniería y asegurándose de que no esté cortando esquinas en las pruebas y pague regularmente su
deuda técnica.
No hay mapa Tendrá que determinar qué es lo mejor para usted y su proyecto. Pero entienda que tiene las
herramientas, y apuesto a que probablemente ya sepa lo que hay que hacer.
¿Qué te detiene?
¡Sal y comienza a hacerlo!
Informe errata
Ultimas palabras
Se trata de elección.
Nadie puede evitar que produzca software de alta calidad. Nadie puede evitar que sea sincero y honesto
con sus clientes sobre el estado de su proyecto y lo que debe hacerse.
No me malinterpreten, nada de esto es fácil. Tenemos décadas de historia y equipaje trabajando en nuestra
contra. Pero al final del día, comprenda que la forma en que elige trabajar y la calidad del trabajo que
produce depende de usted y de nadie más.
No evangelices
No le digas a otras personas qué hacer.
En cambio, lidere con el ejemplo, acepte que los demás no siempre estarán allí y haga lo que se necesita
hacer.
Oh sí, y una cosa más.
No te preocupes por ser ágil
Una pregunta que escuchas mucho de los equipos cuando se ponen ágiles por primera vez es: “¿Ya
llegamos? ¿Estamos siendo ágiles?
Y esa es una pregunta justa para hacer. Como hacer algo nuevo por primera vez, naturalmente querrá
saber cómo lo está haciendo y si lo está haciendo según el libro.
Y eso es totalmente genial. Solo entienda que no hay libro, ni este ni ningún otro. No hay una lista de
verificación ágil que yo o cualquier otra persona pueda darle que le dirá si está siendo ágil.
Es un viaje, no un destino. Realmente nunca llegas allí.
Y no lo olvides. No se trata de "ser" ágil. Se trata de crear excelentes productos y brindar un servicio de
clase mundial a sus clientes.
Informe errata
Todo lo que puedo decir es que si crees que lo has logrado y lo tienes todo resuelto, has dejado de ser ágil.
Por lo tanto, no se obsesione con las prácticas. Tome lo que pueda de este libro y haga que se ajuste a su
situación y contexto únicos. Y cada vez que se pregunte si está haciendo las cosas de la "manera ágil",
hágase dos preguntas:
• ¿Estamos entregando algo de valor cada semana?
• ¿Nos esforzamos por mejorar continuamente?
Si puede responder afirmativamente a ambas preguntas, está siendo ágil.
Informe errata
Parte VI
Apéndices

Apéndice A
Principios ágiles
Aquí hay un resumen del Manifiesto Ágil 1 y doce principios rectores del movimiento ágil de software 2 tomado
del sitio web del Manifiesto Ágil.
A.1 El Manifiesto Ágil
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A
través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas

Software de trabajo sobre documentación completa
Colaboración con el cliente sobre negociación de contrato
Respondiendo al cambio sobre seguir un plan
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
A.2 Doce principios ágiles
1. Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de

software valioso.
2. Acepte los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos ágiles aprovechan el
cambio para la ventaja competitiva del cliente.
1) http://agilemanifesto.org
2) http://agilemanifesto.org/principles.html

T WELVE A GILE P RINCIPLES 252
3. Entregue software de trabajo con frecuencia, desde un par de semanas hasta un par de meses, con
preferencia al menor tiempo.
4. Los empresarios y desarrolladores deben trabajar juntos a diario durante todo el proyecto.
5. Construir proyectos alrededor de individuos motivados. Bríndeles el entorno y el apoyo que necesitan,
y confíe en ellos para hacer el trabajo.
6. El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él
es la conversación cara a cara.
7. El software de trabajo es la medida principal del progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y

usuarios deberían poder mantener un ritmo constante indefinidamente.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo y luego ajusta y ajusta su
comportamiento en consecuencia.
Informe errata
apéndice B
Recursos
Hay muchos grupos de noticias, recursos y otros lugares excelentes para que pueda continuar su viaje.
Aquí hay algunos buenos lugares para pasar el rato y aprender más sobre la entrega ágil de software y
cómo funciona:
• http://tech.groups.yahoo.com/group/extremeprogramming
• http://groups.yahoo.com/group/scrumdevelopment
• http://tech.groups.yahoo.com/group/leanagile
• http: // fi nance.groups.yahoo.com/group/kanbandev
• http://tech.groups.yahoo.com/group/agile-testing
• http://tech.groups.yahoo.com/group/agile-usability
• http: // fi nance.groups.yahoo.com/group/agileprojectmanagement

Apéndice C
Bibliografía
[Bec00] Kent Beck. Programación extrema explicada: abrazo

Cambio. Addison-Wesley, Reading, MA, 2000.
[Bec02] Kent Beck. Desarrollo guiado por pruebas: por ejemplo. Addison Wesley, Reading, MA,
2002.
[Blo01] Michael Bloomberg. Bloomberg por Bloomberg. John Wiley & Sons, Hoboken, Nueva
Jersey, 2001.
[Car90] Dale Carnegie. Cómo ganar amigos e influir en las personas.

Pocket, Nueva York, 1990.
[DCH03] Mark Denne y Jane Cleland-Huang. Software por Num-

Bers: Desarrollo de bajo riesgo y alto rendimiento. Prentice Hall, Englewood Cliffs, Nueva
Jersey, 2003.
[DL06] Esther Derby y Diana Larsen. Retrospectivas ágiles: hacer buenos equipos geniales. The
Pragmatic Programmers, LLC, Raleigh, NC, y Dallas, TX, 2006.
[Eva03] Eric Evans. Diseño basado en dominios: abordar la complejidad en el corazón del
software. Addison-Wesley Professional, Reading, MA, primera edición, 2003.
[FBB + 99] Martin Fowler, Kent Beck, John Brant, William Opdyke y
Don Roberts Refactorización: Mejora del diseño de código existente. Addison Wesley
Longman, Reading, MA, 1999.
[Fea04] Michael Feathers. Trabajando eficazmente con código heredado.

Prentice Hall, Englewood Cliffs, Nueva Jersey, 2004.

Un apéndice C. B IBLIOGRAFÍA 255
[GC09] Lisa Gregory y Janet Crispin. Pruebas ágiles: una guía práctica para probadores y equipos
ágiles. Addison-Wesley, Reading, MA, 2009.
[HH07] Dan Heath y Chip Heath. Hecho para pegar: por qué algunas ideas sobreviven y otras
mueren. Random House, Nueva York, 2007.
[HT03] Andrew Hunt y David Thomas. Prueba de unidad pragmática en Java con JUnit. The
[HT04] Andrew Hunt y David Thomas. Prueba de unidad pragmática en C # con NUnit. The
[Joh98] Spencer Johnson ¿Quién movió mi queso? Una forma increíble de lidiar con el cambio en
su trabajo y en su vida. Putnam Adult, Nueva York, 1998.
[Lik04] Jeffrey Liker. El camino de Toyota. McGraw Hill, Nueva York,

2004
[McC06] Steve McConnell. Estimación de software: desmitificando el arte negro. Microsoft Press,
Redmond, WA, 2006.
[Moo91] Geoffrey A. Moore. Cruzando el abismo. Harper Business,

Nueva York, 1991.
[Sch03] David Schmaltz. Los ciegos y el elefante. Berrett Koehler, San Francisco, 2003.
[SD09] Rachel Sedley y Liz Davies. Coaching ágil. The Pragmatic Programmers, LLC, Raleigh, NC,
y Dallas, TX, 2009.
[Sur05] James Surowiecki. La sabiduría de las multitudes. Anchor, Nueva York, 2005.
Informe errata
Índice
UNA vecinos, para proyecto, 68
Responsabilidad, 18 años , 28 , 32 - 33 programación en pareja, 170
Planificación adaptativa, 20 planeando póker, 126
Analista ágil, 38 rol de programador, 39
Coaching ágil ( Davies) 44 rol de gerente de proyecto, 42
Plan de comunicación ágil, ver roles en, 26 , 34 - 45
Plan de comunicación Grupos autoorganización, 31 - 32
ágiles, 253 especialistas vs. generalistas, 33 , 44
Lenguaje ágil, 25 inicio de proyectos, 41
Manifiesto Ágil 251 rol de probador, 40
rol de diseñadores de experiencia de usuario, 43

Planificación ágil, 20 - 21
ver también Planificación de velocidad en 144
planes ágiles, 133 - 136

acuerdos de trabajo de, 197
Principios ágiles, 251 ver también Cubierta de inicio; Visual

probadores ágiles del
Programadores ágiles, 39
espacio de trabajo, 40
Gerente de proyecto ágil, 42
Retrospectivas ágiles: hacer el bien Pruebas ágiles: una guía práctica para
Grandes equipos ( Derby), 186 Probadores y equipos ágiles ( Gregory y Crispin), 41
Equipos ágiles, 26 - 46
Ambigüedad, 45
responsabilidad en, 32 - 33
Análisis, 165 - 170
rol de analista, 38
Analista, 38
arquitectura del proyecto y, 74
Arquitectura, equipos y, 74
montaje, 88
cuadro de incendio, 148
cambiar en, 34 si
coubicación en, 29 - 30 Beck, Kent, 97 , 211 , 233
propiedad del código, 173 La tienda de surf de Big Wave Dave, 104
lenguaje común de, 198 - 199 Ejemplo de construcción BigCo, 164
retroalimentación constructiva, 184 Ejemplo de simulador de Black Jack,
funcionalidad cruzada en, 33 - 34 204 204 - 205
compromiso con el cliente, 29 - 31 Los ciegos y el elefante

Diseñado por, 169 (Schmaltz), 68n
desarrollo, 37 Bloomberg por Bloomberg ( Bloomberg)
diferencias en, 27 - 28 76
tono de ascensor y, 60 60 Bloomberg, Michael, 76
formando, 44 - 46 Errores, 66 , 134 , 181 , 190
participación en la plataforma de inicio, 52 ver también Lluvia de ideas
gestión de iteraciones, 165 refactorizadora, 62 , 110 , 112
perder un miembro 156 Presupuesto, 83 , 84 , 90

si UG DE SEGUIMIENTO D RUCKER E XERCISE
Seguimiento de errores, 175 Funcionalidad cruzada, 33 - 34

Loco, 200 , 205 , 221 Multitudes, sabiduría de, 126
Tiempo de construcción, 241 Clientes
Cuadro de incendio, 148 - 151 capacidad de cambiar de opinión, 137
vs. tabla de quemado, 150 compromiso con el proyecto, 88

propósito de, 148 lenguaje común con, 198
mostrando a las partes interesadas, 194 confianza de, 17
espacio de trabajo visual y, 196 demos para, 173
Tabla de quemado, 150 diseño y, 169
compromiso de 29 - 31
C fl exibilidad en el alcance, 138
participación en la plataforma de inicio, 52

Carnegie, Dale, 184
involucrado en, 70
Cambio, 34
errores y 181
planificación y 130
Necesidad de, dieciséis
en la entrega de software, 18 años
historias de usuarios y, 101

NO crear listas, 64
ver también Planificación

personas de 110
Características de los miembros del equipo ágil. priorizando, 143
44 prioridades de clasificación, 86
Proceso de registro 242 - 243 papel de, 36
Clientela, ver Co-ubicación de taller de recopilación de historias para,
clientes, 29 - 30 , 75 108 - 113
Código, ver Gestión de iteraciones; responsabilidad del equipo a, 33
Refactorización de como término 25
repositorios de código, 241 hacer una prueba por, 82
Código colectivo de propiedad, 173 entrenamiento vs. parto, 85
Cubierta del comandante, 57 comprender el propósito de 55
Plan de comunicación, 179 - 190 historias del usuario, 99 , 104
combinando reuniones, 187 - 190 ver también Plan de comunicación;
levantamientos diarios, 186 - 187 , 189 Gestión de iteraciones
retroalimentación durante la iteración, 180
reunión de planificación de iteración, 183 - 184

mini-retrospectivas, 184 - 186 re
vitrinas, 182 Reunión diaria de pie, 186 - 187 , 189
reunión de planificación de la historia, 180 - 181 Entrega, ver Entrega de software Fechas de
Comunicación, el mejor medio de 113 entrega, 146 - 147
Comunidad, 253 Entrega versus entrenamiento, 85
Terminación, ver Complejidad realizada, en Software de demostración, 173 , 237
código, 230 - 233 Despliegue, 237
Cono de incertidumbre, 116f Desarrollo, 170 - 173
Restricciones, 106 Equipo de desarrollo, 37
Retroalimentación constructiva, 184 Documentación
Integración continua (CI), 236 - 249 desafíos con, 94 - 97
proceso de registro, 242 - 243 requisitos y, 97 , 113
de fi nido 240 - 241 para un equipo pequeño y compartido, 165
demos y, 236 - 239 Dodds, Keith, 50

cultura de preparación para la producción, 239 Diseño impulsado por dominio: abordar
recursos, 245 Complejidad en el corazón del software
configurarlo, 241 - 242 ( Evans), 199
Costo del proyecto 90 Hecho, 21 - 22
Crispin, Lisa, 41 Ejercicio Drucker 41
257
mi LANZAMIENTO DEL LEVADOR J ANÁLISIS DE TIEMPO USADO
mi antecedentes de 51
Tono de ascensor, 52 , 58 - 60 60 equilibrar y dar, 81 - 87
Plantilla de inclinación del elevador, 59 aclarar objetivos de, 58
Empoderamiento, 32 - 33 intención del comandante y, 57
Rebanadas de extremo a extremo, 100 costo y, 90
Epopeyas, 111 descrito, 51
Errores, ver Estimación de tono de ascensor para, 58 - 60 60
errores, 114 - 115 compromiso en el proceso, 56
días vs. puntos, 122 cómo funciona, 51 - 52
planificación de la técnica de póker, 126 - 127 introducido, 48
sistemas basados en puntos, 120 problemas y desafíos, 74 - 78
proceso de, 116 - 122 necesidad de, 49
propósito de, 115 concepto de vecinos, sesenta y cinco - 71
reestimando, 125 NO lista para, 64 - 66
dimensionamiento relativo, 117 visión general de, 52 - 53
Picos, 125 ejercicio de caja de producto, 61 - 63
técnica de triangulación, 122 - 126 propósito detrás del proyecto, 55
incertidumbre en, 116f Evans, mostrando a las partes interesadas, 192
Eric, 199 partes interesadas y 89
Reunión de ejecutivos, 191 - 195 resumen, 91 91 - 92
Expectativas, ambientación, 180 equipo de montaje, 88
Programación extrema explicada: periodo de tiempo, 52 , 78 - 80
Aceptar el cambio ( Arroyo), 97 transición a, 151

espacio de trabajo visual y, 195
F visualizando la solución, 73 - 74
Fichas, 98
Fracaso, riesgo de, 79f Plumas, Michael, 209
Siglas INVERTIR, 103 , 105
, 223
Iteración, 20 , 25 , 135
Retroalimentación, 180 , 184
Iteración 0, 172
Flexibilidad, 101 , 137 , 154
Gestión de iteraciones, 161 - 178
Fluir, 175
iteración ágil 163 - 164
Diagramas de flujo, 167
análisis y diseño, 165 - 170
Fowler, Martin, 97 , 223 , 245
Ejemplo de construcción BigCo, 164
Furioso cuatro, 83
errores y 200
entregando valor semanalmente, 162
sol desarrollo, 170 - 173
Galton, Francis, 126
retroalimentación, 180
Generalistas, 33 , 44
diagramas de flujo, 167
Gibbons, Robin, 51
iteración 0, 172
Gregory, Janet, 41
análisis justo a tiempo, 166
Kanban 174 - 176
H refactorización y 223
Heath, Chip, 57 pared de liberación, 193
Heath, Dan 57 escaparate, cancelación, 189
Cómo ganar amigos e in fl uencia pruebas, 172 - 174
Personas ( Carnegie), 184 ver también Refactorización de la reunión de planificación de
Caza, Andy, 211 iteraciones, 183 - 184
yo J
En cosas, sesenta y cinco Jobs, Steve 30
Cubierta de inicio Análisis justo a tiempo, 166
258
K ANBAN R EFACTORING
K lanzamientos, 140
Kanban 174 - 176 dimensionando historias, 141
Kelleher, hierbas, 57 planes estáticos, 131 - 133

reunión de planificación de la historia, 180 - 181
L transición de un proyecto a ágil,

151 - 152
Idioma, términos para saber, 25 , 135
velocidad y 144 - 146
Limones contra limonada, 116
ver también Planificación adaptativa;
Liker, Jeffrey, 56
Integración continua; Estimacion; Cubierta de
inicio; Refactorización; Periodo de tiempo;
METRO Historias de usuarios Planificación de póker, 126 - 127
Hecho para pegar ( Heath y Heath), 57
Lista maestra de historias, 25 , 135
McConnell, Steve, 115

Sistemas basados en puntos, 120
Reuniones, ver Plan de comunicación Pregunta del
Prueba de unidad pragmática en C # con NUnit
millón de dólares, 66
(Hunt y Thomas), 211
Mini retrospectivas, 184 - 186
Prueba de unidad pragmática en Java con
Conjunto mínimo de funciones comercializables (MMF),
JUnit ( Hunt y Thomas), 211
140
Priorizando, 143
Errores 66 , 134 , 181 , 190
Beneficios del producto, 62
ver también Refactorizando
Caja del producto, 53 , 61 - 63
Mott, Randy, 79
Dueño del producto, ver Clientes Disponibilidad
de producción, 239
norte Productividad, coubicación y, 29
Vecinos sesenta y cinco - 71 Programadores, 39
Lista de cosas buenas para tener, 154 Gerente de proyecto, 42
NO lista, 53 , 64 - 66 , 109 Proyectos

razones para, 58
O entra, 171
el éxito en, 49
O fi cina, ver Espacio de trabajo visual
preguntas difíciles en 50
Repositorios de código abierto, 241
transición a ágil, 151 - 152
Herramientas de código abierto, 73
desperdiciar, 142
Fuera de las cosas, sesenta y cinco
PAGS Q
Calidad, 83 , 84
Programación en pareja, 170
Preguntas, 50 , 66
Pascal, Blaise, 60 60
Personas, 110 , 167
Imágenes, para lluvia de ideas, 110 R
El toque de Pixar (película), 30 Tarjetas de recetas, 98
Planificación, 20 - 21 , 130 - 159 Prueba de grabación / reproducción, 241
adaptabilidad y 20 Refactorización, 213 - 224

planes ágiles, 133 - 136 enfoque agresivo para, 218
cuadro de incendio, 148 - 151 Black Jack ejemplo, 219 - 221
desafíos en 152 - 157 connotaciones de 222
fechas de entrega, 146 - 147 fl exibilidad y velocidad, 214 - 215
falla, 155 Gran escala, 221
fl exibilidad en el alcance, 137 - 139 práctica de, 216 - 219
lista de historia maestra, 139 - 142 propósito de, 217
priorizando, 143 recursos para 223
gerentes de proyecto y, 42 deuda técnica, 215 - 216
259
Refactorización: mejora del diseño del código existente ( F OWLER) DESLIZADORES T RADE-OFF
desarrollo basado en pruebas y, 229 Partes interesadas, 89 , 191 - 195

Dónde empezar, 219 ver también Preguntas iniciales
ver también Integración continua; de clientes, 41
Desarrollo dirigido por pruebas (TDD); Pruebas; Planes estáticos, 131 - 133
Examen de la unidad Muro de la historia, 196
Refactorización: mejora del diseño de Taller de recopilación de historias, 108 - 113

Código existente ( Cazador de aves), 223 Reunión de planificación de la historia, 180 - 181
Dimensionamiento relativo, 117 Éxito, 49 , 55

Lanzamiento, 140 Ejemplo de tienda de surf, 104
Pared de liberación, 193 , 196 Surowiecki, James, 126

Repositorios, 241
Requisitos, 97 , 153
Recursos, 253
T
Velocidad del equipo, 20 , 135 , 144 , 154 , 156 ,
Retrospectivas, 184 - 186
183 , 188 , 194
Riesgo, 70
pruebas unitarias y, 211
Bloomberg en 76
Equipos, ver Equipos ágiles Deuda
discusión de 75 , 76
técnica, 215 - 216
de fracaso, 79f vale la pena sudar, 77
Plantillas
tono de ascensor, 59
Roles
historias del usuario, 107
ver también Roles de clientes, en equipos ágiles, 26 ,
Terminología, 25 , 135
34 - 45 , 88
Desarrollo guiado por pruebas: por ejemplo
(Arroyo), 233
S Test, para clientes, 82
Alcance, 83 , 84 , 137 , 154 , ver NO listar Scrum Master, 44 Desarrollo basado en pruebas (TDD),
225 - 235
Autoorganización, 31 - 32 complejidad y 230 - 233
Vitrinas, 182 de fi nido 226
Verdades simples ver Tres simples ejemplo de, 231
Verdades visión general de, 226 - 230
sinceridad, 69 razones para, 231

Dimensionando historias, 141 recursos para 233
Rebanadas del pastel, 100 reglas generales para, 226
Deslizadores, compensación, 85 cuando parar 226
Lemas, poder de, 62 Probadores, 40
Software por números: bajo riesgo, Pruebas, 17 , 39 , 40

Desarrollo de alto retorno ( Denne), 140n Entrega de código de registro, 242
software integración continua y, 238
en la gestión de iteraciones, 172 - 174
responsabilidad en, 18 años historias del usuario, 102
ventajas de, 17 ver también Refactorización; Unidad de prueba
cambiar y 18 años , 34 Thomas, Dave, 211
finalización de, 21 - 22 Tres verdades simples 23 - 25

punto de vista del cliente de, 17 Hora, 83
planeando para, 20 - 21 Periodo de tiempo, 90 , 157
verdades de 23 - 25 documentación y 98
Estimación de software: desmitificando el reuniones de planificación iterativa, 183
Arte negro ( McConnell), 115 para proyectos, 78 - 80
Guerrero espartano, 155 El camino de Toyota ( Liker), 56
Especialistas contra generalistas, 33 , 44 Seguimiento de errores, 175
Espiga, 125 Deslizadores de compensación, 85
260
T LLUVIA VS. ENTREGA GRUPOS Y AHOO
Entrenamiento versus entrega, 85 pulido, 112

Transicionando a ágil, 151 reestimar, 125
Triangulación, 122 - 126 tamaño de, 102 , 111 , 119 , 121
Confiar, 66 dimensionándolos, 141
Las verdades ver Tres verdades simples, doce pasos de 164
principios ágiles, 251 guión gráfico y 194
ejemplo de tienda de surf, 104
U plantillas para, 107 , 108

pruebas, 102
Examen de la unidad, 203 - 212
taller de reunión, 108 - 113
beneficios de 206
ver también Plan de comunicación;
Ejemplo de simulador de Black Jack,
Gestión de iteraciones
204 204 - 205
V
errores y 205
depuración y 207
Velocidad, ver Espacio de trabajo visual de
descrito, 206 - 210
velocidad del equipo, 191 - 201
recursos educativos, 210
errores y 200
velocidad del equipo y 211
lenguaje común de, 198 - 199
que probar 207
creando, 195 - 197
ver también Probar cosas NO
reunión de ejecutivos, 191 - 195
RESUELTAS, sesenta y cinco
intenciones 197
Prueba de aceptación del usuario (UAT), 173
visión general, 200 - 201
Diseñadores de experiencia de usuario (UX), 43
W
Historias del usuario
componentes de, 99 - 108

restricciones para 106 Despierta, Bill, 103
de fi nido 98 Quién movió mi queso ( Johnson) 34
documentación y 94 - 97 La sabiduría de las multitudes ( Surowiecki),
ejercicio, 105 126
ayudando a los clientes con 104 Ambiente de trabajo, ver Visual

espacio de trabajo
incompleto, 188
análisis justo a tiempo de, 166 Trabajando efectivamente con código heredado
lista maestra de, 139 (Plumas), 209 , 223
visión general de, 98 - 99
programación en pareja, 170 Y

personas y 168 Grupos de Yahoo, 253
261
La estantería pragmática
Disponible en libros de bolsillo y libros electrónicos sin DRM, nuestros títulos están aquí para ayudarlo a mantenerse al tanto de su juego. Lo
siguiente está impreso a partir de agosto de 2010; asegúrese de visitar nuestro sitio web en
pragprog.com para títulos más nuevos.
Título Año ISBN Páginas
Recetas avanzadas de Rails: 84 nuevas formas de crear aplicaciones 2008 9780978739225 464
impresionantes de Rails
Coaching ágil 2009 9781934356432 248
Retrospectivas ágiles: hacer buenos equipos buenos 2006 9780977616640 200
Desarrollo web ágil con rieles, tercera edición 2009 9781934356166 784
Inicio de la programación de Mac: Desarrolle con Objective-C y 2010 9781934356517 300

Cocoa
Detrás de puertas cerradas: secretos de una gran gestión 2005 9780976694021 192
Lo mejor de Ruby Quiz 2006 9780976694076 304
Programación de cacao: una guía de inicio rápido para desarrolladores 2010 9781934356302 450
Core Animation para Mac OS X y iPhone: creación de interfaces de 2008 9781934356104 200
usuario dinámicas convincentes
Datos básicos: API de Apple para datos persistentes en Mac OS X 2009 9781934356326 256
Procesamiento de datos: resuelva problemas cotidianos 2005 9780974514079 208

utilizando Java, Python y más
Depurarlo! Encuentra, repara y evita errores en tu código 2009 9781934356289 232
Implementación de aplicaciones de Rails: una guía paso a paso 2008 9780978739201 280
Diseñe sitios web accesibles: 36 claves para crear contenido 2007 9781934356029 336
para todos los públicos y plataformas
Desktop GIS: Mapping the Planet with Open Source Tools 2008 9781934356067 368
Desarrollo de aplicaciones de la plataforma de Facebook con rieles 2008 9781934356128 200
Diseño controlado por dominio utilizando objetos desnudos 2009 9781934356449 375
Integración empresarial con Ruby 2006 9780976694069 360
Recetas Enterprise con Ruby y Rails 2008 9781934356234 416
Scripting diario con Ruby: para equipos, probadores y usted 2007 9780977616619 320
ExpressionEngine 2: una guía de inicio rápido 2010 9781934356524 250
FXRuby: Crear GUIs Lean y Mean con Ruby 2008 9781934356074 240
De Java a Ruby: cosas que todo gerente debe saber 2006 9780976694090 160
Continúa en la siguiente página

SIG para desarrolladores web: agregar dónde a sus aplicaciones web 2007 9780974514093 275
API de Google Maps, V2: agregar dónde a sus aplicaciones 2006 PDF-Only 83
Griales: una guía de inicio rápido 2009 9781934356463 200
Recetas maravillosas: engrasar las ruedas de Java 2008 9780978739294 264
Hola, Android: Presentación de la plataforma de desarrollo móvil 2010 9781934356562 320

de Google
Diseño orientado a interfaz 2006 9780976694052 240
Consigue el trabajo tecnológico que amas 2009 9781934356265 280
Patrones de implementación del lenguaje: cree sus propios lenguajes de 2009 9781934356456 350
programación específicos de dominio y generales
Aprender a programar, 2a edición 2009 9781934356364 240
¡Gestionarlo! Su guía para la gestión de proyectos pragmáticos 2007 9780978739249 360

modernos
Administre su cartera de proyectos: aumente su capacidad y 2009 9781934356296 200

finalice más proyectos
Dominar Dojo: JavaScript y herramientas Ajax para grandes 2008 9781934356111 568
experiencias web
Metaprogramming Ruby: programa como los profesionales de Ruby 2010 9781934356470 240
Java modular: creación de aplicaciones flexibles con OSGi y Spring 2009 9781934356401 260
No Fluff Just Stuff 2006 Antología 2006 9780977616664 240
No Fluff Just Stuff 2007 Antología 2007 9780978739287 320
Técnica Pomodoro ilustrada: la manera fácil de hacer más en menos 2009 9781934356500 144
tiempo
Programación práctica: una introducción a la informática usando 2009 9781934356272 350

Python
Prácticas de un desarrollador ágil 2006 9780974514086 208
Automatización pragmática de proyectos: cómo construir, 2004 9780974514031 176

implementar y monitorear aplicaciones Java
Pensamiento y aprendizaje pragmáticos: refactorice su wetware 2008 9781934356050 288
Prueba de unidad pragmática en C # con NUnit 2007 9780977616671 176
Prueba de unidad pragmática en Java con JUnit 2003 9780974514017 160
Control de versiones pragmáticas usando Git 2008 9781934356159 200
Control de versiones pragmáticas utilizando CVS 2003 9780974514000 176
Control de versiones pragmáticas usando Subversion 2006 9780977616657 248
Programando Clojure 2009 9781934356333 304
Programación de Cocoa con Ruby: Cree aplicaciones Mac 2009 9781934356197 300
convincentes usando RubyCocoa
Continúa en la siguiente página

Programación de Erlang: software para un mundo concurrente 2007 9781934356005 536
Programación Groovy: productividad dinámica para el desarrollador 2008 9781934356098 320

Java
Programming Ruby: The Pragmatic Programmers 2004 9780974514055 864

'Guide, Second Edition
Programando Ruby 1.9: La Guía Pragmática de 2009 9781934356081 960

Programadores
Scala de programación: aborde la complejidad multinúcleo en 2009 9781934356319 250

la máquina virtual Java
Prototipo y script.aculo.us: ¡Nunca sabías que JavaScript podría hacer 2007 9781934356012 448
esto!
Recetas de rieles 2006 9780977616602 350
Rieles para desarrolladores .NET 2008 9781934356203 300
Rails para desarrolladores Java 2007 9780977616695 336
Rieles para desarrolladores PHP 2008 9781934356043 432
Desarrollo rápido de GUI con QtRuby 2005 PDF-Only 83
¡Liberarlo! Diseñar e implementar software listo para producción 2007 9780978739218 368
Antipatterns SQL: evitando las trampas de la programación de 2010 9781934356555 352

bases de datos
Prueba guiada de GUI con Ruby 2008 9781934356180 192
¡Envíalo! Una guía práctica para proyectos de software exitosos 2005 9780974514048 224
Stripes ... y el desarrollo web Java vuelve a ser divertido 2008 9781934356210 375
Prueba de manejo ASP.NET MVC 2010 9781934356531 296
TextMate: Edición de energía para Mac 2007 9780978739232 208
La referencia definitiva de ANTLR: construcción de lenguajes 2007 9780978739256 384

específicos de dominio
El programador apasionado: crear una carrera notable en el 2009 9781934356340 200

desarrollo de software
Antología de ThoughtWorks 2008 9781934356142 240
Ubuntu Kung Fu: consejos, trucos, sugerencias y hacks 2008 9781934356227 400
Diseño web para desarrolladores: una guía del programador para 2009 9781934356135 300
diseñar herramientas y técnicas
Desarrollo de iPhone SDK 2009 9781934356258 576

¡Visita PragProg.com para más!
Depurarlo!
Depurarlo! lo equipará con las herramientas, técnicas y enfoques para ayudarlo a
abordar cualquier error con confianza. Estos secretos de depuración profesional
iluminan cada etapa del ciclo de vida del error, desde la construcción de software
que facilita la depuración; a través de la detección de errores, reproducción y
diagnóstico; para desplegar su fi nal eventual. Aprenda una mejor depuración si
está escribiendo Java o lenguaje ensamblador, apuntando a servidores o
microcontroladores integrados, o utilizando enfoques ágiles o tradicionales.
Depurarlo! Encuentra, repara y evita errores en tu código
Paul Butcher (232 páginas) ISBN: 978-1-9343562-8-9. $ 34.95
http://pragprog.com/titles/pbdp
Antipatterns SQL
Si está programando aplicaciones que almacenan datos, entonces es probable
que esté utilizando SQL, ya sea directamente o mediante una capa de mapeo.
Pero la mayor parte del SQL que se usa es ineficaz, difícil de mantener y, a
veces, simplemente erróneo. Este libro le muestra todos los errores comunes y
luego lo guía a través de los mejores fi jos. Además, te muestra qué es detrás estos
fi jos, por lo que aprenderá mucho sobre bases de datos relacionales en el
camino.
Antipatterns SQL: evitando las trampas de la programación de

bases de datos
Bill Karwin (300 páginas) ISBN: 978-19343565-5-5. $ 34.95
http://pragprog.com/titles/bksqla

¡Visita PragProg.com para más!
Impulsando el cambio técnico

La resistencia de sus compañeros de trabajo a las nuevas tecnologías puede
ser desconcertante. Aprenda a leer los "patrones de resistencia" de los usuarios
y luego desmantele sus objeciones. Todo desarrollador debe dominar el arte de
evangelizar. Con estas técnicas y estrategias, ayudará a su organización a
adoptar sus soluciones, sin vender su alma a la política organizacional.
Impulsar el cambio técnico: por qué las personas en su equipo no actúan

sobre buenas ideas y cómo convencerlas de que deberían
Terrence Ryan (200 páginas) ISBN: 978-1934356-60-9. $ 32.95
http://pragprog.com/titles/trevan
Siete idiomas en siete semanas

En este libro obtendrá un recorrido práctico de Clojure, Haskell, Io, Prolog, Scala,
Erlang y Ruby. Ya sea que su idioma favorito esté o no en esa lista, ampliará su
perspectiva de programación al examinar estos idiomas uno al lado del otro.
Aprenderá algo nuevo de cada uno y, lo mejor de todo, aprenderá a aprender un
idioma rápidamente.
Siete idiomas en siete semanas: una guía pragmática para aprender

lenguajes de programación
Bruce A. Tate (300 páginas) ISBN: 978-1934356-59-3. $ 34.95
http://pragprog.com/titles/btlang

La estantería pragmática
La biblioteca pragmática presenta libros escritos por desarrolladores para desarrolladores. Los títulos continúan con el conocido estilo de
programador pragmático y continúan obteniendo premios y excelentes críticas. A medida que el desarrollo se vuelve más y más difícil, los
Programadores Pragmáticos estarán allí con más títulos y productos para ayudarlo a mantenerse al tanto de su juego.
Visítanos en línea
El ágil samurai
http://pragprog.com/titles/jtrap
Código fuente de este libro, erratas y otros recursos. ¡Ven a darnos tu opinión también!
Regístrese para recibir actualizaciones
http://pragprog.com/updates
Ser notificado cuando haya actualizaciones y nuevos libros disponibles.
Unete a la communidad
http://pragprog.com/community
Lea nuestros weblogs, únase a nuestras discusiones en línea, participe en nuestra lista de correo, interactúe con nuestro wiki y benefíciese
de la experiencia de otros programadores pragmáticos.
Nuevo y digno de mención

http://pragprog.com/news
Vea los últimos desarrollos pragmáticos, nuevos títulos y otras ofertas.
Comprar el libro
Si le gustó este libro electrónico, tal vez le gustaría tener una copia en papel del libro. Está disponible para comprar en nuestra tienda: pragprog.com/titles/jtrap
.
Contáctenos
Pedidos en línea: www.pragprog.com/catalog
Servicio al Cliente: support@pragprog.com

Versiones no inglesas: Translations@pragprog.com
Enseñanza pragmática: academic@pragprog.com
Propuestas de autor: propuestas@pragprog.com
Contáctenos: 1-800-699-PROG (+1919847 3884)

Planificar la próxima iteración

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Planificar la próxima iteración

Cargado por

Copyright:

Formatos disponibles

LA HISTORIA - REUNIÓN DE LANZAMIENTO 181

Vas a cometer errores: no te preocupes

Mostrar algo de IPM Escaparate

Obtenga comentarios de los clientes

10.4 Planifique la próxima iteración

Cielos despejados Pocas nubes, posibilidad de lluvia Gran tormenta

- Viento en popa - Estamos entregando - Houston, tenemos un problema

Cómo dar retroalimentación constructiva

Hay dos formas de dar retroalimentación. Puedes servirlo recto y frío:

• “Suzy, trabajo increíble en el módulo de impresión. Aplique el mismo nivel de detalle a

10.5 Cómo alojar una mini retrospectiva

La directiva principal retrospectiva

Independientemente de lo que descubramos, entendemos y realmente

En otras palabras, no es una caza de brujas.

Entonces puedes calentar a la gente haciendo la primera pregunta retrospectiva.

1. ¿Qué estamos haciendo realmente bien?

"Jimmy, buen trabajo en esas pruebas unitarias, amigo".

El otro lado de la ecuación está hablando de dónde podemos mejorar.

2. ¿Dónde necesitamos ser mejores?

10.6 Cómo no organizar un stand-up diario

Sincronización diaria rápida para llegar a la misma página

Coordina actividades con el resto del equipo Corto (<10 min)

• Lo que hicieron ayer

• Lo que están haciendo hoy

• Si hay algo que los frena

Buena información. Simplemente no es muy inspirador o cambia el comportamiento.

• Lo que hiciste para cambiar el mundo ayer

• Cómo vas a aplastarlo hoy

10.7 Haz lo que sea que funcione para ti

Escenario # 1: La historia incompleta

ESTUDIANTE: ¿No, sensei?

Escenario n. ° 2: los enfrentamientos diarios no están agregando valor

ESTUDIANTE: No te estoy siguiendo, Sensei. ¿Cómo podría traer cada

ESTUDIANTE: ¿Estás diciendo que algunos equipos no necesitan stand-ups diarios?

valor. Deben modificar o descartar los que no lo hacen.

Escenario # 3: La iteración donde no se produjo nada de valor

ESTUDIANTE: Gracias maestro. Contemplaré esto más.

Configurar un espacio de trabajo visual

¿Por qué no hacer lo mismo para tu proyecto?

Hablando de eso, aquí vienen ahora.

11.1 Uh-oh ... ¡Aquí vienen los Heavies!

Descargar desde Wow! eBook <www.wowebook.com>

Llevando a los ejecutivos a la velocidad

¿Por qué Tono de Caja de

Conoce a los Mostrar

El muro de lanzamiento Cartas de historia restantes

I1 I2 I3 Iteración 4 Que hacer

Parece que estamos casi ½ camino

No empezado En progreso Listo para la prueba Hecho

En construcción Listo para revisar Bendecido y visto por

Mirando sus relojes, luego van al grano y preguntan cuándo tú

Velocidad del equipo Proyecto quemado

Qué tan rápido vamos Cuando esperamos terminar

El proyecto quema (ver arriba en la Sección 8.5 , La tabla de quemaduras,

11.2 Cómo crear un espacio de trabajo visual

• Un gráfico de velocidad y quemado

• Una cubierta de inicio, si tienen la habitación

No empezado En progreso Listo para la prueba Hecho

11.3 Muestra tu intención

Acuerdos de trabajo Valores compartidos

* *Horas principales de 9 a.m. a 4 p.m. * * No cortamos esquinas

* * Levántate a diario a las 10 en punto * * Sin ventanas rotas

* * Hecho incluye pruebas * *Está bien no estar de acuerdo

* Horas principales de 9 a.m. a 4 p.m. * No cortamos esquinas

* Respeta la construcción * Podemos manejar la verdad