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


Tema 2: Ágil

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


61

Prácticas del Modelado Ágil
Refinamiento iterativo Simplicidad

Crea varios Itera a otros Usa la Despliega los
modelos en paralo artefactos herramienta más modelos de forma
simple simple
Ej. un diagrama de Ej. 5% de un
clases y uno de diagrama de clases, Ej. pizarrón blanco Ej. en la pared; no
secuencia después 5% de un & cámara; video en una página Web
relacionados diagrama de
secuencia

Documentación Trabajo en equipo
Descarta modelos Actualiza solo si Modela con otros Despliega los
temporales vale la pena modelos
Ej. diagramación en
públicamente
Ej. toma una foto; Ej. desarrollar el parejas
borra el pizarrón código es más Ej. Datos de gestión
importante que del proyecto en las
mantener el paredes
diagrama

55

Otros métodos y prácticas
 Adaptative Software
Development (DSA):
Jim Highsmith.
 Dynamic Solutions
Delivery Model (DSDM).
 Feature-driven
Development (FDD);
Jeff De Luca y Peter
Coad.
 Lean Development:
Mary and Tom
Poppedieck
 Pragmatic programming:
Andy Hunt and Dave
Thomas.
www.pragmaticprogram
mer.com

56


62


Tema 3: Scrum

1

Temas

 Clasificación de Scrum
 Workproducts, roles y prácticas
 Errores comunes, adopción y
mezcla de procesos, fortalezas y
debilidades

2

Dr. Ricardo Quintero
1

63

Scrum y Rugby
 Scrum es un término
con el que se identifica
una jugada de Rugby
en la cual un par de
equipos se disputan la
posesión del balón una
vez que se ha
reanudado un juego
por alguna interrupción
…

3

Scrum: prácticas clave
 Equipos auto-dirigidos y auto-
organizados.
 Una vez seleccionado, no se agrega
trabajo adicional a una iteración.
 Reunión diaria “de pie” con preguntas
especiales.
 Iteraciones de 30 días (generalmente).
 Demo a los stakeholders al final de cada
iteración.
 En cada iteración, planeación
adaptativa dirigida por los clientes.

4

2

64

Scrum en la escala de ciclos y
ceremonia
Estrictamente
Preciso en la longitud de las
cascada(secuencial)
Flexible en el grado de iteraciones (30 días), no
ceremonialidad pero en el número de
se recomienda “as iteraciones.
little ceremony as
possible”.

Ciclos
Pocos documentos Muchos documentos
Pocos pasos Ceremonia Muchos Pasos formales

Scrum

UP

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

5

Scrum en la escala de Cockburn

6

3

65

Tamaño de equipos
 1 equipo de Scrum debe ser de 7 o menos
participantes.
 Múltiples equipos pueden formar un proyecto.
 Pueden tenerse “Scrum de Scrums” donde varios
equipos pequeños trabajan juntos y tienen una
reunión diaria con representantes de cada equipo.
 Scrum es complementario a otras prácticas de
tal forma que puede aplicarse a otros dominios de
software (desde misión crítica hasta más
casuales).
 Promueve valores y prácticas de gestión de
proyectos (más que de requisitos,
implementación, análisis, diseño, etc.). Por eso
puede combinarse con otros métodos.

7

Mayor énfasis en procesos empíricos
que en predefinidos
 Ken Schwaber, uno de los
fundadores de Scrum
cuenta la siguiente historia:
 “Deseaba entender porque
los procesos de mis clientes
(cascada y definidos-
detalladamente) no
trabajaban para mi
compañía de software, así
que en 1995 traje varias
metodologías a los expertos
de teoría de procesos en el
DuPont Experimental
Station. Estos expertos,
dirigidos por Babatunde
Ogannaike, son los
expertos teoristas más
respetados en procesos de
control industrial…

8

4

66

que en predefinidos
 “..Inspeccionaron los procesos de desarrollo de
sistemas que les llevé. Raramente había visto un
grupo que se riera tanto. Estuvieron sorprendidos
y asustados de que mi industria (de software)
estuviera tratando de hacer su trabajo usando un
modelo de control de procesos completamente
inapropiado. Decían que el desarrollo de sistemas
tenía mucha complejidad e impredecibilidad por lo
que tenía que ser manejado por un modelo de
control de procesos que referían como “empírico”.
Decían que eso no era totalmente nuevo y que
todos los procesos complejos que no estuvieran
completamente entendidos (o que tenían
entradas cambiantes) requería el modelo empírico
(y no un modelo definido de procesos) …”

9

que en predefinidos

 “…[Ogannaike] me dijo que mi negocio
era un negocio intelectualmente intenso
que requería de mucho intelecto y
creatividad para ser un buen candidato
para un enfoque predefinido…Estaba
particularmente sorprendido de que las
tareas estuvieran enlazadas con
dependencias (tipo PERT), como un
proceso industrial bien definido..”

10

5

67

que en predefinidos

 Las palabras de Ogannaike recuerdan los
procesos industriales de Deming y
Shewhart que poseen énfasis en ciclos
Plan-Do-Study-Act para ambientes
complejos y cambiantes. (El ciclo de
Shewart o la rueda de Deming).

11

Ciclo de vida de Scrum: 4 fases para una
entrega (release)
Planeación Montaje Desarrollo Entrega
(Pre-juego) (Pre-juego) (Juego) (pos-juego)
Propósito: Propósito: Propósito: Propósito:
Establecer la visión, Identificar la mayoría Implementar un -Instalación
expectactivas y de los requisitos y sistema listo para operacional.
aseguramiento priorizarlos para la entregarse en una
financiero primer iteración. serie de iteraciones
(Sprints) de 30 días

Actividades: Actividades: Actividades: Actividades:
-Definir la visión, -Planeación. -Junta de planeación -Documentación.
presupuesto, Product -Diseño exploratorio para el Sprint -Entrenamiento.
Backlog inicial y y prototipos. definiendo el Sprint -Mercadeo & Ventas.
estimación de sus Backlog y
items. estimaciones. …
-Diseño exploratorio -Juntas diarias
y prototipos. Scrum.
-Diseño de la -Revisión del Sprint
Arquitectura de alto
nivel

12

6

68

Ciclo de vida de Scrum

13

Ciclo de vida de Scrum

14

7

69

Temas

debilidades

15

Workproducts (entregables no-software) de las
diversas disciplinas

Requisitos Diseño
•Incluye todos los items del
producto.
•El Release backlog es un
subconjunto del Product Backlog
(PB).
•Incluye: características, UC,
extensiones, defectos,
tecnologías, etc.
Implementación Pruebas & Verificación

Gestión del proyecto Configuración & Ambiente de
Gestión de Cambios
•Estimación del trabajo
restante VS los días
restantes.

•Tareas para la iteración.
Granularidad de 4 a 16 hrs.

16

8

70

Workproducts (o entregables)

 Además de los que se mencionan,
Scrum permite cualquier
Workproduct que de valor al
proyecto. Los principales son:
 El Product Backlog.
 El Sprint Backlog.
 El gráfico del Sprint Backlog

17

Workproducts-Product Backlog
(Requisitos)
 Product Backlog: Incluye una lista de
