desarrollo agil

1. Los métodos ágiles se desarrollaron en
un intento por superar las debilidades
advertidas y reales en IS convencional.
El desarrollo ágil proporciona
beneficios importantes, pero es
imposible aplicarlo en todos los
proyectos, productos, personas y
situaciones.
2

2. La IS á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 del software
incremental; equipos de proyectos
pequeños y con alta motivación; métodos
informales; un mínimo de productos de
trabajo de la IS; y una simplicidad
general de desarrollo. Las directrices
hacen referencia al Análisis y Diseño.
3

3. El desarrollo ágil puede llamarse con
mayor precisión “ingeniería de
software ligera”. Las actividades
básicas del marco de trabajo se
conservan, pero éstas se conforman
como un conjunto mínimo de tareas que
empujan al equipo de proyecto hacia la
construcción y la entrega.
4

4. Qué es la agilidad?
Un equipo ágil es un equipo
rápido que responde de
manera apropiada a los
“cambios”:
Cambios en el software
que se va a construir;
Cambios entre los
miembros del equipo;
Cambios debidos a las
NTIC.
5

5. Un equipo ágil reconoce que el Sw lo
desarrollan individuos y que las aptitudes
y su capacidad para colaborar, son
esenciales para el éxito del proyecto.
Para quienes quieren alcanzar la agilidad,
se define 12 principios:
1) La mayor prioridad es satisfacer al
cliente mediante la entrega temprana
del Software;
2) Bienvenidos los requisitos cambiantes,
incluso en fases tardías del desarrollo;
6

6. 3) Entregar Sw en funcionamiento, con
escala de tiempo lo más corta posible;
4) La gente de negocios y los
desarrolladores deben trabajar juntos a
diario;
5) Construir proyectos alrededor de
individuos motivados;
6) Incentivar la conversación cara a cara;
7) El Sw en funcionamiento es la medida
primaria de progreso;
7

7. 8) Los procesos ágiles promueven el
desarrollo sustentable;
9) La atención continúa a la excelencia
técnica y al buen diseño mejora la
agilidad;
10) La simplicidad es esencial
11) Las mejores arquitecturas, requisitos
y diseños emergen de equipos
autoorganizados;
12) Los equipos se vuelven más efectivos
a intervalos regulares.
8

8. Según Fowler. Cualquier proceso ágil de
software, se caracteriza por 3
suposiciones:
1. Resulta difícil predecir cuáles
requisitos del software persistirán y
cuáles cambiarán. También es difícil
presagiar cómo cambiarán las
prioridades del cliente mientras se
ejecuta un proyecto.
Qué es un proceso ágil ?
9

9. 2. El diseño y la construcción se deben
realizar de manera conjunta, de
modo que los modelos de diseño
sean probados conforme se crean.
Difícil predecir cuanto diseño se
necesita antes de que la
construcción se utilice para probar el
diseño.
3. El análisis, diseño y la construcción
no son predecibles.
10

10. Un proceso ágil de software debe ser
adaptable en forma incremental.
Para la adaptación incremental, un
equipo ágil requiere de 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.
11

11. El desarrollo ágil, según Cockburn, se
centra en los talentos y las habilidades de
los individuos, puesto que el proceso se
ajusta a personas y equipos específicos.
Si los miembros del equipo de software
van a manejar las características del
proceso que se aplica para construirlo,
debe existir rasgos clave entre los “ágiles”
y los demás miembros del equipo
Factores humanos
12

12. Los rasgos son los siguientes:
Competencia;
Enfoque común;
Colaboración;
Habilidad para la toma de decisiones;
Capacidad de resolución de problemas
confusos;
Confianza y respeto mutuo;
Organización propia.
13

13. Modelos ágiles de proceso
La historia de la IS está llena de decenas
de descripciones y metodologías, métodos
de modelado y notaciones, herramientas y
tecnologías obsoletas. Cada elemento
surgió con notoriedad y después lo eclipsó
algo nuevo y mejor.
Los modelos ágiles se ajustan al manifiesto
para el desarrollo de software y a los 12
principios detallados con anterioridad.
14

