PS 2011 12 TemaII Metodos Agiles

06/10/2011
Tema II – Métodos Ágiles

Dr. Javier Garzás
javier.garzas@urjc.es
Universidad Rey Juan Carlos
Procesos de Software www.kybele.urjc.es
ÍNDICE
1 METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4 PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
2
1
06/10/2011
¿Se puede
desarrollar software
igual que industrialmente se
construyen coches o casas?
casas
1955
“La ingeniería software

era igual que la hardware
hardware.
Aquellos tiempos, todos
eran ingenieros hardware
o matemáticos”
B. Boehm
2
06/10/2011
1968
2010
3
06/10/2011
2005
Diseño previo e
inamovible…
4
06/10/2011
…antes de la
Construcción
Predictibilidad…
5
06/10/2011
Ciclo de vida en Cascada

Cascada…
6
06/10/2011
7
06/10/2011
% avance
8
06/10/2011
Diseño Construcción
Tradicional
Software
V1
V2
V3
9
06/10/2011
Predicción vs Evolución
10
06/10/2011
EL CICLO DE VIDA ITERATIVO

INCREMENTAL (I)
Se va liberando parte del producto
periódicamente y cada entrega es un
incremento respecto a la anterior. Cada fase
se realiza varias veces. Lo cual difiere del
desarrollo en cascada, donde las fases del
ciclo de vida se realizan (en teoría) una única
vez, y el inicio de una fase no comienza hasta
que termina la fase que le precede
21
ITERATIVO = INCREMENTAL
http://jan-so.blogspot.com/2008/01/difference-between-iterative-and.html
22
11
06/10/2011
EL CICLO DE VIDA ITERATIVO

INCREMENTAL
Se comenzó a (II)
aplicar en 1950, en
la construcción del
avión cohete X-15
En 1960 es
aplicado por la
NASA en el
proyecto Mercury
23
12
06/10/2011
Principios Ágiles
1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y
contínua de software con valor.
2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles

aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas

a un par de meses, con preferencia por los periodos más cortos posibles.
4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente

a lo largo del proyecto.
5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte

que necesitan, y confiando en ellos para que realicen el trabajo.
Principios Ágiles
6. El método más eficiente y efectivo de comunicar la información a un equipo de
desarrollo y entre los miembros del mismo es la conversación cara a cara.
7. Software que funciona es la principal medida de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Esponsores,

desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de
forma indefinida.
9. La atención continua a la excelencia técnica y los buenos diseños mejoran la

agilidad.
13
06/10/2011
Principios Ágiles
10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se

autoorganizan.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces
mejora y ajusta su comportamiento de acuerdo a sus conclusiones.
Traducción realizada por Agile Spain del original en Inglés. Éste pueden encontrarse
en http://www.agilemanifesto.org/principles.html
14
06/10/2011
HAY 3 TIPOS DE METODOLOGÍAS
Tradicionales Ágiles
Híbridas
29
METODOLOGÍAS ÁGILES VS
METODOLOGÍAS TRADICIONALES
Híbridas
30
15
06/10/2011
Cambiabilidad:
Las metodologías ágiles están

preparadas para adaptarse a cambios,
mientras que las tradicionales presentan
cierta resistencia a los mismos
31
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Metodologías tradicionales:
conceptos característicos de
la fabricación industrial o la
arquitectura
32
16
06/10/2011
Producción en cadena -> Trabajo repetible, generalmente más manual que
intelectual y operario sustituible
División del trabajo y métodos Tayloristas (“Principles of Scientific

Management” (1912)) Actividades diferenciadas: el diseño y la construcción.
Construcción: poca actividad intelectual y más manual.
Los costes de la construcción (y sus cambios) son muy superiores a los del
diseño.
Por ello el diseño pretende controlar el 100% la construcción
Diseño basado en matemáticas - física
33
PERO EN SOFTWARE ¿ES LO MISMO?
•¿CUÁNDO SABEMOS QUÉ SOFTWARE QUERÍAMOS

CONSTRUIR?
•¿CUESTA LO MISMO CAMBIAR UNA COLUMNA QUE

UNA LÍNEA DE CÓDIGO?
•¿EXISTE UNA BASE MATEMÁTICA – CIENTÍFICA?
34
17
06/10/2011
CHOQUES ENTRE “OLAS”: ADAPTATIVO VS.

PREDICTIVO
Algunas diferencias entre ágil y