todos los “items” concebibles del sistema,
priorizados por el Product Owner (el
cliente).
 Es una lista maestra de toda la
funcionalidad deseada en el producto.
 Incluye estimaciones de esfuerzo (en
unidades de tiempo-hombre) de cada
“item”. En principio definidas
burdamente pero refinadas después una
vez que los miembros del equipo se
comprometen
18

9

71

Workproducts-Ejemplo de Product
Backlog

19

Workproducts-Product Backlog

20

10

72

Aspectos prácticos-Product Backlog

 Plantilla básica propuesta. (Se
recomienda como un archivo
compartido en la red, para que los
interesados lo pueda compartir y
modificar)
 Ejemplo 1 en Excel.
 El SprintOmeter.

21

Workproducts-Sprint Backlog
(Project Management)
 Sprint Backlog: Es la lista de Tareas que el
Scrum Team se compromete para el Sprint
actual. Los “items” del Sprint Backlog se
obtienen a partir del Product Backlog (de
acuerdo a las prioridades definidas por el Product
Owner).
 Es crítico que el equipo seleccione los items y
el tamaño del Sprint Backlog, porque ellos son
los que estarán comprometidos con el
trabajo definido en el mismo.
 Se puede definir el estimado diario de horas
restantes para cada tarea.
 Se actualiza diariamente por cada miembro o
por algún responsable común.
 Se puede definir en Excel.

22

11

73


23


24

12

74

Aspectos prácticos-Sprint Backlog

 Plantilla básica propuesta. (Puede
ser un archivo compartido en la
red)
 El SprintOmeter.

25

“de hombre pobre”

1. Localiza un área grande en pared
sin utilizar.
2. Toma una gran hoja de papel (2x2
m. o 3x2 m) y cólocala en la
pared.

26

13

75

3. Ahora dibuja las líneas y coloca las HU y Tareas:

27


28

14

76

4. Después de la primer junta Scrum:

29

4. Después de algunos días:

30

15

77

4. El diagrama de BurnDown:

31

5. Monitoreando el proyecto (Scrum Master)

32

16

78

Workproducts-gráfico Sprint Backlog

 Gráfico Sprint Backlog: es un resumen
visual de la estimación de tiempo
restante de las tareas del Sprint
Backlog.
 Es considerado el dato más crítico del
proyecto.
 Recomendación:
Colocar en la pared y actualizar
diariamente una versión de este
Workproduct para la junta diaria de
Scrum.
33


34

17

79

Notése que el
equipo hace
un ajuste en
las tareas del
Sprint actual
cuando
restaban 619
horas y se
han
percatado
que es mucho
trabajo y el
Sprint corre
el riesgo de
no cumplirse
(remueven
tareas)

35

Roles
Customer Development
•Trabaja en el Sprint Backlog
•Una persona responsable de
(iteración).
crear y priorizar el PB.
•Cada miembro es, solamente,
•A partir del PB selecciona los
un “miembro del equipo”
objetivos del siguiente Sprint.
(team member).
•Junto con los stakeholders,
revisa el sistema al finalizar el
Sprint.

Management Other
•50% desarrollador, no sólo
administrador.
•Conoce y refuerza la visión y objetivos
del proyecto e iteración. •Todos los demás pueden
•Asegura que los valores y prácticas se observar, pero no interferir o
sigan. hablar durante una iteración
•Media entre la administración y el Scrum
team.
•Monitorea el avance y elimina
obstáculos.
•Conduce la reunión diaria de Scrum.
•Conduce la revisión del Sprint (demo).

36

18

80

Prácticas-una puede soportar múltiples disciplinas

Requisitos Diseño

Implementación Pruebas & Verificación

Gestión del proyecto Configuración & Ambiente de
Gestión de Cambios

(valores)
37

Core practices-Requisitos
 Pre-juego Planeación y montaje:
 Todos los stakeholder pueden contribuir para
crear una lista de características, UC,
extensiones, defectos, etc y registrar en el
Product Backlog.
 Se designa un Product Owner y las solicitudes
se hacen a través del mismo.
 En esta sesión se genera el trabajo para, al
menos, la primer iteración.
 Se identifica el Release Backlog, un
subconjunto del Product Backlog que definirá
al siguiente producto operacional.

38

19

81

 Planeación de Sprint:
 Antes del inicio de cada Sprint se manejan
dos juntas:
1) Los stakeholders refinan y re-priorizan el
Product Backlog y el Release Backlog para
seleccionar los objetivos de la siguiente
iteración, dirigidos por valor del negocio o
riesgo.
2) El Scrum Team y el Product Owner se
reúnen para definir como lograr las tareas y
crear el Sprint Backlog (en unas 4 a 16 hrs).
Si el esfuerzo estimado excede los recursos,
ocurre otro ciclo de planeación.

39


 Planeación de Sprint:
 Conforme la iteración procede, el
Sprint Backlog se actualiza, es común
que sea diario durante la parte inicial
de la iteración, conforme nuevas
tareas se descubren.
 Al paso del tiempo (y con
experiencia), el equipo mejora en la
elaboración del Sprint Backlog.

40

20

82

Planeación del Sprint-Aspectos
prácticos
 Es, quizá, el evento más importante de
Scrum. Una mala planeación puede llevar al
fracaso todo el Sprint.
 Resultados de la planeación:
1. El objetivo del Sprint.
2. Una lista de los miembros del equipo y sus
niveles de compromiso.
3. El Sprint backlog.
4. Una fecha definida para el Sprint demo.
5. Una hora y lugar definidos para la junta
diaria de Scrum.

41

prácticos
 El Product Owner la debe atender. De no
hacerlo, el método se verá seriamente
comprometido en su éxito.
 El tiempo del reunión debe respetar el
principio de time-boxing (al principio
puede ser difícil e incluso no lograrse una
reunión satisfactoria, pero aún así persiste,
la próxima reunión se verán presionados a
dar resultados en el tiempo estipulado).

42

21

83

prácticos
 Agenda ejemplo (8:00 a 12:00 hrs)
 8:00 a 8:30 – El Product Owner define el objetivo y sumariza
el Product Backlog. Se define lugar del Demo, hora y fecha.
 8:30 a 10:00 – Estimaciones de tiempo de las HU, posibles
divisiones de las mismas. El Product Owner puede repriorizar
las HU. Se clarifican las HU. Se llenan todos los “Demos” de
cada HU en el PB.
 10:00 a 11:00 – El equipo selecciona las HU a incluir en el
Sprint. Se calcula la velocidad del equipo.
 11:00 a 12:00 – Se determina la hora y lugar de la junta
diaria de Scrum. Se dividen las HU en Tareas.

43

 Revisión de Sprint:
 Al finalizar cada iteración, hay una
reunión de revisión (max. 4 hrs)
convocada por el Scrum master.
Participan el equipo, el Product Owner
y otros stakeholders.
 Se muestra un demo del producto
para informar a los stakeholders de la
función del producto, diseño,
fortalezas, debilidades, esfuerzo del
equipo y futuros puntos de problema.

44

22

84

 Revisión de Sprint:
 Se motiva al “feedback” y a la lluvia
de ideas sobre las direcciones futuras,
pero no se establecen compromisos.
En la siguiente reunión de Sprint
planning, los stakeholders y el equipo
harán los compromisos.
 Prohibido presentaciones en
