You are on page 1of 14

DESARROLLO ÁGIL

Fuente: Ingeniería de Software. Roger S. Presuman.


En 2001, Kent Beck y otros 16 notables desarrolladores, escritores y consultores (BEC01)
(conocidos como la “Alianza Ágil”) firmaron el “Manifiesto para el desarrollo ágil del
software”, el cual establecía:

Hemos descubierto mejores formas de desarrollar el software al construirlo por nuestra cuenta
y ayudar a otros a hacerlo. Por medio de este trabajo hemos llegado a valorar:
A los individuos y sus interacciones sobre los procesos y las herramientas.
Al software en funcionamiento sobre la documentación extensa
A la colaboración del cliente sobre la negociación del contrato.
A la respuesta al cambio sobre el seguimiento de un plan.
Esto es, aunque los términos a la derecha tienen valor, nosotros valoramos más los aspectos
de la izquierda.

Un manifiesto se asocia por lo general con un movimiento político emergente: aquel que ataca
a la vieja guardia y sugiere un cambio revolucionario (en el mejor de los casos para mejorar).
De alguna forma, esto es con exactitud de lo que se trata el desarrollo ágil.
A pesar de que las ideas subyacentes que conducen al desarrollo ágil han estado presentes
por muchos años, no ha sido sino hasta la década pasada que estas ideas han cristalizado en
un “movimiento”. En esencia, los métodos ágiles (también llamados ligeros o livianos) se
desarrollaron en un intento por superar las debilidades advertidas y reales en la ingeniería del
software convencional. El desarrollo ágil proporciona beneficios importantes, pero es imposible
aplicarlo en todos los proyectos, productos, personas y situaciones.

UN VISTAZO RÁPIDO
¿Qué es?
La ingeniería de software ágil combina una filosofía y un conjunto de directrices de desarrollo.
La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental;
equipos de proyecto pequeños y con alta motivación, métodos informales; un mínimo de
productos de trabajo de la ingeniería de software; y una simplicidad general de desarrollo. Las
directrices de desarrollo resaltan la entrega sobre el análisis y el diseño (aunque estas

1
actividades no se descartan), y la comunicación activa y continua entre los desarrolladores y
los clientes.
¿Quién lo hace?
Los ingenieros de software y otros participantes del proyecto (gerentes, clientes y usuarios
finales) trabajan juntos en un equipo ágil: un equipo con organización propia y que controla su
propio destino. Un equipo ágil fomenta la comunicación y la colaboración entre todos los que
trabajan en él.
¿Por qué es importante?
El ambiente moderno de los negocios ocasiona que los sistemas basados en computadoras y
los productos de software estén acelerados y en cambio contínuo. La ingeniería del software
ágil representa una opción razonable a la ingeniería convencional para ciertas clases de
software y ciertos tipos de proyectos de software. Ha demostrado su utilidad al entregar
sistemas exitosos con rapidez.
¿Cuáles son los pasos?
El desarrollo ágil podría llamarse con mayor precisión “ingeniería de software ligera”. Las
actividades básicas del marco de trabajo -comunicación con el cliente, planeación,
modelado, construcción, entrega y evolución- se conservan, pero éstas se conforman como
un conjunto mínimo de tareas que empuja al equipo de proyecto hacia la construcción y la
entrega (habrá quienes argumenten que esto se hace a costa del análisis del problema y del
diseño de la solución).
¿Cuál es el producto obtenido?
Los clientes e ingenieros de software que han adoptado la filosofía ágil tienen la misma visión:
el único producto de trabajo realmente importante es un “incremento de software” en
funcionamiento, el cual se entrega al cliente en una fecha prometida.
¿Cómo puede estar seguro de que lo he hecho correctamente?
Si el equipo de software está de acuerdo en que el proceso funciona y que dicho equipo
produce incrementos de software entregables que satisfacen al cliente, entonces el trabajo está
bien hecho.
No es la antitesis de la práctica sólida de la ingeniería del software y es posible aplicarla como
una filosofía predominante para cualquier trabajo de software.
En la economía moderna, a menudo resulta difícil o imposible predecir cómo evolucionarán
con el tiempo los sistemas basados en las computadoras (por ejemplo, las aplicaciones Web).
Las condiciones del mercado cambian con rapidez, las necesidades de los usuarios finales
2
evolucionan, y las nuevas amenazas competitivas emergen sin previo aviso. En muchas
situaciones ya es imposible definir por completo los requisitos antes de que comience el
proyecto. Los ingenieros de software deben ser tan ágiles como para responder a un ambiente
de negocios fluido.
¿lo anterior significa que el reconocimiento de estas realidades modernas ocasiona que
descarten los valiosos principios, conceptos, métodos y herramientas de la ingeniería de
software? No, ¡en lo absoluto! Como todas las disciplinas de ingeniería, la ingeniería de
software continúa en evolución. Se puede adaptar con facilidad para enfrentar los retos que
implica una exigencia de agilidad.