tradicional…
36
18
06/10/2011
Contrato:
En las metodologías tradicionales

normalmente existe un contrato cerrado,
mientras que en las ágiles no existe este
tipo de contrato o, si existe, es bastante
flexible
37
Interacción con el cliente:
En las metodologías tradicionales, el

cliente interactúa con el equipo de
desarrollo mediante reuniones. Sin
embargo, en las metodologías ágiles el
cliente forma parte del equipo de
desarrollo
38
19
06/10/2011
Tamaño de los grupos:
Las metodologías ágiles están definidas

para grupos pequeños (menos de 10
integrantes) que trabajan en el mismo sitio.
Sin embargo, las metodologías
tradicionales se definen para grupos
grandes y posiblemente distribuidos
39
Arquitectura del software:
Para las metodologías tradicionales la

arquitectura del software es esencial y se
expresa mediante modelos. Las ágiles,
por su parte, ponen un menor énfasis en
la arquitectura del software
40
20
06/10/2011
Documentación:
La documentación en los procesos ágiles

es más relajada, mientras que en los
procesos tradicionales es más
exhaustiva.
41
EJERCICIO: ¿CUÁL ES MÁS ADECUADO?
ÁGIL / TRADICIONAL
1. Gran cambiabilidad de los requisitos

2. Necesidad de una arquitectura robusta
3. Documentación muy detallada
4. Un contrato cerrado
5. Se necesita interacción con el cliente
6. Tamaño equipo pequeño
7. Se necesita predicción
8. Se necesita Reacción - Adaptación
Procesos de Software www.kybele.urjc.es 42
21
06/10/2011
ÍNDICE
3 SCRUM
43
METODOLOGÍAS HÍBRIDAS
Híbridas
44
22
06/10/2011
La realidad en las empresas refleja

posturas moderadas en la implantación
de metodologías ágiles, hibridas y
orientadas por la necesidad, al negocio y
mejor práctica para cada organización y
proyecto
45
Consisten en adaptaciones de las

Metodologías Ágiles, muchas veces
incorporándole prácticas formales, como,
por ejemplo, el robustecer y hacer menos
iterativa la fase de diseño de la arquitectura
software
46
23
06/10/2011
CUATRO MÉTODOS DE DESARROLLO
El intercambio de la
cultura organizacional
y la estabilidad del
proyecto sugieren dos
métodos nuevos de
desarrollo además de
los métodos formales y
ágiles
47
ÍNDICE
3 SCRUM
48
24
06/10/2011
SCRUM
Metodología ágil que proporciona un

marco para la gestión de proyectos. Está
especialmente indicada para proyectos
con un cambio rápido en los requisitos
49
SCRUM
Basada en entregas parciales priorizadas

por el beneficio que aporta al receptor del
proyecto
50
25
06/10/2011
SCRUM
Permite obtener resultados tempranos y

que permite adaptarse a los cambios en
los requisitos
51
CARACTERÍSTICAS PRINCIPALES
Reuniones a
lo largo del
proyecto
Desarrollo
software
mediante
iteraciones
52
26
06/10/2011
EL PROCESO DE SCRUM
53
SPRINT
A cada iteración se le
denomina sprint. El sprint es
un periodo de corta
duración (2-4 semanas) en el
que se crea un producto
potencialmente entregable
54
27
06/10/2011
PRIMER PASO: PRODUCT BACKLOG
Las características que van a

implementarse en el sprint
provienen de la Pila del
Producto (Product Backlog),
que contiene una serie de
requisitos priorizados para
su aplicación
55
HISTORIAS DE USUARIO
El product backlog debe

ser una lista priorizada y
estimada de historias
de usuario
Como xxx, quiero hacer

yyy con el objetivo de
zzz
56
28
06/10/2011
PRIORIZACIÓN: ESTIMACIÓN Y VALOR
Planning
Poker
Secuencia
de Fibonacci
57
PRIORIZACIÓN: RESPONSABILIDAD DEL

PRODUCT OWNER (CLIENTE)
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil#historias-usuario
58
29
06/10/2011
SPRINT BACKLOG
Una vez seleccionadas las

características que van a
desarrollarse en el Sprint,
se conforma la Pila del
Sprint (Sprint Backlog), que
se mantendrá inamovible
durante toda la iteración
59
SPRINT BACKLOG
•Velocidad: cantidad de story

