jueves, 15 de octubre de 2009

Metodologias Agiles de Desarrollo

Metodologías Ágiles de desarrollo de software

Este en esta primera parte se describen las principales características de de las metodologías ágiles, expresadas en el Manifiesto, sus ventajas y desventajas, así como algunos casos donde no conviene usar métodos ágiles.
Hoy en día con el auge de la tecnología, y con el objetivo de agilizar y automatizar los procesos en el desarrollo de software, nos vemos en la necesidad de implantar Metodologías de Desarrollo de Software que nos ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologías ágiles de desarrollo de software han despertado interés gracias a que proponen simplicidad y velocidad para crear sistemas. Las metodologías tradicionales no se adaptan a las nuevas necesidades o expectativas que tienen los usuarios hoy en día, en parte que los métodos usados no son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos cambios generalmente implican altos costos, demanda de tiempo y la reestructuración total del proyecto que se esté llevando; en contraparte, los métodos ágiles permiten un desarrollo iterativo y adaptable que permite la integración de nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el cliente como el desarrollador queden satisfechos porque el producto final tiene una calidad adecuada.
Un proceso es ágil cuando el desarrollo de software es:
- Incremental. Entregas pequeñas de software, con ciclos rápidos.
- Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación.
- Sencillo. El método en sí mismo es simple, fácil de aprender y modificar.
- Esta bien documentado y es adaptable. Permite realizar cambios de último momento).

Sus elementos claves son:

– Poca documentación
– Simplicidad
– Análisis como una actividad constante
– Diseño evolutivo
– Integraciones
– Testeos diarios


Cuando usar metodologías ágiles

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema). Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi adecuada para una gran cantidad de proyectos. Sin embargo existen métodos más generales y con mejores resultados que otros. Saber qué reglas y metodologías aplicar en cada caso es más importante y útil que seguir ciegamente siempre las mismas.
Las propias prácticas de los métodos ágiles limitan o descartan su uso en algunos proyectos. A continuación se detallan algunos casos donde no conviene usar métodos ágiles.
Las propias prácticas de los métodos ágiles limitan o descartan su uso en algunos proyectos. A continuación se detallan algunos casos donde no conviene usar métodos ágiles.

-Aplicaciones distribuidas. Las pruebas unitarias son complicadas de aplicar entre componentes. Sería necesario construir una arquitectura de pruebas para probar directamente los componentes, que podría ser tan complicada como el sistema que se desea construir.
-Aplicaciones que requieren seguir un diseño estricto. Por ejemplo: sistemas operativos, software de telecomunicaciones.
-Aplicaciones que requieren una documentación exhaustiva. Por ejemplo: sistemas militares, médicos o industriales.
-Aplicaciones basadas fundamentalmente en interfaces gráficas de usuario: No es fácil aplicar pruebas unitarias a las interfaces gráficas.
-Aplicaciones con código heredado. Habría que reescribir todo el código heredado siguiendo los principios ágiles.
-Proyectos muy grandes. La comunicación entre los miembros del equipo es difícil de conseguir.
-Proyectos escritos en lenguajes no orientados a objetos. Lenguajes como C, Pascal, Cobol o Fortran hacen imposible técnicas como la refactorización.
-Aplicaciones donde la escalabilidad o la eficacia sean importantes. La escalabilidad o la eficacia no son características que se pueden añadir durante el proceso del desarrollo del software o que puedan obtenerse refactorizando: deben considerarse desde un principio.

Ventajas de las metodologías ágiles

Las metodologías ágiles presentan diversas ventajas como:

-Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
-Entrega continua y en plazos cortos de software funcional.
-Trabajo conjunto entre el cliente y el equipo de desarrollo.
-Minimiza los costos frente a cambios.
-Importancia de la simplicidad, al eliminar el trabajo innecesario.
-Atención continua a la excelencia técnica y al buen diseño.
-Mejora continua de los procesos y el equipo de desarrollo.
-Evita malentendidos de requerimientos entre el cliente y el equipo.
-El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente.
-Cada componente del producto final ha sido probado y satisface los requerimientos.

Problemas comunes a los métodos ágiles.

Como en cualquiera otra metodología, también hay desventajas y problemas que surgen a la hora de implementarlas:

-Falta de documentación del diseño. El código no puede tomarse como una documentación. En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de código fuente.
-Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
-Falta de calidad. Probar el código de forma constante no genera productos de calidad, sólo revela falta de análisis y diseño.
-Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los diseños convencionales, los proyectos ágiles dependen críticamente de las personas.
-Falta de procesos de revisión del código. Con métodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programación en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador.
-Falta de reusabilidad. La falta de documentación hacen difícil que pueda reutilizarse el código ágil.
-Sobre costos y retrasos derivados de la refactorización continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorización no pueden despreciarse.
-Restricciones en cuanto a tamaño de los proyectos abordables.
-Rigidez. Algunos métodos ágiles son muy rígidos: deben cumplirse muchas reglas de una forma estricta para garantizar el éxito del proyecto. Por ejemplo XP exige en realidad mucho esfuerzo, concentración y orden.
-Cambios. Los modelos de datos son “pesados” y no pueden cambiarse así como así solo porque el cliente que ira incorporar más funciones al sistema.
-Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.

Manifiesto de las Metodologías Ágiles

A principios de 2001 se reunieron los representantes de cada una de las metodologías ágiles, había mucho en común entre estas metodologías, utilizando el término “Ágil” como definición común a todas ellas. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. De esta forma, crearon lo que acordaron en llamar: el manifiesto para desarrollo de software ágil.
El Manifiesto comienza enumerando los principales valores del desarrollo ágil.
1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Si se sigue un buen proceso de desarrollo, pero el equipo falla, el éxito no está asegurado; sin embargo, si el equipo funciona, es más fácil conseguir el objetivo final, aunque no se tenga un proceso bien definido.
2. Desarrollar software que funciona más que conseguir una buena documentación. Aunque se parte de la base de que el software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
3. La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.
4. Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta. Para poder adaptarse a los cambios que puedan surgir.
El resultado es un Manifiesto para el Desarrollo de Software Ágil, una declaración de los principios y valores comunes de los procesos ágiles.
El manifiesto fue sólo eso, una publicación que actuó como un punto de partida para aquellos que compartían estas ideas básicas. Algunos de los principios más importantes definidos en este manifiesto son:
-Interacción personal de individuos por sobre los procesos y las herramientas.
-Trabajar con el código por sobre documentación escrita.
-La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
-Responder al cambio antes que seguir y mantener un plan.
-La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor.
-Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente.
-La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
-La simplicidad es esencial.

1 comentario: