Manual01

Métodos ágiles-Scrum y XP

Object-Oriented Technology Training
Dr. Ricardo R. Quintero Meza

1
Métodos Ágiles-Scrum y XP

El Desarrollo Iterativo y
Evolutivo: Scrum y XP

Tema 1: Iterativo y Evolutivo
(Dr. Ricardo Quintero)

1

Repositorio en línea de Material
Adicional

 http://tinyurl.com/cursoagil

2

Dr. Ricardo Quintero 1

2

Temas
 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

3

Desarrollo y construcción “predecible”

Al construir un teléfono celular es posible definir, sin
ambigüedades, sus especificaciones y pasos de
construcción.
Después de alguna experiencia en la construcción de
teléfonos es posible hacer estimaciones confiables de
costo y tiempo de futuros teléfonos a construir.

4


3

Desarrollo y construcción “no
predecible”

Suponga una persona que desea construir una casa “a la
medida”. Se quieren utilizar materiales y métodos
ecológicos, pero no se está seguro al 100% de lo que
se desea.
Cambia o clarifica sus decisiones conforme pasa el
tiempo al ver la casa y sus costos.

5

Desarrollar Software es “Desarrollar
nuevos productos”

+ Predictibilidad de proyectos -

Desarrollo de nuevos
Manufactura en masa o productos o proyectos con
Manufactura predecible: alto nivel de inventiva:
Niveles bajos de cambio o Alto grado de novedad,
novedad con altos niveles de creatividad y cambio sin
creación idéntica o casi experiencia previa de
idéntica casos idénticos a partir de
los cuales estimar o
derivar planes confiables

6


4

Proyectos predecibles y no predecibles
P. Predecibles P. No predecibles

Al principio es posible definir sus Raramente es posible crear una
especificaciones y después especificación detallada y no
construir cambiante
Al inicio, se puede estimar de forma Al principio no es posible. Conforme
confiable el esfuerzo y el costo van surgiendo datos empíricos,
incrementalmente va siendo posible
planear y estimar
Es posible identificar, definir, Al principio, no es posible. Se
calendarizar y establecer requieren pasos adaptativos
detalladamente el orden de todas conducidos por ciclos construir-
las actividades retroalimentar
La adaptación al cambio no La adaptación creativa para los
predecible no es la norma y la cambios no previstos es la norma.
razón de cambio es relativamente La razón de cambio es alta.
baja

7

¿En que categoría cae el software?

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

El desarrollo de software cae en la
categoría de desarrollo de un
producto nuevo.

8


5

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 situaciones semejantes a las de la
construcción de un nuevo producto, aún cuando tenga experiencia previa
9

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.

10


6

Considere el “enfoque de cascada”

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

11

Ejercicio: ¿Por qué estimaciones
predictivas fallan?

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

12


7

¿Por qué las 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.

13

¿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.

14


8

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

15

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

 Los métodos ágiles e iterativos
impulsan flexibilidad y
maniobrabilidad: ventajas
competitivas.

16


9

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”

17

Recursos Web

 www.agilealliance.com
 www.cetus-links.org
 www.bradapp.net
 alistair.cockburn.us
 www.martinfowler.com

18


10

Temas
 Motivación

19

Desarrollo iterativo
 Los métodos ágiles son un subconjunto
de los métodos iterativos y evolutivos.
 Es un enfoque para construir software (o
cualquier cosa) en el cual el ciclo de vida
se compone 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.

20


11

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).

21

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
Una iteración de 3 incrementalmente RELEASE AL
semanas CLIENTE

22


12

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.

23

Disciplinas a través de las iteraciones

24


13

Temas
 Motivación

25

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.

26


14


 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 en color verde 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
27

 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.

28


15


 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.

29


 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.

30


16

Temas
 Motivación

31

Ejercicio-El principio de Timeboxing

 Lea el artículo Time boxing for top
team performance.
 Resuelva el ejercicio El principio de
Timeboxing.

32


17

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
(alcance) para una iteración no pueden 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”).

33

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.

34


18

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.

35

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

36


19

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.

Alcance
(tareas) Tiempo Tiempo, alcance, 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”!

37

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. Time boxing
es un antidoto 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.

38


20

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.

39

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

 Los métodos ágiles e iterativos enfrentan
el cambio, pero no el caos.
 Esto se logra con la siguiente regla:
Una vez que se han determinado las
solicitudes para una iteración y estas
se están llevando a cabo, ningún
stakeholder externo puede cambiar el
trabajo.

40


21

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

 No se vale que el administrador del
producto (por decir alguien) diga:
“¿Pueden hacer esto también?”
Deberá esperar a la siguiente iteración.
Sin embargo, el equipo puede reducir
el ámbito de la iteración si a la fecha
final del timebox no se puede lograr.

41

Temas
 Motivación

42


22

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.

43

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.

44


23

Análisis evolutivo de requisitos
 En el desarrollo evolutivo y adaptativo no
se trata de que los requisitos están “sin
límite” o “cambiantes continuamente”.
 Al contrario, mucho del descubrimiento y
refinamiento ocurre durante las primeras
iteraciones.
 La rápida atención en estas iteraciones
tiene como propósito entender los
requisitos arquitectónicamente más
significativos o de más alto valor al
negocio.

45

Análisis de requisitos evolutivo
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 46


24

Planeación evolutiva y adaptativa
 Igual que con los requisitos, 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)

47

El Cono de Incertidumbre

Mayor información: COCOMO 2.0
48


25

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.

49

Respuesta iterativa a la incertidumbre
 Esto es consistente con otras prácticas
administrativas en otros dominios de
desarrollo de nuevos productos, donde es
común una fase exploratoria inicial.
 Aún más, se motiva a la planeación
adaptativa más que a la planeación
predictiva.
 Es decir, una planificación detallada no se
crea hasta que se ha avanzado más allá
de un breve tiempo, de tal manera que el
nivel de detalle y compromiso se
consensa con la calidad de la información.

50


26

Contratos de precio fijo

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

51

Contrato de dos fases

52


27

Contrato de dos fases
 Primera fase:
 Un contrato relativamente pequeño de tiempo fijo y
precio fijo, con el objetivo de cumplirse en unas
cuantas iteraciones, haciendo desarrollo temprano
(pero parcial) de software y análisis evolutivo de
requisitos.
 El resultado de la fase –incluyendo el software
base- se comparte con los clientes para el
contrato de precio fijo de la segunda fase.
 El refinamiento evolutivo de las especificaciones y
código en la fase uno ofrece datos de mayor
calidad para los estimadores de la fase dos y al
mismo tiempo ofrece avances del software.

53

Temas
 Motivación

54


28

Entrega incremental
 Es la práctica de entregar
repetidamente un sistema a
producción (o al mercado) en
una serie de capacidades
extendidas. Es una práctica
promovida por los métodos ágiles e
IID.
 Las entregas incrementales son en
un rango de 3 a 12 meses.

55

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í
56


29

Temas
 Motivación

57

Entrega evolutiva
 Es un refinamiento de la entrega
incremental.
 Con la diferencia de que aquí existe un
interés muy marcado por obtener
“feedback” respecto al producto
instalado y usar este “feedback” para
guiar la siguiente entrega.
 El objetivo es conocer necesidades
difíciles de predecir.
 Recomendación: hacer una mezcla de
ambas prácticas.

58


30

Entrega Incremental vs. 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.

59

Temas
 Motivación

60


31

El error más común
 Líderes de proceso iterativos y ágiles
continuamente ven 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 !

61

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.

62


32

Métodos iterativos

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

63

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.

64


33

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

65


34

El Desarrollo Iterativo y
Evolutivo: Scrum y XP

Tema 2: Ágil
(Dr. Ricardo Quintero)

1

Agenda
 Desarrollo ágil
 Clasificación de los métodos
 Los principios y el manifiesto ágil
 Gestión de proyectos ágiles
 Abrazando la comunicación y la retroalimentación
 Prácticas y herramientas de proyectos simples
 Procesos empíricos VS Procesos definidos y
prescriptivos
 Disciplina de sustentabilidad:el roce humano.
 El equipo como un Sistema Complejo Adaptativo.

