Desarrollo Ágil

RESUMEN DEL LIBRO: Ingeniería de Software. Roger S. Presuman.
Capitulo 4.- DESARROLLO ÁGIL


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 oftware convencional. El desarrollo ágil proporciona beneficios importantes, pero es imposible aplicarlo en todos los proyectos, productos, personas y situaciones.



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 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.

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.


¿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 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 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.


“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.
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.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 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 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 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 DeMarco 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 que 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 él. Nada motiva más a un equipo que aceptar la responsabilidad de cumplir los compromisos que él

Como conclusion: El Desarrollo ágil no deja de ser una tendencia metodológica para el desarrollo de nuevos proyectos.
Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento"