Lunes 30 de junio 2014
Un modelo de desarrollo ágil, generalmente es un proceso Incremental, (pequeños y frecuentes releases o entregas con ciclos rápidos), también Cooperativo (Clientes y desarrolladores trabajan constantemente con una comunicación muy fina y constante), sencillo (El método es fácil de aprender y modificar para el equipo, es bien documentado por medio de libros o la Web) y finalmente adaptativo (capaz de permitir cambios de último momento).
Cualquier proceso del software ágil se caracteriza por la forma en la que aborda cierto número de suposiciones acerca de la mayoría de proyectos de software:
Dadas estas tres suposiciones, surge una pregunta importante: ¿cómo crear un proceso que pueda manejar lo impredecible? La respuesta, como ya se dijo, está en la adaptabilidad del proceso (al cambio rápido del proyecto y a las condiciones técnicas). Por tanto, un proceso ágil debe ser adaptable.
Pero la adaptación continua logra muy poco si no hay avance. Entonces, un proceso de software ágil debe adaptarse incrementalmente. Para lograr la adaptación incremental, un equipo ágil requiere retroalimentación con el cliente (de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador eficaz para la retroalimentación con el cliente es un prototipo operativo o una porción de un sistema operativo. Así, debe instituirse una estrategia de desarrollo incremental. Deben entregarse incrementos de software (prototipos ejecutables o porciones de un sistema operativo) en periodos cortos de tiempo, de modo que la adaptación vaya a ritmo con el cambio (impredecible). Este enfoque iterativo permite que el cliente evalúe en forma regular el incremento de software, dé la retroalimentación necesaria al equipo de software e influya en las adaptaciones del proceso que se realicen para aprovechar la retroalimentación.
Un modelo de desarrollo ágil, generalmente es un proceso Incremental, (pequeños y frecuentes releases o entregas con ciclos rápidos), también Cooperativo (Clientes y desarrolladores trabajan constantemente con una comunicación muy fina y constante), sencillo (El método es fácil de aprender y modificar para el equipo, es bien documentado por medio de libros o la Web) y finalmente adaptativo (capaz de permitir cambios de último momento).
Cualquier proceso del software ágil se caracteriza por la forma en la que aborda cierto número de suposiciones acerca de la mayoría de proyectos de software:
- Es difícil predecir qué requerimientos de software persistirán y cuáles cambiarán. También es difícil pronosticar cómo cambiarán las prioridades del cliente a medida que avanza el proyecto.
- Para muchos tipos de software, el diseño y la construcción están imbricados. Es decir, ambas actividades deben ejecutarse en forma simultánea, de modo que los modelos de diseño se prueben a medida que se crean. Es difícil predecir cuánto diseño se necesita antes de que se use la construcción para probar el diseño.
- El análisis, el diseño, la construcción y las pruebas no son tan predecibles como nos gustaría (desde un punto de vista de planeación).
Dadas estas tres suposiciones, surge una pregunta importante: ¿cómo crear un proceso que pueda manejar lo impredecible? La respuesta, como ya se dijo, está en la adaptabilidad del proceso (al cambio rápido del proyecto y a las condiciones técnicas). Por tanto, un proceso ágil debe ser adaptable.
Pero la adaptación continua logra muy poco si no hay avance. Entonces, un proceso de software ágil debe adaptarse incrementalmente. Para lograr la adaptación incremental, un equipo ágil requiere retroalimentación con el cliente (de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador eficaz para la retroalimentación con el cliente es un prototipo operativo o una porción de un sistema operativo. Así, debe instituirse una estrategia de desarrollo incremental. Deben entregarse incrementos de software (prototipos ejecutables o porciones de un sistema operativo) en periodos cortos de tiempo, de modo que la adaptación vaya a ritmo con el cambio (impredecible). Este enfoque iterativo permite que el cliente evalúe en forma regular el incremento de software, dé la retroalimentación necesaria al equipo de software e influya en las adaptaciones del proceso que se realicen para aprovechar la retroalimentación.
COMPARACIÓN DE MÉTODOS ÁGILES Y TRADICIONALES
PROGRAMACIÓN EXTREMA (XP)
A fin de ilustrar un proceso ágil con más detalle, daremos un panorama de la programación extrema (XP), el enfoque más utilizado del desarrollo de software ágil. Aunque las primeras actividades con las ideas y los métodos asociados a XP ocurrieron al final de la década de 1980, el trabajo fundamental sobre la materia había sido escrito por Kent Beck. Una variante de XP llamada XP industrial [IXP] se propuso en una época más reciente. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes.
VALORES XP
Se define un conjunto de cinco valores que establecen el fundamento para todo trabajo realizado como parte de XP: comunicación, simplicidad, retroalimentación, valentía y respeto. Cada uno de estos valores se usa como un motor para actividades, acciones y tareas específicas de XP.
PROCESO DE XP
CONCLUSIÓN
La programación extrema puede aportar nuevas formas de buscar y optimizar el modelo de desarrollo de software libre.
Pruebas, metáfora y refactorización son prácticas que serian interesantes plasmar mas formalmente en el desarrollo libre ceñido a la aplicación de Xp.
Los resultados en distintos proyectos del paradigma demuestran que es un complemento valioso a los múltiples métodos de desarrollo de software en los últimos años.
Los enfoques de métodos de agilidad tienen la distinción de que los últimos operan de modo geográficamente distribuido y por ende se toma al cliente en los procesos Oss como un codesarrollador.
No hay comentarios:
Publicar un comentario