2


35

Desarrollo ágil

 Los Métodos ágiles aplican:
 Desarrollo evolutivo e iterativo
“timeboxed”.
 Planeación adaptativa.
 Promueven entregas evolutivas.
 Incluyen otros valores y prácticas que
motivan la agilidad-respuestas
rápidas y flexibles al cambio.

3

Desarrollo ágil

 Su lema es:
Enfrentar el cambio.
 Su punto estratégico es:
Maniobrabilidad

4


36

Desarrollo ágil

 No es posible definir exactamente a
los Métodos ágiles, porque sus
prácticas específicas varían.
 Pero las siguientes prácticas son
compartidas por diversos métodos:
 Iteraciones pequeñas “timeboxed”.
 Refinamiento adaptativo y
evolutivo de planes y objetivos

5

Desarrollo ágil

 Además los Métodos ágiles
promueven prácticas y principios
que reflejan una “sensación de
agilidad” como: simplicidad,
ligereza, comunicación, equipos
autodirigidos, programación sobre
documentación y más.

6


37

Ejemplo de prácticas ágiles en Scrum

 Ejemplos de prácticas ágiles en
Scrum (que estudiaremos más al
detalle posteriormente) son:
 Un lugar común para el proyecto.
 Equipos auto-dirigidos que se
coordinan a través de reuniones diarias
con preguntas concretas que cada
miembro responde.

7

Ejemplo de prácticas ágiles en XP
 Ejemplos de prácticas ágiles en XP (que
estudiaremos más adelante) son:
 Usar notas concisas en papel (story cards)
para sumarizar requisitos.
 Programar en parejas.
 Trabajar en un lugar común con participación
de tiempo completo de “proveedores de
requisitos” para que los requisitos escritos
puedan complementarse con explicaciones
verbales.

8


38

Iterativo VS ágil
 Como concepto de proceso de software,
“ágil” es más nuevo que el enfoque
“iterativo”.
 Muchos métodos IID (Evo o UP) no fueron
diseñados como ágiles en su definición
original, pero se pueden aplicar en un espíritu
ágil.
 Aunque podríamos imaginar métodos IID
no-ágiles, la mayoría (por no decir todos)
están adoptando los valores y prácticas
ágiles –es raro que alguien promueva la
no-agilidad.

9

Agenda
prescriptivos

10


39

Clasificación de los métodos por
ceremonia y ciclos
Estrictamente El peso del método en
cascada(secuencial) términos de
documentación, pasos
El número y longitud formales, revisiones, etc.
de las iteraciones

Ciclos
Pocos documentos Muchos documentos
Pocos pasos
Ceremonia Muchos Pasos formales

Scrum

UP

XP
Evo
Muchas iteraciones
pequeñas (5 días)

11

Agenda
prescriptivos

12


40

El Manifiesto Ágil
 Manifiesto (según diccionario RAE):
Escrito en que se hace pública declaración de
doctrinas o propósitos de interés general.
 El 2001 un grupo interesado en los métodos
ágiles e iterativos acuñaron el término.
 Se reunieron para formar la Alianza Ágil
(www.agilealliance.com) con un Manifiesto y un
conjunto de estatutos de principios.
 Éstos guían la gestión de proyectos ágiles.

13

Valores del Manifiesto Ágil
 “Individuos e interacciones sobre
procesos y herramientas.

 Software trabajando sobre
documentación de comprensión.

 Colaboración del cliente sobre
negociación de contrato.

 Respuesta al cambio sobre
seguir un plan.

Es decir, si bien existe valor en los segundos elementos,
valoramos los primeros más

14


41

Ejercicio – El Manifiesto ágil
 Lea el Manifiesto Ágil y todo el grupo
realice el siguiente ejercicio:
 Dividimos el grupo en 4 equipos.
 Cada equipo selecciona alguna de las doctrinas
(valores) del movimiento ágil y hará una
“araña” con los puntos más importantes que lo
justifican. Se pega la “araña” en las paredes.
 Cada equipo expondrá al resto su doctrina
