Contrucciondesoftware Adelanto

z . . . [ e t.al.
]
c o l á s P ae U N T REF
© Ni dición
d e e s t a e
i o n a l de Tres
©
e r s i d a d Nac duntref
(Univ a ra E
F e b r e r o ) p
U n i v e rsidad
de d e la rero).
i t o r i a l e F e b
(Ed
a l d e Tres d e re chos
i o n s d
Nac
a d o s todos lo a Edun-
Reserv e d i c ión pa i 2736,
r
a n
de est REF), Mosco e nos
( U N T e B u
tref ñ a , P cia. d
Pe .ar
Sáenz w.unt r e f. e d u
r e s . w w
Ai
Construcción de software: una mirada ágil
z . . . [ e t.al.]
© Ni dición
d e e s t a e
i o n a l de Tres
©
(Univ a ra E
F e b r e r o ) p
U n i v e rsidad
de d e la rero).
(Ed
i o n s d
Nac
r
a n
( U N T e B u
Pe .ar
r e s . w w
Ai
Construcción de software:
una mirada ágil
z . . . [ e t.al.] Diego Nicolás Paez

F
o l á s P ae U N T EFontdevila
RPablo
© Ni c d i c ión s Suárez
esta e T r e
de Carlos Fontela
© de a c i o n al Marcio
e r s i d a dN untref
Degiovannini
(Univ a r a Ed Alejandro Molinari
F e b r ero) p
U n i v e rsid d a
de d e la rero).
(Ed
i o n s d
Nac
r
a n
( U N T e B u
Pe .ar
r e s . w w
Ai
EDUNTREF
Editorial de la universidad nacional de tres de febrero
Coordinación editorial
Néstor Ferioli
Corrección
Licia López de Casenave
Ilustraciones
María Compalati
Directora de diseño editorial y gráfico
Marina Rainis
Diseño y diagramación
Valeria Torres
Coordinación gráfica
Marcelo Tealdi
z . . . [et.al.]
i c o lás P a e
n U N TREF
© N edici ó
e e s t a a l d e Tres
© d Nacio n
s i d a d
(Unive r
a r a Eduntref
F e b r ero) p
U n i v e rsidad
de de la r ero).
t o r i a l e F e b
(Edi d e Tres d e chos
i o n a l s d e r
Nac
d o s to dos lo E dun-
r v a
seMaría Compalati. –1a a r a
Repor ónSáenzpPeña: i 2736,
Construcción de software: una mirada ágil / Nicolás Paez...
[et.al.]; ilustrado
e d i c ied.–
Universidad Nacionale tade Febrero, 2014.Moscon
desTres
296 p.: il.; 23d xe F),
15 cm.
f ( U N T R E
. d e B uenos
tre
ISBN 978-987-1889-43-3
ñ a , II.Pcia
Pe du.ar
Sáeilus.nz e
1. Software. 2. Informática. I. Paez, Nicolás
n t r e f.
ww.u
Compalati, María,
Aires. w
CDD 005.3
© Nicolás Paez... [et.al.]

© de esta edición UNTREF (Universidad Nacional de Tres de Febrero) para Eduntref
(Editorial de la Universidad Nacional de Tres de Febrero). Reservados todos los derechos
de esta edición para Eduntref (UNTREF), Mosconi 2736, Sáenz Peña, Provincia de Bue-
nos Aires. www.untref.edu.ar
Primera edición septiembre de 2014.
Hecho el depósito que marca la ley 11.723.
Queda rigurosamente prohibida cualquier forma de reproducción total o parcial de esta
obra sin el permiso escrito de los titulares de los derechos de explotación.
Impreso en la Argentina.
Índice
Prólogo....................................................................................................9
Agradecimientos....................................................................................13
Prefacio.................................................................................................15
¿Por qué cambiar?.................................................................................19
t.al.]
Iterativo por naturaleza...........................................................................31
z . . . [ e
Delineando el alcance............................................................................39
© Nnoi es predecir...........................................................................49
dición
e de Tres
Estimar
e e s t a a l
© d
Planificación
Nac i o n
constante..........................................................................59
s i d a d ................................................................71
(Univ
Empezando e
por rla aceptación.
a r a Eduntref
F e b
Arquitectura y diseño r eenro ) p
U n i v e rsidad
emergencia......................................................87
de d e la rero).
i t o r i a e F e b
Probar, probar, probar..l.........................................................................105
Esto (está
a l d e Tres d
Edlisto......................................................................................125
e r e chos
i o n s d
Integrando
a d o s t odos lo a Edun-
Naelcproducto al instante.........................................................137
Reserv e d ic ión pa i 2736,
r
En retrospectiva...................................................................................155
ta oscon
de es............................................................................175
Reuniendo al equipo.
M
T R E F ) , u e nos
( U N e B
cia. d
Irradiando información.........................................................................183
tref ñ a , P
e n z P e e d u .ar
¿Quién manda a quién?........................................................................197
S á r e f .
s . w w.unt
No hay como un buen ambiente...........................................................209
w
La fantasíaA r e
deievitar los cambios..........................................................221
Formalizando compromisos.................................................................229
Construyendo con calidad día tras día..................................................241
Un día de desarrollo ágil.......................................................................249
Todo muy lindo pero............................................................................261
La riqueza de la diversidad...................................................................273
Bibliografía y referencias......................................................................290
Prólogo
—¿Y vos qué hacés, Juan? ¿Seguís trabajando con com-

putadoras?
—Mmm… ahora trabajo más con personas que con
computadoras.
Esta conversación la tuve una semana antes de escribir es-

tas líneas, y me llama la atención
. . [ e l.] personal y pro-
tel.acambio
fesional quelá s P z .
e respuesta. Los N
ami T EF
Rdesarrollamos
c o implica
© Ni y soluciones U que
software
s t a e dicienóntecnologíae deTrlaeinforma-
basadas s
ción nos d e
dimos e cuenta que losioproblemas n a l d que soluciona-
© son eminentemente
d a ac
d Nhumanos,
mos
n i v e r s i E d y los modelos mate-
untref
(U a los que rqueremos p a r a d
rsidazona
máticos llevarlos son simplificaciones
e b r )
eparaonosotros, i v e
d e F
tranquilizadoras
l a nosU n
llevan a nuestra
.
de
e rer o )
confort.
Y(E dito rial d debe sumarse s d e Felabforma
a esta complejidad,
l d e Trunae que
r e c h oensenquela
a sd e
Nacion simultáneamente s leloproducto
se resuelve el problema es construcción social,
o s t o d o Eyd n-
eluequipo
que evolucionan
e r v a d a r a
es
que loRproduce.
e d i c ió n p 2 36,fi-
7desde
e s
Esto se contrapone t a con el paradigma s c o n i
utilizado
nes dedlaedécada de 1960,
T R E F
que ), veMalodesarrollo B u
dee nos
software
(U N
trefconstrucciónñhecha e
. d de software por
como “una
a , P ciafábricas
en
e n z P
recursos”, equiparando e diseño con u .ar a equipos
construcción,
e d
S á r e f.
t con máquinas.
con líneas de montaje y personas
s . w w w.unen
Ai
Ese cambio r e paradigmático el desarrollo de software,
al que suele llamarse Desarrollo ágil, tiene impacto doble.
Por un lado, nos lleva a tener un acercamiento más huma-
nista y holístico. Por otro, nos exige profundizar nuestro
conocimiento en las herramientas y prácticas. Los artesa-
nos se dedican continuamente a aprender y mejorar su ar-
te, los músicos a dominar sus instrumentos. Eso les permi-
te crear e improvisar. Así también, a los desarrolladores de
software a dominar nuestras herramientas y prácticas nos
permite imaginar soluciones innovadoras y realizar cam-
10 • Construcción de software: una mirada ágil
bios a bajo costo en productos existentes, en un proceso

creativo grupal con el que generamos resultados asombro-
sos, personas felices y equipos altamente productivos.
Un punto de inflexión en los paradigmas es cuando es-
tos empiezan a enseñarse como “la mejor manera actual”
de realizar la práctica profesional. Los autores de este libro
son todos profesionales de la industria y docentes universi-
tarios que están llevando la experiencia en la práctica pro-
fesional a sus clases y materias, enseñando desde el nuevo
paradigma.
Y se enfrentaron a una dificultad, como muchos de no-
sotros en esa situación. ¿Con qué material de soporte en-
señamos? El mismo problema tienen los profesionales que
quieren actualizar su conocimiento.
Hay pocos libros escritos originalmente
a e z . . . [et.al.]sufren en E
castellano
F
sobre Desarrollo
i c o l á sP Ágil, las traducciones
n U N TR incon-
de las
N
© en los términos
sistencias d
emismo,
claves, ó
ici al punto que para singlés.
realasegurar-
e e s t a a l d e T
nos quedhablamos
©Además, quizá por
de lo
elN
n
debemos recurrir
aciodel Desarrollo Ágil (desde
r s i d a d origen
untref
Unive los libros
la (industria),
o ) p a
existentesr a Ed
se enfocan en nichos
i d a d del
b r e r v e r s
Unise generanodiferen-
de Feaún entredautores
conocimiento y, por la rápida dinámica de creación del co-
nocimiento, e laen inglés r er ).
t o r i a l e F e b
Edloi tanto, librosede Tpocos
cias.(Por d ya están desactualiza-
reosincluso
años
chos
dos en cuanto i o n
a a l d
terminología s d e re
conceptos.
Este
c fue un gran
Nabalance o s t o os lopara los autores,
ddesafío E -
dununifi-
r v
ese mínimos, a d ar a
car losRconceptos
e d i c ió en pcuestiónsuficiente
conncontenido
i 2 7 3
para
6 ,un
s
que sea una explicación t a del tema o n
sc una enciclope-
y no solo
dey sinecaer en laRtentación
glosario, E F ), Mdeohacer eno s
f ( U N T . d e B uaún
re
dia del tconocimiento, que
ñ a , Pcia
estaría desactualizada antes
P e
enz era poco, losntautores
de finalizar su escritura.
e d u.ar realizar-
Sádesafío
Y si ese .u r e f. decidieron
lo en un grupo ires.dewseis ww personas, apostando a lograr con-
A
sensos en criterios y estilos.
El resultado es un libro que ayudará a profesionales,
docentes y alumnos a incorporar ideas, prácticas y herra-
mientas de Desarrollo Ágil de Software, ya que:
• Tiene los contenidos mínimos de todas las facetas del
Desarrollo Ágil de Software.
• Está organizado según las categorías del nuevo paradig-
ma, cada una de ellas tratada con profundidad, estilo y
Prólogo • 11
terminología consistente (no una adaptación forzada de

los conceptos nuevos en esquemas mentales previos).
• Contiene material pensado, escrito y usado en situacio-
nes reales de enseñanza, tanto universitaria como profe-
sional.
• Aporta numerosas referencias que permiten profundi-
zar cuando el lector lo desee.
• Logra riqueza conceptual y profundidad gracias al
aporte de puntos de vista y experiencias distintas.
Creo que este libro es la continuación y aceleración de la
adopción del Desarrollo Ágil de Software, que empezamos
de a poco entre 2001 y 2005 en distintas materias de la Fa-
cultad de Ingeniería de la Universidad de Buenos Aires, y
. [ e .] el evento Ágiles
t.alcon
P .
que tuvo luego un salto cualitativo
z .
aeque dio impulso REF la-
a laTcomunidad
o
2008 en Buenos
c l á s Aires, U N
© Ni
tinoamericana. e
Actualmente
t a dicseióestá n enseñando oeempezan-
Tr s
d e
do a enseñar e s
Desarrollo Ágilcde i o n a l
Softwaredeen universidades
© a d Ny aeste librodfacilitará
de toda América
e r s i d Latina, untref mucho este
(Univ a r a E ad
ero)al pdocente aUpreparar rssuidmateria;
proceso.
e
Este F e
libro b r
ayudará n i v e al
d e l a o )
er como.
(Editoartenerial und librolo deque
alumno, a complementar
s d e F brclase;
aprendaeen
profesional,
a l d e Tre autoaprendizaje
e re c hos
y referen-
cia. Peroacnoioesnsuficiente para aprender lo s d
a hacer Desarrollo
Ágil N d
de Software. Ningún o s t dolos será.
olibro E dun-
e r v a a r a
p “Secrets of Con-
ResWeinberg comenta
Gerald
e d i c ióennsu libro 2736, es
sulting” que e t a
el simpacto c o n i
de proporcional R E F Mosde la audiencia.
que tienen nuestras
al),tamaño
enseñanzas
e noGe-s
inversamente
( U N T e B u
d de mentor-
neramos treunf cambio mayor ñ a , P
en ia.relación
cuna
e
mentoreado, que e
nzenPcada lectortrdeefun e d u.aPero,
libro. r por otro
S á .
lado, al libro pueden acceder
s . w w w.un muchas personas más, solo
podemosAser i r e
mentores de algunas pocas personas.
Entonces, tomá lo aprendido en este libro, y llevalo a
la práctica, una práctica conciente, evaluando en cada mo-
mento qué te falta aprender. Busca mentores en tu universi-
dad, en tu empresa, en la comunidad. Sumate a equipos que
quieran ir más allá de su zona de confort.
Y recordá, cuando hayas avanzado en ese camino, que
este libro es sólo la base sobre la cual innovar.
Juan Gabardini
Agradecimientos
A mi madre y a mi hermano, por estar siempre presentes;

a Veily, por ayudarme a ver las cosas con otro matiz; a mis
colegas de Snoop Consulting, Southworks y Kleer, por las
ricas experiencias compartidas y a las comunidades de ági-
les de Argentina y América Latina, por ese espacio de in-
tercambio y experimentación del cual todos podemos ser
parte. [et.al.]
aez... EF Paez
c o l á s P U N T RNicolás
©ANmii esposa, por t a e dicióAnmis hijos,e por s
Treayudarme
d e e s el apoyo.
o n a l d
a© poner las cosas en perspectiva. i
d Nac A Carlos, por invitarme a
e r s i d a untref
(Univ
participar de esto.
) p a ra Ed dadSuárez
F e b r e r o
U n i v e rsiPablo
d e d a y al resto rdeermi
emis lpadres .
o)fami-
A Fátima, misl hijos,
i t o r i a e F e b
(Edacompañarmedeen Telre
lia, por s d que llevó aceste
camino
h oslibro;
ion a l e re
os dnuestra comuni-
Nacproyectos
a mis socios y compañeros de Grupo Esfera, protagonistas
s to d o sa lÁgiles, dun-
de tantos
e rv a d o
compartidos,
p a r a E
Res
dad latinoamericana en la queió
e d ic n seguimos
tanto ,
aprendiendo
2 73a6ella,
y creciendo; aeJuan s t a Gabardini, por c o n i
os esta aventura.
abrirme la puerta
y a losd e E F ),porMcompartir nos
coautores
( U N T R
de este libro,
e B u e
tref ñ a , P cia. d Diego Fontdevila
e .ar más am-
áenzporP soportarme
A miSfamilia,
.unlibror e f. e d u
t y de tantas otras inicia-
–en el sentido
s
plio– en la escritura . w dew
w este
r e
Ai alumno hoy desconocido que, allá por 1998,
tivas; a aquel
me preguntó por Extreme Programming, y me indujo a
mis primeras lecturas sobre lo que terminaría siendo el
agilismo.
Carlos Fontela
A Flor y a mi familia, porque siempre están ahí; a los
coautores de este libro y en especial a Carlos, porque gra-
cias a él entré en el mundo de la docencia y la escritura. A
mis ex compañeros de C&S, con los que intentamos todo
14 •Construcción de software: una mirada ágil
tipo de prácticas ágiles y otras locuras y a mis ex-jefes, por

la confianza que me tuvieron. A todo el equipo de Atix,
con quienes aprendo cada día algo nuevo.
Marcio Degiovannini
A Gabriela, a mi familia y especialmente a mi madre,
por acompañarme siempre. A mis compañeros de trabajo
de C&S, con quienes ponemos en práctica y entusiasmo
estos temas. A los alumnos y colegas de Taller de Desarrollo
de Proyectos 2 de la FIUBA, de quienes aprendo en cada
clase. A Carlos, por ser un referente y confiar en nosotros, y
a los coautores por todo el esfuerzo, colaboración y cono-
cimiento puesto en este proyecto.
Alejandro Molinari
. . . al.]
[et.colaboración
A Juan Gabardini e
s P a z
por su gran
T R E F
en la revi-
lá
©ANMaríao Compalati
sión delic
contenido.
i c UN
ión embarcarse
s ta e d
por aceptar e es ilus-
Trcomo
d e e n a l d
© de esta obra.
tradora
s i d a d Naciode Tres de Febrero por su
r
vela publicaciónpdearesta
A la iUniversidad
(Unpara
Nacional
a Eduntref
apoyo
F e b r ero) obra.
U n i v e rsidad
de de la r ).
roautores
eLos
t o r i a l e F e b
i o n a l s d e r
Nac
r v a a r a
Rese e d i c ión p 2 7 36,
s ta c o n i
de e ), Mos
f ( U N T R E F
. d e B uenos
tre ñ a , Pcia
Pe du.ar
Sáenz n t r e f. e
ww.u
Aires. w
Prefacio
El por qué de este libro

Este libro es una introducción al desarrollo ágil, pasando
por todos los temas importantes, y sin profundizar en nin-
guno. Los autores entendemos que, en el caso de que el
lector interesado desee profundizar l.alguno,
[ e t . a ] puede recu-
rrir a otros libros más
s P z...
aloseespecíficos N T EF blogs
o jornadas, cursos,
Rágil,
c o l á U
© Ni
y otros recursos, en
a e
cuales
d i c iónes muy pródiga.
la comunidad
T r e
tanto en
s
e estque
América Latina
©Otradcuestión
como en
seN
España,
daaen c i onal esdeque mucha gen-
paralelo
( U n ive
te todavía rsidadque el desarrollo
considera
r a Edágiluntref
no es serio, o se
erpara p a
o) no planificar,nnoivdocumentar rsidad o no
lo usa como atajo
F e b r U e
denada que no seadprogramar.
hacer
e lyamostrar ero). del
Por eso, nos proponemos
robjetivo
(Ed ágil es serdlaemejor
desmitificar estas cuestiones
Tremaneras d de realizarch
que el
os
desarrollo
i o n a l s d e re proyectos
Nac de software,
de desarrollo
o s to os loefectiva, en
dedmanera
E d un-
la inmen-
e r v a d a ra
Res el libro eviene n puna brecha27en36la ,li-
sa mayoría de los casos.
Asimismo, d ic iaócubrir i
a
est castellana.),EnM o onexcelentes
schay
deen lengua
teratura
R E F efecto,
e n o sde
li-
(UN
bros sobre desarrollo T ágil de software, desde B
haceu
de escritos en in-
ya más
ref pero
quince taños, a
en suñmayor , P c ia. están
parte
enzsePhan e traducido al castellano, e d u .ar pero inclu-
Sápocos
glés. Unos r e f.
w.unten experiencias en proyec-
so estos mismos
r e s . w
están w basados
Ai de software de países de habla inglesa, con
tos de desarrollo
una idiosincrasia distinta a la de los países latinoamericanos
o a España.
Lo escrito está basado en la experiencia, profesional y
académica, de seis autores con varios años de trabajo en
el uso práctico de métodos ágiles. Todos ellos, sin excep-
ción, han trabajado en organizaciones desarrollando soft-
ware, son docentes universitarios y han dictado capacita-
ciones en forma particular.
Audiencia
El libro está dirigido a todas las personas que trabajan en
desarrollo de software, pero que aún no han experimenta-
do profundamente con el desarrollo ágil, tal vez porque no
han sabido cómo hacerlo, tal vez por falta de conocimien-
tos y hasta tal vez porque lo miran con cierta prevención.
Los gerentes en general pueden encontrar en este libro
nuevas ideas sobre gestión, los comerciales pueden incor-
porar otra mirada sobre el tema, los clientes de equipos de
desarrollo pueden usarlo para mejorar su interacción con
los mismos, los analistas de negocio y funcionales van a ha-
llar formas novedosas y muy efectivas para interactuar con
usuarios y desarrolladores. Los testers se encontrarán con
filosofías y técnicas de trabajo que le otorgan mucho valor
. .] puntos de vis-
[et.alnuevos
a sus tareas, a la vez que les
a e z . .
proponen F
TREsoluciones
i c o lás P en fin,
ta. Los desarrolladores,
N i ó n
podrán U N
encontrar
a© t a edhoyicsoportan Tres
coneresignación.
muchas cuestiones
d e e s que
n a l d
© No es este un libro
a d
para
N a cio
expertos en métodos ágiles. Los
(Upueden rsid
niveexperimentado
que ya han abundantemente
r a untref
Edprecisos con el agilis-
mo
ero
encontrar ) p a
consejos más
rsen idaladcomu-
F e b r U n i v e
de
nidad ágil, que en América
d e l a
Latina y en España
r e r
está muy
o).desde
desarrollada.
i t o r i
En a lparticular, las JornadasFÁgiles,
e e b que
2008 (Esedvienen d
haciendoe s d ciudades c
Tenredistintas os
dehAmérica
i o n a l s d e re
Nac de losoéxitos
Latina, son un espacio
s
muy
to
rico s lo
dy oerrores
para compartir experien-
dun- a
cias, aprenderrv a d r a
ajenos, yEescuchar
se de todo elicmundo.
Revenidos ión p a
oradores
ta e d o n i 2 7 36,
de e deseen s sc
F), Moleyendo sobre
No obstante, quienes hayan incursionado en algunas
prácticas ágiles y N T R Econtinuar B uesus s
nofun-
f ( U
tre complementación . d e
ciaotras prácticas y méto-
damentos,
P e ñ a , Pcon .ar para com-
dos, tienenáe
S z libro un importante
enneste
r e f. e dualiado
n t
w.uefectivamente.
prender cómo trabajar
Aires. wwmás
Estructura del libro
Los primeros dos capítulos son una introducción al tema
del desarrollo de software ágil y construyen un puente en-
tre las premisas básicas tradicionales de la comunidad de
desarrollo de software y los pilares de la filosofía ágil. El
resto de los capítulos están organizados de acuerdo a nues-
tra experiencia en proyectos reales de desarrollo de soft-
Prefacio • 17
ware, describiendo las actividades típicas más o menos en

el orden en que cobran importancia en el proyecto. Es-
tos capítulos, salvo el apéndice, son de dos tipos: o bien se
enfocan en una técnica o área de práctica particular (por
ejemplo, el capítulo Arquitectura y diseño en emergencia)
o bien se enfocan en algún aspecto de la agilidad que nos
parece central (por ejemplo, el capítulo “La fantasía de evi-
tar los cambios”). El apéndice, como cierre, hace una re-
corrida por los métodos ágiles más establecidos. A lo largo
del texto, los recuadros resaltan algún contenido o defini-
ción, y los que tienen las iniciales de un autor presentan
una anécdota o comentario personal.
Traducciones
z . . . [ e t.al.]
c o l á s P ae en este libro U N T REF su ori-
Muchos
© en Niinglés. En nuestro
términos utilizados
e icióden hacer unaTobra
dafán
tuvieron
sen cas-
gen
d e s t a
eintentado proveer i o n a l de re
©
tellano hemos
d a d N ac traducciones para todos
ellos. ivers i duntref
Etraducción
Unlos casos de términos
(En p a r a dad
F e b r ro)
ehemos con una
U n i v e rsiampliamen-
de
te establecida, la la
utilizado. En los casos de
).
términos
con diversas t o r i a l d e
e F e sibno laotienen,
r e r
Ed i
nos (aventuramos
traducciones o directamente
es d a proponer
Trmayoría os
i o n a en d
l suegran
s d e re clahnuestra,
Nac
indicando siempre el término
s to d o s lo
original en una nota
d u -
al pie.
n
Finalmente, r v aendo algunos pocos casos, a ra E
hemos decido
e
Reslos términosedoriginales ión por p no encontrar6tra-
mantener
s ta i c
c o n i 2 73 ,
d
duccionese e
apropiadas que no M
alteren
, osla esencia del término
U
(user story, backlog). N T R E F )
e B u e nos
tref ( P cia. d
e ñ a ,
S áenz P .untref.edu.ar
Qué viene despuéswww
Aires.
Más allá de leer este y otros libros, y de experimentar en
proyectos propios, creemos que para hacer desarrollo ágil
es necesario aprender de otros, de los que tienen caminos
parecidos y de los que ya han recorrido un largo trecho, de
sus errores y también de sus aciertos. Para eso no hay un lu-
gar mejor que la comunidad ágil, un espacio de pertenen-
cia en el que practicantes de distintas extracciones com-
parten conocimientos y organizan eventos para aprender
en conjunto. El sitio central de la comunidad ágil de Amé-
rica Latina es www.agiles.org, y el foro es foro-agiles@

yahoogroups.com. Allí se pueden encontrar referencias a
comunidades y eventos locales y regionales. Esperamos
verlos.
z . . . [et.al.]
i c o lás P a e
n U N TREF
© N edici ó
© d Nacio n
s i d a d
(Unive r
a r a Eduntref
F e b r ero) p
U n i v e rsidad
de de la r ero).
t o r i a l e F e b
i o n a l s d e r
Nac
r v a a r a
Rese e d i c ión p 2 736,
s ta c o n i
de e ), Mos
f ( U N T R E F
. d e B uenos
tre ñ a , Pcia
Pe du.ar
Sáenz n t r e f. e
ww.u
Aires. w
¿Por qué cambiar? • 19
¿Por qué cambiar?
Leyendas fundacionales
Casi todas las actividades económicas y las disciplinas cien-
tíficas tienen leyendas fundacionales. Por ejemplo, dicen
que la física moderna nació cuando a Newton, que dormía
bajo un manzano, le cayó una fruta en la cabeza. Los pri-
meros filósofos, según nos cuenta
. [ e .]
t.laaltradición, compartían
P a e z . . T R E F idílico
sus conocimientos
i c o l á s en el ágora de Atenas,
U N un lugar
© Ndiscípulos ión debatir Tabiertamente
dicpodían
e de res
donde y maestros
e e s t a a l
d
sus preocupaciones.
i o n
©Y así pasa con atodas
e r s i d d Nlasaccienciasdyuntref actividades huma-
(U
nas. n
Pocoi v importa si son
p a ra
ciertas E
o no esas leyendas.d Pro-
r o )
bretengan de verdad, r s i d a
iveparte haya sido
de FPero
bablemente ealgo l a Uynotra
inventada.
t o r i a l d
lo cierto e es que influyen
F e b ero). per-
en rnuestra
(Ed
cepción i
actual. Y el r
desarrollo e sd de e
software no podía ser
menos. ional d e T e re c hos
c
Nanostálgicos oshubo s d
lo un tiempouenn-que
Los
a d o s
asegurantodque a Ednos deja-
R e s e r v n p a r
dició
los clientes nos decían que aplicación deseaban,
ban trabajandospor t a unelargo tiempo, yccuando o n i 2736,
volvíamos
con eld e e Mos porqueecumplía
),se alegraban
producto
U N T E
desarrollado,
R F
e B u nos
plenamente (
tref con susverexpectativas. P . dno sólo los clien-
cEsiamás,
e ñ a , ar la eje-
enz Psino quentampoco .desarrolladores
tes no necesitaban a los desarrolladores durante
Sáproyecto, t r e f. e d u
cución del
s . w w w.u con los
Ai
necesitábamos r e comunicarnos los clientes, ya que con-
tábamos con una documentación tan exhaustiva y lograda
sobre el producto a construir, que cualquier comunicación
podía arruinar nuestro trabajo.
Se nos ha contado que en aquellos tiempos, los clientes
desconocían que el software era un producto modificable,
aunque ya algunos se estaban preguntando qué significa-
ba el prefijo “soft” en la palabra en cuestión. Por otro lado,
ese no era un problema, pues ¿quién querría modificar al-
go tan perfecto?
Los profesionales de desarrollo de software, debido a es-

tas condiciones, podían planificar sus proyectos con segu-
ridad, sabiendo que, una vez iniciado el proyecto, no había
ningún peligro de que el plan cambiase. La tranquilidad
que brindaba la previsión de todo futuro posible era muy
reconfortante.
Además, existía –y existe– el dogma del mayor costo del
cambio conforme el proyecto avanza, lo cual favorecía que
cualquier modificación fuera vista como una amenaza. No
es que el dogma sea absolutamente falso [Boehm1981], pe-
ro más que inducirnos a rechazar pedidos del cliente, de-
bería animarnos a buscar formas más sencillas de imple-
mentarlos.
En realidad, ninguno de los autores de este libro cono-
ció tiempos tan felices. Lo cierto
. .] tanto si hubieran
.esalque,
[esettratase
a e z . . REFde la his-
N i c o l á sP
existido esos tiempos, como si
ó n U NdeTmitos
toria
e s edici sehoytrabajaba
© del desarrollotade software, vemos que sinsduda las
d e re
–yTmuchos to-
cosas nod e
son así. Sin embargo, n a l
o cosas funcionaban de esa
© lo hacen– pensando
d a d Nqueacilas
davía
r s i untref
(Unive
manera. ara Ed d
F e b r ero) p U n i v e rsida
de de la r ero).
t o r i a l e F e b
(Edi
Errores de inmadurez
d e Tres d e os po-
chHace
i o n a l s d e r
Nadec 60 años oque
El desarrollo de software
s
es
seod
t os lo computadoras,
una disciplina joven.
E dun-ha-
co más
r v a d programan
se a intentaricsistematizar a r a
ce 40R seeempezó
e d ión p un proceso, i 2 7 3y6 ,
hace
s t a
e e la complejidad. c o n
), MoSiscomparamos
unos 30 se empezaron a introducir paradigmas que permi-
tieran d
el manejo de T R E F uenconoslas
f ( U N . d e B
tre
ingenierías tradicionales,
ñ a
que
, Pencia
general tienen varios si-
glos de antigüedad, e
enz Pno deberíamos du.arinmadura.
asombrarnos
e de que la
nuestra Sseaáconsiderada w una .u n t r e
actividadf. humana
Aires. no
Prácticamente wwexiste ciencia que se haya aplicado en
sus inicios sin cometer grandes errores. Los médicos de la
antigüedad pretendían curar a sus enfermos con purgas y
sangrías, que en ocasiones aceleraban la llegada de la muerte.
Algunos errores no han sido tan graves, sino que solo
fueron simplificaciones fácilmente refutables. Pero aun es-
tas simplificaciones, muchas veces han puesto en entredi-
cho la disciplina en sus momentos fundacionales. La eco-
nomía, dicen los especialistas, nació con el libro de Adam
Smith, que explica su funcionamiento en un mundo ideal
de competencia perfecta. Cuando se vio que esa simplifi-

cación era excesiva, muchos pretendieron predicar la inva-
lidez de toda la ciencia económica, por lo que fue nece-
sario investigar en el marco de hipótesis más realistas para
devolverle el prestigio que se estaba esfumando.
Algo parecido pasó con la astronomía, al punto que el
sistema de universo definido por Ptolomeo dos siglos antes
de Cristo, seguía siendo utilizado en el siglo XV, hasta que
Copérnico lo puso en entredicho, provocando gran con-
trariedad en el mundo académico de la época, que no es-
taba dispuesto a que se modificasen las nociones esenciales
de su ciencia.
Con el desarrollo de software también han pasado estas
cosas. Se han cometido gruesos errores iniciales que han
provocado el fracaso de muchos
z . . . [ e .al.] y el abandono
tproyectos
de iniciativaslá
o P ae
desinformatización.
U N
Más tarde,T se EFestable-
Rhan
©N c
i fundamentos ción en supuestos
dibasados s
cido algunos
e s t a e d e Tresimplistas,
d e
o simplemente
© a la disciplina. erróneos, que
c i o n a
tambiénl han hecho perder
dad N a
prestigio
n i v e r s i Además, el
E
ambiente
d untref académico es
(U a pensar en rtérminos
reacio
o ) ra a pesar desiladcorta
panuevos, ad his-
b r e i v e r
e Fe
toria del software.
Pordejemplo: la Un
d itoria l d e
de Fe brero).
( E T r e s choensuna
• La idea de la a
i o n l de del trabajo ensroles,
división
d e r e
basada
Nactayloriana o[Aitken
visión
s t oque os lollevó a queEd
d1960], -
unlabor
se crearan
e r va d p a r a
Res diferenciada.
varias especialidades,
e
y
d ic
cada
iónanalista
una tuviera
2
una
36, se
7jamás
totalmente
e s t a Un
c o i
funcional
n
s nos libre!),oda-
de con unRprogramador
comparaba
T E F ), Mo(¡Dios u e n s
do que estos (U N
últimos eran el equivalente e B
. d gente a la que
de los obreros
tref en la producción
ñ a , P cdeiasoftware,
industriales
enz pensar,
no seSleápedía
e
P sino solo ftrabajar. e d u ar pensar es-
.Para
r e .
unt lo que querían los clien-
s . w
taban los analistas, w w.sabían
que
r e
Ai eran sus necesidades y como lograr satisfacer-
tes, cuales
las desde lo técnico. En definitiva, cada persona, según su
rol, buscaba un objetivo diferente. A nadie se le ocurría
pensar que en realidad se necesitaba un equipo multidis-
ciplinario trabajando en pos de entregar valor al cliente.
• También se dio importancia excesiva a los documen-
tos. Partiendo de la idea, tal vez razonable, de dejar re-
gistro de las decisiones que se toman en un proyecto
mediante documentos, y siguiendo con la noción de que
cada perfil se debía ceñir a sus tareas específicas, se llegó

al extremo de que la única forma de comunicación en
los proyectos eran los documentos. Los analistas especifi-
caban requerimientos, que era lo que podían ver los di-
señadores, programadores y testers. Al fin y al cabo, ¿qué
otra cosa debían conocer los programadores y testers de
su proyecto? Los diseñadores también especificaban el
diseño con documentos, probablemente acompañados
de complejos y detallados diagramas. Si esos diagramas
luego debían ser mantenidos conforme cambiaba el soft-
ware, no era un problema que se tuviese en cuenta.
• Los diseñadores se podían lucir con complicados dise-
ños que mostraran su genialidad. Los programadores,
toda vez que podían, introducían código que nadie sino
ellos podrían entender.Y . .eso l.] felices a todos, sin
t.ahacía
[elos
a e z .
P bueno para el trabajo REF
© Nic olássi era
preguntarse UNTfinal.
dición Traesers secun-
d e estafinale también
Porque el producto
n a l
había d e
pasado
io los documentos, que de-
© Lo único importante
dario.
s i d a d Nac eran
( U
finían nqué r
ivese iba a desarrollar
p a r a Eduntref
y cómo se iba a construir la
adimpor-
r e r
aplicación. Elbsoftware
e o ) en sí mismo noi v e
era rlosidque
F
dey hasta se fantaseaba U n
lala generación automática
taba,
l d e con
e b r e r o ). de
código d r i a
itoenfatizar de Fen un futuro
(E para esta idea, pensando
e T r e s c h o s
feliz
cioelndíaalendque todo esosyalonossedpudo

en el que la codificación humana fuera eresostener más.
innecesaria.
Nallegó
Pero to d o Edu n-
e s er vados p a ra
R
s ta e dición o n i 2 7 36,
de enos condena c
La evidencia
T R E F ), Mos B nos
ueque
tre f (U N a . d e
Todos conocemos casos
ñ
de
a , P cien
proyectos de software han
z P
fracasado. Ha habido e problemas .ar los han
pequeños
duquienes
proyectos,
Sáenintrascendentes
más o menos
.u n t r e
(salvof. e
para
ww
. wde
A rescasos
sufrido), y ihay grandes fracasos, de esos que men-
cionan los libros. A veces los particulares parecen ser solo
eso, y los desechamos pensando que son una pequeña pro-
porción de los proyectos.
De Marco y Lister mostraban1, hace ya 25 años, la gran
proporción de proyectos de software que fracasaban. Tal
vez pensemos que es un dato anacrónico.
1
Es famoso el primer capítulo de la primera edición de Peopleware, cuyo título
es “Somewhere Today, A Project Is Failing” (en castellano: “Hoy, en algún lu-
gar, un proyecto está fracasando”).
Ya no es tiempo de seguir equivocándonos

En los tiempos que corren, los clientes quieren todo lo an-
tes posible.Ya no se puede, como en otros períodos, decirle
a un cliente que vamos a trabajar durante un año y le mos-
traremos todo cuando esté terminado. Ellos quieren ver el
software funcionando, lo antes posible, hacer observaciones
sobre el mismo, saber cómo vamos en el proyecto y cuán-
to falta para el feliz día en que determinada funcionalidad
esté lista.
Como además los clientes se han dado cuenta de que el
software es maleable, que admite cambios aún durante su
desarrollo, están constantemente buscando mejorar el pro-
ducto. Si bien en un punto eso puede irritarnos, es parte
ineludible de la naturaleza del software
z . . . [ e t.al.] y, por lo F tanto, de-
o lás P
bería serlo también de ae nuestro trabajo.
U RE en los
NTcambios
© N i c
Precisamente, i ó n
dic no puedaneserTrígidos.
la necesidad de realizar
proyectos llevaeasque
d e t a loseplanes
i o n a l d res Hay
©entender que aladplanificación
que
s i d Nac debe ser algo vivo, algo
( U iv
que senpuede e r adaptar en tiempos,
r a end
E untref
alcance, e incluso por
p a
ero)de la incertidumbre rsidaelddiseño
F e b
cuestiones derivadas r U n i v e sobre
de
de la solución.
d a
ees el lcosto ).
rono
reque
i t o r i
Otrodinconvenientea l d e
del F e
cambio,b por
( E e T r e s h o s
ser posible es barato.
a c i o n al dAdicionalmente, s lo s erecempeora
ese costo
d si
N
el diseño es complicado
o
y
sque el o
toddesarrollamos
código poco legible.
E un-
dtremen-
Además, e r v a d
s complejo queicielóde
el software p a r a hoy es
Remás e d n décadas 2 6,
73com-
damente
e s t a s c o n i
atrás. Esa
plejidaddeno se puede Rencarar E F ), conMoprocesos nos
de desarrollo
e
( U N T e B u
trefLo mismo aplica cia. dun producto com-
que solo funcionan razonablemente bien con pequeños
programas. e ñ a , aP la calidad:
P
Sáenserz construido f. e d u armente. Esta
.en
plejo necesita con r e
w.unt al producto a posteriori.
la calidad
no puede ser algo
r e s . w
quewagregamos
Ai lado, los roles con objetivos contrapuestos pue-
Por otro
den hacer perder el objetivo principal, que es entregar va-
lor al cliente. Este valor no puede estar en los documen-
tos, que son artefactos que nos sirven a los desarrolladores
durante la construcción. ¿O alguno de nosotros, cuando
quiere que le construyan una casa, está dispuesto a recibir
planos a cambio?
Los clientes exigentes nos obligan a que tengamos cri-
terios de aceptación, sin ambigüedad, que nos indiquen
cuando hemos cumplido lo que ellos requieren y cuando

podemos dar por concluido el desarrollo de una funciona-
lidad. Y esos criterios nos van a servir también a nosotros
para medir el avance, aun cuando los clientes no sean tan
exigentes en ese punto.
Como consecuencia de todo lo dicho, el tiempo en que
nuestro optimismo nos hacía pensar que los errores y des-
cuidos podían ser tolerados, o incluso no ser percibidos, ha
quedado atrás.Y eso exige pensar en otras maneras de de-
sarrollar.
Buscando encauzar al desarrollo de software

Siguiendo con la analogía de las demás ciencias y técnicas,
no siempre es fácil romper con
. . . al.]
[elot.establecido para cambiar
sP a e z N TRE F lue-
N i c o l á
métodos y procedimientos. Hace
ó n
falta
U ver los errores,
©evidenciarlos ytafinalmente
go ed ici proponer cambios T s
resusmostran-
do sus d e
ventajas. e sMuchos pretenderían n a l d e
mantener
o retoques a las visiones anteo-
© o a lo sumo arealizar N a c i
jeras,
niveNo rsles id fuedfácil a Heisenberg
pequeños
Eduntref
del(U
pasado.
p a r a y a Einsteindponer
F
en entredicho e b ar e
la r o )
física clásica con
U n i v e rsidatan poco
proposiciones
de que parecían
intuitivas la
dedescabelladas. r ero).debe
Algo parecido
i t o r i a l d e F e b
(Edocurrido
haberle
d e Trde
a Lord Keynes esla cuando se atrevió a pro-
e choOsa los
poner cambios i o n a
en l la lógica s d e
macroeconomía.r
Nacmedievalesoque, s todedaopoco,s lo introducíandu n-
médicos
r v a d a r a E cambios
Reseen la Españaedislámica.
aprendidos
i c ihay p
ónproblemas 2 7 36co-,
Pero parecesobvio t a que
e habría que)tratar si c o n i
y
osenfrentarlos
se están
de errores,
metiendo
R E F , Mde e os
yncorre-
f ( U N T . d e B u
tre
girlos. En el desarrollo de
ñ a
software
, P cia seguimos purgando pa-
P e .ar 60 años.
Sáenzque, siwbien
cientes hasta matarlos por deshidratación. Esto no es serio
n t r e f. e ducumplió
en una disciplina u
wwdel .siglo
es joven, ya
Por eso es ique
A resa.fines pasado se empezaron a su-
gerir las mejoras que llevaron a los métodos ágiles.
En efecto, resulta totalmente insólito plantear que los
proyectos de software se alarguen por la necesidad de ge-
nerar documentación innecesaria, que cuando un cliente
pida un cambio estemos con la guardia en alto para que
no arruine nuestro diseño, que los equipos sean en realidad
compartimientos estancos de perfiles que solo se comuni-
can mediante documentos, que los clientes deban confor-
marse con ver documentos de requerimientos y de diseño
en vez de software funcionando, que los planes estén talla-

dos en piedra.
Y si a fines del siglo pasado no podíamos seguir preten-
diendo todo eso, mucho menos una vez que surgieron per-
sonas que, como hicieran en otros tiempos y desde otras
disciplinas Copérnico, Heisenberg, Einstein, Colón o Ke-
ynes, han puesto en entredicho unas cuantas verdades ins-
taladas y nos han demostrado que el desarrollo de software
puede ser más eficiente, más cooperativo, más transparen-
te y menos rígido de lo que había sido hasta ese momento.
Hoy, un poco más de una década más tarde, es todavía más
inverosímil que haya gente que no perciba que los princi-
pios en los que nos habíamos basado tenían serios errores
de concepción, que hacían que los métodos derivados de
los mismos fueran inadecuados[e al.]
ent.determinados contextos.
o l á s P aez... U N T REF
© Ni c dicalió n
d e
La naturaleza e s
del t a e
software a
rescate
i o n l de Tres
©
d dedlas N
a ac
e r
Ahora bien, variass i
niven el propio) software
respuestas a losuntref
E dlasproblemas plantea-
dos(Uestán
o p a r a y en i d ad de
peculiaridades
b r e r i v e r s
de Fe de desarrollo
los proyectos
d e la Un
del mismo.
rero).
Expliquémonos:
(Ed
• A menudonseadice l d e es d
queTrel software esde r e choess de-
maleable,
i o
acse puede adaptar
Nque s
os losu construcción,
cir,
a d o s tod durante
E ny -aun
duusar
e r v a r a
Res ión p
una vez terminado. ¿Qué mejor, entonces, que esa
e d ic 73 6 ,
estqué
maleabilidad para a resistirnos tantoosa c
poder ofrecer ni 2 que sa-
alternativas
ocambios a nuestros
de ¿Por
clientes?
REF ) , M los
e nos
( U N T e B u
tref
bemos posibles?
ñ cia. d y, por lo tanto,
a,esPparticionable
• Por otro lado,zel P
n e
software
d u .ar
Sáeconstruir
se puede unt
por .etapas,
w r e
de f. e
modo tal que cada una
. w w
s a la salida de la misma tengamos un pro-
Aireque
implique
ducto, parcial, pero con valor para el cliente. ¿Por qué
no usar esta característica para darle visibilidad durante
su construcción?
• Otra cuestión a la cual se le presta poca importancia es
que el desarrollo de software implica la materialización
de conocimiento en programas de computadora. ¿Por
qué no usar las reuniones de captura de conocimiento
para interactuar más con nuestros clientes y dentro del
mismo equipo? ¿Por qué no aprovechar para socializar?
• Contrariamente a lo que sucede en otras disciplinas, el

diseño y la construcción del producto no son procesos
separados, uno único y el otro repetitivo, sino que se ha-
cen en conjunto, con un único producto para cada dise-
ño. Entonces, ¿por qué nos resistimos de manera tan apa-
sionada a los cambios de diseño durante el desarrollo?
• El software es también susceptible de ser copiado en
forma íntegra. ¿Por qué no aprovechamos esta caracte-
rística para entregar productos de calidad?
• Si decimos que el software es extensible, ¿por qué nos
resistimos a hablar de la evolución permanente de cada
producto?
Es cierto que, otras veces, el propio software conspira pa-
ra solucionar los problemas, como
. . [et.a l.] con la visibilidad
ocurre
sP
del producto. En a e
efecto:z . TREF
olá
©• AlNsericun i c iópor UN
n definición,
e d
sta el desarrollo,
producto invisible e Treesscompli-
d e edurante n a l d
© cado saber,
a d N a cio cuanto se ha construi-
Un verdefinir
do y icuanto sid queda por construir.
a EdPor untref
esto se ha vuelto
(necesario r o) p a r s idadpara el
F e b r e técnicas y métricas
U n i v r
específicas
e
d e Esta faltaddee visibilidad
software. la del producto e r )lo. que
también
o
t o
hace difícil r i a
quel el cliente sepa
e F e b
rápidamente r si
(Edi
construimos es lodquee s d Por eso eschque
Télreesperaba. e oscon-
i o n a l s d e r
o que tambiénn-per-
Nacdefinir criterios
viene
o s to dosde ldesarrollo
de aceptación,
Edu cono-
miten querel
e s e v a d
propio equipo
p a r a pueda
cerRcuando puede dar e ón
iciterminada
dpor 7
la construcción
i 2 36,de
s t a o n
de e funcionalidad.
determinada
T R E F ) , Mosc nos
uemuchas
• Otro problema
f ( U N d
del software es su complejidad,
. e B
tremencionada, pero ñ a ,poco a
Pcicomprendida
veces
e n z P e d u . a r cabalmen-
Sá
te. En efecto, se habla
w
con
. u n t ref.e
ligereza de sistemas media-
nos de, digamos
ireno w
wcincuenta
s.estamos mil clases. ¿Somos conscien-
tes deAque hablando del equivalente de una
máquina de cincuenta mil piezas, sino de una con cin-
cuenta mil tipos de piezas distintas?
El resto lo cubren las personas

Otro aspecto característico del software es que es un pro-
ducto construido en su totalidad por personas. Por eso es
que la mayor parte de los problemas y de las soluciones de-
bemos verlas más desde la sociología que desde la tecnolo-

gía. Esto puede ser duro para la mayoría de nosotros, e in-
cluso para quienes se desempeñan en roles gerenciales, que
hemos sido formados más en tecnología que en discipli-
nas humanísticas. Sin embargo, deberíamos pensar que las
habilidades sociológicas, aunque carezcamos de nociones
formales, están en nuestro ADN y que las venimos practi-
cando desde que nacimos. Por ejemplo:
• Durante milenios, hemos evolucionado comunicán-
donos cara a cara para poder entendernos y superar los
malos entendidos, los equívocos, y todo lo que solo po-
demos expresar mirando a nuestro interlocutor. Por eso
es importante no olvidar que esa es la manera más natu-
ral de comunicación entre humanos.
. [ e .]
t.alhace
• Nuestra naturaleza P ae z .
social. también T
que EF pro-
Rseamos
c o l á s
Ni a formar equipos U N
ión que se sienten
©pensos a ediycsus éxitos
exitosos, orgu-
s t
de suecreatividad e T r e s
llosos e
d resueltos fueron
©problemas c i o n ld
acomplejos.
y, sobre todo, si los
ad N a muy Estos equi-
n i v e r s idautoorganizarse, Ed untref
U
(externos,
pos tienden a
o ) p a r a sin necesidad
i
de impulsos
d
dalogren.
F e e r
ybartrabajar mejor cuanta
U n i
másv e r s
sinergia
•d e último, contrariamente
d e la a lo queFdicen ro). re-
Por
i t o r i a l e e b realgunos
(Ed
franes, aprendemos
d e
de
T r e
nuestrossd errores, y somos
c h os
los úni-
i
cos animales o n a l
capaces de reflexionar s d e r
sobree los mismos,
lo contrapartida,
Nanocvolverlos oa scometer.
para t odoYscomo E dunten--
e r v a d a r a
Resa analizar y e
demos
d i c i n p quei hayan
a repetiróconductas
2 7 3 6,
lleva-
st a con
de e
do a resultados exitosos.
F ), M os s
nocaso
( UN T R
Ahora bien, dificultades Etambién hay. e
Aunque B u
en e
este
tref no suelen P deia
c d
las. personas que traba-
las dificultades
e ñ a ,
venir
.ar
jan, sinoSde nz P típicos del
áeprejuicios t r e f.
mundoe d ucorporativo, que
w w . u n
Aires w
atentan contra la.naturaleza humana:
• Una de las nociones que más conspira contra la autoesti-
ma de las personas, y que afecta la calidad de lo producido
por esta misma razón, es el considerar a las personas co-
mo “recursos”, pretendiendo que, como ocurre con otros
recursos que afectan nuestro proyecto, se trata de piezas
intercambiables. Eso lo pueden provocar tanto los geren-
tes de mentalidad industrial, como las metodologías que
ponen el foco en que no importan tanto las personas co-
mo el seguimiento de un método supuestamente infalible.
• Asimismo, cuando por cuestiones de costos o cronogra-

ma, se impulsa a las personas a construir un producto de
baja calidad, también se afecta la autoestima de todo el
equipo de trabajo. En realidad, todo cronograma ajus-
tado de manera irreal es percibido como una falta de
respeto por los equipos experimentados. Si bien en al-
gunas ocasiones se le puede pedir un compromiso a un
equipo ante una necesidad puntual, esto funciona en la
medida en que el equipo haga suyo este compromiso, y
que realmente sea una excepción definida y acordada,
no la regla. Las presiones ejercidas sobre las personas pa-
ra que produzcan más no funcionan, simplemente por-
que el hecho de que se pueda obligar a alguien a estar
más tiempo sentado en una silla, no implica que de esa
manera se logre creatividad e
z . . . .al.]
[ o tproductividad.
P a e TREque F cons-
N i c o
• Otro aspectolás negativo es un entorno
ó n U Nlaboral
i y mesas incómodas,
©pire contra la producción.
e s t a edicSillas d e T res fal-
de
©tasoftware
de luz, infraestructura c inadecuada, l
iona no contar con el
a d N a
ersid que impiden
necesario
UniavInternet
(ceso
para desarrollar,
r a E d untref
restricciones de ac-
r e r o ) pa investigar,
e r s i a
son todos
d d pro-
e Fque
blemas b
e acarrean frustración i v
Uyncuestan bastante más
d d e laun buen r ro).enfo-
edebe
t o r i
de lo que parece.a l Por eso,
i permitir que Tlasrepersonas e e b
gerente
F
(Eden
carse
d e s d trabajen ccómodas h o s y
a l e re
acion más que
eficientemente
N s to d o s losquedtrabajen”.
en “hacer
duy nen- los
• Y por último,
r v a d
hayo que confiar en lasrpersonas
a a E
Reseque las personas
equipos
e d i c ón p Si uni gerente
iconforman. 2 7 36,vi-
e e s ta osc o n
ve obsesionado
d por desarmar
F ) , Mequipos
Epor temor a queeformen
que disfrutan
n o
del
s
(UNTRcon
trabajo en conjunto,
d Bue grupos
trefterminará
elitistas,
ñ a , P c i
trabajadores a . poco motivados y
P e . a r
S enz venw
menos áproductivos. Si solo considera
. u n t duque están traba-
ref.ecódigo,
es. wwcon sus colegas, investigan solucio-
jando cuando los escribiendo y no cuando
Airconversan
piensan,
nes en la web o se reúnen espontáneamente, solo va a
lograr una actitud defensiva y poco productiva.
El manifiesto ágil
Así como Copérnico cuestionó los principios de la astro-
nomía de su tiempo, o como Colón impugnó la teoría de
la Tierra plana, hubo un conjunto de personas que se die-
ron cuenta de que las premisas en las que se basaba el desa-

rrollo de software tenían fallas, y propusieron una serie de
ideas para remediarlas.
Los cuestionadores de las premisas antiguas del desarro-
llo de software fueron un conjunto de 17 críticos2 de los
procesos tradicionales, que se reunieron para redactar lo
que denominaron el “manifiesto ágil” en febrero de 2001.3
El manifiesto dice4:
“Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como ayudando
a terceros. A través de este trabajo hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
e
• Colaboración con el cliente [sobre
. . l.]
t.anegociación contractual.
P a e z .
s el cambio sobre seguir T plan.F
R E
© Nic oláante
• Respuesta UNun
ón
icielementos
e dlos res va-
Esto es, aunque
d e e s t a
valoramos
i o n a l ddee laTderecha,
© más los dealadizquierda.”
loramos
s i d Nac
(Univ e r
a r a Eduntref
F e b r e ro) p
U n i v e rsidad
e 10 años de la
Losdúltimos
i t o r i a l e F e b redero10).años,
(Ed
Ahora bien, si el manifiesto
l d e es d una adopción
ágil
Tr¿Hubo tiene ya más
re s
choimpor-
i
¿qué pasó desde o n a entonces? s d e
s lo una mejora
tanteNdeac los principioss ágiles? todo¿Hubo duen n- los
e r v a d o a r a E
R
proyectoses de desarrollo
e
de
d
software?
ic ió n p ¿Se puede ver
2 7
una
3 6 co-
,
rrelación entreslata
e mayor adopción de los o
c n i
métodos ágiles y
deen los proyectos?
la mejora
R E F Mos[VersionOne2012],
La),encuesta e nos
( U N T e B u
t
realizadaref
a fines de 2012,
a
parece
, P c i a. d
indicar que las tres pre-
nzla P
guntas se pueden responder eñ en formaepositiva. d u .armuestra una
Sáede
Respecto r e f.
w.unt usando métodos ági-
adopción, la encuesta nos
r e s . w w
Ai
mayor proporción de organizaciones
les, a la vez que una mayor proporción de los proyectos en
2
Se trata de Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor,
Ken Schwaber, Jeff Sutherland y Dave Thomas. Todos venían del mundo in-
dustrial y no académico y, en forma separada, estaban trabajando en propues-
tas para remediar esta problemática desarrollando métodos propios.
3
Mientras estaba explotando la burbuja de Internet.
4
Tomamos la traducción oficial al castellano, que se encuentra en http://agi-
lemanifesto.org/iso/es/. El manifiesto original en inglés se encuentra en
http://agilemanifesto.org/
cada organización.5 Incluso ha aumentado la adopción de

métodos ágiles en equipos distribuidos.
Las otras dos preguntas no se encuentran respondidas
en forma directa por la encuesta, pero los encuestados de-
claran haber obtenido mejoras gracias a su adopción del
desarrollo ágil. Un 90% dice haber mejorado su habilidad
para manejar cambios de prioridades. Otras ventajas obser-
vadas han sido bajar el tiempo en salir al mercado y la me-
jor alineación con el negocio.
La encuesta se sale del molde de aquellas que buscan
mostrar mejoras en tiempos, costos, o apego a los requeri-
mientos del cliente. En efecto, el movimiento ágil no con-
sidera al alcance de un proyecto como algo fijo, y si los
tiempos o los costos mejoran, esto es más bien un efecto
secundario. Para cualquier agilista,
z . . . et.alal.]calidad
[facilidad del produc-
to, la visibilidadsdel
i c o l á P a e
proceso, la
n U N
de TR F a los
E
adecuación
N
© en las necesidades
cambios edison ó
cdeli cliente y el menor stiempo
reque
e s t a l d e T
©condunos
de retorno e de la inversión
N a c i ona
más importantes cum-
ad
niversiddel proyecto.
plir requisitos fijos y establecidos en el momento
untref
del(Ulanzamiento
ero) p ara Ed d
rsida
F e b r U n i v e
de de la r ero).
t o r i a l e F e b
(Edi
En resumen
d e Tres d e chnooscam-
i o n a l s d e r
ac
Si lasNcosas no están
o
funcionando
s to d os lo de software
bien, ¿Por qué
E du n- ser
biar? ¿Por quérvfingira d que
e Al fin y al cabo, el desarrollo
a ra debe
lo queRnoeses?
e d ic n pvimos, la propia
iócomo 2 7 6,
3natu-
s ta c on i
de e
raleza del software y la
, Moensnuestra
actividad
)ayuda
inherentemente humana
s
que permite construirlo,
f ( U N T R E F
nos
. d e B uendeotra-
tarea
tre Entonces, ¿qué
bajar mejor.
ñ a , nos ia cambiar? ¿El mie-
Pcimpide
P
enz ¿No somose e u.ade
dacaso, r una disci-
S á
do a lo desconocido?
n t r e f.
parte,
plina joven, que nowdebería
s.errores,
irelos ww.utenerle miedo al cambio?
Aen
Insistir en el “no puede ser”, nos lleva al
conservadurismo de Poincaré que, por aferrarse a antiguas
concepciones físicas, no se atrevió a dar el salto que luego
Einstein postularía: por eso hoy nos acordamos mucho más
del segundo que del primero.
En eso estamos, pues. Avancemos.
5
Tengamos en cuenta, no obstante, que el 77% de los encuestados son empre-
sas europeas o estadounidenses, lo que no dice mucho de la adopción en los
países de habla castellana.
Iterativo por naturaleza • 31
Iterativo por naturaleza
En los últimos cuarenta años, no ha habido ningún mo-

delo de proceso de desarrollo de software exitoso que no
sea iterativo. Desde el proceso en espiral hasta el unificado,
todos los procesos recomendados tanto desde la academia
como la industria asumen una estructura de aproximacio-
nes sucesivas para su desarrollo.
Sin embargo, como vimos[e
. .]
alcapítulo
ent.el anterior, son
P a e z . . T R EF y prác-
c o l
comunes múltiplesá s visiones (el modelo
U N
en cascada)
©N (lai planificación de n basada en tareas)
icióplazo
dlargo
ticas
e s t a e
e en el que,ien a l d e Tresmedida,que
asumendun
se©
proceso
N on mayor
aalcprincipio.
o menor
i d a
sabe todo lo importanted
rs hemos escuchado untref
Univeveces
(Muchas p a r a Ed enunciados condla clá-
ida
Febde
sica estructura ro)
rerecomendación Univedersclaudicación:
seguida
de la
dlasepruebas ).
reelrodise-
r
“Haytoque
i i a l
hacer
d no podemos enseñarlo e F e
en paralelobcon
d porque es confuso”;
(Epero
ño, d e Tres así e chos
i o n a l s d e r
Nade:
o la otra c
eserque v el análisis puede r
R“Claro e d ic ión serpainfluenciado
i 2 6,
73por
e s t a os c o n
de
el diseño, pero de todas
R
maneras
el F
E ), Mpor
siempre hay que
e
ha-
os
nre-
( U N
cer todo lo que pide T cliente, eso se B
e u
llaman
tref
querimientos”.
ñ a , P cia. d
e .ar falta el co-
áenz laPvocación
En estosSejemplos, r e f. e d u
w.unto la técnica para llevarla a
parece clara pero
r e s
raje o la percepción . w wprofunda
Ai
buen término. En cada uno, se deja para después algo que
debería hacerse antes y, por lo tanto, se asume en lugar de
aprender o discutir. En fin, así nos va.
Parte del éxito de los métodos ágiles está en abrazar esa
perspectiva de persona mirando al abismo, y proponer téc-
nicas específicas para lidiar con la complejidad.
Ejemplos concretos son:
• El time-boxing, consistente en limitar el tiempo a utilizar
antes que el alcance de las tareas, forzando un límite que
podemos controlar siempre (el tiempo transcurrido) y

usándolo como medida para controlar otros aspectos
(alcance, avance, calidad, valor entregado, etc.).
• El desarrollo guiado por pruebas (Test Driven Develop-
ment o TDD ), consistente en escribir las pruebas antes de
escribir el código y hacerlo iterativamente de manera tal
que las mismas puedan ser ejecutadas una y otra vez para
garantizar que el código evoluciona correctamente.
• Las prácticas de planificación estratégica y táctica1 que
se ejecutan iterativamente durante el proyecto.
En este capítulo nos proponemos revisar las razones por las
cuales creemos que los procesos iterativos y por incremen-
tos son la evolución natural del desarrollo de software.
z . . . [et.al.]
P a e TREF
Nicoládes software
El©desarrollo
edici
como ó n U
proceso
N iterativo
e s t a a l d e Tres
de confusión N
La©principal a
reinantecio n
alrededor del proceso de
desarrollo e a d
rsid como vimos untref
dcapítulo
nivconsiste,
(Umirada p a r a
en el
E anterior, en
ddiseño,
una
Fe
basada en
b r ro) etc.) queUson
actividades
epruebas, disjuntas
n i v e rsidaacabo
(análisis,
d e
implementación,
d e l a llevadas
e r o ) . por
al poco y smal,dprincipalmente Feb r
(Editori Estadconfusión
gente que se comunica a través
r e e fácil
de documentos.
i o n a l T
e con el modelo denecascada,
hace
s r choess im-
identificar
e
N ac
plícitamente el proceso
s to d o s lo d u n -de-
ado de actividades E prime-
raejemplo,
Reserv y después
cir, con una secuencia (por
ó n p aAún
ro implementación i
a edic tiendeosa cdificultar
pruebas). cuando 6,sea
ni 2la73aplica-
no
s t
explícita,eestaepreconcepción o
d
ción de un proceso N T R E F), M
iterativo. B uenos
f ( U
trebien ¿Qué es ñunaproceso . d e
ciaiterativo? Es un proceso
Ahora
P e , alPresultado r nos per-
á enz
de aproximaciones
S sucesivas
t r e f. e u.aque
dfinal,
u n
el.producto
w
s. wdelwresultado.
mite ir ajustando tanto como el proceso para
maximizar Aielrevalor Un ejemplo es la escritu-
ra de este libro: produjimos varios borradores hasta llegar al
resultado final.2 En concreto, es un proceso donde las acti-
vidades se repiten en cada iteración, permitiendo obtener
y analizar los resultados de esas múltiples actividades y uti-
lizarlos para nutrir a las demás (por ejemplo, las pruebas se
ejecutan en cada iteración sobre lo construido).
1
Véase el capítulo “Planificación constante”.
2
En este momento, estamos haciendo un refinamiento de este capítulo.
Lo anterior no quiere decir que todas las actividades

tengan que realizarse en todas las iteraciones, el foco pue-
de variar a medida que transcurre el proyecto, por ejemplo
estar en un momento en la puesta en producción y en otro
en la construcción.
Figura 2.1
Una obra iterativa y
por incrementos.
z . . . [ e t.al.]
© Ni dición
d e e s t a e
i o n a l de Tres
©
(Univ a ra E
F e b r e r o ) p
U n i v e rsidad
de d e la rero).
(Ed
i o n s d
Nac
r
a n
( U N T e B u
Pe .ar
Sáenz u
Un proceso iterativo nos ayuda a:
r e f. e d
• Innovar: podemos . w w w.una
usar unot varias iteraciones para ex-
i r e s
plorarAalternativas. Si las alternativas son descartadas, el
proceso nos permite limitar el esfuerzo dedicado a ellas
mediante la asignación de un número acotado de itera-
ciones a esa exploración. Si las alternativas son seleccio-
nadas, pueden refinarse en futuras iteraciones.
• Minimizar el costo de nuestros errores: como cada itera-
ción aborda solo una parte del problema completo, si
nos equivocamos, no estamos arriesgando todo nuestro
proyecto.
• Maximizar las oportunidades de mejora: un proceso ite-

rativo provee múltiples oportunidades concretas (por
ejemplo, retrospectiva3 al final de cada iteración) para la
reflexión tendiente a la mejora.
• Imprimir un ritmo: con iteraciones de duración fija, los
equipos realizan sus actividades a intervalos regulares,
facilitando la asimilación de las prácticas (por su repeti-
ción disciplinada). El ritmo también fomenta el mante-
ner un nivel de esfuerzo sustentable y evita el burnout.4
• Maximizar las oportunidades de control: al final de cada ite-
ración podemos evaluar métricas y validar el producto
para determinar el progreso y la alineación en relación a
los objetivos del proyecto.
z . . . [et.al.]
i
Un proceso c o a e
ás P por incrementos
literativo n U N TREF
© N ici
editerativo ó rescada ite-
e
Para ser efectivo, e sunt aproceso a l d
depende e deTque
d
© produzca resultados Na n
cio que nos den sensación
ración
r s i d a d concretos
untref
UniveSin esa sensación
de(avance.
a Edrevisar
esradifícil la planificación
y garantizareque
F b r e
el r o )
proyecto p en su
n i
conjunto
U v e rsidenaladdirec-
vaya
ción e
dcorrecta (es decir,dque e vaya la a cumplir con sus o).
eelrobjetivos).
t o r i a l e F e b r
( E
Para diayudar en esa tarea,
T r e s
es d
común dividir
h
produc-
os
to en incrementos,
o n a l e
dparticiones que spueden d e r e c
desarrollarse
i
Nac iteraciones o
dos lplanificar
en distintas
a d o s o
y tpermiten el trabajo
E n-pa-
duconjun-
r
Rese En eestev a r a
ra cumplir con el alcance
d i c ión p
completo mediante
i
un
2 7 6,
3produ-
to de iteraciones.
s t a
e eincrementoEoFrefina
modelo, n
cada iteración
c o
osanterior,
ce un d nuevo
T R ), Muno B
de n
u e os
manera
f
tal que alefinal ( U N . d e
, Pcia
todos los incrementos han sido construidos
tr ñ a
mediante sucesivos P e
refinamientos.
du.ar
Sáenz n t r e f. e
ww.u
Aires. w
No estamos solos
Este modelo de proceso iterativo y por incrementos no es
una característica exclusiva del desarrollo de software. Co-
3
Véase el capítulo “En retrospectiva”.
4
Entendemos por sustentable un nivel de esfuerzo que puede mantenerse du-
rante todo el proyecto, como opuesto a los esfuerzos excesivos como traba-
jar cuarenta horas extra por semana, que si se mantienen en el tiempo causan
serios problemas, incluyendo la rotación de personal (véase [DeMarco 1987],
capítulo 3).
mo muestran Rob Austin y Lee Devin en su libro Artful

Making [Austin 2003], tanto en el teatro como en otras for-
mas de arte, en el diseño de estrategia, y otros trabajos crea-
tivos, los procesos exitosos son iterativos por la naturaleza
del trabajo. Los autores describen las siguientes condiciones
de aplicabilidad de esta forma de trabajo:
• Necesidad de innovación: cuando el producto es original o
por lo menos lo es en el contexto actual.
• Repetición confiable: el proceso de trabajo es repetible, es
decir, contamos con la capacidad y disciplina para traba-
jar iterativamente.
• Bajo costo de iteración: el costo de iteración se define co-
mo la suma de:
. . [ e l.] de modificar lo
tel.acosto
˚˚Costo de reconfiguración:
s P z .
ae en iteraciones T REF o de
que o
i c l á
hemos realizado U N anteriores,
© Ncambiar
s t a e
el proceso. dición e Tresalterna-
d e e exploración: eliocosto n a l dexplorar
©˚˚ Costo de
s i d a Nac finalmente en el produc-
d incluidas
de
tivasve r
(Utonifinal, porque
que no son
a r a Eunaduntref
r o)
erporque
se p
encuentra alternativa
e d o
amejor
rsidarmónico
de F e b U n i v
simplemente la
no forman un todo
).
rial de
con eloresto.
(Edit s de Febrero
l d e T r e reenclas
s el
hoque
o n
Estas condiciones
i a s
son típicas de situaciones d e
Nacque se obtiene
producto
os tes os lo (por loEmenos
odintangible dun-par-
es e rv a d p a ra
R
cialmente), y requiere
e
el
d
trabajo
ic ió n colaborativo de
2
un grupo
736,
de personas. sta
e s c o n i
de de ArtfulRMaking
El modelo E F Mopermite
), nos e nos a
caracterizar
( U N T d e B u
ef
nuestrostrprocesos de desarrollo
a , P cia. ágil
para decidir si corresponde
e
o no un proceso iterativo. ñ
nz P de softwareLa filosofía
d u r
.yamuchos otros
conciben Sáal e
desarrollo nt r
.uinnovadore f. e
como un proceso emi-
. w w w
A es
nentementeirinnovador. Por entendemos:
• Que los problemas a los que nos enfrentamos son radi-
calmente nuevos cada vez. Aunque parezca que muchos
proyectos tienen cosas en común, lo que tienen de parti-
cular e interesante tiende a ser siempre más de lo esperado.
• Que la forma de trabajo apropiada para lidiar con esos pro-
blemas no puede definirse en detalle de antemano. Dicho
de otra forma, que nuestros procesos y prácticas de trabajo
deben adaptarse a la realidad específica de cada proyecto.
Si no hubiera necesidad de innovación, bastaría re-usar

software existente. Lo que ocurre con el reuso es que nor-
malmente los requerimientos suenan a “quiero algo pare-
cido pero distinto”. Las expectativas sobre el reuso tienden
a ser altas, ya que implica no tener que desarrollar software,
pero en la mayoría de los casos requiere extensión y adap-
tación. Además, el reuso en sí implica desafíos análogos o
mayores en complejidad a los del desarrollo de software a
medida.5
En cuanto a la repetición confiable, es uno de los desa-
fíos metodológicos fundamentales de la ingeniería de soft-
ware, como tema fundamental de la madurez que discu-
timos en el capítulo anterior. En ese aspecto, los métodos
ágiles promueven una práctica y disciplina cotidiana (por
ejemplo, reuniones diarias, validación
. . . al.y] revisiones periódi-
et.soportan
[que
P a
cas a intervalossregulares, e z N REFla repeti-
Ttanto
N i c o l á etc.)
ó n U
© sustentable como
ción
t a ed
la ici continua. Tres
mejora
© d e
Finalmente, e sdada la propia
a c i o n al de intangible del
naturaleza
software (como d
i v e r s i ad Nal hardware,
opuesto
E d
que tiene costos de
untref
(Un
reconfiguración mayores), yade
r o ) rala mano de ciertas
pintegración s i d a d
prácticas
específicas F e b
(por r e
ejemplo,
U n i v e r
continua), en el desa-
dees posible mantener
rrollo de bajo la el costo de iteración.
rero).
al eb
(Editori de Tres de F echos
ionaun
Naccomo
l
o s lo s der
La mejora
r v a d s to
proceso
o dempírico
a ra E dun-
DadasRlas
e
escaracterísticas ión del p software (comple-
ta e d ic
esenciales
on i 2 736,
d e e
jo, intangible, s
ajustado al uso y M osc
cambiante [Brooks 1975]),
E F ),
TRinformación n s
ue elopro-
y entendiéndolo N
e f ( U como
. d B
empaquetada,
e
ceso detrdesarrollo a , Pcde
es un proceso ia aprendizaje continuo,
P e ñ du.ardel sistema,
tanto sobre
S á elosnzrequerimientos n t
y elf.e
r e contexto
como sobre el diseño wwy w u
el .proceso de desarrollo. Desde esa
perspectiva, es. proceso
Airtodo de desarrollo debe implicar la
mejora continua para garantizar mínimamente que se lo-
gren los resultados esperados, porque si no aprendemos lo
suficiente sobre el contexto y el proceso, es poco probable
que logremos pasar la prueba final de que el software sirva
para lo que lo construimos.
5
Watts Humphrey, al diseñar las métricas del PSP (Personal Software Process),
propuso contar el tamaño de un sistema como lo escrito + lo reusado [Hum-
phrey 2005b]. Véase [Garlan 1995] para una discusión de las dificultades en
reuso de componentes de software.
Dicho de otra forma, si no nos esforzamos por mejorar,

es muy poco probable que acertemos desde el principio o,
como vimos en la sección anterior, que sepamos lo sufi-
ciente como para lograr nuestros objetivos.
La filosofía ágil asume esta mejora como un proce-
so empírico, es decir, basado en la exploración y la expe-
rimentación. En un equipo ágil, todos los individuos son
solidariamente responsables por experimentar, evaluar y
adaptar el proceso y las prácticas de desarrollo en forma
iterativa, para lograr los objetivos del proyecto.
Los métodos ágiles promueven la mejora mediante al-
gunas prácticas propias de un proceso iterativo:
• Retrospectivas: al final de cada iteración se evalúa el pro-
ceso y se establece un compromisol.de
[ e t . a ] mejora.
P
• Revisiones: al final
s ezcada
ade ... iteración se evalúaT REelFproduc-
c o l á U N
©toNy ise determinan t a e dición apropiados.
los refinamientos
s
Trepequeñas
d e
• Incrementos: s
eel producto seiorealiza n a l departes
en
©que pueden seravalidadas c
d Natempranamente,
n i v e r s i d E d untref reduciendo el
(U
impacto de los
r e
errores.
r o ) para e d
rsidaavance
e F e
• Planificación
d b estratégica: se revisan
a U n
las i v
prioridades, y
e l
d Basada en hitos o ) .
rer iteracio-
ditorial y entregas
resultados del
(Ecompletadas
proyecto.
s d e Feb como
nes
a l d e Tre de subconjuntos
e re cde o
h s
funcio-
Nac i o n o s d
todos llas
nalidad.
a d
• Planificaciónrvtáctica:o s organizan
se r a
tareas un-
deEladiteración
e
Res subsiguiente. p a
inmediata
a e dición 736,
d e e st
) , M o sconi 2 os
f ( U N TREF . d e Buen
tre
En resumen a, Pci a
z P e ñ u ar
.abordarlos
en
Sáproblemas r e f. e d
Lidiar con
. w w w .unt sobre el problemapro-
complejos requiere
ires
gresivamente, tanto para aprender
mo sobreAla solución. Enfrentar con éxito una gran incer-
co-
tidumbre requiere la sabiduría de dividir el problema en

partes pequeñas, y la humildad para enfrentarlas como si
cada una fuera tan importante como el todo. La filosofía y
los métodos ágiles proponen prácticas específicas para me-
jorar la efectividad del proceso iterativo. Depende de no-
sotros aplicarlas con criterio para maximizar los resultados.
En los próximos capítulos esperamos poder ayudar a lo-
grarlo.
Delineando el alcance • 39
Delineando el alcance
Todo proyecto, independientemente de la disciplina a la

que pertenezca, comienza por una visión. La misma cons-
tituye el punto de partida y la motivación para realizar el
proyecto. Puede que dicha visión esté formalmente docu-
mentada o no, pero más allá de esto es fundamental que
todos los integrantes del equipo la conozcan, pues es el
instrumento que debería guiarnos
z . . . [ e t.aadella.]los
hora de tomar de-
cisiones. Cuando P
c o l á s ae
vamos al ámbito
U N T REF ágiles,
métodos
©N
estas i
afirmaciones son igualic
e n pero aquíelos distin-
d deióválidas,
d e e s
tivo es la estrategia t apara convertir
i o n l
esaavisiónde enTrun entrega-
ble
e r s i d d NaElcprimerdpaso
©de valor para elacliente. para transformar
untref
(Univen producto
la visión
r o ) p ra E del alcance.
es la definición
a s i d
Este es el
a d
ebre ive r
la Un
foco del presente capítulo.
de F d e rero).
(Edanálisis y planificación
Alcance,
i o n
Nac de alcance os de s d
lola actividad deunanáli-
La definición
r v a d o s todparte
es
a ra E d -
e
es En este d
sis delRproyecto. proceso
c p lo fundamental
iónde yanálisis 6,
t a e i n i 2 73mismo
s
es entender laenecesidad
e ciertas ocasiones
den
del cliente o
sucnegocio.
Mosde un proyecto
Al
tiempo, R E F el),alcance e s
nopue-
( U N T e B u
tref y, en eseñcaso,
de ser variable
a , P cia. d deEsalcance
la definición se ve
naturalmente “mezclada”
entécnicas e
z P tratadas enreeste
con u
planificación.
e d .a r
por esto que
algunas Sdeálas f.
s . w w w.unt“Planificación constante”.
capítulo serán tam-
Ai r e
bién referenciadas en el capítulo
Backlog de producto
El primer paso en el proceso de materialización de la vi-
sión es la definición del alcance. En términos ágiles, está
representado por el backlog de producto.1 Este backlog de
1
El término backlog de producto, en inglés product backlog, fue acuñado en
Scrum, pero en la actualidad se lo usa más allá de Scrum.
producto es una lista de ítems que representa todo el traba-

jo necesario para concretar la visión. En términos tradicio-
nales de gestión, el backlog podría ser análogo a una WBS2
orientada a producto. Sin embargo, hay una diferencia en-
tre las WBS de los enfoques tradicionales, generalmente
compuestas por todas las tareas a realizar, y el backlog del
producto de los métodos ágiles, el cual debiera contener
solo ítems que tengan valor real para el cliente.
Dependiendo del método particular que se utilice, es-
tos ítems podrán tomar distinta forma, pero como ya he-
mos mencionado, en todos los casos deberán ser los que el
cliente valore.
Algo fundamental para los métodos ágiles es que el
cliente priorice los ítems de backlog. Luego de un trabajo
de análisis, dichos ítems deberán
. . tser l.]
.aestimados
[etendremos por el equi-
sP a e z . TR F E
N i c o l á
po de desarrollo. De esta forma
i ó n U N la información
©
necesaria para planificar
ducto. de esta
edlaicconstrucción d e res pro-
de nuestro
T
©Para generar elabacklog cioproductol
na a partir de la vi-
d N
d muy popular a
niveuna
(Uexiste rsitécnica de
r a Edenuntref
sión,
e r o ) p a los ambientes
r s i d a d ági-
Fe
les denominada b rVisual Story Mapping. ni v e
de d e la U r ero).
t o r i a l e F e b
n a
Visual storyioMapping l o s d e r
Nac análisis, o s to dos lpor E n-
du[Patton
Esta técnica der v a d
esede la idea dedque
propuesta
a ra
Jeff Patton
2005],Rparte e ic ióa nnivelporganizacional
i 2 7 6,
3traba-
s
jamos eneunecontextot a de negocio ocon sc o n
d F ) , M
deEciertos procesos deB
determinados
n o
ob-
s
jetivos que requieren
f ( U N TR . d e ue que
negocio,
tre a cabo porñpersonas
son llevados a , Pcique a realizan ciertas acti-
Pe
enla zejecución denestas e du.ar se realizan
S á
vidades. Para
.u t r e f.actividades,
wwwherramientas
ciertas tareas utilizando
ires. producto/software.
en juegoAnuestro
y es ahí donde entra
A partir de esto tene-
mos una jerarquía: proceso de negocio (objetivo) > activi-
dades > funcionalidades de nuestro software.
Esta técnica se aplica en sesiones de trabajo con los
usuarios y los miembros del equipo de desarrollo. En lí-
neas generales podemos decir que la técnica consta de cua-
tro pasos:
2
La sigla WBS hace referencia a Work Breakdown Structure, un artefacto de
uso muy común en la gestión tradicional de proyectos.
Figura 3.1.
Vista conceptual
del Story Map
1. Identificar los procesos de negocio (objetivo).

2. Identificar los usuarios.
z . . . [ e t.al.]
©4.N i
3. Identificar las
dición del software.
actividades de los usuarios.
de e
Identificar s t
lasa e
funcionalidades
ional de Tres
© aplicar la técnica
d a ac contar con marcadores,
desNnecesario
Para
e r s i
nivpapel, tarjetas) (opanotas Eduntref
(Ude
cinta
o r a autoadhesivas)
i d de d
a al me-
r
ebredistintos y una r s
Univededetrabajo
de oFmesa
nos tres colores superficie (una
d e l a o
rer tra- ) .
pizarra
i t o r i a l
amplia). Sobre la superficie
e F e b trabajo
d papel: el eje horizon-
(Eddos ejes utilizando
zaremos
d e es de
rcinta
Tmientras e hos re-
cvertical
i o
tal representará n a
el ltiempo, s
que d r
eleeje
Nacimportancia s t s lo (cuanto más
odelonegocio n-
duarriba,
presentará
e r v a d o para
a ra E
Res
más importante).
edici ón p i 2 736 ,
e s t a c o n
de
TR E F ), Mos B u e nos
(U N e
P e .ar
r e s . w w
Ai Figura 3.2.
Superficie de trabajo
para el VSM.
Entonces comenzaremos ubicando en la parte superior las

tarjetas que constituyen los distintos procesos de negocio. A
continuación, en un segundo nivel (utilizando tarjetas de otro
color), ubicaremos las tarjetas con las distintas actividades que
conforman el proceso de negocio, prestando atención a man-
tener la secuencia en que dichas actividades deben ejecutarse.
Figura 3.3
Identificación de
procesos de
negocio y
actividades
Por último, en un tercer nivel, ubicaremos las funcionalida-

des que nuestra aplicación deberá proveer para que puedan
completarse las actividades identificadas previamente. Es
común que para completar una actividad dada, el sistema
deba proveer más de una funcionalidad. Es por eso que nos
encontraremos con varios niveles de tarjetas de funciona-
lidades, siendo los de más arriba, los lmás
. . . [ e a .] de
t.algunas importantes. Del
mismo modo puedeasuceder
s P e z que
N T R F
lasEfuncionali-
i c o
dadesNresultenl á indispensables i ó n U
© e d i c para el negocio mientras
r e s
T a estas
que
esta
otras sean complementarias. de atender
alasl funcionalidades
Es importante
© de al ubicaradlas tarjetas
cuestiones N a c i o n
con del
ive r s i d Ed untref
Unprimer
sistema.
(El ) p a radebería dad que
F e b r
nivele r o
de tarjetas
U n e rsiaquellas
incluir
i v
de el conjunto
constituyen
d e mínimola de funcionalidades r e r o .
)nece-
di
sario para t o r i a
completar l el flujo de d e
negocio. F e b
(E d e Tres e chos
i o n a l s d er
Figura 3.4.
Nac
a a
Visión final del
Rese rv a r
ión p
Visual Story Map
ta e d ic
on i 2 736,
de e s c
T R E F ), Mos B uenos
tref ( U N . d e
e ñ a , Pcia
Sáenz
P
n t r e f. e du.ar
ww.u
Aires. w
Al finalizar la actividad de Visual Story Mapping tendre-

mos:
• El mapa de funcionalidades que nuestra aplicación de-
berá implementar y no solo eso sino que tendremos
una visión global de como cada funcionalidad encaja en
el contexto de negocio que pretendemos resolver.
• El conjunto de funcionalidades que constituyen nuestro

backlog de proyecto, siendo las funcionalidades del pri-
mer nivel las de mayor prioridad.
El resultado del Visual Story Mapping es un mapa “físico”
de las stories que constituyen el sistema. Generalmente es-
te mapa no se descarta, sino que es colgado en algún lugar
visible dentro del espacio de trabajo de equipo, para tener
como referencia de contexto a lo largo de todo el proyecto.
Con esto ya estamos en condiciones de estimar y plani-
ficar el desarrollo de la aplicación, pero esas son cuestiones
que trataremos en el siguiente capítulo.
User stories
dezVisual
e et.al.]
... [ Story Mapping F ha-
Al describir la técnica
c o l á s P a U N T REhemos
© Ndei funcionalidades
blado n
ióaplicación.
ddeiclasuelen En los contextos
d e
ágiles dichas e s t a e
funcionalidades
i o n a l d Trescon user
e
representarse
© Alguien podría
stories.
s i d a Nacque las user stories son espe-
d pensar
( e
cificaciones r
Univ de requerimientos, a r a duntref
loEcual no es correcto. La
b
definición purista r e r o )
indica pque una user i v
storyees ad
rsunidrecordatorio
F e
derelevante que debe U n
la con el usuario,rloercual
de algo
r i a l d ehablarse F e b o).hace
( ito las userdestories
que aElodsumo
T r e s deconsiderarse
puedan
e c h
el título
os
i o n
de un requerimiento. a l s d e r
Las ac stories tienentoundoforma
Nuser s s lomuy simple,duconsiste n-
e rv a d o p a r a E
Res
en una oración escrita
e
en
d
el
ic
lenguaje del
iónel siguiente
negocio
7
que
3 6
ge-
,
neralmente se expresa
e es ta utilizando
osco ni 2
patrón:
d<rol> quiero R
Como EF), M para <beneficio>
T <funcionalidad> Buenos
f (UNcomunes, dePuser
treejemplos c de para un portal
ia.stories
a
nz Peñpodríantreser:f.edu.ar
Algunos
Sáeelectrónico
de comercio
w.un
i r e s
• ComoAcomprador . w wquiero buscar productos por rango
de precio para ver solo aquellos que estén a mi alcance.
• Como vendedor quiero poder duplicar una publicación
pasada para evitar cargar toda la información otra vez.
• Como moderador quiero editar las publicaciones para
asegurarme que respeten las políticas de la empresa.
Las user stories son un artefacto propuesto por Extreme
Programming, cuyo uso y popularidad se ha extendido
mucho más allá de este método particular. Posiblemente
parte de su gran popularidad se deba al libro de Mike

Cohn [Cohn 2004], el cual es una referencia obligada para
quienes deseen ahondar en el tema.
User Stories vs. Casos de uso

Es común que en una primera aproximación tienda a ver-
se a las user stories como análogas a los casos de uso del
Proceso Unificado, en el sentido que ambos artefactos des-
criben en cierto modo una funcionalidad del sistema. Esta
analogía no parece apropiada, ya que más allá de la forma
de estos artefactos, hay una diferencia radical en el propó-
sito de cada uno, dado por el contexto metodológico en el
cual se usan.
Habitualmente, al trabajar con casos de uso se tiende a ge-
nerar documentos que especifiquen con bastante nivel de
z . . . [et.al.]
detalle la funcionalidad que el programador debe implemen-
i c o lás P a e
n U N TREF
tar. Por su parte, las user stories son intencionalmente vagas,
© N edici ó
pues lo que buscan es promover el diálogo entre quien debe
© d n
implementar la funcionalidad y quien la ha requerido. Es jus-
Nacio
s i d a d
to esta diferencia de enfoque la que lleva a que en general
(Unive r r a Eduntref
no se utilicen casos de uso al trabajar con métodos ágiles.
a
F e b r ero) p
U n i v e rsidad
N.P.
de de la r ero).
t o r i a l e F e b
(Edi
Propiedades INVEST
d e sd
Tseresuele e choascier-
Al hablar deouser
i n a l stories
s e r
hacerdreferencia
Nac deseables
tas propiedades s to doestas
que s lodebieran cumplir.d un-Di-
r v a d o a r a E
chas R ese
propiedades enunciadas n
d i c ióen inglésp forman la 6sigla
7 3 ,
INVEST: s ta e c o n i 2
de e (independiente): E F ), enMoelssentido nos
• Independent U
f ( N TR
. d e B ueindepen-
de
trede las demás;ñesto
diente a , nos ia más libertad a la
Pcbrindará
P
enz y al mismo
deáplanificar e e u.ar ayudarnos
ddebería
horaS
n t r e f.
tiempo
wwa.ula hora de estimar.
Aires. w
a evitar ambigüedades
• Negotiable (negociable): una user story no es un contrato
de funcionalidad, pues sus detalles van evolucionando y
definiéndose conjuntamente entre el cliente y el desa-
rrollador a medida que se desarrolla.
• Valuable (valiosa): si una story no tiene valor para el
cliente entonces no tiene razón de ser.
• Estimable (estimable): si una story no puede ser estima-
da por el equipo entonces no es posible que este pueda
asumir un compromiso para su construcción.
• Small (pequeña): al ser pequeñas serán más fáciles de es-

timar, tendrán menos ambigüedades y darán una mayor
flexibilidad a la hora de planificar.
• Testable (que puede probarse): tenemos que poder
probarla para que podamos definir una condición de
aceptación, sin esto ¿cómo saber cuando está termi-
nada?
Más allá que estas propiedades se han popularizado con las
user stories, la realidad es que son propiedades deseables
para todo requerimiento, estemos o no trabajando con un
enfoque ágil.
Story Cards
Durante el proceso de análisis,
z . . . [ e t.aseal.]que se useFla técni-
ya
ca de Visual o ás PMapping
lStory ae o no, las user U TREsuelen es-
Nstories
N i c i ó n
© en fichastabibliográficas
cribirse
e s edic que seddenominan e s Story
Tlareuser
© d
Cards. Cada e story card tiene
cel i on a l
enunciado de story
N a
(Como <rol>
nivnegocio idad <necesidad>
ersquiero E d untref
para <beneficio>), el
(Ude
valor que tiene
o ) p a r
la a story y la cantidad
i d aded story
b r e r i v e r s
d e Fe
points que el equipo le asignó en
la poca Un
la estimación.
).
Las user stories
i t o r i a l d e
brindan muy
e e b
información
F rerorespec-
to de(Eladfuncionalidad,
l d e Treso
por es esdque se suele r e ch osque
decir
a c
son simplementeion a un recordatorio
s lodesd e
algo que debe ha-
N o d o
s tconsecuencia,arloaimportante Edu no n -
rvadenosí,
blarse con el cliente. En
esestories
son lasRuser
ición
sino la p
discusión que se
73 ,
da en6tor-
no a ellas. esta ed c o n i 2
e
Pordúltimo, F ), M os nos
( U N R
paraTdejar E bien u e
en claro las expectativas
e B
respectotredef la funcionalidad P cia. por
provista d cada user story,
e ñ a , .lasarcondiciones
al dorso de la n
S á e z P
story card se suelen
r e d
escribir
f . e u
de aceptación de la story,
w uncuales
w.tenga
las t funcionan como una
Ai
especificación r e s .
para w quien que implementarla.
En resumen, estas tres particularidades suelen ser referi-
das en inglés como CCC:
• Card: la tarjeta física donde se escriben las stories.
• Conversation: la discusión que debe darse entre el
cliente y el equipo de desarrollo en torno a cada user
story.
• Confirmation: los criterios de aceptación que verifican
el cumplimiento de las user stories.
Figura 3.5.
Story Card
z . . . [et.al.]
i c o lás P a e
n U N TREF
© N edici ó
© d Nacio n
s i d a d
(Unive r
a r a Eduntref
F e b r ero) p
U n i v e rsidad
de de la r ero).
t o r i a l e F e b
(Edi temprana
Épicas y Temas
d e es d es común
Trproyecto e hosno se
cque
En una etapa n
i o a l del
s d e r
lo funcionalidades.
ac
tengaNdemasiado t o dosalgunas n-
r v a d o s
detalle sobre
a r a E dufuncio-
R se
Más alláede esto, puede
e
que
d i c
ya
n p
se sepa que
iyóseguramente algunas
2 7 ,
36más
nalidades serán muy
s ta grandes
c o n i
requieran
e e para serEimplementadas.
de unaditeración F ), Mos A estas user s
nosto-
( U N T R d e B u e
tre f
ries “grandes”, que por serlo no
cia .
cumplen
, Pépicas.
con las propieda-
des INVEST, se las P e ñ a r
duya.asea
suele llamar
Sáelado,nzen ocasiones tresulta r e f. e
Por otro
w w w . u n útil, por cues-
Aires.
tiones de negocio o de planificación, agrupar
user stories solo para facilitar su identificación. Estos con-
conjuntos de
juntos de user stories suelen denominarse temas.
Visual Story Mapping y User Stories

Al hacer Visual Story Mapping es común enunciar las fun-
cionalidades de la aplicación como user stories, pero sin
entrar en mayor detalle que su enunciado y su prioridad.
O sea, tendremos una story card que ubicaremos en el ma-
pa que solo contendrá el enunciado de la story y su valor
de negocio. A esta altura la story card no tendrá condicio-

nes de aceptación, pues estamos en un etapa muy tempra-
na donde recién estamos definiendo qué debe hacer nues-
tra aplicación. Incluso es posible que algunas user stories
no cumplan con el criterio INVEST o directamente sean
épicas.
Otras técnicas
Existen algunas otras técnicas de uso común en contextos
ágiles para la identificación del alcance del proyecto.
Una de estas técnicas es la conocida como Impact
Mapping, desarrollada por Gojko Adzic [Adzic2012]. Esta
técnica va más allá de la identificación del alcance, trabaja
sobre la planificación estratégica, con un foco importante
. . [ e l.] los involucrados
t.aentre
en la comunicación y colaboración
s P ae z . T REF
técnicos yo
c delánegocio.
Ni técnica de análisis U N
©Otra t a e cióesn la denominada
diágil resProduct
TVisual
e
Canvas d[Pichler s
e 2013]. Esta, alioigual n a l d e
© N a c
adalternativa alEclásico
que el Story
ersidhace
Mapping propone
(UnLaivmisma
una
a r a untref
dfoco Product Backlog
lineal.
r e r o )unpimportante
e rsida d
en los destinata-
d e
rios del F e b
software en construcción
a U y n i
estáv basada en varios
e l
dse ubican sobre un o )
rerfísico. .
elementos visuales
i t o r i a l que
e F e b
canvas
(Ed
Por último, nos pareceTrelevante
l d e res d destacarreque c h o
máss allá
a
naquí mencionadas, e
d herramientas
Naciocomo
de las técnicas
o s to d o sUML os otras
lhay
E un-
dactivida-
tradicionales
e r v a d los diagramas
a
de clases,
r a
des y R es que suelendresultar
estados,
e i c iónmuypútiles para i 736,
compren-
2
der el dominio e s ta
de un negocio. Asimismo,
os c o nes importante
deque cuando seRE F ), M s
nomis-
,elos
destacar
( U N T utilizan diagramas UML
d e B u
mos notrse efsuelen generarautilizando, P cia.software, sino que se
P e ñ r
nz informal
Sáeleentendimiento
dibujan de manera
u n t r e f. e .a pues el fin
en pizarrasdoupapel,
es facilitar
w w. y no la documentación.
Aires. w
En resumen
En este capítulo hemos analizado un conjunto de técni-
cas y artefactos de uso común al trabajar con métodos ági-
les. Como puede notarse en la descripción de cada técni-
ca, se propone trabajar cara a cara con el cliente, valiéndose
de herramientas físicas. Esto no impide que luego de cada
actividad todo sea volcado en algún software, pero es im-
portante que durante las sesiones de trabajo se utilicen las

herramientas físicas (tarjetas, notas autoadhesivas y otras),
puesto que permiten reacomodar elementos con facilidad,
experimentando distintas alternativas.
Con lo visto en este capítulo hemos presentado el en-
foque ágil para entender las necesidades de nuestro clien-
te y su negocio. Asimismo, como parte de este proceso de
entendimiento, hemos definido un conjunto de artefactos
que nos servirán como entrada para las siguientes activida-
des del proceso de construcción.
z . . . [et.al.]
i c o lás P a e
n U N TREF
© N edici ó
© d Nacio n
s i d a d
(Unive r
a r a Eduntref
F e b r ero) p
U n i v e rsidad
de de la r ero).
t o r i a l e F e b
i o n a l s d e r
Nac
r v a a r a
Rese e d i c ión p 2 736,
s ta c o n i
de e ), Mos
f ( U N T R E F
. d e B uenos
tre ñ a , Pcia
Pe du.ar
Sáenz n t r e f. e
ww.u
Aires. w

Contrucciondesoftware Adelanto

Cargado por

Información del documento

Descripción original:

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

Contrucciondesoftware Adelanto

Cargado por

Copyright:

Formatos disponibles

z . . . [ e t.al.

z . . . [ e t.al.] Diego Nicolás Paez

(Univ a r a Ed Alejandro Molinari

© Nicolás Paez... [et.al.]

¿Por qué cambiar?.................................................................................19

—¿Y vos qué hacés, Juan? ¿Seguís trabajando con com-

Esta conversación la tuve una semana antes de escribir es-

bios a bajo costo en productos existentes, en un proceso

terminología consistente (no una adaptación forzada de

A mi madre y a mi hermano, por estar siempre presentes;

tipo de prácticas ágiles y otras locuras y a mis ex-jefes, por

El por qué de este libro

ware, describiendo las actividades típicas más o menos en

rica Latina es www.agiles.org, y el foro es foro-agiles@

¿Por qué cambiar?

Los profesionales de desarrollo de software, debido a es-

de competencia perfecta. Cuando se vio que esa simplifi-

cada perfil se debía ceñir a sus tareas específicas, se llegó

cioelndíaalendque todo esosyalonossedpudo

Ya no es tiempo de seguir equivocándonos

cuando hemos cumplido lo que ellos requieren y cuando

Buscando encauzar al desarrollo de software

en vez de software funcionando, que los planes estén talla-

• Contrariamente a lo que sucede en otras disciplinas, el

El resto lo cubren las personas

bemos verlas más desde la sociología que desde la tecnolo-

• Asimismo, cuando por cuestiones de costos o cronogra-

ron cuenta de que las premisas en las que se basaba el desa-

cada organización.5 Incluso ha aumentado la adopción de

Iterativo por naturaleza

En los últimos cuarenta años, no ha habido ningún mo-

podemos controlar siempre (el tiempo transcurrido) y

Lo anterior no quiere decir que todas las actividades

• Maximizar las oportunidades de mejora: un proceso ite-

mo muestran Rob Austin y Lee Devin en su libro Artful

Si no hubiera necesidad de innovación, bastaría re-usar

Dicho de otra forma, si no nos esforzamos por mejorar,

tidumbre requiere la sabiduría de dividir el problema en

Todo proyecto, independientemente de la disciplina a la

producto es una lista de ítems que representa todo el traba-

1. Identificar los procesos de negocio (objetivo).

Entonces comenzaremos ubicando en la parte superior las

Por último, en un tercer nivel, ubicaremos las funcionalida-

Al finalizar la actividad de Visual Story Mapping tendre-

• El conjunto de funcionalidades que constituyen nuestro

parte de su gran popularidad se deba al libro de Mike

User Stories vs. Casos de uso

• Small (pequeña): al ser pequeñas serán más fáciles de es-

juntos de user stories suelen denominarse temas.

Visual Story Mapping y User Stories

de negocio. A esta altura la story card no tendrá condicio-

portante que durante las sesiones de trabajo se utilicen las

También podría gustarte