points o historias de
usuario que terminan por
iteración.
• Burndown charts
60
30
06/10/2011
HISTORIAS
LAS REUNIONES
Son una parte importante

dentro de Scrum. Se definen
diversos tipos de reuniones:
• Daily Scrum
• Sprint Planning Meeting
• Sprint Review Meeting
• Sprint Retrospective
62
31
06/10/2011
REUNIÓN DIARIA (DAILY SCRUM)
Reunión de no más de 15 minutos en la

que se presenta que hizo ayer cada
miembro del equipo, que va a hacer hoy y
que problemas se ha encontrado
63
REUNIÓN DE PLANIFICACIÓN DEL SPRINT

(SPRINT PLANNING MEETING)
Se realiza al principio de cada Sprint,

definiendo en ella que se va a realizar en
ese Sprint. Esta reunión da lugar al Sprint
Backlog. Su duración no debe ser mayor
de 8 horas
64
32
06/10/2011
REUNIÓN DE REVISIÓN DEL SPRINT

(SPRINT REVIEW MEETING)
Se realiza al final del Sprint. Durante la

misma se indica qué ha podido
completarse y qué no, presentando el
trabajo realizado a los implicados. No debe
durar más de 4 horas
65
RETROSPECTIVA DEL SPRINT (SPRINT

RETROSPECTIVE)
Se realiza al final del Sprint, sirve para que

los implicados den sus impresiones sobre
el Sprint que acaba de terminar. Se utiliza
para la mejora del proceso. Esta reunión
debería durar 4 horas
66
33
06/10/2011
RESUMEN
•Scrum: Metodología ágil que proporciona un marco

para la gestión de proyectos, indicada especialmente
para proyectos con un cambio rápido en los requisitos.
•Sprint: Período de corta duración (2-4 semanas) en el

que se crea un producto potencialmente entregable.
•Product backlog: Lista priorizada que contiene una

serie de los requisitos del producto priorizados para su
realización.
•Sprint backlog: Lista con las características que van a

desarrollarse en el Sprint.
67
RESUMEN
•Daily Scrum: Reunión de no más de 15 minutos en la que se

presenta que hizo ayer cada miembro del equipo, que va a hacer
hoy y los problemas que se ha encontrado.
•Sprint planning meeting: Reunión de no más de 8 horas

realizada al principio de cada Sprint, en la que se define que se va
a realizar en el mismo.
•Sprint review meeting: Reunión de no más de 4 horas realizada

al final del Sprint, en la que se presenta el trabajo realizado a los
implicados.
•Sprint retrospective: Reunión de no más de 4 horas que se

realiza al final del Sprint, realizada para recoger las impresiones de
los implicados respecto al Sprint realizado.
68
34
06/10/2011
ÍNDICE
3 SCRUM
69
Automated builds
Continuous integration
Unit testing
Refactoring
Iterative development
Pair programming
Daily meetings
On-site customer
35
06/10/2011
ÍNDICE
3 SCRUM
71
OTRAS METODOLOGÍAS ÁGILES
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development

Feature-Driven Development
Lean Development (LD)
Kanban
72
36
06/10/2011
eXtreme Programming

Kanban
73
eXtreme Programming (XP)
Centrada en potenciar las relaciones

interpersonales. Se basa en la
realimentación continua entre el cliente y
el equipo de desarrollo, la comunicación
fluida entre todos los participantes, la
simplicidad en las soluciones
implementadas y el coraje para
enfrentarse a los cambios
74
37
06/10/2011
CARACTERÍSTICAS DE eXtreme Programming

(XP)
El juego de la planificación: hay una comunicación
frecuente entre el cliente y los programadores. Los técnicos
estiman el esfuerzo requerido para la implementación,
mientras que los clientes deciden sobre el tiempo de cada
iteración.
Entregas pequeñas: una entrega no debería tardar más de

tres meses, tiempo en el que debe desarrollarse una versión
del sistema que sea operativa aunque no cuente con toda la
funcionalidad del sistema.
Metáfora: es una historia que describe el funcionamiento del

sistema. El sistema es definido por una metáfora o un
conjunto de ellas compartidas por el cliente y el equipo de
desarrollo.
75

(XP)
Diseño simple: se debe diseñar la solución más simple que
pueda funcionar.
Pruebas: la producción del código está dirigida por pruebas

unitarias.
Refactorización: la reestructuración del código es necesaria

