Métodos Ágiles

Tema 1: Iterativo y Evolutivo

(Dr. Ricardo Quintero)

1
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

2
Desarrollo y construcción “predecible”

Al construir un producto, como un teléfono celular es

posible definir sin ambigüedades, sus especificaciones y
pasos de construcción
Después de construir algunos teléfonos es posible, de
forma confiable, hacer estimaciones de costos y
tiempos de futuros teléfonos a construir

3
 Desarrollo y Construcción “No
Predecible”

En contraste
Suponga que una persona desea construir una casa “a la
medida”. Requiere utilizar materiales y métodos
ecológicos, pero no está segura al 100% de lo que
desea.
Cambia o clarifica sus decisiones conforme pasa el tiempo
4
al ver la casa y considerar sus costos
 Desarrollar Software es “Desarrollar
nuevos productos”

+ Predictibilidad de proyectos -

Desarrollo de nuevos
Manufactura en masa o productos o proyectos con
Manufactura alto nivel de inventiva:
predecible:
Alto grado de novedad,
Niveles bajos de cambio o creatividad y cambio sin
novedad con altos niveles experiencia previa de casos
de creación idéntica o casi idénticos a partir de los
idéntica cuales estimar o derivar
planes confiables 5
Proyectos predecibles y no predecibles
P. Predecibles
Al principio es posible definir sus
especificaciones y después construir
Al inicio, se puede estimar de forma
confiable el esfuerzo y el costo
Es posible identificar, definir,
programar y establecer
detalladamente el orden de todas
las actividades
La adaptación al cambio no
predecible no es la norma y la
razón de cambio es relativamente
baja
P. No predecibles
Raramente es posible crear una
especificación detallada y no
cambiante
Al principio no es posible. Conforme
van surgiendo datos empíricos,
incrementalmente va siendo posible
planear y estimar
Al principio, no es posible. Se
requieren pasos adaptativos
dirigidos por ciclos construir-
retroalimentar
La adaptación creativa para los
cambios no previstos es la norma.
La razón de cambio es alta.
6
¿En que categoría cae el software?

Desarrollar software no es un
problema de manufactura en masa o
predecible

El desarrollo del software cae en la

categoría de desarrollo de un nuevo
producto

7
 Si esto no convence …

Muchos proyectos utilizan tecnologías nuevas (y no sencillas) que

incrementan el grado de novedad y no predictibilidad.
Estas tecnologías llevan a un inexperto a vivir experiencias semejantes a
aquéllas de la construcción de un nuevo producto para un inexperto,
8
aún cuando lo haya construido antes.
Por lo tanto …
 Debido a que el paradigma de
manufactura predecible es el
incorrecto para desarrollar software
entonces …

Las prácticas y valores que tienen

sus raíces en el mismo no
resultan útiles

9
Considere el enfoque de “cascada”

 Especificación predictiva de los

requisitos.
 Estimaciones y planes especulativos,
aplicables a la manufactura predecible
que incorrectamente se han aplicado a los
proyectos de software, un dominio que
requiere trabajo inventivo, de alta razón
de cambio y novedad.

10
Ejercicio: ¿Por qué estimaciones
predictivas fallan?

 Usando el artículo de
Parnas y Clemens (1986) realice el
ejercicio
¿Porqué estimaciones predictivas fal
lan?

11
¿Por qué estimaciones predictivas
fallan?

 Parnas y Clemens (1986) nos dan

razones:
 Los clientes o usuarios suelen no estar
seguros (de forma precisa) lo que
quieren.
 Les resulta difícil establecer todo lo que
quieren y desean.
 Muchos de los detalles de lo que
realmente quieren solamente se revela
al momento del desarrollo.

12
¿Por qué estas estimaciones
predictivas de estimación fallan?

 (cont..)Parnas y Clemens (1986) nos dan

razones:
 Para las personas los detalles son
abrumadoramente complejos.
 Conforme van viendo el producto
desarrollado, van cambiando su mente (lo
que desean).
 Factores externos (como el producto de un
competidor o servicio) dirigen los cambios o
extensiones en las solicitudes.

13
La motivación de los Métodos Ágiles

 La motivación principal para los

métodos ágiles e iterativos
subyace en la apreciación de que:

La actividad de construir software

es compleja, con alto nivel de
cambio y con naturaleza no
predecible

14
Pero también son motivados por el
deseo de competir y ganar

 Los métodos ágiles e iterativos

impulsan flexibilidad y
maniobrabilidad: ventajas
competitivas.

15
Pero también son motivados por el
deseo de competir y ganar
 Goldman y Preiss en su
libro Agile competitors and
Virtual Organizations:
Strategies for Enriching the
Customer nos enseñan:

“Agilidad es acerca de éxito y

triunfo: éxito en salir
triunfante en las arenas
competitivas; triunfo en
predicciones y clientes, en
el centro de las tormentas
competitivas que muchas
empresas actuales
enfrentan”

16
Recursos Web
 www.agilealliance.org
 www.bradapp.com
 alistair.cockburn.us
 www.martinfowler.com
 www.mountaingoatsoftware.com

17
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

18
Desarrollo iterativo
 Los métodos ágiles son un enfoque para
construir software (o cualquier cosa) en
un ciclo de vida compuesto por varias
iteraciones en secuencia.
 Cada iteración es un mini-proyecto
auto-contenido compuesto por
actividades como análisis de requisitos,
diseño, programación y pruebas.
 Los métodos ágiles son un subconjunto
de los métodos iterativos y evolutivos.

19
Desarrollo iterativo
 El objetivo final de una iteración es
obtener un release de iteración: un
sistema parcial estable, integrado y
probado.
 Es decir: Todo el software a través de
todos los equipos de desarrollo se integra
en un release en cada iteración.
 Los release pueden ser internos (para el
equipo de desarrollo) o externos (para
el cliente).

20
 Desarrollo iterativo e incremental
(IID)
La retroalimentación (feedback) de la iteración N dirige el
refinamiento y adaptación de los requisitos y el diseño en la
iteración N+1

feedback feedback

Se construye para Se construye para Se construye para

algunos requisitos algunos requisitos algunos requisitos

El Sistema crece RELEASE AL

Una iteración de 3
incrementalmente CLIENTE
semanas

21
Longitud de las iteraciones
 Muchos proyectos tienen al menos
tres iteraciones antes de un
release público final.
 En los métodos modernos:

La longitud recomendada de una

iteración oscila entre 1 y 6
semanas

22
Disciplinas a través de las iteraciones

Cada iteración incluye programación de “calidad de

producción”. No debe resultar en un prototipo o prueba
de concepto, sino un subconjunto del sistema final 23
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Liberación incremental
 Evolución incremental
 Los errores más comunes

24
Planeación iterativa dirigida por el
cliente y por el riesgo

 ¿Qué hacer en cada iteración?

 Los métodos IID promueven una
combinación de prioridades dirigida por
el cliente y por los riesgos.

25
Planeación iterativa dirigida por el
cliente y por el riesgo

 Desarrollo iterativo dirigido por

los riesgos:
 Seleccione los elementos más
riesgosos y difíciles para las
primeras iteraciones.

 Ej.- Un cliente podría decir: “Deseo que las

páginas Web sean verdes y que el sistema
maneje 5,000 transacciones simultáneas”
El color verde puede esperar por tanto se
buscaría resolver primero el volumen de
transacciones
26
Planeación iterativa dirigida por el
cliente y por el riesgo
 Desarrollo iterativo dirigido por el cliente:
 La elección de características para cada
iteración debe venir del cliente –cualquiera que
sea lo que él considera de mayor valor.

 De esta forma el cliente conduce el proyecto,

iteración por iteración, solicitando las
características que en ese momento
considera de mayor valor para el negocio.

27
Planeación iterativa dirigida por el
cliente y por el riesgo

 Desarrollo iterativo dirigido por el

cliente (cont…):
 De esta forma el cliente adaptativamente
planea la selección para la siguiente iteración,
brevemente antes de iniciarla, basado en la
experiencia adquirida en la iteración previa,
más que de forma especulativa al inicio del
proyecto.
 Conforme nueva información va surgiendo el
cliente va percibiendo control y capacidad
de decisión.

28
Planeación iterativa dirigida por el
cliente y por el riesgo

 Aplique ambas técnicas…

 Porque:
 Los clientes no siempre son capaces de
percibir lo que técnicamente es más
difícil o riesgoso.
 Los desarrolladores no siempre aprecian

lo que es de más alto valor para el

negocio.

29
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

30
Ejercicio-El principio de Timeboxing

 Lea el artículo Time boxing for top

team performance.
 Resuelva el ejercicio El principio de
Timeboxing.

31
El principio de TimeBoxing
 Timeboxing:
 Es la práctica de mantener fija la fecha final de
la iteración y no permitir cambios.
 Este principio debería aplicar también para la