“Agilidad:1, todo lo demás: 0”


Tom DeMarco

Sobre el desarrollo ágil de software, Alistair Cockburn (COCO2a) argumenta que varios
modelos de desarrollo de software tradicionales tienen una falla importante: olvidan las
fragilidades de las personas que construyen el software de computadora. Los ingenieros
de software no son robots. Ellos muestran una gran variedad en los estilos de trabajo y
diferencias significativas en su grado de habilidad, creatividad, orden, consistencia y
espontaneidad. Algunos se comunican muy bien en forma escrita, otros no. Cockburn
argumenta que los modelos de procesos pueden “enfrentar las debilidades comunes de la
gente con disciplina o tolerancia (alguna de las dos)” (COCO2a), y que los modelos de proceso
más prescriptivos eligen la disciplina. Él establece: “Como la consistencia en la acción es una
debilidad humana, las metodologías que exigen un alto grado de disciplina son frágiles”
(COCO2a).
Los modelos de proceso funcionarán si proporcionan un mecanismo realista que fomente la
disciplina necesaria, o deben estar caracterizados de manera que muestren “tolerancia” por la
gente que realiza el trabajo de ingeniería de software. De manera invariable, la gente de
software adopta y sostiene más fácilmente las prácticas tolerantes, pero (como Cockburn lo
admite) tal vez sea menos productiva. Como la mayoría de las cosas en la vida, se deben
considerar los intercambios.

3
¿Qué es la agilidad?

¿Qué es la agilidad en el contexto del trabajo de la ingeniería del software? Ivar Jacobson
(JACO2) proporciona una definición útil:
Agilidad se ha convertido actualmente en la palabra de moda en cuanto se describe un
moderno proceso de software. Cualquiera es ágil. Un equipo ágil es un equipo rápido que
corresponde de manera apropiada a los cambios. Estos son en gran parte la materia de
desarrollo de software. Cambios en el software que se va a construir, cambios entre los
miembros del equipo, cambios debidos a las nuevas tecnologías, cambios de todo tipo que
pueden incidir en el producto que se construye o en el proyecto que crea el producto. En
cualquier actividad de software se debe incluir un soporte para los cambios, esto es algo que
adoptamos porque es el alma y el corazón del software. Un equipo ágil reconoce que el
software lo desarrollan individuos que trabajan en equipo y que las aptitudes de esta gente, y
su capacidad para colaborar, son esenciales para el éxito del proyecto.

De acuerdo con la visión de Jacobson, la insistencia en el cambio es el conductor primordial


hacia la agilidad. Los ingenieros de software deben tener pies veloces si quieren ajustarse a
los cambios rápidos que describe Jacobson.

“La agilidad es dinámica, con contenido específico, ajustable al cambio de manera


dinámica y orientada al crecimiento”.
Steven Goldman et al.

Pero la agilidad es más que una respuesta efectiva al cambio. También incluye la filosofía del
manifiesto enunciado al principio de este material. Estimula las estructuras y actitudes de los
equipos para que la comunicación (entre los miembros del equipo, entre los técnicos y la gente
de negocios, entre los ingenieros de software y sus gerentes) sea más fácil. Resalta la entrega
rápida de software operativo y le resta importancia a los productos de trabajo intermedio (lo
cual no siempre es bueno); adopta al cliente como una parte del equipo de desarrollo y trabaja
para eliminar la actitud del tipo “nosotros y ustedes” que aún perjudica a muchos proyectos

4
de software; reconoce que la planeación tiene sus límites en un mundo incierto y que el plan
de proyecto debe ser flexible.

La Alianza Ágil define 12 principios para quienes quieren alcanzar la agilidad:


1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua
de software valioso.
2. Bienvenidos los requisitos cambiantes, incluso en fases tardías del desarrollo. La
estructura de los procesos ágiles cambia para la ventaja competitiva del cliente.
3. Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un
par de meses, con una preferencia por la escala de tiempo mas corta.
4. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del
proyecto.
5. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte
que necesitan, y confiar en ellos para obtener el trabajo realizado.
6. El método más eficiente y efectivo de transmitir la información hacia y dentro de un
equipo de desarrollo es la conversación cara a cara.
7. El software en funcionamiento es la medida primaria de progreso.
8. Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores,
desarrolladores y usuarios deben ser capaces de mantener un paso constante de
manera indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad –el arte de maximizar la cantidad de trabajo no realizado – es esencial.
11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de
equipos autoorganizados.
12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo;
entonces su comportamiento se ajusta y adecua una concordancia.

La agilidad se puede aplicar en cualquier proceso de software. Sin embargo, para lograrlo es
esencial que el proceso sea diseñado en una forma que permita al equipo del proyecto
adaptar y coordinar las tareas, conducir la planeación en una forma que entienda la fluidez de
un enfoque de desarrollo ágil, eliminar todo pero no los productos de trabajo esenciales y
mantenerlos controlados, y enfatizar una estrategia de entrega incremental que proporcione
5
software en funcionamiento al cliente tan rápido como sea factible para el tipo de producto y el
ambiente operativo.
¿Qué es un proceso ágil?

Cualquier proceso ágil de software se caracteriza de una manera que refiere tres suposiciones
clave acerca de la mayoría de los proyectos de software:

1. Resulta difícil predecir cuales requisitos de software persistirán y cuales cambiarán. De


igual forma, es difícil presagiar cómo cambiarán las prioridades del cliente mientras se
ejecuta un proyecto.
2. Para muchos tipos de software, el diseño y la construcción están intercalados. Esto es,
ambas actividades se deben realizar de manera conjunta, de modo que los modelos de
diseño sean probados conforme se crean. Resulta difícil predecir cuánto diseño se
necesita antes de que la construcción se utilice para probar el diseño.
3. El análisis, el diseño y la construcción no son predecibles (desde el punto de vista de la
planeación), lo que sería deseable.

Dados los puntos anteriores surge una pregunta importante: ¿cómo se crea un proceso
susceptible de manipular en forma impredecible? La respuesta, como ya se ha puntualizado
antes, reside en la adaptabilidad del proceso (a un proyecto y a acondiciones técnicas que
cambian con rapidez). Por lo tanto, un proceso ágil debe ser adaptable.
Pero una adaptación continua sin un progreso logra muy poco. Por lo tanto, un progreso ágil
de software debe adaptarse de forma incremental. Para llevar a cabo una adaptación
incremental, un equipo ágil requiere de la retroalimentación con el cliente. Un catalizador
efectivo para la retroalimentación del cliente es un prototipo operacional o una porción de un
sistema operacional. Por lo tanto, debe instituirse una estrategia incremental de desarrollo.
Los incrementos de software (prototipos ejecutables o una porción de un sistema operacional)
deben entregarse en cortos periodos para que la adaptación mantenga un buen ritmo con el
cambio (imprevisibilidad). Este enfoque iterativo le permite al cliente evaluar el incremento del
software de manera regular, proporcionar la retroalimentación necesaria al equipo de
software, e influir sobre las adaptaciones del proceso que se realizan para adecuar la
retroalimentación.

6
“No existe un sustituto para la retroalimentación rápida, ni en el proceso de desarrollo
ni en el producto mismo”.
Martin Fowler

Las políticas del desarrollo ágil