para la mejora de la calidad del mismo. Se mejora la estructura
interna del código sin alterar su comportamiento externo.
Programación por pares: la producción se hace en parejas, lo

que conlleva evitar errores, mejorar el diseño, etc.
Propiedad colectiva del código: cualquier programador puede

cambiar cualquier parte del código en cualquier momento.
76
38
06/10/2011

(XP)
Integración continua: cada parte del código es integrada en
el sistema una vez que está lista.
40 horas por semana: de debe trabajar un máximo de 40

horas semanales, y no realizar horas extra durante dos
semanas seguidas. Si esto ocurre, algo está realizándose
mal.
Cliente in-situ: el cliente debe estar presente y disponible

todo el tiempo para el equipo, conduciendo el trabajo hacia lo
que aportará mayor valor de negocio.
Estándares de programación: la comunicación entre

programadores se realiza a través del código, por lo que es
importante que se sigan unas reglas para mantener el código
legible.
77
eXtreme Programming

Kanban
78
39
06/10/2011
DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)
Primera metodología ágil (1994) y la mas próxima

a los métodos tradicionales. Metodología iterativa e
incremental en el que equipo de desarrollo y
usuario trabajan juntos. Propone cinco fases:
estudio de viabilidad, estudio del negocio, modelado
funcional, diseño y construcción y por último
implementación. Las tres últimas fases son
iterativas, y existe realimentación entre cada fase.
79
eXtreme Programming

Kanban
80
40
06/10/2011
ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
Metodología iterativa, orientada a los

componentes software más que a las tareas y
tolerante a los cambios. Su ciclo de vida consta de
tres fases: especulación, en la que se inicia el
proyecto y se planifican las características del
software; colaboración, en la que se desarrollan las
características; y aprendizaje, en la que se revisa su
calidad y se entrega al cliente.
81
eXtreme Programming

Kanban
82
41
06/10/2011
FEATURE-DRIVEN DEVELOPMENT (FDD)
Metodología iterativa que consta de 5 pasos.

Las iteraciones son cortas, centrándose en
las fases de diseño e implementación del
sistema partiendo de una lista de
características que debe reunir el software
83
eXtreme Programming

Kanban
84
42
06/10/2011
LEAN DEVELOPMENT (LD)
Los cambios se consideran riesgos, pero si

se manejan adecuadamente se convierten en
oportunidades que mejoren la
productividad del cliente. Es necesario
introducir un mecanismo que permita
implementar dichos cambios
85
eXtreme Programming

Kanban
86
43
06/10/2011
KANBAN
Metodología que ayuda a controlar de modo

armónico la fabricación de productos en la
cantidad y tiempo necesarios en cada uno de
los procesos
87
KANBAN
•Divide el trabajo en bloques, se escribe cada elemento en una

tarjeta/post-it y se coloca en una superficie visible (pizarra,
pared, etc.)
•Utiliza columnas con nombre para indicar en que lugar del

flujo de trabajo se encuentra cada elemento.
•Limita el Work in Progress (trabajo en curso). Asigna límites

concretos a los elementos que están en progreso en cada
estado del flujo de trabajo.
•Mide el lead time (tiempo de ciclo). Optimiza el proceso para

que el tiempo de ciclo sea lo más pequeño y predecible posible.
88
44
06/10/2011
KANBAN
3 3 2 1 3
PENDIENTE DESARROLLO PRUEBA ENTREGA FINALIZADO
J G E D A
K H F B
L I C
FLUJO
89
ÍNDICE
3 SCRUM
90
45
06/10/2011
Different methodologies are possible & needed

(project size, system criticality, priorities, fears)
Criticality (defects cause loss of...)
Prioritized for Legal Liability

Prioritized for Productivity & Tolerance
Life
(L)
L6 L20 L40 L100 L200 L500 L1000
Essential
money
(E) E6 E20 E40 E100 E200 E500 E1000
Discretionary
money
(D) D6 D20 D40 D100 D200 D500 D1000
Comfort
(C) C6 C20 C40 C100 C200 C500 C1000
1-6 - 20 - 40 - 100 - 200 - 500 - 1,000

Alistair Cockburn Number of people involved +20%
¿Y QUE OCURRE CON LA DOCUMENTACIÓN?
92
46
06/10/2011
DOCUMENTAR, DE MANERA ÁGIL, PERO