fecha final de todo el proyecto.
 Si eventualmente sucediera que las solicitudes
hechas (ámbito) para una iteración no puedan
satisfacerse dentro del timebox, entonces en
lugar de cambiar la fecha final, el alcance se
reduce (colocando las prioridades de más bajo
riesgo al final de la lista de “deseos”).

32
El principio de TimeBoxing
 Esto con el fin de que se obtenga
un sistema parcial (pero
creciente) en un estado estable y
probado.
Es importante que el Timeboxing no se
utilice para presionar a los desarrolladores
para que trabajen largas horas para cumplir
con la inminente fecha de terminación. Si el
paso normal de trabajo es insuficiente,
haga menos.

33
Longitud del TimeBox
 No todos los Time-box necesitan ser
iguales:
 La primer iteración puede ser 4
semanas.
 La segunda iteración 3 semanas, etc.
 Como ya mencionamos la longitud
recomendada es: 1 a 6 semanas.

34
Longitud del TimeBox
 Se ha demostrado que Pasos cortos
ofrecen:
 Menor complejidad.
 Menor riesgo.
 Mejor retroalimentación.
 Más alta productividad.
 Mayor tasa de razón de éxito.
 Todos los métodos modernos (incluyendo
Scrum o XP o UP) requieren o
recomiendan aplicar Timeboxing a las
iteraciones.

35
 TimeBoxing

Construye para feedback Construye para En Timeboxing,

algunos requisitos algunos requisitos la variable
tiempo en cada
iteración se
mantiene fija

1 iteración de 3 semanas 1 iteración de 2 semanas

“timeboxed”. La fecha final no “timeboxed”. La fecha final no
se cambia. se cambia.

Ámbito
(tareas) Tiempo Tiempo, ámbito, recursos
y calidad son las 4
variables comunes con las
que se puede jugar en un
Proyecto proyecto.
Timeboxing remueve el
tiempo de estas opciones
durante una iteración
Calidad Recurso ¡Recuerde el “Iron
(gente) Triangle”!
36
Beneficios del Time-Boxing
 Enfoque: El enfoque psicológico que
promueve una fecha de terminación fija
de 3 semanas es muy diferente al que
promueve una de 3 meses.
 Timeboxing es un antídoto a la Ley de
Parkinson: “El trabajo se expande para
ocupar todo el tiempo disponible”
 Las personas recuerdan más fechas
postergadas que características
postergadas: es un capricho de la
naturaleza humana.

37
Beneficios del Time-Boxing
 Obliga a atacar niveles pequeños de
complejidad: la investigación ha
demostrado que pasos de complejidad
baja se realizan más productivamente.
 Obliga a tomar decisiones difíciles y
de compensación tempranamente: se
obliga a ser realista en lo que se hará y
en lo que no se hará. Obliga al manejo
de prioridades.

38
Durante la iteración, ningún cambio de
los Stakeholder externos

 No se permite que el
Administrador del producto (o algún
otro stakeholder) diga:
“¿Pueden hacer esto también?”
Deberá esperar a la siguiente iteración.
Sin embargo, el equipo puede reducir
el alcance de la iteración si a la
fecha final del Timebox no es posible su
implementación completa.

40
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

41
Desarrollo evolutivo y adaptativo
 Desarrollo iterativo evolutivo:
 Los requisitos, planes, estimaciones y
soluciones evolucionan o se refinan en el
transcurso de las iteraciones.
 En lugar de ser completamente definidos o
“congelados” en un esfuerzo mayúsculo de
especificación antes de que el desarrollo
iterativo empiece.

Los métodos evolutivos son consistentes con el patrón de

descubrimiento y cambio no predecible en el
desarrollo de un nuevo producto.

42
Desarrollo evolutivo y adaptativo
 Desarrollo adaptativo:
 Es un término relacionado con evolutivo.
 Implica que los elementos se adaptan en
respuesta al “feedback” del trabajo
anterior –”feedback” de usuarios,
testers, desarrolladores, etc.
 La intención es la misma que en el desarrollo
evolutivo, pero el nombre sugiere un mecanismo
más fuerte de repuesta-feedback en la
evolución.

43
Análisis evolutivo de los requisitos
1 2 3 4 5 ... 20

requirements workshops

Imagine this will

ultimately be a 20-
iteration project.

requirements

requirements
software