14. La XP, es una
metodología para el
desarrollo de
proyectos software
que trata de dar
solución a los
problemas de la IS
desde un enfoque
distinto al
tradicional. 15

15. La XP, recibe este calificativo porque
defiende un enfoque radical.
Reconoce las bondades de las
prácticas de las metodologías
tradicionales y propone llevarlas
hasta su extremo:
“Si diseñar es bueno, diseñemos
todo el tiempo”
“Si las pruebas son buenas,
probemos todo el tiempo”
16

16. La XP utiliza un enfoque OO, como su
paradigma de desarrollo preferido. La
XP abarca un conjunto de reglas y
prácticas que ocurren en el contexto
de 4 actividades del marco de trabajo:
Planeación;
Diseño;
Codificación;
Prueba.
17

17. Planeación
diseño
codificación
prueba
Incremento de software
velocidad calculada
del proyecto
Lanzamiento
Historias del usuario
valores
criterios de las pruebas de iteración
Plan de iteración
Diseño simple
cartas CRC
Soluciones pico
prototipos
Programación
en pareja
Integración continua
Prueba de unidad
Pruebas de aceptación
refabricación
Proceso de desarrollo extremo
18

18. Comunicación. Para ser efectiva,
debe involucrar a todos los
participantes en el proyecto, y debe
ser libre y sincera;
Simplicidad. Nunca debe perderse
de vista que el objetivo de un
proyecto es proporcionar valor al
cliente; no es demostrar la pericia
técnica del equipo ni construir una
aplicación que resuelva más
problemas que los del cliente;
Valores
19

19. Refabricación. No se puede dirigir
adecuadamente un proceso si no se
dispone de realimentación
permanente sobre su progreso. La
realimentación puede provenir del
cliente, de los programadores, de
herramientas automáticas, etc.
Coraje. A veces, hacer lo que es
correcto requiere valor. Por ejemplo,
hay que tener coraje para reescribir
código que funciona.
20

20. Los valores mencionados dan origen a
cinco principios básicos:
1.- Conseguir realimentación rápida;
2.- No complicar las cosas con
suposiciones (asumir que las
cosas son simples);
3.- Realizar cambios incrementales;
4.- Abrazar el cambio;
5.- Generar productos de calidad.
Principios
21

21. Prácticas
Los principios se manifiestan a través
de las prácticas de XP.
Son actividades que el equipo de un
proyecto lleva a cabo cada día. Las
12 prácticas de la XP tienen su
origen en prácticas conocidas en la
IS y en el sentido común. Sin
embargo, lo que caracteriza a este
conjunto es la cohesión de todos los
elementos, y que cada práctica ha
sido llevada al extremo:
22

22. 1. El juego de la planificación.
Esta práctica busca dividir la
funcionalidad de un proyecto en
pequeños fragmentos
autocontenidos, c/u de los cuales se
denomina historia de usuario.
2. Entregas frecuentes. Se trata
de publicar una nueva versión en
cuanto sea posible aportar algún
nuevo valor al cliente.
23

23. 3. Diseño simple. El sistema debe
ser el más simple posible que cumpla
especificaciones (pruebas de
aceptación). En un entorno donde los
requisitos del cliente y sus prioridades
cambian continuamente, no tiene
sentido realizar un diseño sofisticado.
La mejor forma de obtener una idea
de los futuros requisitos de un sistema
es proporcionar cuanto antes un
prototipo;
24

24. 4. Pruebas automáticas. ¿Cómo
puede saber un programador que el
código que ha escrito funciona
realmente? ¿Cómo puede saber que
seguirá funcionando siempre, incluso
aunque lo refactorice?
La única manera de asegurarlo con
cierta confianza es escribiendo
pruebas automáticas con las que
pueda comprobar el código en
cualquier momento y sin esfuerzo. 25