DOCUMENTAR
[…] Frecuentemente escucho a los desarrolladores

decir que no les gusta documentar, que no lo
encuentran útil, pero… ¿No era el objetivo principal
de documentar el ayudar a otros? ¿Cómo es
posible una visión tan distorsionada de la
documentación?
“Agile Documentation, Anyone?” por Bran Selic

IEEE Software de noviembre (Diciembre, 2010)
93
DOCUMENTAR, DE MANERA ÁGIL, PERO

DOCUMENTAR
[…] El propósito de la documentación es enseñar a quienes no
están familiarizados con un sistema cómo este se estructura,
funciona y los motivos que llevaron a decidirse por ese diseño.
Los principales usuarios de la documentación de diseño
son los futuros responsables del mantenimiento del
sistema. La única alternativa a no tener documentación de
diseño es explorar directamente el sistema, buscar un camino
a través de una selva sin mapa ni brújula. Así, mientras que
documentar tiene un coste, la inversión, si se hace
correctamente, vale la pena […]
“Agile Documentation, Anyone?” por Bran Selic

IEEE Software de noviembre (Diciembre, 2010)
94
47
06/10/2011
48
06/10/2011
En la batalla…
“ Cuando preparo una batalla,

encuentro que los planes son
inútiles, pero la planificación es
indispensable”
Dwight Eisenhower
98
49
06/10/2011
¿QUÉ hacer? MODELO DE PROCESOS

ISO CMMI- CMMI- CMMI-
12207 ACQ DEV SVC
¿CÓMO hacerlo? METODOLOGÍAS
50

PS 2011 12 TemaII Metodos Agiles

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PS 2011 12 TemaII Metodos Agiles

Загружено:

Авторское право:

Доступные форматы

06/10/2011

Tema II – Métodos Ágiles

Procesos de Software www.kybele.urjc.es

1 METODOLOGÍAS ÁGILES VS TRADICIONALES

5 OTRAS METODOLOGÍAS ÁGILES

6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES

“La ingeniería software

Ciclo de vida en Cascada

EL CICLO DE VIDA ITERATIVO

EL CICLO DE VIDA ITERATIVO

2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles

3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas

4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente

5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte

7. Software que funciona es la principal medida de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Esponsores,

9. La atención continua a la excelencia técnica y los buenos diseños mejoran la

10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se

HAY 3 TIPOS DE METODOLOGÍAS

Las metodologías ágiles están

METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES

División del trabajo y métodos Tayloristas (“Principles of Scientific

Construcción: poca actividad intelectual y más manual.

Por ello el diseño pretende controlar el 100% la construcción

Diseño basado en matemáticas - física

PERO EN SOFTWARE ¿ES LO MISMO?

•¿CUÁNDO SABEMOS QUÉ SOFTWARE QUERÍAMOS

•¿CUESTA LO MISMO CAMBIAR UNA COLUMNA QUE

•¿EXISTE UNA BASE MATEMÁTICA – CIENTÍFICA?

CHOQUES ENTRE “OLAS”: ADAPTATIVO VS.

Procesos de Software www.kybele.urjc.es

Algunas diferencias entre ágil y

En las metodologías tradicionales

Interacción con el cliente:

En las metodologías tradicionales, el

Tamaño de los grupos:

Las metodologías ágiles están definidas

Arquitectura del software:

Para las metodologías tradicionales la

La documentación en los procesos ágiles

EJERCICIO: ¿CUÁL ES MÁS ADECUADO?

1. Gran cambiabilidad de los requisitos

Procesos de Software www.kybele.urjc.es 42

1 METODOLOGÍAS ÁGILES VS TRADICIONALES

5 OTRAS METODOLOGÍAS ÁGILES

6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES

La realidad en las empresas refleja

Consisten en adaptaciones de las

CUATRO MÉTODOS DE DESARROLLO

1 METODOLOGÍAS ÁGILES VS TRADICIONALES

5 OTRAS METODOLOGÍAS ÁGILES

6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES

Metodología ágil que proporciona un

Basada en entregas parciales priorizadas

Permite obtener resultados tempranos y

PRIMER PASO: PRODUCT BACKLOG

Las características que van a

PRIMER PASO: PRODUCT BACKLOG

El product backlog debe

Como xxx, quiero hacer

PRIMER PASO: PRODUCT BACKLOG

PRIORIZACIÓN: ESTIMACIÓN Y VALOR