Power Point. El énfasis en la
presentación es en mostrar el
producto.

45

Revisión de Sprint-Aspectos
prácticos
 Asegúrate de presentar claramente el objetivo
del Sprint. Si en la reunión hay gente que no sabe
nada del producto, da alguna explicación.
 Enfócate en presentar el producto, no
presentaciones en PowerPoint.
 Procura que tu demo sea sobre escenarios
fáciles y ágiles de presentar (más que
cuestiones estéticas).
 Manten la demo a nivel de funcionalidad (el
¿Qué?)y no tecnicismos (el ¿Cómo?).
 Si es posible, trata que el auditorio pruebe el
producto.
 No muestres arreglos o características
pequeñas. Enfócate en lo importante.

46

23

85

Core practices-Project Management

 No agregar a una iteración:
 Durante una iteración, la administración no
agrega trabajo al equipo o individuos. Se
busca un “enfoque ininterrumpido”.
 En el raro caso de que algo tenga que
agregarse algo deberá removerse.
 Pero, antes de cada nueva iteración el
Product Owner y la administración tienen el
derecho y la responsabilidad de re-priorizar el
Product Backlog e indicar que hacer en la
siguiente iteración, de tal forma que la
requisición de trabajo no exceda los recursos.

47


 Cerdos y gallinas:
 Durante la Scrum meeting, sólo el Scrum
Team puede hablar (the Pigs). Los demás
pueden atender a la reunión, pero se
mantienen en silencio (the chickens), aún el
jefe.
 Sólo se les permite “feedback” para puntos
de explicación relevante del negocio para el
trabajo del equipo.
 “Huevos con jamón-¿Quién está involucrado
y quien comprometido? ¿El cerdo o la
gallina?”

48

24

86


 Scrum Master firewall:
 El Scrum Master debe asegurarse de que el
equipo no sea interrumpido por solicitudes de
trabajo de terceros y de ocurrir, removerlas y
manejarlas con “inteligencia”.
 El Scrum Master debe asegurarse de que el
método de Scrum se aplique, removiendo
obstáculos, proveyendo recursos y tomando
decisiones.
 Debe tomar la iniciativa cuando ve que las
reuniones no están completando su trabajo o
si el equipo no está participando (hablando,
por ej.)

49

 Scrum diario:
 Cada día de trabajo en el mismo lugar y hora, se
tiene una reunión con los miembros del equipo (en
círculo), en el que se realizan las preguntas
especiales Scrum para cada miembro:
1) ¿Qué hiciste desde el último Scrum?
2) ¿Qué harás desde ahora y hasta el siguiente
Scrum?
3) ¿Qué obstáculos tienes para alcanzar los
objetivos?
4) ¿Alguna tarea a agregar al Sprint Backlog?
5) ¿Haz aprendido o decidido algo nuevo, de
relevancia para alguno de los miembros del
equipo?

50

25

87


 Scrum diario:
 La reunión es mejor manejarla en círculo
para motivar a la brevedad.
 En promedio 15 a 20 minutos para 7 a 10
personas. Reuniones más largas pueden
tenerse al inicio de la iteración.
 Miembros que no son del equipo (chickens)
están fuera del círculo.
 Se maneja junto a un pizarrón en el cual las
tareas y obstáculos se van escribiendo.
 El Scrum Master borra los obstáculos sólo
cuando han sido removidos

51

 Scrum diario:
 Puede existir alguna forma de comunicación
externa para miembros no presentes.
 El Scrum Master asegura que las reglas se
sigan y prepara el lugar para una reunión
eficiente.
 Debe empezar a la hora.
 Ninguna otra discusión se permite que las 5
preguntas. El Scrum Master tiene la autoridad
de reenfocar la discusión.
 Si otros aspectos necesitan discusión, se
pueden tener reuniones secundarias
inmediatamente después del Scrum meeting
con subconjuntos del Scrum team.

52

26

88

Scrum diario-Aspectos prácticos
 En el Sprint Backlog “de hombre pobre” cada
miembro del equipo puede actualizar el tiempo
restante de cada tarea, es muy importante que
todos actualicen sus tareas. Si esta tarea se
deja sólo al Scrum Master, será mucho trabajo:

53

Scrum diario-Aspectos prácticos
 ¿Qué hacer con los impuntuales? Puede pagar
una “multa” y usar luego el dinero para algún
evento social 
 ¿Qué hacer con los que “no saben que hacer el
día actual”? Se les escucha (sin discutir) y luego se
lleva a todo el equipo al Sprint Backlog para que
adecuen o agreguen nuevas tareas. Con el SB
actualizado se les pide a los “susodichos” que
seleccionen lo que harán el día de hoy. En
ocasiones, si esto no funciona, el Scrum Master
tendrá que realizar coaching más personal (incluso
decidir si vale la pena seguir con ese miembro o no
en el equipo).

54

27

89


 Decisiones en 1 hora:
 Los bloqueos reportados en el Scrum
Meeting y que requieren decisión del
Scrum Master deben decidirse,
idealmente, inmediatamente o dentro
de 1 hora.
 Se promueve el valor de “Es mejor
tomar malas decisiones a no decidir.
Las malas decisiones se pueden
revertir”

55


 Remoción de bloqueos en 1 día:
 Los bloqueos reportados en el Scrum
Meeting deben removerse idealmente
antes de la siguiente reunión.

56

28

90


 Equipos de 7:
 Scrum se puede escalar a proyectos
grandes, pero recomienda tener un
máximo de 7 miembros.
 Proyectos más grandes se manejan
como multi-equipo.

57


 Scrum of Scrums:
 Se pueden manejar para multi-equipos reuniones
de Scrum de Scrums.

58

29

91


 Sprint:
 El trabajo generalmente se organiza
en iteraciones de 30 días de
calendario; cada una llamada un
Sprint.

59


 Equipos auto-dirigidos y auto-
organizados:
 Se empodera al equipo con autorización y
recursos de tal forma que caminen a su ritmo
y resuelvan sus problemas.
 El Scrum Master y la administración proveen
recursos y remueven obstáculos.
 Es el reto más fuerte para la adopción de
Scrum.

60

30

92

Core practices-Configuración &
Ambiente de Gestión de Cambios

 Cuarto común del proyecto:
 Idealmente el equipo trabajo junto en un
espacio común para el proyecto, en lugar de
oficinas separadas o cubículos.
 Para otras actividades se pueden considerar
los espacios separados y privados.
 Se han reportado casos de éxito con equipos
geográficamente dispersos que participan
mediante comunicación virtual.

61

Core practices-Configuración &
Ambiente de Gestión de Cambios

 Construcción diaria:
 Al menos una integración diaria y una
prueba de regresión a todo lo largo
del código verificado.
 Más adelante veremos la práctica de
Integración Continua de XP que es
aún mejor.

62

31

93

Valores que promueve Scrum
 Compromiso:
 Dado que el Scrum Team se compromete a
metas definidas por iteración y se le da la
autonomía y autoridad para decidir como
alcanzarla.
 Dado que la Administración y el Scrum
Manager se comprometen a no introducir
nuevo trabajo, eliminar obstáculos y proveer
recursos.
 El Product Owner se compromete a definir y