25. 5. Integración continua.
Nuevamente se lleva al extremo una
práctica convencional de la IS.
Si la integración es una fase crucial,
en la que pueden aparecer errores,
¿por qué dejarla para el final,
cuando el riesgo es mayor? Resulta
más conveniente realizar integración
continua (cada hora, cada día). Es
imprescindible que el proceso de
integración esté automatizado. 26

26. 6. Refactorización. La
refactorización es un proceso
disciplinado por el cual se modifica el
diseño de un módulo sin afectar a su
comportamiento externo.
Gracias a la refactorización, es
posible compatibilizar el diseño
simple con la flexibilidad.
El coraje para refactorizar proviene
de la disponibilidad de pruebas
automáticas. 27

27. 7. Programación por parejas.
Llevar al extremo una práctica
habitual: las revisiones formales de
código. Si revisar el código es bueno,
¿por qué no revisarlo continuamente,
incluso desde el mismo momento en
el que se escribe por primera vez? En
la programación por parejas, dos
programadores comparten un único
ordenador y colaboran para escribir el
código o las pruebas 28

28. 8. Propiedad colectiva del código.
En el transcurso de una
refactorización, o mientras se corrige
un defecto, algún programador va a
tener que modificar líneas de código
escritas por otro programador.
XP invita a llevar a cabo esa
modificación con coraje, y el coraje
procede de las pruebas automáticas.
29

29. 9. Semana de 40 horas. Los
programadores cansados se
equivocan más. Si las semanas de
más de 40 horas son la norma, algo
no funciona bien en el proyecto;
10. Metáfora. El objetivo de esta
práctica es encontrar una metáfora
que ayude al equipo del proyecto y al
cliente a hablar en los mismos
términos, compartiendo una visión
común del sistema;
30

30. 11. Cliente en el equipo. Para
lograr una realimentación ágil, el
cliente no puede estar muy lejos del
equipo; en una situación ideal, el
cliente debe estar dentro del equipo.
12. Estándares de codificación. Es
una necesidad cuando se trata de
escribir código que otros
programadores puedan entender y
modificar..
31

31. Lo propuso Highsmith, como una técnica
para construir software y sistemas
complejos. Los apoyos filosóficos del DAS
se enfocan en la colaboración humana y la
organización propia del equipo.
Argumenta que un enfoque de desarrollo
ágil y adaptativo basado en la colaboración
es “tanto como una fuente de orden en las
complejas interacciones entre disciplina e
ingeniería”.
Desarrollo adaptativo de software (DAS)
32

32. especulación
colaboración
aprendizaje
Incremento de software
ajuste para ciclos subsecuentes
Lanzamiento
Planeación del ciclo adaptativo
enunciado de la misión
restricciones del proyecto
requisitos básicos
Plan de lanzamiento en el tiempo
Recopilación de requisitos
JAD
especificaciones mínimas
Componentes implementados/probados
grupos de enfoque para retroalimentación
revisiones técnicas formales
Post morten
Desarrollo Adaptativo de Software
33

33. Es un enfoque de desarrollo de
software ágil que “proporciona un
marco de trabajo para construir y
mantener sistemas con restricciones
de tiempo muy estrechas mediante el
empleo de la construcción de
prototipos incrementales en un
ambiente de proyecto controlado”
Método de desarrollo de sistemas dinámicos (MDSD)
34

34. Al igual que la PE y el DAS, el MDSD
sugiere un proceso iterativo de software.
En la red mundial hay una organización
(DSDM Consortium, www.dsdm.org) que
de manera colectiva asume el papel de
“conservador” del método. Esta
organización ha defindo un modelo ágil de
proceso, llamado el ciclo de vida del MDSD.
Este método define 3 ciclos iterativos
diferentes, a los cuales preceden 2
actividades del ciclo de vida adicionales: 35

35. Estudio de factibilidad. Establece los
requisitos básicos de negocio y las
restricciones asociadas con la aplicación del
método y para evaluar si la aplicación es
una candidata viable para el proceso del
MDSD.
Estudio de negocios. Establece los
requisitos funcionales y de información que
permitirán que la aplicación proporcione un
valor al negocio.
36

