Prcesos giles

La programacin extrema [Beck, 2000] es un nuevo enfoque algo polmico

para el desarrollo de software basado en el modelo iterativo e incremental. El
primer paso es que el equipo de desarrollo de software determine las diversas
caractersticas (historias) que el cliente deseara que el producto apoyara. Para
cada una de estas caractersticas, el equipo informa al cliente cunto tiempo
tardar en implementar esa caracterstica y cunto costar. Este primer paso
corresponde a los requisitos y los flujos de trabajo de anlisis del modelo
iterativo e incremental (Figura 2.4).

El cliente selecciona las caractersticas que se incluirn en cada compilacin

sucesiva mediante el anlisis de costo-beneficio (Seccin 5.2), es decir, sobre
la base del tiempo y las estimaciones de costos proporcionadas por el equipo
de desarrollo, as como los beneficios potenciales de la caracterstica para Su
negocio. La construccin propuesta se divide en partes ms pequeas
denominadas tareas. Un programador primero elabora casos de prueba para
una tarea; Esto se denomina desarrollo impulsado por pruebas (TDD). Dos
programadores trabajan juntos en una computadora (programacin en pareja)
[Williams, Kessler, Cunningham y Jeffries, 2000], implementando la tarea y
asegurando que todos los casos de prueba funcionen correctamente. Los dos
programadores alternan el mecanografiar cada 15 o 20 minutos; El
programador que no est escribiendo chequea cuidadosamente el cdigo
mientras est siendo ingresado por su compaero. La tarea se integra en la
versin actual del producto. Idealmente, la implementacin e integracin de
una tarea no debera tomar ms de unas pocas horas. En general, una serie de
pares implementarn tareas en paralelo, por lo que la integracin tiene lugar
de manera esencialmente continua. Los miembros del equipo cambian
cotidianamente los socios de codificacin, si es posible; Aprender de los dems
miembros del equipo aumenta el nivel de habilidad de todos. Los casos de TDD
utilizados para la tarea se conservan y se utilizan en todas las pruebas de
integracin.

En la prctica se han observado algunos inconvenientes de la programacin en

pareja [Drobka, Noftz y Raghu, 2004]. Por ejemplo, la programacin de pares
requiere grandes bloques de tiempo ininterrumpido, y los profesionales de
software pueden tener dificultades para encontrar bloques de tiempo de 3 a 4
horas. Adems, la programacin de pares no siempre funciona bien con
individuos tmidos o dominantes, o con dos programadores inexpertos.
Una serie de caractersticas de la programacin extrema (XP) son algo
diferentes a la forma en que el software suele desarrollarse:
Las computadoras del equipo XP se instalan en el centro de una gran sala
con pequeos cubculos.
Un representante del cliente trabaja con el equipo de XP en todo
momento.
Ninguna persona puede trabajar horas extras durante dos semanas
consecutivas.
No hay especializacin. En su lugar, todos los miembros del equipo de XP
trabajan en requisitos, anlisis, diseo, cdigo y pruebas.
No hay ningn paso de diseo general antes de que se construyan las
distintas construcciones. En su lugar, el diseo se modifica mientras se
 est construyendo el producto. Este procedimiento se denomina
refactorizacin.
Cada vez que un caso de prueba no se ejecuta, el cdigo se reorganiza hasta
que el equipo est convencido de que el diseo es simple, sencillo y ejecuta
todos los casos de prueba satisfactoriamente.