correspondiente. Cada equipo comentará su
punto de vista sobre la doctrina. Discusión y
comentarios.
 Se toman fotos digitales a cada araña y se
distribuyen entre los participantes.

15

Principios ágiles (leeremos las
justificaciones en el Manifiesto)
1. Nuestra más alta prioridad es satisfacer
al cliente a través de entregas continuas
y tempranas de software valuable.
2. Bienvenidos los cambios de requisitos
aún en etapas posteriores al desarrollo.
Los procesos ágiles aprovechan el
cambio a favor de la ventaja competitiva
del cliente.
3. Entrega software trabajando
frecuentemente, desde un grupo de
semanas hasta un grupo de meses, con
preferencia a escalas breves de tiempo

16


42

Principios ágiles
4. La gente del negocio y los
desarrolladores deben trabajar en
conjunto diariamente a lo largo del
proyecto.
5. Construye el proyecto con gente
motivada. Dales el ambiente y soporte
necesario y confía en que harán bien el
trabajo.
6. El método más eficiente y efectivo para
conllevar información hacia y dentro el
equipo de desarrollo es la conversación
cara-a-cara.

17

Principios ágiles
7. Software trabajando es la medida
principal de progreso.
8. Los procesos ágiles promueven el
desarrollo sustentable.
9. Los patrocinadores, desarrolladores y
usuarios deben mantener una paz
constante indefinidamente.
10. Atención constante a la excelencia
técnica y el buen diseño aumenta la
agilidad.

18


43

Principios ágiles
11. Simplicidad-el arte de maximizar el
monto de trabajo no hecho-es esencial.
12. Las mejores arquitecturas, requisitos y
diseños emergen a partir de equipos
auto-organizados.
13. A intervalos regulares, el equipo
reflexiona sobre como ser más efectivo,
acorde a lo cual ajusta su
comportamiento.

19

Agenda
prescriptivos

20


44

Gestión de proyectos ágiles

 Aunque más adelante veremos
prácticas concretas de gestión de
proyectos ágiles (en Scrum y XP).
Hay generalizaciones comunes a
todos los métodos.
 Veremos dos descripciones bien
conocidas.

21

Gestión de proyectos ágiles:Jim
Highsmith

1. Entrega algo útil al usuario; verifica que
es lo que le resulta de valor.
2. Cultiva stakeholders comprometidos.
3. Emplea un estilo de liderazgo
colaborativo.
4. Construye equipos competentes y
colaborativos.
5. Posibilita la toma de decisiones en
equipo.
Gestion de Proyectos ágiles -Highsmith.pdf

22


45

Gestión de proyectos ágiles:Jim
Highsmith

6. Utiliza iteraciones cortas
“timeboxed” para ofrecer entregas
rápidas.
7. Motiva la adaptabilidad.
8. Busca la excelencia técnica.
9. Enfócate en actividades de
entrega, no en actividades de
cumplimiento de procesos.

23

Gestión de proyectos ágiles:Augustine
and Woodcock

1. Visión guiada: establece una visión
guiada para el proyecto. Refuérzala
continuamente a través de palabras y
acciones.
2. Trabajo en equipo & colaboración:
facilita la colaboración y el trabajo en
equipo a través de relaciones y espíritu
comunitario.
3. Reglas simples: establece y soporta
un conjunto de prácticas guía, tales
como Scrum y XP.

24


46

Gestión de proyectos ágiles:Augustine
and Woodcock

4. Apertura en la información: Ofrece
acceso abierto y visible a la gestión del
proyecto y otra información.
5. Roce ligero: Aplica sólo el control
suficiente para fomentar
comportamiento emergente en equipo
auto-dirigido.
6. Vigilancia ágil: Refuerza la visión,
sigue o adapta las reglas, escucha a la
gente.

25

Gestión de proyectos ágiles:papel del
administrador

 Tanto en Scrum como en XP se regresa
tanto el control como la planeación al
equipo, no al administrador.
 El administrador no crea la estructura de
partición del trabajo, la estimación de
tiempos; todo esto se hace en equipo.
 Generalmente el administrador no dice a
la gente lo que hará.
 El administrador no define y asigna