36. Iteración del modelo funcional. Produce
una serie de prototipos incrementales que
demuestran la funcionalidad para el cliente.
El propósito durante éste ciclo iterativo es
recopilar requisitos adicionales mediante la
retroalimentación de lo que obtiene el
usuario, mientras éste trabaja con el
prototipo.
Iteración de construcción y diseño.
Revisa la construcción de prototipos
durante la iteración del modelo funcional
37

37. Implementación. Coloca el incremento más
reciente (un prototipo “operacionalizado”) en
el ambiente operativo. Se debe destacar que:
1.El incremento puede no estar 100%
completo, o
2.Se pueden requerir cambios cuando el
incremento se coloca en el sitio.
En cualquier caso, el trabajo de desarrollo del
MDSD continúa al regresar a la actividad de
iteración del modelo de función.
38

38. El MDSD se puede combinar con la PE
para obtener un enfoque conjunto que
define un modelo sólido de proceso (el
ciclo de vida del MDSD) con los aspectos
prácticos (PE) necesarios para construir
incrementos de software. Además los
conceptos del DAS de colaboración y
equipos autoorganizados se pueden
adaptar a un modelo de proceso
combinado
39

39. Es un modelo (propuesto por Schwaber y
Beedle) ágil de proceso. Los principios de
la melé son consistentes con el manifiesto
ágil:
Los equipos de trabajo pequeños
están organizados para “maximizar la
comunicación, minimizar los gastos
generales y maximizar el hecho de
compartir conocimiento tácito e
informal”.
Melé
40

40. El proceso debe adaptarse a los
cambios técnicos y de negocios “para
asegurar que se produzca el mejor
producto posible”.
El proceso produce incrementos
frecuentes de software “los cuales se
pueden inspeccionar, ajustar, probar,
documentar y construir”.
El trabajo de desarrollo y la gente que
lo realiza están divididos en “particiones
o paquetes de bajo acoplamiento”. 41