Dos siglas asociadas con la programacin extrema son YAGNI ("no vas a
necesitarlo") y DTSTTCPW ("haz lo ms simple que posiblemente podra
funcionar"). En otras palabras, un principio de programacin extrema es
minimizar el nmero de caractersticas; No hay necesidad de construir un
producto que haga ms de lo que el cliente realmente necesita.
La programacin extrema es uno de una serie de nuevos paradigmas que se
denominan colectivamente procesos giles. Diecisiete desarrolladores de
software (ms tarde denominados Agile Alliance) se reunieron en una estacin
de esqu de Utah durante dos das en febrero de 2001 y produjeron el
Manifiesto para el Desarrollo Agile de Software [Beck et al., 2001]. Muchos de
los participantes haban sido autores de sus propias metodologas de desarrollo
de software, incluyendo Extreme Programming [Beck, 2000], Crystal [Cockburn,
2001] y Scrum [Schwaber, 2001]. En consecuencia, la Agile Alliance no
prescribi un modelo de ciclo de vida especfico, sino que estableci un grupo
de principios subyacentes que eran comunes a sus enfoques individuales para
el desarrollo de software.

Los procesos giles se caracterizan por un nfasis considerablemente menor

en anlisis y diseo que en casi todos los otros modelos de ciclo de vida
modernos. La implementacin comienza mucho antes en el ciclo de vida,
porque el software de trabajo se considera ms importante que la
documentacin detallada. La capacidad de respuesta a los cambios en los
requisitos es otro objetivo importante de los procesos giles, as como la
importancia de colaborar con el clientte.

Uno de los principios en el Manifiesto es entregar software de trabajo con

frecuencia, idealmente cada 2 o 3 semanas. Una forma de lograr esto es usar
timeboxing [Jalote, Palit, Kurien, y Peethamber, 2004], que se ha utilizado
durante muchos aos como una tcnica de gestin del tiempo. Una cantidad
especfica de tiempo se reserva para una tarea, y los miembros del equipo
hacen entonces el mejor trabajo que pueden durante ese tiempo. En el
contexto de los procesos giles, normalmente se reservan 3 semanas para
cada iteracin. Por un lado, le da al cliente la confianza de saber que una
nueva versin con funcionalidad adicional llegar cada 3 semanas. Por otro
lado, los desarrolladores saben que tendrn 3 semanas (pero no ms) para
entregar una nueva iteracin sin interferencia del cliente de ningn tipo; Una
vez que el cliente ha elegido el trabajo para una iteracin, no puede ser
cambiado o aumentado. Sin embargo, si es imposible completar toda la tarea
en el timebox, el trabajo puede ser reducido ("descoped"). En otras palabras,
los procesos giles demandan tiempo fijo, no caractersticas fijas.
Otra caracterstica comn de los procesos giles es tener una reunin corta a
una hora regular cada da. Todos los miembros del equipo tienen que asistir a
la reunin. Hacer que todos los participantes se paren en un crculo, en lugar
de sentarse alrededor de una mesa, ayuda a asegurar que la reunin no dura
ms de los 15 minutos estipulados. Cada miembro del equipo a su vez
responde a cinco preguntas:
 1. Qu he hecho desde la reunin de ayer?
2. En qu estoy trabajando hoy?
3. Qu problemas me impiden lograr esto?
4. Qu hemos olvidado?
5. Qu aprend que me gustara compartir con el equipo?

El objetivo de la reunin stand-up es plantear problemas, no resolverlos; Las

soluciones se encuentran en las reuniones de seguimiento, preferiblemente
celebradas directamente despus de la reunin de pie. Al igual que el tiempo-
boxeo, las reuniones de pie son una tcnica de gestin exitosa ahora utilizada
en el contexto de procesos giles. Tanto las iteraciones con tiempo como las
reuniones de pie son ejemplos de dos principios bsicos que subyacen a todos
los mtodos giles: la comunicacin y la satisfaccin del
Cliente lo ms pronto posble.

Los procesos giles se han utilizado con xito en una serie de proyectos de
pequea escala. Sin embargo, los procesos giles an no se han utilizado
ampliamente para determinar si este enfoque cumplir con sus promesas
iniciales. Adems, incluso si los procesos giles resultan buenos para los
productos de software a pequea escala, eso no significa necesariamente que
puedan utilizarse para productos de software de mediano o gran escala, como
se explicar a continuacin.

Para apreciar por qu muchos profesionales del software han expresado sus
dudas sobre los procesos giles en el contexto de los productos de software
medianos y especialmente a gran escala [Reifer, Maurer y Erdogmus, 2003],
considrese la siguiente analoga por Grady Booch [2000]. Cualquiera puede
martillar con xito juntos algunos tablones para construir una casita de perro,
pero sera temerario construir una casa de tres dormitorios sin planes
detallados. Adems, las habilidades en plomera, cableado y techos son
necesarias para construir una casa de tres dormitorios, y las inspecciones son
esenciales. (Es decir, ser capaz de construir productos de software a pequea
escala no significa necesariamente que uno tiene las habilidades para la
construccin de productos de software de mediana escala.) Adems, el hecho
de que un rascacielos tenga la altura de 1000 casetas no significa que uno
pueda Construir un rascacielos apilando 1000 casetas en la parte superior de la
otra. En otras palabras, la construccin de productos de software a gran escala
requiere habilidades an ms especializadas y sofisticadas que las necesarias
para combinar productos de software a pequea escala.

Un factor determinante para decidir si los procesos giles son realmente un

gran avance en la ingeniera de software ser el costo del futuro
mantenimiento posterior a la entrega (Seccin 1.3.2). Es decir, si el uso de
procesos giles resulta en una reduccin en el costo del mantenimiento
posterior al lanzamiento, XP y otros procesos giles sern ampliamente
adoptados. Por otra parte, la refactorizacin es un componente intrnseco de
los procesos giles. Como se explic anteriormente, el producto no est
diseado como un todo; En su lugar, el diseo se desarrolla de forma
incremental, y el cdigo se reorganiza cada vez que el diseo actual es
insatisfactorio por cualquier razn. Esta refactorizacin contina durante el
mantenimiento posterior a la entrega. Si el diseo de un producto cuando pasa
su prueba de aceptacin es abierto y flexible, entonces el mantenimiento
perfecto debe ser fcil de lograr a bajo costo. Sin embargo, si el diseo tiene
que ser refactorizado siempre que se agregue funcionalidad adicional,
entonces el costo de mantenimiento posterior a la entrega de ese producto
ser inaceptablemente alto. Como consecuencia de la novedad del enfoque,
hasta ahora slo existe una pequea cantidad de datos experimentales sobre
el desarrollo utilizando procesos giles, y casi ninguno sobre el mantenimiento.
Sin embargo, los datos preliminares indican que la refactorizacin puede
consumir un gran porcentaje del costo total [Li y Alshayeb, 2000].

Sin embargo, los experimentos han demostrado que ciertas caractersticas de

los procesos giles funcionan bien. Por ejemplo, Williams, Kessler, Cunningham
y Jeffries [2000] han demostrado que la programacin de pares conduce al
desarrollo de cdigo de mayor calidad en un tiempo ms corto, con mayor
satisfaccin en el trabajo. En consecuencia, incluso si los procesos giles en
conjunto resultan ser decepcionantes, algunas caractersticas de los procesos
giles pueden ser adoptadas como prcticas de ingeniera de software en el
futuro.

El Manifiesto para el Desarrollo de Software gil afirma esencialmente que los

procesos giles son superiores a procesos ms disciplinados como el Proceso
Unificado (Captulo 3). Los escpticos responden que los defensores de los
procesos giles son poco ms que los hackers. Sin embargo, hay un terreno
intermedio. Los dos enfoques no son incompatibles; Es posible incorporar
caractersticas probadas de procesos giles dentro del marco de procesos
disciplinados. Esta integracin de los dos enfoques se describen en libros como
el de Boehm y Turner [2003].

En conclusin, los procesos giles parecen ser un enfoque til para la

construccin de productos de software a pequea escala cuando los requisitos
del cliente son vagos. Adems, algunas de las caractersticas de los procesos
giles pueden utilizarse eficazmente en el contexto de otros modelos de ciclo
de vida.
Agile Processes
Extreme programming [Beck, 2000] is a somewhat controversial new approach
to software development based on the iterative-and-incremental model. The
first step is that the software development team determines the various
features (stories) the client would like the product to support. For each such
feature, the team informs the client how long it will take to implement that
feature and how much it will cost. This first step corresponds to the
requirements and analysis workflows of the iterative-and-incremental model
(Figure 2.4).
The client selects the features to be included in each successive build using
costbenefit analysis (Section 5.2), that is, on the basis of the time and the
cost estimates provided by the development team as well as the potential
benefits of the feature to his or her business. The proposed build is broken
down into smaller pieces termed tasks. A programmer first draws up test
cases for a task; this is termed test-driven development (TDD). Two
programmers work together on one computer (pair programming) [ Williams,
Kessler, Cunningham, and Jeffries, 2000], implementing the task and ensuring
that all the test cases work correctly. The two programmers alternate typing
every 15 or 20 minutes; the programmer who is not typing carefully checks
the code while it is being entered by his or her partner. The task is then
integrated into the current version of the product. Ideally, implementing and
integrating a task should take no more than a few hours. In general, a number
of pairs will implement tasks in parallel, so integration takes place essentially
continuously. Team members change coding partners daily, if possible;
learning from the other team members increases everyones skill level. The
TDD test cases used for the task are retained and utilized in all further
integration testing.
Some drawbacks to pair programming have been observed in practice
[Drobka, Noftz, and Raghu, 2004]. For example, pair programming requires
large blocks of uninterrupted time, and software professionals can have
difficulty in finding 3- to 4-hour blocks of time. In addition, pair programming
does not always work well with shy or overbearing individuals, or with two
inexperienced programmers.
A number of features of extreme programming (XP) are somewhat different to
the way that software is usually developed:
The computers of the XP team are set up in the center of a large room lined
with small cubicles.
A client representative works with the XP team at all times.
No individual can work overtime for two successive weeks.
There is no specialization. Instead, all members of the XP team work on
requirements, analysis, design, code, and testing.
There is no overall design step before the various builds are constructed.
Instead, the design is modified while the product is being built. This
procedure is termed refactoring. Whenever a test case will not run, the code is
reorganized until the team is satisfied that the design is simple,
straightforward, and runs all the test cases satisfactorily.

Two acronyms now associated with extreme programming are YAGNI (you
arent gonna need it) and DTSTTCPW (do the simplest thing that could
possibly work). In other words, a principle of extreme programming is to
minimize the number of features; there is no need to build a product that does
any more than what the client actually needs.
Extreme programming is one of a number of new paradigms that are
collectively referred to as agile processes. Seventeen software developers
(later dubbed the Agile Alliance) met at a Utah ski resort for two days in
February 2001 and produced the Manifesto for Agile Software Development
[Beck et al., 2001]. Many of the participants had previously authored their
own software development methodologies, including Extreme Programming
[Beck, 2000], Crystal [ Cockburn, 2001], and Scrum [Schwaber, 2001] .
Consequently, the Agile Alliance did not prescribe a specific life-cycle model,
but rather laid out a group of underlying principles that were common to their
individual approaches to software development.
Agile processes are characterized by considerably less emphasis on analysis
and design than in almost all other modern life-cycle models. Implementation
starts much earlier in the life cycle, because working software is considered
more important than detailed documentation. Responsiveness to changes in
requirements is another major goal of agile processes, and so is the
importance of collaborating with the client.
One of the principles in the Manifestois to deliver working software
frequently, ideally every 2 or 3 weeks. One way of achieving this is to use
timeboxing [Jalote, Palit, Kurien, and Peethamber, 2004] , which has been used
for many years as a time management technique. A specific amount of time is
set aside for a task, and the team members then do the best job they can
during that time. Within the context of agile processes, typically 3 weeks are
set aside for each iteration. On the one hand, it gives the client confidence to
know that a new version with additional functionality will arrive every 3
weeks. On the other hand, the developers know that they will have 3 weeks
(but no more) to deliver a new iteration without client interference of any
kind; once the client has chosen the work for an iteration, it cannot be
changed or increased. However, if it is impossible to complete the entire task
in the timebox, the work may be reduced (descoped). In other words, agile
processes demand fixed time, not fixed features.
Another common feature of agile processes is to have a short meeting at a
regular time each day. All team members have to attend the meeting. Making
all the participants stand in a circle, rather than sit around a table, helps to
ensure that the meeting lasts no more than the stipulated 15 minutes. Each
team member in turn answers five questions:
1. What have I done since yesterdays meeting?
2. What am I working on today?
3. What problems are preventing me from achieving this?
4. What have we forgotten?
5. What did I learn that I would like to share with the team?
The aim of the stand-up meeting is to raise problems, not solve them;
solutions are found at follow-up meetings, preferably held directly after the
stand-up meeting. Like time-boxing, stand-up meetings are a successful
management technique now utilized within the context of agile processes.
Both timeboxed iterations and stand-up meetings are instances of two basic
principles that underlie all agile methods: communication, and satisfying the
clients needs as quickly as possible.

Agile processes have been successfully used on a number of small-scale

projects. However, agile processes have not yet been used widely enough to
determine whether this approach will fulfill its early promise. Furthermore,
even if agile processes turn out to be good for small-scale software products,
that does not necessarily mean that they can be used for medium- or large-
scale software products, as will now be explained.
To appreciate why many software professionals have expressed doubts about
agile processes within the context of medium- and especially large-scale
software products [ Reifer, Maurer, and Erdogmus, 2003], consider the
following analogy by Grady Booch [2000]. Anyone can successfully hammer
together a few planks to build a doghouse, but it would be foolhardy to build a
three-bedroom home without detailed plans. In addition, skills in plumbing,
wiring, and roofing are needed to build a three-bedroom home, and
inspections are essential. (That is, being able to build small-scale software
products does not necessarily mean that one has the skills for building
medium-scale software products.) Furthermore, the fact that a skyscraper is
the height of 1000 doghouses does not mean that one can build a skyscraper
by piling 1000 doghouses on top of one another. In other words, building
large-scale software products requires even more specialized and
sophisticated skills than those needed to cobble together small-scale software
products.
A key determinant in deciding whether agile processes are indeed a major
breakthrough in software engineering will be the cost of future postdelivery
maintenance (Section 1.3.2). That is, if the use of agile processes results in a
reduction in the cost of postdelivery maintenance, XP and other agile
processes will become widely adopted. On the other hand, refactoring is an
intrinsic component of agile processes. As previously explained, the product is
not designed as a whole; instead, the design is developed incrementally, and
the code is reorganized whenever the current design is unsatisfactory for any
reason. This refactoring then continues during postdelivery maintenance. If
the design of a product when it passes its acceptance test is openended and
flexible, then perfective maintenance should be easy to achieve at a low cost.
However, if the design has to be refactored whenever additional functionality
is added, then the cost of postdelivery maintenance of that product will be
unacceptably high. As a consequence of the newness of the approach, as yet
only a small amount of experimental data exist on development using agile
processes, and almost none on maintenance. However, preliminary data
indicate that refactoring can consume a large percentage of the overall cost
[ Li and Alshayeb, 2002].
Nevertheless, experiments have shown that certain features of agile processes
work well. For example, Williams, Kessler, Cunningham, and Jeffries [2000]
have shown that pair programming leads to the development of higher-quality
code in a shorter time, with greater job satisfaction. Accordingly, even if agile
processes as a whole prove to be disappointing, some features of agile
processes may be adopted as mainstream software engineering practices in
the future.
The Manifesto for Agile Software Development essentially claims that agile
processes are superior to more disciplined processes like the Unified Process (
Chapter 3). Skeptics respond that proponents of agile processes are little
more than hackers. However, there is a middle ground. The two approaches
are not incompatible; it is possible to incorporate proven features of agile
processes within the framework of disciplined processes. This integration of
the two approaches is described in books such as the one by Boehm and
Turner [2003].
In conclusion, agile processes appear to be a useful approach to building
small-scale software products when the clients requirements are vague. In
addition, some of the features of agile processes can be effectively utilized
within the context of other life-cycle models.