Existe un debate considerable (a veces estridente) sobre los beneficios y la aplicabilidad del
desarrollo ágil del software como alternativa a procesos de ingeniería del software más
convencionales. Jim Highsmith (a manera de broma) analiza los extremos cuando caracteriza
el sentimiento del campo proagilidad (“agilitadores”). “Los metodólogos tradicionales son un
conjunto de tipos que se arrastran en el lodo y que prefieren producir documentación que no
fluye, en vez de un sistema de trabajo que cubra las necesidades del negocio.” Como
contraparte, establece la posición del campo de la ingeniería del software (de nuevo, en forma
de broma): “los metodólogos “ligeros” y “ágiles” son un conjunto de intrusos informáticos que
van a estar ahí para dar una maldita sorpresa cuando intenten elevar sus juguetes a nivel de
software de la empresa”.
Al igual que todos los argumentos sobre la tecnología de software, este debate sobre la
metodología corre el riesgo de degenerar en una guerra religiosa. Si estalla la guerra,
desaparece el pensamiento racional, y las creencias en vez de los hechos, guían la toma de
decisiones.
Nadie esta en contra de la agilidad. La pregunta real es: ¿Cuál es la mejor manera de lograrla?
Igual de importante es la pregunta: ¿cómo se construye un software que satisfaga hoy las
necesidades de los clientes y muestre las características de calidad que le permitan
extenderse y escalar para cubrir a largo plazo las necesidades del cliente?
No existen respuestas absolutas para ninguna de estas preguntas. Aun dentro de la escuela
ágil se han propuesto varios modelos de proceso, cada uno con un enfoque sutilmente
diferente para el problema de la agilidad. Dentro de cada modelo hay un conjunto de “ideas”
(que los agilitadores suelen llamar “tareas de trabajo”) que representan una separación
significativa de la ingeniería del software convencional. Y aun así, muchos conceptos de
agilidad son tan sólo adaptaciones de buenos conceptos de la ingeniería del software. Como
punto final hay mucho que ganar si se considera lo mejor de ambas escuelas, y nada que
ganar si se denigra alguno de los 2 enfoques.

7
NO ES NECESARIO ELEGIR ENTRE AGILIDAD E INGENIERIA DEL SOFTWARE. EN
LUGAR DE ELLO, SE PUEDE DEFINIR UN ENFOQUE DE INGENIERIA DE SOFTWARE
QUE SEA ÁGIL

Factores humanos
Los defensores del desarrollo ágil del software resaltan la importancia de los “factores de las
personas” en un desarrollo ágil exitoso. Como establecen Cockburn y Highsmith: “el desarrollo
ágil se centra en los talentos y las habilidades de los individuos, puesto que el proceso se
ajusta a las personas y equipos específicos”. El punto clave en esta afirmación es que el
proceso se ajusta a las necesidades de las personas y del equipo, y no al revés.

“Aquello apenas suficiente para un equipo es excesivo o insuficiente para otro”.


Alistair Cockburn

UN EQUIPO CON ORGANIZACIÓN PROPIA CONTROLA EL TRABAJO QUE


DESARROLLA. EL EQUIPO ESTABLECE SUS PROPIOS COMPROMISOS Y DEFINE LOS
PLANES PARA CUMPLIRLOS.

Si los miembros del equipo de software van a manejar las características del proceso que se
aplica para construirlo, debe existir un gran número de rasgos clave entre la gente de un
equipo ágil y el equipo mismo:

Competencia. En el contexto de un desarrollo ágil (al igual que en la ingeniería del software
convencional), la “competencia” abarca un talento innato, habilidades específicas relacionadas
con el software, y un conocimiento general del proceso que el equipo haya elegido aplicar. La
habilidad y el conocimiento del proceso pueden y deben enseñarse a toda la gente que
funge como miembro de un equipo ágil.
Enfoque común. Aunque los miembros del equipo ágil desempeñen tareas diferentes y
aporten distintas habilidades al proyecto, todos deben enfocarse en una meta: entregar al
cliente un incremento de trabajo de software dentro del tiempo establecido. Alcanzar