41. Conforme se construye el producto se
realizan pruebas y documentación
constantes.
Los procesos de melé proporcionan la
“capacidad de declarar un producto como
´realizado´ siempre que esto se requiera
(porque la competencia acaba de hacer
un lanzamiento, porque la compania
necesita dinero, porque el usuario/cliente
necesita las funciones, porque ya se está
en el momento en que se prometió……. 42

42. Con los principios de la melé se guían
las actividades dentro de un proceso
que incorpora las siguientes
actividades del marco de trabajo:
requisitos, análisis, diseño, evolución y
entrega. En cada actividad del marco
de trabajo las tareas de trabajo
suceden dentro del patrón de proceso
llamado sprint
43

43. La melé subraya el uso de un conjunto
de “patrones de software” que ha
probado su efectividad en proyectos
con tiempos de entrega muy
reducidos, requisitos cambiantes y
condiciones críticas en los negocios.
Cada uno de estos patrones de proceso
define un conjunto de actividades de
desarrollo:
44

44. Retrasos: son una lista que considera la
prioridad de los requisitos o características
de proyecto que proporcionan un valor
comercial para el cliente. En cualquier
momento se pueden agregar elementos a
los retrasos (así se introducen los
cambios). El gerente de producto evalúa
los retrasos y actualiza las prioridades de
acuerdo con lo requerido.
45

45. Sprint: consiste en unidades de trabajo que
se requieren para satisfacer un requisito
definido en los retrasos en un periodo
predefinido (el lapso usual es de 30 días). En
esta etapa los elementos de los retrasos a los
que se dirigen las unidades de trabajo del
sprint están congelados (es decir, durante el
sprint no se introducen cambios). Por lo
tanto, el sprint permite a los miembros del
equipo trabajar en un ambiente enfocado al
corto plazo, pero estable.
46

46. Reuniones de melé: son reuniones cortas
(por lo general de 15 minutos) y las realiza a
diario el equipo de melé. Existen 3 preguntas
que plantean y responden todos los
miembros del equipo:
¿ Qué hiciste desde la última reunión?
¿ Cuáles obstáculos encontraste?
¿ Qué esperas lograr para la siguiente
reunión del equipo?
47

47. Un líder del equipo, llamado “maestro de
la melé”, preside la reunión y evalúa las
respuestas de cada persona. Cada reunión
de melé ayuda al equipo a descubrir
problemas potenciales tan pronto como
sea posible. Estas reuniones diarias
también conducen a la “socialización del
conocimiento”, y por ende, a promover
una estructura de equipo con organización
propia.
48

48. Demostración: se entrega el
incremento del software al cliente de
forma que éste demuestre y evalúe la
funcionalidad implementada. Es
importante señalar que la demostración
quizá no contenga toda la funcionalidad
planteada, sino aquellas funciones
susceptibles de entregarse dentro del
periodo establecido.
49

49. Flujo del proceso melé
Melé: reunión diaria de 15 minutos
Los miembros del equipo responden
a las preguntas básicas:
1.- ¿Qué hiciste desde la última reunión?
2.- ¿Tienes algún obstáculo?
3.- ¿Qué harás antes de la próxima reunión?
La nueva funcionalidad
se demuestra
al final del sprint
Retraso del producto:
Características del producto deseadas por
el cliente que han recibido prioridad
Elementos de
retraso expandidos
por el equipo
Retraso de Sprint:
Características
Asignadas al Sprint
30 días
Cada 24
horas
50

50. Beedle y sus colegas presentan un
análisis completo de estos patrones y
establecen:
“La melé supone la existencia
del caos…..”
El patrón de proceso de la melé permite
que un equipo de desarrollo de software
trabaje de manera exitosa en un mundo
donde la eliminación de la incertidumbre
es imposible.
51

51. Historia de usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia
Número:
Iteración asignada: 2
Prioridad en negocio: Alta
(Alta/Media/Baja)
Puntos estimados:
Riesgo en desarrollo
(Alta/Media/Baja)
Puntos reales
Descripción:
Se introducen los datos del artículo (título, fichero adjunto,
tópicos) y de los autores (nombre, e-mail, afiliación). Uno de
los autores debe indicarse como autor de contacto. El sistema
confirma la correcta recepción del artículo enviando un e-mail
al autor de contacto con su login y password para que el
autor pueda posteriormente acceder al artículo
Observaciones:
Historias de usuario
52

52. Nombre de la clase: PEDIDO
Responsabilidades Colaboradores
Revisar si existen
elementos en
existencia
Línea de pedidos
Determinar el precio Línea de pedidos
Revisa si el pago es
válido
Cliente
Despacha a la
dirección de entrega
Cartas CRC
53

53. Trabajo de investigación
Investigar por lo menos 5 métodos y/o
metodologías (OMT, Cristal Clear, Desarrollo
conducido por Características (DCC), Agile
Unified Process (AUP), Essential Unified Process
(EssUP), Feature Driven Development (LSD),
Open Unified Process (OpenUP), Ariadne
Development Method(ADM),etc.) de desarrollo:
1. Características;
2. Marco de trabajo;
3. Acciones y tareas por actividad;
4. Ventajas y Desventajas.
FECHA DE ENTREGA: 06-09-12 (enviar por correo y
presentar impreso)
54

54. Número: 1 Nombre: Gestión de Biblioteca
Usuario: Autor-de-historia-de-ususario
Modific. de Historia Número: Iteración asignada: 2
Prioridad en negocio: Alta
(Alta/Media/Baja)
Puntos estimados:
Riesgo en desarrollo (A/M/B) Puntos reales
Descripción:
Se requiere un sistema de control de préstamos en
una biblioteca. El sistema debe admitir altas, bajas de
usuarios y de libros. Los usuarios pueden pedir libros
en préstamo, pero no pueden tener más de dos libros
en préstamo en un momento determinado. Los libros
se han de devolver a las 48 horas de la fecha de
préstamo. Cada vez que un usuario devuelve un libro
después de la fecha de la devolución, se penaliza
reduciendo en una unidad el número de libros que
puede tener simultáneamente. Cuando llega a cero el
socio se da de baja automáticamente.
55