2. Manifiesto Ágil
Las metodologías ágiles son métodos de desarrollo
de software en los que las necesidades y soluciones
evolucionan a través de una colaboración estrecha
entre equipos multidisciplinarios.
Se caracterizan por enfatizar la comunicación frente
a la documentación, por el desarrollo evolutivo y
por su flexibilidad.
3. Manifiesto Ágil
Estas metodologías surgen a mediados de los años
90, en respuesta a los modelos de proceso clásicos
ya existentes.
La aparición de procesos ágiles se debe al hecho de
haber encontrado supuestos clave en desarrollos
precedentes:
4. Manifiesto Ágil
1. Es difícil predecir qué requisitos persistirán y cuáles
cambiarán, así como las prioridades del cliente.
2. El diseño y el desarrollo de software están
intercalados. Por ello se realizarán conjuntamente,
probando el diseño a medida que se crea, pues es
complicado predecir cuánto diseño es necesario
antes de llegar a implementarlo.
3. El análisis, el diseño y la implementación no son
predecibles desde el punto de vista de la
planificación.
5. Manifiesto Ágil
El 17 de febrero de 2001, Kent Beck (creador de
Extreme Programming) reunió a diecisiete críticos de
los modelos de del desarrollo de software basados
en procesos. El objetivo de la reunión: tratar sobre
técnicas y procesos para desarrollar software.
6. Manifiesto Ágil
En la reunión se acuñó el término “Métodos Ágiles”
para definir a los métodos que estaban surgiendo
como alternativa a las metodologías formales, a las
que consideraban excesivamente “pesadas” y rígidas
por su carácter normativo y fuerte dependencia de
planificaciones detalladas previas al desarrollo.
7. Manifiesto Ágil - Valores
Los integrantes de la reunión resumieron los
principios sobre los que se basan los métodos
alternativos en cuatro postulados, lo que ha
quedado denominado como Manifiesto Ágil.
8. Manifiesto Ágil - Valores
“Valorar más a los individuos y su interacción que a
los procesos y las herramientas”
Si bien es cierto que los procesos ayudan al trabajo,
son una guía de operación y que las herramientas
mejoran la eficiencia. Más importantes son las
personas con conocimiento técnico y actitud
adecuada, que son las que producen resultados.
9. Manifiesto Ágil - Valores
“Valorar más a los individuos y su interacción que a
los procesos y las herramientas”
La defensa a ultranza de los procesos lleva a
postular que con ellos se pueden conseguir
resultados extraordinarios con personas mediocres,
y lo cierto es que este principio es peligroso cuando
los trabajos necesitan creatividad e innovación.
10. Manifiesto Ágil - Valores
“Valorar más el software que funciona que la
documentación exhaustiva”
Poder ver anticipadamente cómo se comportan las
funcionalidades esperadas sobre prototipos o sobre
las partes ya elaboradas del sistema final ofrece una
retroalimentación muy estimulante y enriquecedora
que genera ideas imposibles de concebir en un
primer momento.
11. Manifiesto Ágil - Valores
“Valorar más el software que funciona que la
documentación exhaustiva”
Es muy difícil conseguir un documento que
contenga todos los requisitos detallados antes de
comenzar el proyecto.
12. Manifiesto Ágil - Valores
“Valorar más el software que funciona que la
documentación exhaustiva”
El manifiesto no afirma que no hagan falta. Los
documentos sirven de soporte, transmiten
conocimiento, registran información, y en muchas
cuestiones legales o normativas son obligatorios,
pero se resalta que son menos importantes que los
productos que funcionan.
13. Manifiesto Ágil - Valores
“Valorar más la colaboración con el cliente que la
negociación contractual”
Un contrato no aporta valor al producto. Es una
formalidad que establece líneas divisorias entre
responsabilidades, que fija los referentes para
posibles disputas contractuales entre cliente y
proveedor.
14. Manifiesto Ágil - Valores
“Valorar más la colaboración con el cliente que la
negociación contractual”
En el desarrollo ágil el cliente es un miembro más
del equipo, que se integra y colabora en el grupo de
trabajo.
15. Manifiesto Ágil - Valores
“Valorar más la respuesta al cambio que el
seguimiento de un plan”
Para un modelo de desarrollo que surge de entornos
inestables, que tienen como factor inherente el
cambio y la evolución rápida y continua, resulta
mucho más valiosa la capacidad de respuesta que la
de seguimiento y aseguramiento de planes pre-
establecidos
16. Manifiesto Ágil - Valores
“Valorar más la respuesta al cambio que el
seguimiento de un plan”
Los principales valores de la gestión ágil son la
anticipación y la adaptación; diferentes a los de la
gestión de proyectos ortodoxa: planificación y
control para evitar desviaciones sobre el plan.
17. Manifiesto Ágil - Principios
1. Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de
software con valor.
2. Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
18. Manifiesto Ágil - Principios
3. Entregamos software funcional frecuentemente,
entre dos semanas y dos meses, con preferencia
al periodo de tiempo más corto posible.
4. Los responsables de negocio y los
desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
19. Manifiesto Ágil - Principios
5. Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
20. Manifiesto Ágil - Principios
7. El software funcionando es la medida principal
de progreso.
8. Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y
usuarios debemos ser capaces de mantener un
ritmo constante de forma indefinida.
21. Manifiesto Ágil - Principios
9. La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
22. Manifiesto Ágil - Principios
12. A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en
consecuencia.
24. Extreme Programming (XP)
La programación extrema o eXtreme Programming
(XP) es un enfoque de la ingeniería de software
formulado por Kent Beck, autor del primer libro
sobre la materia, Extreme Programming Explained:
Embrace Change (1999).
25. Extreme Programming (XP)
Se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los
defensores de XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de
proyectos
26. Extreme Programming (XP)
Creen que ser capaces de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto
es una aproximación mejor y más realista que
intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos después en controlar
los cambios en los requisitos.
27. XP - Objetivos
1. Establecer las mejores prácticas de Ingeniería de
Software en los desarrollo de proyectos.
2. Mejorar la productividad de los proyectos.
3. Garantizar la Calidad del Software desarrollando,
haciendo que este supere las expectativas del
cliente.
28. XP - Prácticas
1. Equipo completo: Forman parte del equipo todas
las personas que tienen algo que ver con el
proyecto, incluido el cliente y el responsable del
proyecto.
2. Planificación: Se hacen las historias de usuario y
se planifica en qué orden se van a hacer y las
mini-versiones. La planificación se revisa
continuamente.
29. XP - Prácticas
3. Test del cliente: El cliente, con la ayuda de los
desarrolladores, propone sus propias pruebas para
validar las mini-versiones.
4. Versiones pequeñas: Las mini-versiones deben ser lo
suficientemente pequeñas como para poder hacer
una cada pocas semanas. Deben ser versiones que
ofrezcan algo útil al usuario final y no trozos de
código que no pueda ver funcionando.
30. XP - Prácticas
5. Diseño simple: Hacer siempre lo mínimo
imprescindible de la forma más sencilla posible.
Mantener siempre sencillo el código.
6. Pareja de programadores: Los programadores
trabajan por parejas (dos delante del mismo
ordenador) y se intercambian las parejas con
frecuencia (un cambio diario).
31. XP - Prácticas
7. Desarrollo guiado por las pruebas automáticas: Se
deben realizar programas de prueba automática y deben
ejecutarse con mucha frecuencia. Cuantas más pruebas
se hagan, mejor.
8. Integración continua: Deben tenerse siempre un
ejecutable del proyecto que funcione y en cuanto se
tenga una nueva pequeña funcionalidad, debe
recompilarse y probarse. Es un error mantener una
versión congelada dos meses mientras se hacen mejoras
y luego integrarlas todas de golpe. Cuando falle algo, no
se sabe qué es lo que falla de todo lo que hemos metido.
32. XP - Prácticas
9. El código es de todos: Cualquiera puede y debe
tocar y conocer cualquier parte del código. Para
eso se hacen las pruebas automáticas.
10. Normas de codificación: Debe haber un estilo
común de codificación (no importa cual), de
forma que parezca que ha sido realizado por una
única persona.
33. XP - Prácticas
11. Metáforas: Hay que buscar unas frases o nombres
que definan cómo funcionan las distintas partes del
programa, de forma que sólo con los nombres se
pueda uno hacer una idea de qué es lo que hace cada
parte del programa. Un ejemplo claro es el
"recolector de basura" de java. Ayuda a que todos los
programadores (y el cliente) sepan de qué estamos
hablando y que no haya mal entendidos.
34. XP - Prácticas
12. Ritmo sostenible: Se debe trabajar a un ritmo que se
pueda mantener indefinidamente. Esto quiere decir
que no debe haber días muertos en que no se sabe
qué hacer y que no se deben hacer un exceso de
horas otros días. Al tener claro semana a semana lo
que debe hacerse, hay que trabajar duro en ello para
conseguir el objetivo cercano de terminar una
historia de usuario o mini-versión.
35. XP - Planificación
La planificación en XP responde dos preguntas clave
del desarrollo de software: predecir qué se habrá
terminado para la fecha de entrega, y determinar
qué hacer después. Se hace énfasis en guiar al
proyecto -que es bastante directo- en vez de predecir
exactamente lo que se necesitará y cuánto tiempo
tomará hacerlo -que es bastante dificil.
Hay dos pasos claves en la planificación de XP:
36. XP - Planificación
Planificación de la Entrega, es una práctica en donde el Cliente
presenta las características deseadas a los programadores, y los
programadores estiman la dificultad. Teniendo las estimaciones de
costo, y sabiendo la importancia de las características, el Cliente
establece un plan para el proyecto. Los planes iniciales de entregas
son necesariamente imprecisos: ni las prioridades ni las estimaciones
son sólidas, y tampoco sabremos qué tan rápido trabaja el equipo
hasta que empiece a trabajar. Sin embargo, incluso el primer plan de
entrega es lo suficientemente preciso como para tomar decisiones, y
el equipo XP revisa de forma regular el plan.
37. XP - Planificación
Planificación de la Iteración; es la práctica en donde el equipo
establece el rumbo cada un par de semanas. Los equipos XP
construyen software en iteraciones de dos semanas, y entregan
software útil al finalizar cada iteración. Durante la Planificación de
la Iteración, el Cliente presenta las características deseadas para las
siguientes dos semanas. Los programadores las descomponen en
tareas, y estiman su costo (a un nivel de detalle más fino que
durante la Planificación de la Entrega). El equipo entonces se
compromente a terminar ciertas características basándose en la
cantidad de trabajo que pudieron terminar en la iteración anterior.
38. XP - Planificación
Estos pasos de planificación son muy simples, y le brindan al cliente muy
buena información y excelente flexibilidad para guiar al proyecto.
Cada dos semanas se hace completamente visible el progreso. No existe
el "90% terminado" en XP: una historia está terminada, o no lo está.
Este foco en la transparencia resulta en una paradoja: por un lado, con
tanta visibilidad, el Cliente está en la posición de cancelar el proyecto si
el progreso no es suficiente. Por otro lado, como el progreso es tan
visible, y hay completa libertad para decidir qué se hará después, los
proyectos XP tienden a entregar más de lo necesario, con menos presión
y estrés.
40. DSDM
Provee un framework para el desarrollo ágil de
software, apoyado por LA continua implicación del
usuario en un desarrollo iterativo y creciente que sea
sensible a los requerimientos cambiantes, para
desarrollar un sistema que reúna las necesidades de
la empresa en tiempo y presupuesto.
41. DSDM
Fue desarrollado en el Reino Unido en los años 90 por un
consorcio de proveedores y de expertos en la materia del
desarrollo de sistemas de información, combinando sus
experiencias de mejores prácticas.
El consorcio DSDM es una organización no lucrativa y
proveedor independiente, que posee y administra el
framework.
La primera versión fue terminada en enero de 1995 y
publicada en febrero de 1995.
42. DSDM - CICLO DE VIDA
Consiste en 3 fases: fase del pre-proyecto, fase del ciclo
de vida del proyecto, y fase del post-proyecto.
La fase del ciclo de vida del proyecto se subdivide en 5
etapas:
1. Estudio de viabilidad,
2. Estudio de la empresa,
3. Iteración del modelo funcional,
4. Diseño e iteración de la estructura
5. Implementación.
43. DSDM - CICLO DE VIDA
DSDM reconoce que los proyectos están limitados
por el tiempo y los recursos, y los planes acorde a las
necesidades de la empresa.
44. DSDM - PRINCIPIOS
Involucrar al cliente es la clave para llevar un proyecto
eficiente y efectivo, donde ambos, cliente y
desarrolladores, comparten un entorno de trabajo para
que las decisiones puedan ser tomadas con precisión.
El equipo del proyecto debe tener el poder para tomar
decisiones que son importantes para el progreso del
proyecto, sin esperar aprobación de niveles superiores.
45. DSDM - PRINCIPIOS
DSDM se centra en la entrega frecuente de productos,
asumiendo que entregar algo temprano es siempre mejor
que entregar todo al final. Al entregar el producto
frecuentemente desde una etapa temprana del proyecto, el
producto puede ser verificado y revisado allí donde la
documentación de registro y revisión puede ser tenida en
cuenta en la siguiente fase o iteración.
46. DSDM - PRINCIPIOS
El principal criterio de aceptación de entregables en DSDM
reside en entregar un sistema que satisface las actuales
necesidades de negocio. No está dirigida tanto a
proporcionar un sistema perfecto que resuelva todas las
necesidades posibles del negocio, sino que centra sus
esfuerzos en aquellas funcionalidades críticas para alcanzar
las metas establecidas en el proyecto/negocio.
47. DSDM - PRINCIPIOS
El desarrollo es iterativo e incremental, guiado por la realimentación de los
usuarios para converger en una solución de negocio precisa.
Todos los cambios durante el desarrollo son reversibles.
El alcance de alto nivel y los requerimientos deberían ser base-lined antes de
que comience el proyecto.
Las pruebas son realizadas durante todo el ciclo vital del proyecto. Esto tiene
que hacerse para evitar un caro coste extraordinario en arreglos y
mantenimiento del sistema después de la entrega.
La comunicación y cooperación entre todas las partes interesadas en el
proyecto es un prerrequisito importante para llevar un proyecto efectivo y
eficiente.
48. DSDM – PRESUNCIONES
Ningún sistema es construido a la perfección en el primer intento
(El principio de Pareto - regla 80/20). En el proceso de desarrollar
un sistema de información, el 80% del beneficio de la empresa
proviene del 20% de los requisitos del sistema, así DSDM comienza
implementando primero este 20% de requisitos para cumplir con el
80% de las necesidades de la empresa, lo que es suficientemente
bueno tanto en cuanto los usuarios estén íntimamente involucrados
en el proceso de desarrollo y en una posición de asegurar que el
20% restante no causará serias consecuencias al negocio.
Implementar la totalidad de requerimientos a menudo causa que
un proyecto supere plazos y presupuestos, así la mayoría de las
veces es innecesario construir la solución perfecta.
49. DSDM – PRESUNCIONES
La entrega del proyecto debería ser a tiempo, respetando
presupuestos y con buena calidad.
DSDM solo requiere que cada paso del desarrollo se
complete lo suficiente como para que empiece el
siguiente paso. De este modo una nueva iteración del
proyecto puede comenzar sin tener que esperar a que la
previa se complete enteramente. Y con cada nueva
iteración el sistema se mejora incrementalmente.
Recuérdese que las necesidades del negocio cambian
constantemente y a cualquier ritmo con el tiempo.
50. DSDM – PRESUNCIONES
Ambas técnicas de Desarrollo y Gestión del proyectos están incluidas en DSDM.
Además de desarrollar nuevos SI, DSDM puede ser usado también en proyectos
de ampliación de sistemas TI actuales o incluso en proyectos de cambio no
relacionados con las TI.
La Evaluación de riesgos debiera centrarse en entregar función de negocio, no
en el proceso de construcción.
La gestión recompensa la entrega de productos más que la consecución de
tareas.
La Estimación debería estar basada en la funcionalidad del negocio en lugar de
líneas de código.