detalladamente la mayoría de los roles y
responsabilidades.

26


47

Gestión de proyectos ágiles:papel del
administrador

 Al contrario:
 El rol del administrador del proyecto es
realizar coaching, ofrecer recursos,
mantener la visión, remover
impedimentos, promover los principios
ágiles, etc.

27

Agenda
prescriptivos

28


48

Programación como si la gente
importara

“La gente es más importante que
cualquier proceso. Buena gente con
un buen proceso superará siempre
a buena gente sin ningún proceso”
Grady Booch (1996)

29

importara
 El primer valor del Manifiesto ágil es que
los Individuos y las interacciones
están sobre los procesos y las
herramientas.
 Nos recuerda que: la programación es
una actividad humana.
 Atento al impacto del “trabajo extra” en la
habilidad para programar bien o
mantener una vida familiar o social
saludable, XP tiene la regla de paz
sustentable-evitar el “trabajo extra”

30


49

importara

 Los hábitos correctos de trabajo y
conocimiento juegan un papel
significativo en la productividad-el valor
de la educación constante y del
mentoring para desarrolladores.
 XP motiva fuertemente la transferencia
de habilidades a través de la
programación en parejas.

31

importara

 El énfasis en la comunicación es
también importante, especialmente
las conversaciones cara-a-cara.
 Las reuniones diarias de Scrum y
un lugar común para el proyecto
y en XP la programación en
parejas y todo el equipo junto
son ejemplos.

32


50

Agenda
prescriptivos

33

Prácticas y herramientas de proyectos
simples

 Muchos métodos ágiles promueven
el principio de hacer lo más
simple que posiblemente
funcione – un aforismo* XP.

*Sentencia breve y doctrinal que se propone como regla
en alguna ciencia o arte (Diccionario RAE)

34


51

simples

 Muchos métodos ágiles promueven
un enfoque “low-tech, high-
touch”.
 Low-tech es relativo, si una
herramienta Web es lo más simple,
úsala.

35

simples

Es un malentendido igualar los métodos ágiles
con falta de habilidad o auto-disciplina. Un
proyecto aplicando todas las prácticas XP tiene
plena estructura y disciplina. Pero –y esto es
quizá el punto clave en los métodos ágiles- las
prácticas “disciplinadas” son muy orientadas-a-
entregables o de orientación-a-calidad-en-el-
código. Los desarrolladores rápidamente ven
los beneficios.

36


52

Agenda
prescriptivos
 Disciplina de sustentabilidad: el roce humano.

37

Procesos Empíricos vs. Definidos y
Prescriptivos
 Proceso definido (o prescriptivo): tiene un conjunto
ordenado y predefinido de actividades a seguir durante el
desarrollo. Útil en dominios predictivos de manufactura.
 Proceso empírico: usado para dominios inestables y de
alto-cambio. En lugar de sustentarse en muchas actividades;
se basa en mediciones frecuentes y respuestas dinámicas a
eventos variables.
 Los métodos ágiles promueven los Procesos empíricos en
lugar de Procesos definidos.
 Ej.- Scrum no nos indica las actividades a realizar por
iteración (salvo una reunión al inicio del día).
 Ej.- UP está en un punto medio, lista actividades
comunes, pero el equipo las puede ignorar o hacer en
cualquier orden.

38


53

Procesos empíricos VS. Definidos y
Prescriptivos

 Los métodos ágiles entienden que el
grado de “peso de un método” y la
predefinición de actividades
ordenadas están en función del tipo
de proyecto.
 Un método o proyecto ágil cae en un
“continuum” de empirismo, dirigido
por las necesidades.

39

Basado en Principios VS Basado
en Reglas

 En lugar de considerar un conjunto
predefinido de reglas (roles,
organización de equipo,
responsabilidades, etc.) el equipo y
el administrador son guiados por
los principios más que por las
prácticas.

40


54

Agenda
prescriptivos

41

Disciplina de sustentabilidad: el toque
humano

 No hay pocas historias de intentos
en adoptar métodos que requieren
disciplina y esfuerzo, sólo para
terminar en poco tiempo con poco
apego a los mismos.
 Los factores sociales y