software
In evolutionary iterative
development, the
requirements evolve
over a set of the early
iterations, through a
series of requirements
90% 90%
workshops (for
example). Perhaps
after four iterations and
50%
workshops, 90% of the
requirements are 30%
defined and refined. 20% 20%
5% 8% 10%
Nevertheless, only 2%
10% of the software is
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
built.
a 3-week iteration

week 1 week 2 week 3

M T W Th F M T W Th F M T W Th F

kickoff meeting team agile start de-scope final check-in demo and next
clarifying iteration modeling & coding & iteration and code- 2-day iteration
goals with the team. design, testing goals if freeze for the requirements planning
1 hour UML too much iteration workshop meeting;
whiteboard work baseline 2 hours
sketching.
5 hours Most OOA/D and
Use-case modeling
applying UML during
during the workshop
this period 45
Planeación evolutiva y adaptativa
 Igual que con los requisitos, en la planeación
adaptativa y evolutiva no se trata de que los
estimados y fechas se desconozcan por siempre.
 Esto es, debido a que los primeros requisitos
son muy cambiantes (y a otros factores), existe
una fase inicial de alto nivel de
incertidumbre, la cual declinará conforme el
tiempo avance y la información se acumule.
 Esto ha sido llamado el cono de
incertidumbre. Steve McConnell's Software
Project Survival Guide (Microsoft Press, 1998,
ISBN: 1-57231-621-7)

46
El Cono de Incertidumbre

Mayor información: COCOMO 2.0 47

Respuesta iterativa a la incertidumbre

 La respuesta iterativa a la
incertidumbre es postergar los
estimados semi-confiables de
costo, esfuerzo o tiempo hasta
que unas pocas de las iteraciones
han pasado. Razonablemente un
10% o 20% del proyecto.

48
Contratos de precio fijo
 Con respecto a hacer una oferta de
precio fijo y estimaciones
evolutivas, algunos métodos IID
recomiendan realizar el proyecto en
un contrato de dos fases, cada
uno de múltiples iteraciones
“timeboxed”.

50
Contrato de dos fases

51
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

53
Entrega incremental

Esta práctica no debe confundirse con el desarrollo iterativo. Un ciclo

de entrega de 6 meses podría componerse por 10 iteraciones. El
resultado de cada iteración no se libera al mercado, pero los
resultados de una entrega sí
55
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

56
Entrega evolutiva
 En la Entrega Incremental hay un plan
definido para las entregas futuras (el
“feedback” no conduce el plan de
entregas).
 En la Entrega Evolutiva no hay plan (o al
menos no uno fijo) de entregas futuras;
cada una es creada dinámicamente en base
a la información que va surgiendo.

58
Agenda
 Motivación
 Desarrollo Iterativo
 Planeación iterativa dirigida por los
riesgos y por el cliente
 El principio de “Time boxing”
 Desarrollo evolutivo y adaptativo
 Entrega incremental
 Entrega evolutiva
 Los errores más comunes

59
El error más común
 Líderes de proceso iterativos y ágiles
continuamente se encuentran en escenarios así:
Líder: Seguro, nosotros no aplicaremos la cascada-
ya sabemos que no funciona. Adoptaremos el
método <X> y estamos ante nuestro primer
proyecto. Ya hemos estado trabajando durante
dos meses y hemos terminado prácticamente el
análisis de los casos de uso y la planificación y
programación de lo que iremos haciendo en cada
iteración. Después de revisar y aprobar los
requisitos finales y la programación de
iteraciones, empezaremos a programar …
Ups !

60
El error más común
 Esta es una profunda falta de
entendimiento del método y una
sobreimposición de los métodos
de cascada en los métodos
iterativos.
 Suele ser uno de los errores más
comunes. Evítalo.

61
Métodos iterativos
 Los métodos iterativos
precedieron a los ágiles.
 Los métodos iterativos pueden o
no ser considerados ágiles.

62
Métodos iterativos
 Ejemplos:
 Evo (el primero, inició en los 1960s)
 UP (desarrollado a mediados de los 1990s)
 Microsoft Solutions Framework. (una
descripción de las mejores prácticas usadas
por Microsoft)
 OPEN de Henderson-Sellers, FireSmith y
Graham
 Modelo de espiral WinWin o Modelo de espiral
MBASE de Barry Bohem.

63
Lecturas recomendadas
 Rapid Devlopment-  The Mythical Man-
Steve McConell. Month-Frederick
Examina variaciones del Brooks. La edición de
desarrollo iterativo. plata de este clásico
discute las ventajas
de IID, además de
muchas otros temas
muy interesantes

64