8
esta meta requiere que el equipo también se centre en adaptaciones continuas (pequeñas y
grandes) mediante las cuales el proceso satisfará las necesidades del equipo.
Colaboración. La ingeniería del software (sin considerar el proceso) incluye evaluar, analizar
y usar información que se comunica al equipo de software; crear información que ayudará al
cliente y a otros a entender el trabajo del equipo; y construir información (software de
computadora y bases de datos relevantes) que ofrezca un valor comercial para el cliente. Estas
tareas se cumplirán si los miembros del equipo colaboran, entre ellos, con el cliente y con sus
gerentes.
Habilidad para la toma de decisiones. Todo buen equipo de software (incluidos los equipos
ágiles) debe permitirse la libertad de controlar su propio destino. Esto implica que al equipo
se le dé autonomía, es decir, autoridad para tomar decisiones en cuanto a cuestiones
técnicas y del proyecto.
Capacidad de resolución de problemas confusos. Los gestores de software deben
reconocer que el equipo ágil enfrentará ambigüedades y sufrirá golpes de manera continua
debido al cambio. En algunos casos, el equipo debe aceptar que el problema que está
resolviendo hoy tal vez no sea el problema que deba resolver mañana. Sin embargo, las
lecciones aprendidas en cualquier actividad para la resolución de problemas (incluidas aquellas
que sirven para solucionar el problema erróneo) pueden beneficiar al equipo en fases
posteriores del proyecto.
Confianza y respeto mutuo. El equipo ágil se debe convertir en lo que De Marco y Lister
llaman un equipo “cuajado”. Un equipo cuajado muestra la confianza y el respeto necesarios
para que “se unan con tanta fuerza, que el todo sea mayor que la suma de las partes”
Organización propia. En el contexto del desarrollo ágil la organización propia implica tres
factores:
a) El equipo ágil se organiza a sí mismo para el trabajo que debe hacerse;
b) El equipo organiza el proceso que mejor se ajusta a su ambiente local;
c) El equipo organiza el programa de trabajo con el que se alcance de mejor manera la
entrega del incremento del software. La organización propia tiene varios beneficios
técnicos, pero lo más importante es que mejora la colaboración y eleva la moral del
equipo. En esencia, el equipo sirve como su propia gestoría. Ken Schwaber puntualiza
estos aspectos cuando escribe: “El equipo selecciona la cantidad de trabajo que
cree que es capaz de hacer dentro de la iteración, y el equipo se compromete con
el trabajo. Nada desalienta más a un equipo que alguien más se comprometa por
9
él. Nada motiva más a un equipo que aceptar la responsabilidad de cumplir los
compromisos que él mismo hizo”.

Equipos de sincronización y estabilización


Fuente: Ingeniería de software clásica y orientada a objetos. Stephen R. Shach.
Una alternativa de la organización de los equipos es el de sincronización y estabilización que
utiliza Microsoft (Cusumano y Selby, 1997). Microsoft construye productos grandes; por
ejemplo Windows 2000 consiste en más de 30 millones de líneas de código construidas por
aproximadamente 3000 programadores y probadores reutilizando una gran parte de Windows
NT 4.0 (Business Week Online, 1999). La organización de los equipos es un aspecto
fundamental de la construcción exitosa de un producto de este tamaño.

Los buenos resultados del modelo de ciclo de vida de sincronización y estabilización son, en
gran medida, una consecuencia del modo en que se organizan los equipos. Cada una de las
tres o cuatro construcciones sucesivas del modelo de sincronización y estabilización la
construyen diversos equipos pequeños paralelos, conducidos por un gerente, y constituidos por
tres a ocho desarrolladores, junto con tres a ocho probadores quienes trabajan uno a uno con
los desarrolladores. El equipo dispone de las especificaciones para realizar su tarea; cada uno
de los integrantes del equipo tiene la libertad para diseñar e implementar las partes de esa
tarea como desee. El motivo por el que este tipo de organización no se convierte en un caos
es el paso de sincronización que se realiza a diario: diariamente se prueban y depuran los
componentes parcialmente terminados. Así pues, aunque se nutre la creatividad y autonomía
individual, todos siempre trabajan juntos.