psicológicos necesarios para la
adopción sustentable se están
perdiendo.

42


55

humano

 Los creadores de algunos métodos
ágiles (XP, Crystal) reconocen que
factores humanos como el
disfrute, la simplicidad, el estímulo
a corto plazo, etc; son ingredientes
para crear un suelo fértil para la
auto-disciplina sostenible en las
prácticas.

43

humano

 Por ejemplo, el desarrollo dirigido
por pruebas revela sus ventajas
rápidamente a aquellos que lo usan.
 Los desarrolladores disfrutan la
“pequeña victoria” de pasar una
prueba y la clarificación en el diseño
que viene a partir de escribir las
pruebas antes de que el código sea
probado (práctica común en XP).

44


56

Agenda
prescriptivos

45

El equipo como un Sistema Complejo
Adaptativo

 Algunos métodos ágiles (ej. Scrum)
hablan de un equipo de desarrollo
saludable como un Sistema Complejo
Adaptativo (SCA).
 Lo comparan con una “parvada de
pájaros”. Cada pájaro tiene reglas de
comportamiento local relativamente
simples, pero a nivel macro exhiben un
comportamiento emergente.
 Esto es distinto a una coordinación
dirigida por un líder.

46


57

El equipo como un Sistema Complejo
Adaptativo

 Los métodos ágiles promueven el
valor de que para proyectos
creativos-inventivos una cultura
inspirada en SCA es más valiosa
que el control y planeación de los
administradores.
 Ej.- En Scrum los equipos son auto-
organizados; la organización a nivel de
equipo y adaptación se realiza en la
Scrum meeting.

47

¿Mucha promoción ágil?
 Visto como un todo los principios y
prácticas ágiles (por ejemplo de XP o
Scrum) tienen un “sabor fresco” nuevo.
 Se engloban en:
 Abrazar los cambios de requisitos.
 La comunicación.
 La auto-organización de equipos.
 La planeación adaptativa. Etc.
 Y poseen algunas prácticas novedosas como el
desarrollo dirigido por pruebas y la integración
continua.

48


58

Métodos ágiles específicos
 De acuerdo a una encuesta de
Shine, XP y Scrum son los
métodos ágiles más ampliamente
utilizados.
 Scrum: su énfasis distintivo entre
los métodos es su fuerte promoción
a los equipos auto-organizados, a la
medición diaria de los equipos y el
evitar seguir pasos predefinidos.

49

 XP: es el método ágil más conocido;
enfatiza la colaboración, rápida y
temprana creación del software; y buenas
prácticas experimentadas de desarrollo.
Se fundamenta en 4 valores:
 Comunicación.
 Simplicidad.
 Retroalimentación
 Coraje o valor.

50


59

 Familia Crystal: fue desarrollada por
Alistair Cockburn.
 Al mismo tiempo que reconoce la
necesidad del ciclo de vida iterativo, en
este grupo de métodos Cockburn favorece
los aspectos del “peopleware” sobre los
procesos: comunicación, educación, etc.
 Su definición del desarrollo de software:
“un juego cooperativo de invención y
comunicación”.

51

 Familia Crystal: diferentes versiones de
Crystal (Clear, Yellow,…) contienen
incrementalmente “peso del método”
como una función del tamaño del staff,
criticalidad y prioridad del proyecto.
 Se selecciona el tamaño y la criticalidad y
se mapea a una versión particular Crystal
con un “peso del método” recomendado.
 Utilizaremos este modelo para clasificar
Scrum y XP.

52


60

Familia Crystal

53

Modelado Ágil
 Es un conjunto de principios y prácticas
para el análisis de requisitos y modelado
que complementa a muchos métodos IID.
 El Modelado Ágil promueve la creación
colaborativa “low-tech, high-touch” con
modelos que ayuden más al
entendimiento y la comunicación.
 Sus prácticas promueven velocidad,
simplicidad y creatividad

54


Manual01

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Manual01

Similaire à Manual01 (20)

Plus de Ricardo Quintero

Plus de Ricardo Quintero (20)

Dernier

Dernier (15)

Manual01