priorizar el Product Backlog, guiar los objetivos
por iteración y revisar y ofrecer “feedback”
iteración a iteración.

63


 Enfoque:
 Dado que el Scrum Team se enfoca en
los objetivos establecidos de la
iteración, sin distracciones.
 El Scrum Master y la administración se
enfocan en proveer recursos, remover
obstáculos y evitar interrupciones al
equipo con solicitudes adicionales.

64

32

94


 Apertura:
 El Product Backlog está disponible para
visualizar el trabajo y las prioridades.
 Las Daily Scrums hacen visible el
estado general de los individuos y sus
compromisos.
 La velocidad del trabajo y su tendencia
es visible con el Backlog graph.

65

 Respeto:
 Más responsabilidad de equipo que “chivos
expiatorios”.
 Los miembros del equipo se respetan por sus
debilidades y fortalezas y no por sus fallas en
las iteraciones.
 El equipo completo (más que el
administrador), mediante auto-organización y
dirección, adopta la actitud de resolver
problemas “individuales” mediante la
exploración grupal de soluciones dándole los
recursos y la autoridad para reaccionar a los
retos (tal como traer un experto consultor para
compensar sus carencias de expertise).

66

33

95


 Coraje:
 La administración tiene el coraje de
planear y guiar adaptativamente y
confiar en el equipo evitando decirles
que tienen que hacer.
 El equipo tiene el coraje de tomar la
responsabilidad de la auto-dirección y
la auto-gestión.

67

Temas

debilidades

68

34

96

Errores comunes y malos entendidos
 No ser equipo auto-dirigido; los administradores o
el Scrum Manager dirige u organiza el equipo.
 No actualizar diariamente el Sprint Backlog.
 Agregar nuevo trabajo individual o a la iteración.
 El Product Owner no se involucra o no decide.
 No hay Sprint Review.
 Muchos masters.
 La documentación es mala: no se habló de
documentación, pero el principio ya se ha
comentado –aquella que agregue valor al
proceso-.

69

Errores comunes y malos entendidos

 El diseño o la documentación es mala: lo
mismo que la documentación.
 Scrum meetings muy largas o no
enfocadas.
 La iteración no termina en un producto
parcial integrado y probado.
 Cada iteración termina en un release de
producto.
 Planeación predictiva. Planeación tipo
PERT.

70

35

97

Mezcla de procesos: Scrum+UP
 Las prácticas de Scrum son iguales
o especializaciones de las prácticas
de UP o son adiciones consistentes.
 Aunque Scrum no promueve orden
en las actividades, se puede
aprovechar el orden de UP para los
Sprints.
 Cuando estudiemos XP veremos su
mezcla con Scrum

71

Estrategias de adopción
 En contraste a la recomendación
precautoria de UP (un proyecto piloto),
los creadores de Scrum motivan a las
organizaciones para adoptarlo en su
proyecto más difícil y crítico.
 Esta recomendación atrevida la sustentan
en la visión que tienen los creadores de
que es una medicina fuerte con una alta
razón de éxito.

72

36

98

Estrategias de adopción
 Después de que inicia el primer proyecto, pero no
antes de la segunda iteración (es decir, cuando
todas las prácticas se han probado)
administración ajena al proyecto y clientes
potenciales se les puede invitar para observar los
Scrum meetings, Sprint Planning y Sprint
Reviews.
 Los proyectos de segunda generación de Scrum
pueden iniciar antes de complementar los
primeros, aunque se debe dar tiempo de madurar
al primero (algunas 3 iteraciones). Los miembros
del equipo del segundo equipo se pueden
beneficiar al atender alguna de las reuniones del
primer equipo.

73

Lecturas recomendadas

 La biblia de Scrum es: Agile
Software Development with Scrum

74

37

99

Ejercicio

 Realizaremos un ejercicio de Scrum.
 Se formaran 3 equipos (no más de
7 integrantes).
 Este es el Product Backlog.
 Este es el ejercicio.

75

38

100

EJERCICIO - ¿Porqué estas estimaciones predictivas fallan?

LECTURA: A rational design process: How and Why to fake it

1) Lea la parte I.- THE SEARCH FOR THE PHILOSOPHER’S STONE: WHY DO WE
WANT A RATIONAL DESIGN PROCESS? Conteste las siguientes preguntas:
a. ¿Qué se entiende por una persona racional?
________________________________________________________________
________________________________________________________________
________________________________________________________________
b. ¿Porqué el proceso de desarrollo de software es considerado irracional?
________________________________________________________________
________________________________________________________________
________________________________________________________________
c. ¿Cuál es el propósito de los métodos de desarrollo de software?
________________________________________________________________
________________________________________________________________
________________________________________________________________

2) Lea la parte II.- WHY WILL A SOFTWARE DESIGN “PROCESS” ALWAYS BE
AN IDEALISATION? Identifique las 7 razones por las cuales el desarrollo de
software es considerado irracional. Escríbalas en una sola línea:
a. _____________________________________________________________
b. _____________________________________________________________
c. _____________________________________________________________
d. _____________________________________________________________
e. _____________________________________________________________
f. _____________________________________________________________
g. _____________________________________________________________

3) TAREA: En casa lea el resto del artículo. Escriba sus comentarios sobre el “disfraz”
que es necesario colocar a nuestro proceso de desarrollo de software.

101

A RATIONAL DESIGN PROCESS:
HOW AND WHY TO FAKE IT

David L. Parnas
Computer Science Department
University of Victoria
Victoria BC V8W 2Y2 Canada
and
Computer Science and Systems Branch
Naval Research Laboratory
Washington DC 20375 USA

and

Paul C. Clements
Computer Science and Systems Branch
Naval Research Laboratory
Washington DC 20375 USA

I. THE SEARCH FOR THE PHILOSOPHER'S STONE: WHY DO WE
WANT A RATIONAL DESIGN PROCESS?
A perfectly rational person is one who always has a good reason for what he does. Each step taken can
be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational
professionals. However, to many observers, the usual process of designing software appears quite irra-
tional. Programmers start without a clear statement of desired behavior and implementation constraints.
They make a long sequence of design decisions with no clear statement of why they do things the way
they do. Their rationale is rarely explained. Many of us are not satisfied with such a design process. That
is why there is research in software design, programming methods, structured programming and related
topics. Ideally, we would like to derive our programs from a statement of requirements in the same sense
that theorems are derived from axioms in a published proof. All of the methodologies that can be con-
sidered "top down" are the result of our desire to have a rational, systematic way of designing software.
This paper brings a message with both bad news and good news. The bad news is that, in our opinion,
we will never find the philosopher's stone. We will never find a process that allows us to design software
in a perfectly rational way. The good news is that we can fake it. We can present our system to others
as if we had been rational designers and it pays to pretend do so during development and maintenance.

1

102

II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN
IDEALISATION?
We will never see a software project that proceeds in the "rational" way. Some of the reasons are listed
below:

(1) In most cases the people who commission the building of a software system do
not know exactly what they want and are unable to tell us all that they know.
(2) Even if we knew the requirements, there are many other facts that we need to
know to design the software. Many of the details only become known to us as we
progress in the implementation. Some of the things that we learn invalidate our design
and we must backtrack. Because we try to minimize lost work, the resulting design
may be one that would not result from a rational design process.
(3) Even if we knew all of the relevant facts before we started, experience shows that
human beings are unable to comprehend fully the plethora of details that must be
taken into account in order to design and build a correct system. The process of
designing the software is one in which we attempt to separate concerns so that we are
working with a manageable amount of information. However, until we have
separated the concerns, we are bound to make errors.
(4) Even if we could master all of the detail needed, all but the most trivial projects
are subject to change for external reasons. Some of those changes may invalidate
previous design decisions. The resulting design is not one that would have been
produced by a rational design process.
(5) Human errors can only be avoided if one can avoid the use of humans. Even after
the concerns are separated, errors will be made.
(6) We are often burdened by preconceived design ideas, ideas that we invented,
acquired on related projects, or heard about in a class. Sometimes we undertake a
project in order to try out or use a favourite idea. Such ideas may not be derived from
our requirements by a rational process.
(7) Often we are encouraged, for economic reasons, to use software that was
developed for some other project. In other situations, we may be encouraged to share
our software with another ongoing project. The resulting software may not be the
ideal software for either project, i.e., not the software that we would develop based
on its requirements alone, but it is good enough and will save effort.
For all of these reasons, the picture of the software designer deriving his design in a rational, error-free,
way from a statement of requirements is quite unrealistic. No system has ever been developed in that
way, and probably none ever will. Even the small program developments shown in textbooks and papers
are unreal. They have been revised and polished until the author has shown us what he wishes he had
done, not what actually did happen.

2

103

EJERCICIO - Timeboxing

LECTURA: Timeboxing for top team performance

1) Lea la INTRODUCCIÓN. Conteste las siguientes preguntas:
a. Según el autor ¿Cuál es la definición de un proyecto exitoso?
________________________________________________________________
________________________________________________________________
________________________________________________________________
b. Complete:
Timebox: Define y establece un ________________________________ y
después se ajusta el __________________________________ para que lo que
se desea entregar se entregue en ______________________________ adecuado.
Esto asume que __________________________________________ es lo más
importante y frecuentemente lo es. Hay otros aspectos a considerar también:
________________________________, ___________________________,
___________________________________ y _______________________. Más
adelante los revisaremos.

2) Lea la parte THE “IRON TRIANGLE”.
En un proyecto, los recursos suelen ser fijos. Lo que se puede manejar es lo
siguiente (defina):
a. Schedule:_____________________________________________________
b. Scope:_______________________________________________________
c. Quality:______________________________________________________

3) Se les llama el “Triángulo de hierro” por su relación inmutable. El autor menciona
dos ejemplos de esta relación. De acuerdo a su experiencia, proporcione un ejemplo
más:
EJEMPLO:_____________________________________________________________
______________________________________________________________________
______________________________________________________________________

4) Lea: THE LAST FEATURES y conteste:
¿Cuál es la mejor estrategia de
TimeBoxing?___________________________________________________________
______________________________________________________________________
_____________________________________________________________________.

5) Revise la Figura 2 The 90/90 Rule. ¿De que forma timeboxing contribuye a que el
10% de un sistema no nos tome el 90% del tiempo
disponible?__________________________________________________________
___________________________________________________________________
___________________________________________________________________
6) Lea: THE RIGHT FEATURES. Conteste ¿Como seleccionar las características que
primero se deben entregar en un
sistema?____________________________________________________________

104

___________________________________________________________________
___________________________________________________________________
__________________________________________________________________.
7) Lea: INCREMENTAL RELEASES. Mencione los pasos que sigue la estrategia de
Jim McCarthy de Microsoft para entregas incrementales: (gotta have=consigue
tener; should have= debería tener; nice to have=sería bueno tener)
a. _________________________________________________________
b. _________________________________________________________
c. _________________________________________________________
d. _____________________________________________________________
_____________________________________________________________
_____________________________________________________________
e. _____________________________________________________________
f. _____________________________________________________________
8) Lea: STOP APOLOGIZING ¿Cuál fue la enseñanza que Bill Gunther le enseñó al
autor cuando era un joven ingeniero de Sistemas de
IBM?______________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
¿Cuál es tu opinión al
respecto?_______________________________________________________________
______________________________________________________________________
______________________________________________________________________

Timeboxing for Top Team Performance Página 1 de 5

105

Timeboxing For Top Team Performance
by
Rick Zahniser

What’s your definition of a successful software project? How about this:
A successful software project delivers a quality product on time, within budget.
Time is always a factor in software development, and developers are always complaining about it.
“They didn’t give us enough time.”
“They didn’t let us estimate; they just told us when it was due.”
“We had to skip most of the system testing in order to deliver on time.”
Timeboxing grabs that problem by the horns and wrestles it to the ground. (Forgive me -- I’m from Colorado!) We
set an end time -- that is, a timebox -- and then adjust our scope so that we deliver what we can within the time
allotted. This presumes that the schedule is the most important aspect of the project, and frequently it is. Now
there are other aspects, including resources, development skill, scope and quality. Let’s look at these aspects
realistically, with an eye to managing them so that we look good!

The “Iron Triangle”
On a given project, resources are usually fixed; and unless you believe in the Mongolian Horde Approach (hire a
hundred people and hope some of them are good) the best team is a small one. Once you’ve put that team
together, you’ve established their capability, at least in the short run. Now you have three aspects to manage, as
shown in Figure 1.
Schedule: The time when the software product is due.
Scope: The functions and features delivered in the software product.
Quality: The absence of defects in the product.
I call these three “The Iron Triangle” because they have an immutable relationship. For example:
1. If we increase the scope, the schedule must grow, or the quality must decline.
2. If we shorten the schedule, we must decrease the scope or deliver with more defects.
The best timeboxing strategy holds quality constant and reduces scope to meet a schedule. Reducing scope flies
in the face of what I call “The World’s Greatest Program” syndrome -- the tendency on the part of developers to
put every great feature into the first release, even if it causes us to be late. (Roland Racko calls this creeping or
galloping elegance.) The customer always wants those features; they just don’t understand how much it will cost
them. I’d like to acquaint you with the facts, so you can feel good about leaving some features out when you’re
approaching the end of your timebox.

The last features
Those latest and greatest features cost more than you expect, and here’s why. Remember the 90:90 rule:
The first 90% of a system takes 90% of the time:
The last 10% takes the other 90% of the time!
That sounds like a joke, but Figure 2 shows why it’s true. As we approach 100% complete, our progress slows
down drastically. This is because we’re making tough decisions in the face of uncertainty. Moreover, they’re not
very good decisions. We will probably have to make many of them over again, when we have more information.
This last 10% also accounts for much of the arguing and fighting that goes on in a project. Timeboxing forces us
to forgo these last features, but it also lets us avoid most of the conflict that goes with them.
Pareto’s Law -- the old “80:20 rule” -- gives us another justification for procrastinating on those last features. In
the systems world, it predicts that:
20% of the system will give us 80% of the payback.
Now, in reality, this 20% only applies to a particular set of users. If we have a diverse set of users, we will have to

http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005


106
give each group a different 20%, but it’s reasonable to expect that we can please the vast majority of our users
with 80-90% of the features. Sooner or later, we’re going to deliver those last features, but not right now!