La fortaleza de este enfoque es que, por una parte, se estimula a cada uno de los
programadores para que sea creativo e innovador, una característica de un equipo
democrático. Por otra parte el paso de sincronización diaria garantiza que los cientos de
desarrolladores trabajen juntos hacia un objetivo común, sin necesidad de comunicación y
coordinación, características de un equipo con un programador jefe (figura 4.3)

10
Los desarrolladores de Microsoft deben seguir muy pocas reglas, pero una de éstas es que
deben apegarse estrictamente al tiempo establecido para introducir su código en la base de
datos del producto para la sincronización de ese día. Cusumano y Selby (1997) lo comparan
con decir a los niños que pueden hacer lo que gusten durante todo el día, pero tienen que
estar en la cama a las 9:00 p.m. Otra regla es que, si en cierto día el código de un
desarrollador impide que el producto sea compilado para la sincronización, el problema debe
solucionarse de inmediato, para que el resto del equipo pueda probar y depurar el trabajo de
ese día.
¿El uso del modelo del ciclo de vida de sincronización y estabilización y la organización del
equipo asociado garantizan que otra organización de software sea tan exitosa como Microsoft?
Esta situación es muy poco probable. Microsoft, Inc. es más que un modelo de sincronización y
estabilización, es una organización constituida por una serie de gerentes y desarrolladores de
software muy talentosos, con un ethos de grupo evolucionado. El simple uso del modelo de
sincronización y estabilización no convierte mágicamente a una organización en otra Microsoft.
Sin embargo, el uso de muchas de las características del modelo en otras organizaciones
podría conducir al mejoramiento en el proceso. Por otra parte, se ha sugerido que el modelo
de sincronización y estabilización es simplemente un modo de permitir a un grupo de hackers
desarrollar productos grandes, y que el éxito de Microsoft se debe a la magnífica
comercialización, más que a un software de calidad.

11
El modelo de Madurez de la Capacidad del Personal
Fuente: Ingeniería de software. Ian Sommerville.

El software Engineering Institute (SEI) en USA lleva a cabo un programa de largo plazo de
mejora del proceso del software. Parte de este programa es el Modelo de Madurez de la
Capacidad (CMM) para el proceso del software. Éste se refiere a las mejores prácticas en
ingeniería de software. Para soportar este modelo, también propusieron un Modelo de
Madurez de la Capacidad del personal (P-CMM) (Curtis et al., 1995). Este se puede utilizar
como un marco de trabajo para mejorar la forma en la que una organización administra sus
activos humanos.
De igual forma en la que una organización administra sus activos humanos.
De igual forma que el CMM, el P-CMM es un modelo de 5 niveles como se muestra en la
siguiente figura:

12
El modelo de capacidad de madurez del personal
Los 5 niveles son:
1. Inicial. Ad hoc, se utilizan prácticas informales de administración de personal.
2. Repetible. Establece las políticas para el desarrollo de la capacidad del personal.
3. Definido. Estandarización de las mejores prácticas de administración de personal a lo
largo de la organización.
4. Administrado. Se establecen e introducen las metas cuantitativas para la
administración del personal.
5. Optimizado. Existe un enfoque continuo en la mejora de la competencia individual y la
motivación de la fuerza de trabajo.

Curtis et al. señalan que los objetivos estratégicos del P-CMM son:
1. Mejorar la capacidad de las organizaciones de software incrementando la capacidad de
su fuerza de trabajo;

13
2. Asegurar que la capacidad de desarrollo de software sea una atributo de las
organizaciones más que de pocos individuos;
3. Alinear la motivación de los individuos con la de la organización;
4. Retener los activos humanos (por ejemplo, personas con habilidades y conocimiento
importantes) dentro de la organización.

El P-CMM es una herramienta práctica para mejorar la administración de las personas en una
organización ya que suministra un marco de trabajo para motivar, reconocer estandarizar y
mejorar las buenas prácticas. Refuerza la necesidad de reconocer la importancia de las
personas como individuos y de desarrollar sus capacidades. Por supuesto, la aplicación
completa de este modelo es muy extensa y probablemente innecesaria para muchas
organizaciones. Sin embargo, el modelo es una guía de ayuda que puede conducir a mejoras
importantes en la capacidad de las organizaciones para producir software de alta calidad.

14

You might also like