The right features
Making Pareto’s Law work for you may sound like magic, but there actually is a systematic way of finding out what
features you should deliver first. Ask your customers to rank the features they want. You can do this most easily
in a group meeting of customers and developers.
Write each feature on a Post-it®, put these on a whiteboard, and have the group rank them (1 is high, 10 is low.).
Then ask your developers to estimate how difficult each feature will be to implement (1 is easy, 10 is hard) and
multiply these two to give you a priority weight for each feature. On the whiteboard, build a matrix like the one I’ve
shown in Figure 3. It will show you, the team and the customers which features you should implement first and
which you might postpone. (Quality practitioners will recognize this process as a part of QFD or “Quality Function
Deployment.”)

Incremental Releases
This whole process of managing features is the best way to stage incremental releases of a software product. Jim
McCarthy, Program Manager for Microsoft C++ products, asserts that you can build customer confidence through
a series of timely releases, which delivers a steady stream of new features. To do this, he says you have to get
into a stable state, and be ready to ship at any time.
Here’s a strategy for delivering that first release:
1. Define your features.
2. Prioritize them.
3. Define three subsets:
• Gotta have
• Should have
• Nice to have
3. Build the ‘gotta have’ subset as a prototype. Define a timebox, start prototyping, and deliver what you have
when you run out of time. (Since it’s a prototype, you won’t have trouble explaining why it looks incomplete.)
4. Use this early experience with the prototype to define timeboxes for your first incremental release.
5. Stay within your timeboxes, delivering the features you have ready, on time.

Maintaining Quality
If you’re in a stable state, you have a much better chance of controlling quality. A couple of basic metrics will
demonstrate stability and dramatically improve your ability to deliver a quality product as you reach the end of a
timebox. You need Defects Discovered, and Defects Corrected for each time period (days or weeks.) Figure 4 is
a graph of these two measures; you can also derive (and graph) other important measures such as Defects
Remaining and Mean Time to Repair.
Who does this defect tracking and graphing? According to McCarthy, Microsoft has a ratio of one Quality
Assurance (QA) person for every two developers on the team. This graph is a great way for QA to highlight the
coordination between these two factions on your team.

You can timebox anything
So far, we’ve been talking about timeboxing for product delivery. As I began studying the literature on timeboxing
(see sidebar) I realized that I had been doing a form of timeboxing for over a decade. Training companies
frequently have a set format for their courses; for example, all of their courses may be four days long. To build a
course, you start with an overall four-day timebox, and break that down into smaller timeboxes to fit within breaks
and lunches. That realization led me to try timeboxing in our methodology experiments at CASELab. We put
every activity into a one-to two-hour timebox and gave the participants an opportunity to expand the box “a little”
but not more than 20%.
We found that you can timebox any development activity, from requirements definition, to system design, to



107
paper prototyping your screens. You define a time interval, and work within it. When you run out of time, you
stop, and move on. Of course, you have to be reasonable; you can’t do ten days of coding in a two-day timebox;
but you actually might able to build a prototype in three days. You won’t know until you try.

Stop apologizing!
Early in my career, as a young IBM Systems Engineer, I was working on a SPOOLing package with Bill Gunther,
an old software hand from Northrop Corporation. I suggested that, for some good reasons, we might be able to
slip the package we were working on a couple of weeks from its scheduled delivery date.
“NO!!” he said, vehemently. “People won’t remember why we were late; they will only remember that we were
late.”
That’s still true; it’s all too easy to get a reputation for always being late. If schedule is important in your software
shop, you CAN be on time, if you’ll simply manage the iron triangle properly. And timeboxing is a good way to do
that.

## Go to top Go to sidebar

FIGURES

Schedule

Scope Qualit y

Figure 1. The Iron Triangle



108

Figure 2. The 90/90 Rule

Feature Customer Delivery Priority
Rank Cost
Capture existing file 3 4 12
Create new records 1 1 1
Allocate new space interactively 5 9 45
Validate keys interactively 2 2 4
Validate all fields interactively 6 6 36
Recreate file from backup 3 4 12
Update file from journal 8 7 56
Modify existing records 1 3 3
Find record by primary key 1 2 2
Find record by secondary key 2 6 12
... etc... ... ... ...

Figure 3. Feature Priority Matrix



109

Figure 4. Defects found vs. Defects fixed.

Sidebar
Want to Learn More About Timeboxing?
The term ‘timebox’ was first used by Scott Shultz of DuPont, as a key component of Rapid Iterative Production
Prototyping (RIPP), a predecessor of RAD, which Shultz developed in the early 80’s. James Kerr and Richard
Hunter interview him in Inside RAD: How to build fully functional computer systems in 90 days or less. (McGraw-
Hill, 1994, pp. 14-16.)
In Rapid Application Development, James Martin calls timeboxing “a variant of RAD” and devotes an entire
chapter to it.(Prentice-Hall, 1991, Chapter 11.)
Without using the word “timeboxing”, Tom Gilb provides a cogent discussion of “Deadline pressure: how to beat
it” in Principles of Software Engineering Management (Addison-Wesley, 1988, Chapter 17.)
For more on QFD, see The Customer-Driven Company: Managerial Perspectives on QFD by William Eureka and
Nancy Ryan (American Supplier Institute, 1988.)
For an interesting discussion of creeping or galloping elegance, and incremental delivery, see Roland Racko’s
“Object Lessons: Joseph and the CD-ROM of Many Colors” (Software Development, September 1994.)
Jim McCarthy is a frequent speaker at Software Development and other national conferences. His talk “21 Rules
of Thumb for Delivering Quality Software on Time” is a classic, available on tape from Conference Copy, Inc.
717-775-0580. (Session 04, Conf. #698D)
Finally, Pascal Zachary’s Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at
Microsoft (Free Press, 1994) is must reading for any one who needs to understand the realities of the Iron
Triangle. (It’s also a GREAT read!)

About the Author. [Updated:] When this was written, Rick Zahniser was the founder & chairman of CASELab, a
startup which specialized in coaching software teams to world-class performance. In 1999, he decided to watch
the Turn of the Century from Belize, Central America. You can meet him and chat with him on his website
http://belizenorth.com.
Copyright, CASElab, 1995. All rights reserved.
Go to top


110

________________________

________________________
1
Agile Processes

The weather-cock on the church spire, though made of iron, would soon be broken by the
storm-wind if it did not understand the noble art of turning to every wind.

-- Heinrich Heine

Many of us have lived through the nightmare of a project with no process to guide it. The
lack of a process leads to unpredictability, repeated error, and wasted effort. Customers
are disappointed by slipping schedules, growing budgets, and poor quality. Developers are
disheartened by working ever longer hours to produce ever poorer software.
Once we have experienced such a fiasco, we become afraid of repeating the experi-
ence. A common response to fear is to create a process that we believe eliminates what we
are afraid of. We are afraid that
• The project will produce the wrong product.
• The project will produce a product of inferior quality.
• The project will be late.
• We’ll have to work 80 hour weeks.
• We’ll have to break commitments.
• We won’t be having fun.
Our fears motivate us to create a process that constrains our activities and demands
certain outputs and artifacts. We draw these constraints and outputs from past experience,
choosing things that appeared to work well in previous projects. Our hope is that they will
work again, and take away our fears.

7

111

Chapter : 8

But projects are not so simple that a few constraints and artifacts can reliably prevent
error. As errors continue to be made, we diagnose those errors and put in place even more
constraints and outputs in order to prevent those errors in the future. After many projects
we may find ourselves overloaded with a huge cumbersome process that greatly impedes
our ability to get projects done.
A big cumbersome process can create the very problems that it is designed to prevent.
It can slow the team to the extent that schedules slip and budgets bloat. It can reduce
responsiveness of the team to the point that they are always creating the wrong product.
Unfortunately this leads many teams to believe that they don’t have enough process. So, in
a kind of runaway process inflation, they make their process ever larger.
Runaway process inflation is a good description of the state of affairs of the software
industry circa 2000 A.D. Though there were still many teams operating without a process.
The adoption of very large heavyweight processes was rapidly growing; especially in
large corporations.

The Agile Alliance

In early 2001, motivated by the observation that software teams in many corporations
were stuck in a quagmire of ever increasing process, a group of industry experts met to
outline the values and principles that would allow software teams to develop quickly and
respond to change. They called themselves the Agile Alliance . Over two days they worked
to create a statement of values. The result was the manifesto of the Agile Alliance. Over
the next three months they continued to work together to create the principles of agility.

The Manifesto: a statement of agile values

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

~ Individuals and interactions over processes and tools ~
~ Working software over comprehensive documentation ~
~ Customer collaboration over contract negotiation ~
~ Responding to change over following a plan ~

That is, while there is value in the items on
the right, we value the items on the left more.

112

9 Chapter : :

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn
Ward Cunningham Martin Fowler James Grenning Jim Highsmith
Andrew Hunt Ron Jeffries Jon Kern Brian Marick
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland
Dave Thomas

Individuals and interactions over processes and tools. People are the most
important ingredient of success. A good process will not save the project from failure if
the team doesn’t have strong players; but a bad process can make even the strongest of
players ineffective. Even a group of strong players can fail badly if they don’t work as a
team.
A strong player is not necessarily an ace programmer. A strong player may be an
average programmer, but someone who works well with others. Working well with others,
communicating and interacting, is more important that raw programming talent. A team of
average programmers who communicate well are more likely to succeed than a group of
superstars who fail to interact as a team.
The right tools can be very important to success. Compilers, IDEs, source code con-
trol systems, etc., are all vital to the proper functioning of a team of developers. However,
tools can be overemphasized. An overabundance of big unwieldy tools is just as bad as a
lack of tools.
My advice is to start small. Don’t assume you’ve outgrown a tool until you tried it
and found you can’t use it. Instead of buying the top of the line, mega-expensive, source
code control system, find a free one and use it until you can demonstrate that you’ve out-
grown it. Before you buy team licenses for the best of all CASE tools, use white boards
and graph paper until you can unambiguously show that you need more. Before you com-
mit to the top-shelf behemoth database system, try flat files. Don’t assume that bigger and
better tools will automatically help you do better. Often they hinder more than they help.
Remember, building the team is more important that building the environment. Many
teams and managers make the mistake of building the environment first and expecting the
team to gel automatically. Instead, work to create the team, and then let the team configure
the environment on the basis of need.

Working software over comprehensive documentation. Software without docu-
mentation is a disaster. Code is not the ideal medium for communicating the rationale and
structure of a system. Rather, the team needs to produce human readable documents that
describe the system, and the rationale for their design decisions.
However, too much documentation is worse than too little. Huge software documents
take a great deal of time to produce, and even more time to keep in sync with the code. If
they are not kept in sync, then they turn into huge lies, and become a significant source of
misdirection.
I have no problem with a short rationale and structure document that the team pro-
duces and keeps in sync from month to month. But I want that document to be short and

113

Chapter : 10

salient. It should discuss the overall design rationale, and only the highest level structures
in the system.
If all we have is a short rationale and structure document, how do we train new team
members about the system? We work closely with them. We transfer our knowledge to
them by sitting next to them and helping them. We make them part of the team through
close training and interaction.
The two documents that are the best at transferring information to new team mem-
bers, are the code and the team. The code does not lie about what it does. It may be hard to
extract rationale and intent from the code; but the code is the only unambiguous source of
information. The team holds the ever-changing roadmap of the system in their heads.
There is no way to put that roadmap down on paper and transfer it to others that is faster
and more efficient than interaction with the team.
Many teams have gotten hung up in pursuit of documentation instead of software.
This is often a fatal flaw. There is a simple rule that prevents it:
Produce no document unless its need is immediate and significant.

Customer collaboration over contract negotiation. Software cannot be ordered
like a commodity. You cannot write a description of the software you want and then have
someone develop it on a fixed schedule for a fixed price. Time and time again, attempts to
treat software projects in this manner have failed. Sometimes the failures are spectacular.
It is tempting for the managers of a company to tell their development staff what their
needs are, and then expect that staff to go away for awhile and return with a system that
satisfies their needs. But this mode of operation leads to poor quality and failure.
Successful projects involve customer feedback on a regular and frequent basis. Rather
than depending upon a contract, or a statement of work, the customer of the software
works closely with the development team, providing frequent feedback on their efforts.
A contract that specifies the requirements, schedule, and cost of a project is funda-
mentally flawed. In most cases the terms it specifies become meaningless long before the
project is complete. The best contracts are those that govern the way the development
team and the customer will work together.
As an example of a successful contract, in 1994 I negotiated a contract for a large,
multi-year, half-million-line, project. We, the development team, were paid a relatively
low monthly rate. Large payouts were made to us when we delivered certain large blocks
of functionality. Those blocks were not specified in detail by the contract. Rather the con-
tract stated that the payout would be made for a block when the block passed the cus-
tomer’s acceptance test. The details of those acceptance tests were not specified in the
contract.
During the course of this project we worked very closely with the customer. We
released the software to him almost every Friday. By Monday of Tuesday of the following
week he would have a list of changes for us to put into the software. We would prioritize
those changes together, and then schedule them into subsequent weeks. The customer

114

11 Chapter : :

worked so closely with us that acceptance tests were never an issue. He knew when a
block of functionality satisfied his needs because he watched it evolve from week to week.
The requirements for this project were in a constant state of flux. Major changes were
not uncommon. There were whole blocks of functionality that were removed, and others
that were inserted. And yet the contract, and the project, survived and succeeded. The key
to this success was the intense collaboration with the customer; and a contract that gov-
erned that collaboration rather than trying to specify the details of scope and schedule for a
fixed cost.

Responding to change over following a plan. It is the ability to respond to change
that often determines the success or failure of a software project. When we build plans, we
need to make sure that our plans are flexible and ready to adapt to changes in the business
and technology.
The course of a software project cannot be predicted far into the future. There are too
many variables to account for. We simply aren’t very good at estimating the cost of a large
project. The business environment that the software must serve is likely to change during
the course of development. It is difficult to write reliable requirements. Customers are
likely to alter the requirements once they see the system start to function.
It is tempting for novice managers to create a nice PERT or Ghant chart of the whole
project, and tape it to the wall. They may feel that this chart gives them control over the
project. They can track the individual tasks and cross them off the chart as they are com-
pleted. They can compare the actual dates with the planned dates on the chart and react to
any discrepancies.
But what really happens is that the structure of the chart degrades. As the team gains
knowledge about the system, and as the customer gains knowledge about their needs, cer-
tain tasks on the chart will become unnecessary. Other tasks will be discovered and will
need to be added. In short, the plan will undergo changes in shape, not just changes in
dates.
A better planning strategy is to make detailed plans for the next few weeks, very
rough plans for the next few months, and extremely crude plans beyond that. We should
know the tasks we will be working on for the next few weeks. We should roughly know
the requirements we will be working on for the next few months. And we should have a
only a vague idea what the system will do after a year.
This decreasing resolution of the plan means that we are only investing in a detailed
plan for those tasks that are immediate. Once the detailed plan is made, it is hard to change
since the team will have a lot of momentum and commitment. But since that plan only
governs a few weeks worth of time the rest of the plan remains flexible. The lower resolu-
tion parts of the plan can be changed with relative ease.

115

Chapter : 12

Principles

The above values inspired the following twelve principles. These principles are the char-
acteristics that differentiate an agile process.
• Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
The MIT Sloan Management Review published an analysis of software development
practices that help companies build high quality products 1. The article found a num-
ber of practices that had a significant impact upon the quality of the final system. One
was a strong correlation between quality, and the early delivery of a partially func-
tioning system. The article reported that the less functional the initial delivery, the
higher the quality in the final delivery.
Another finding of this article was a strong correlation between final quality and fre-
quent deliveries of increasing functionality. The more frequent the deliveries, the
higher the final quality.
An agile process is one that delivers early and often. We strive to deliver a rudimen-
tary system within the first few weeks of the start of the project. And we strive there-
after to continue to deliver systems of increasing functionality every few weeks.
Customers may choose to put these systems into production if they think they are
functional enough. Or they may choose simply to review the existing functionality
and report on changes they want made.
• Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
This is a statement of attitude. The participants in an agile process are not afraid of
change. They view changes to the requirements as good things, because they mean
that the team has learned more about what it will take to satisfy the market.
An agile team works very hard to keep the structure of their software flexible, so that
when requirements change, the impact to the system is minimal. Later in this book we
will learn the principles of object oriented design that help us to maintain this kind of
flexibility.
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter time scale.
We deliver working software. And we delivery it early and often. We are not content
with delivering bundles of documents, or plans. We don’t count those as true deliver-
ies. Our eye is on the goal of delivering software that satisfies the customer’s needs.

1. Product-Development Practices That Work: How Internet Companies Build Software , MIT Sloan Management Review,
Winter 2001, Reprint number 4226

116

13 Chapter : :

• Business people and developers must work together daily throughout the project.
In order for a project to be agile, there must be significant and frequent interaction
between the customers, developers, and stakeholders. An agile project is not like a
fire-and-forget weapon. An agile project must be continuously guided.
• Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
An agile project is one in which people are considered the most important factor of
success. All other factors, process, environment, management, etc., are considered to
be second order effects, and are subject to change if they are having an adverse effect
upon the people.
For example, if the office environment is an obstacle to the team, the office environ-
ment changes. If certain process steps are an obstacle to the team, the process steps
change.
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
In an agile project, people talk to each other. The primary mode of communication is
conversation. Documents may be created, but there is no attempt to capture all project
information in writing. An agile project team does not demand written specs, written
plans, or written designs. They may create them if they perceive an immediate and
significant need, but they are not the default. The default is conversation.
• Working software is the primary measure of progress.
Agile projects measure their progress by measuring the amount of software that is
working. They don’t measure their progress in terms of the phase that they are in, or
by the volume of documentation that has been produced, or by the amount of infra-
structure code they have created. They are 30% done when 30% of the necessary
functionality is working.
• Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
An agile project is not run like a 50 yard dash; it is run like a marathon. The team does
not take off at full speed and try to maintain that speed for the duration. Rather they
run at a fast, but sustainable, pace.
Running too fast leads to burnout, shortcuts, and debacle. Agile teams pace them-
selves. They don’t allow themselves to get too tired. They don’t borrow tomorrow’s
energy to get a bit more done today. They work at a rate that allows them to maintain
the highest quality standards for the duration of the project.

117

Chapter : 14

• Continuous attention to technical excellence and good design enhances agility.
High quality is the key to high speed. The way to go fast is to keep the software as
clean and robust as possible. Thus, all agile team-members are committed to produc-
ing only the highest quality code they can. They do not make messes and then tell
themselves they’ll clean it up when they have more time. If they make a mess, they
clean it up before they finish for the day.
• Simplicity--the art of maximizing the amount of work not done--is essential.
Agile teams do not try to build the grand system in the sky. Rather they always take
the simplest path that is consistent with their goals. They don’t anticipate tomorrow’s
problems and try to defend against them today. Rather they do the simplest and high-
est quality work today, confident that it will be easy to change if and when tomorrows
problems arise.
• The best architectures, requirements, and designs emerge from self-organizing teams.
An agile team is a self organizing team. Responsibilities are not handed to individual
team members from the outside. Rather, responsibilities are communicated to the
team as a whole, and the team determines the best way to fulfill them.
Agile team members work together on all aspects of the project. Each is allowed input
into the whole. No single team member is responsible for the architecture, or the
requirements, or the tests, etc. The team shares those responsibilities and each team
member has influence over them.
• At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
An agile team continually adjusts its organization, rules, conventions, relationships,
etc. An agile team knows that its environment is continuously changing, and knows
that they must change with that environment to remain agile.

Conclusion

The professional goal of every software engineer, and every development team, is to
deliver the highest possible value to our employers and customers. And yet, our projects
fail, or fail to deliver value, at a dismaying rate. Though well intentioned, the upward spi-
ral of process inflation is culpable for at least some of this failure. The principles and val-
ues of agile software development were formed as a way to help teams break the cycle of
process inflation, and to focus on simple techniques for reaching their goals.

02/11/2009
118

Product Backlog para un Sprint de
59 minutos
• Este backlog posee un número de “items” a considerar para
completar un Sprint (iteración).
• El equipo puede decidir, junto con el Product Owner (el
instructor), cual es el tema u objetivo del Sprint.
• El Product Owner decidirá el orden de prioridad de los
items.
• El equipo deberá enfocarse en no más de 5 “items” para el
demo del Sprint.
• Se hará algo creativo (comercial, folleto, stand, poster).

Backlog para turismo espacial-Marte
visita la Tierra
• Crear la portada, marca y/o logo
• Definir los tópicos mayores para el turismo marciano.
• Describir el tour “El Arte en Europa”.
• Describir un tour basado en el folklore.
• Esquematizar una expedición a las “7 maravillas del mundo antiguo”.
• Definir los mensajes de “warning” (gravedad, oxígeno, etc.)
• Sugerir opciones de vestuario.
• Explicar las opciones de viaje hacia/desde Marte.
• Describir un tour “Deportes humanos”.
• Esquematizar la política de devoluciones.
• Sugerir servicios relacionados.
• Definir los medios de publicación.
• Definir una campaña de 12 meses.
• Establecer la forma de obtener más información.
• Definir los precios de los tours.

1

Manual01

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Manual01 (20)

Más de Ricardo Quintero (20)

Último (20)

Manual01