Métodos Ágiles

Mtodos giles-Scrum y XP
Object-Oriented Technology Training

Dr. Ricardo R. Quintero Meza

1

Repositorio en lnea de Material
Adicional
o http:/ / tinvurl.com/ cursoaqil

Dr. Ricardo Quintero
^ El Desarrollo Iterativo y M
Evolutivo: Serum y XP

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

(7

l

Al construir un telfono celular es posible definir, sin ambigedades, sus
especificaciones y pasos de construccin.
Despus de alguna experiencia en la construccin de telfonos es posible hacer
estimaciones confiables de
costo y tiempo de futuros telfonos a construir.
^ Temas

V | bi Motivacin : : : j

o Desarrollo Iterativo

o Planeacin iterativa dirigida por los

riesgos y por el cliente

o El principio de "Time boxing"

o Desarrollo evolutivo y adaptativo

o Entrega incremental

o Entrega evolutiva

o Los errores ms comunes 3


3

Suponga una persona que desea construir una casa "a la
medi daSe quieren utilizar materiales y mtodos ecolgicos,
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.
DesarrollarSoftwareesDesarrollar
nuevosproductos


Manufactura en masa o
Manufactura
predecible:
Desarrollo de nuevos productos o
proyectos con alto nivel de
inventiva:
Predictibilidad de proyectos
Niveles bajos de cambio o novedad
con altos niveles de creacin
idntica o casi idntica
Alto grado de novedad,
creatividad y cambio sin
experiencia previa de casos
idnticos a partir de los cuales
estimar o derivar planes
confiables

4
Proyectospredeciblesynopredecibles

Enquecategoracaeelsoftware?
Desarrollar software no es un problema de
manufactura en masa o predecible.
El desarrollo de software cae en la
categora de desarrollo de un producto
nuevo.

P. Predecibles P. No predecibles
Al principio es posible definir sus
especificaciones y despus construir
Raramente es posible crear una
especificacin detallada y no
cambiante
Al inicio, se puede estimar de forma
confiable el esfuerzo y el costo
Al principio no es posible. Conforme
van surgiendo datos empricos,
incrementalmente va siendo posible
planear y estimar
Es posible identificar, definir,
calendarizar y establecer
detalladamente el orden de todas las
actividades
Al principio, no es posible. Se requieren
pasos adaptativos conducidos por
ciclos construir- retroalimentar
La adaptacin al cambio no predecible
no es la norma y la razn de cambio es
relativamente baja
La adaptacin creativa para los
cambios no previstos es la norma. La
razn de cambio es alta.

Muchos proyectos utilizan tecnologas nuevas (y no sencillas) que incrementan el
grado de novedad y no predictibilldad.
Estas tecnologas llevan a un inexperto a situaciones semejantes a las de la
construccin de un nuevo producto, an cuando tenga experiencia precia
Porlotanto
o Debido a que el paradigma de manufactura
predecible es el
incorrecto para desarrollar software
entonces ...
Las prcticas y valores que tienen sus races
en el mismo no resultan tiles.
Considere el enfoque de cascada


o Especificacin predictiva de las
especificaciones, o 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 razn de
cambio y novedad.
Ejercicio: Por qu estimaciones
predictivas fallan?
o Usando el artculo de Parnas y
Clemens (1986) realice el ejercicio
Porgu las estimaciones predictivas
fallan?

Por qu las estimaciones predictivas
fallan? o Parnas y Clemens (1986) nos
dan razones:
Los clientes o usuarios suelen no estar
seguros (de forma precisa) lo que quieren.
Les resulta difcil establecer todo lo que
quieren y desean.
Muchos de los detalles de lo que
realmente quieren solamente se revela al
momento del desarrollo.
Por qu estas estimaciones
predictivas de estimacin fallan?
o (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.
La motivacin de los mtodos giles
o La motivacin principal para los mtodos giles e
iterativos
subyace en la apreciacin de que:
La actividad de construir software es compleja,
con alto nivel de cambio y con naturaleza no
predecible

Pero tambin son motivados por el deseo de
competir y ganar
o Los mtodos giles e iterativos impulsan
flexibilidad y maniobrabilidad: ventajas
competitivas.
Mtodos giles-Scrum y XP 9

9

^ Pero tambin son motivados por el

^ deseo de competir y ganar

o Goldman y Preiss en su

libro Agile competitors and
VirtuafOrganizations: Strategies for Enriching the r
Customer nos ensean: AGIL
E
COHPfTITORS

"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"
VIRTUAL
ORGANIZATIO
NS
smmXittwKNHOUNG
CUSTOMER
Steven L. Goldman
Roger N. Nagel
a Kenneth Preiss , us
i*ff jQy
17
^RecursosWeb
o www.aqilealliance.com

o www.cetus-links.orq

o www.bradapp.net

o alistair.cockburn.us

o www.martinfowler.com

18

Temas
o Motivacin
Desarrollo Iterativo
Planeacin iterativa dirigida por los
El principio de "Time boxing"
Desarrollo evolutivo y adaptativo
Entrega incremental
Entrega evolutiva
Los errores ms comunes
Desarrolloiterativo
Los mtodos giles son un subconjunto de los
mtodos 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 iteracin es un mini-proyecto auto-
contenido compuesto por actividades como
anlisis de requisitos, diseo, programacin y
pruebas.

Desarrolloiterativo
El objetivo final de una iteracin es obtener un
re/ease de iteracin: un sistema parcial estable,
integrado y probado.
Es decir: Todo el software a travs de todos los
equipos de desarrollo se integra en un release en
cada iteracin.
Los release pueden ser internos (para el equipo
de desarrollo) o externos (para el cliente).
Desarrollo iterativo e incremental (I ID)

La retroalimentacin (feedback) de la iteracin Ndirige el
refinamiento y adaptacin de los requisitos y el diseo en la
iteracin N+l
Una iteracin de 3
semanas
El Sistema crece
incrementalment
e
RELEASE
AL
CLIENTE

1
2
Longitud de las iteraciones
o Muchos proyectos tienen al menos tres
iteraciones antes de un release pblico
final, o En los mtodos modernos:
La longitud recomendada de una iteracin
oscila entre 1 y 6 semanas.
Disciplinas a travs de las iteraciones

Ths s -are is
r..iqnpr.tivr,
ntf liter.

Deptoymerc
Corgu-
iicirChaiQ?

A cur-week Nation <f or n-amp*)
/. miri-pnjrr: th.il nrl.irtrr.
y.o-V n nov d 5C2lr5s,e'r.rq r
a stable ?:<e:..1ab a
____ s _____
Natethac
akhsugh
t?rat en n:
_d?s - I
rt'.rr.l,rrS:he
rative t
!
s1
and
emphasis
chacos

Temas
o Motivacin o Desarrollo Iterativo
o; Planeacin iterativa dirigida por los riesgos
y por el cliente
o El principio de "Time boxing" o Desarrollo
evolutivo y adaptativo o Entrega incremental
o Entrega evolutiva o Los errores ms
comunes
Planeacin iterativa dirigida por el
cliente y por el riesgo
o Qu hacer en cada iteracin?
Los mtodos 11 D promueven una combinacin
de prioridades dirigida por el cliente y por los
riesgos.

o Desarrollo iterativo dirigido por los
riesgos:
Seleccione los elementos ms
riesgosos y difciles para las
primeras iteraciones.
Ej.- Un cliente podra decir: "Deseo que las pginas
Web sean en color verde y que el sistema maneje
5,000 transacciones simultneas"


El color verde puede esperar por tanto se
buscara resolver primero el volumen de
transacciones
Desarrollo iterativo dirigido por el cliente:
La eleccin de caractersticas para cada iteracin
debe venir del cliente -cualquiera que sea lo que
l considera de mayor valor.

De esta forma el cliente conduce el proyecto,
iteracin por iteracin, solicitando las
caractersticas que en ese momento considera de
mayor valor para el negocio.
o Desarrollo iterativo dirigido por el cliente
(cont...):
De esta forma el cliente adaptativamente planea la
seleccin para la siguiente iteracin, brevemente antes
de iniciarla, basado en la experiencia adquirida en la
iteracin previa, ms que de forma especulativa al
inicio del proyecto.
Conforme nueva informacin va surgiendo el cliente va
percibiendo control y capacidad de decisin.


o Aplique ambas tcnicas...
Porque:
o Los clientes no siempre son capaces de percibir
lo que tcnicamente es ms difcil o riesgoso,
o Los desabolladores no siempre aprecian lo
que es de ms alto valor para el negocio.

Ejercicio-EI principio de Timeboxing
o Lea el artculo Time boxing for top
team performance. o Resuelva el
ejercicio El principio de Timeboxing.
ElprincipiodeTmeBoxing
o Timeboxinq:
Es la prctica de mantener fija la fecha final
de la iteracin y no permitir cambios.
Este principio debera aplicar tambin para la fecha
final de todo el proyecto.
o Si eventualmente sucediera que las solicitudes hechas
(alcance) para una iteracin no pueden satisfacerse
dentro del timebox, entonces en lugar de cambiar la
fecha final, el alcance se reduce (colocando las
prioridades de ms bajo riesgo al final de la lista de
"deseos").
^ Temas
Hi | o Motivacin
o Desarrollo Iterativo o Planeacin iterativa
dirigida por los riesgos y por el cliente

( o El principio de "Time boxing"

o Desarrollo evolutivo y adaptativo o Entrega
incremental o Entrega evolutiva o Los errores
ms comunes
31

LongituddelTimeBox
o No todos los Time-box necesitan ser guales:
La primer iteracin puede ser 4 semanas.
La segunda iteracin 3 semanas, etc. o Como ya
mencionamos la longitud
recomendada es: 1 a 6 semanas.
^ElprincipiodeTimeBoxing

o 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 terminacin. Si el paso normal
de trabajo es insuficiente, haga menos.

34

LongituddelTimeBox
Se ha demostrado que Pasos cortos poseen:
Menor complejidad.
Menor riesgo.
Mejor retroalimentacin.
Ms alta productividad.
Mayor razn de xito.
Todos los mtodos modernos (incluyendo Serum o XP o UP)
requieren o recomiendan aplicar Timeboxing a las
iteraciones.
Mtodos
giles-
Scrum y XP

Alcance
(tareas)
Calidad
19
TimeBoxing

Tiempo Tiempo, alcance, recursos
y calidad son las 4 variables comunes con las
que se puede jugar en un proyecto.
Timeboxing remueve el tiempo de estas
opciones durante una iteracin
Recurso Recuerde el "I ron
(gente) Triangle"!
37

Beneficios del Time-Boxing
o Enfoque: El enfoque psicolgico que
promueve una fecha de terminacin fija de 3
semanasesmuydiferentealquepromueveuna
de 3 meses. Time boxing es un antidoto a la
Ley de Parkinson: "El trabajo se expande
para ocupar todo el tiempo disponible"
oLas personas recuerdan ms fechas
postergadas que caractersticas
postergadas: esuncaprichodela
naturalezahumana.

38

feedback
En Timeboxing, la
variable tiempo en
cada iteracin se
mantiene fija
V
1 iteracin de 3 semanas
"timeboxed". La fecha final no se
cambia.
Construye para
algunos requisitos
O
1 iteracin de 2 semanas
"timeboxed". La fecha final no se
cambia.
Construye para
algunos requisitos
O
j

BeneficiosdelTime-Boxing
o Obliga a atacar niveles pequeos de complejidad: la
investigacin ha demostrado que pasos de
complejidad baja se realizan ms productivamente, o
Obliga a tomar decisiones difciles y de
compensacin tempranamente : se obliga a ser
realista en lo que se har y en lo que no se har.
Obliga al manejo de prioridades.
Durante la iteracin, ningn cambio de los
Stakeholder externos
o Los mtodos giles e iterativos enfrentan el cambio,
pero no el caos, o Esto se logra con la siguiente regla:
Una vez que se han determinado las solicitudes para una
iteracin y estas se estn llevando a cabo, ningn
stakeholder externo puede cambiar el trabajo.
Durante la iteracin, ningn cambio de los
Stakeholder externos
o No se vale que el administrador del producto (por
decir alguien) diga: "Pueden hacer esto tambin?"
Deber esperar a la siguiente iteracin. Sin
embargo, el equipo puede reducir el mbito
de la iteracin si a la fecha final del timebox
no se puede lograr.

^ Temas
1 o Motivacin
o Desarrollo Iterativo o Planeacin iterativa
dirigida por los riesgos y por el cliente o El
principio de Time boxing"

|
:
ks Desarrollo evolutivo y adaptativo

o Entrega incremental o Entrega evolutiva o Los errores
ms comunes
42

Desarrolloevolutivoyadaptativo
o 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 maysculo de especificacin
antes de que el desarrollo iterativo empiece.
Los mtodos evolutivos son consistentes con el patrn de
descubrimiento y cambio no predecible en el desarrollo de un nuevo
producto.
Desarrolloevolutivoyadaptativo
o Desarrollo adaptativo:
Es un trmino relacionado con
evolutivo.
Implica que los elementos se adaptan en
respuesta al "feedback" del trabajo anterior -
"feedback" de usuarios, testers, desabolladores,
etc.
o La intencin es la misma que en el desarrollo evolutivo, pero el
nombre sugiere un mecanismo ms fuerte de repuesta-
feedback en la evolucin.
Anlisisevolutivoderequisitos
o En el desarrollo evolutivo y adaptativo no se trata de
que los requisitos estn "sin lmite" o "cambiantes
continuamente", o Al contrario, mucho del
descubrimiento y refinamiento ocurre durante las
primeras iteraciones, o La rpida atencin en estas
iteraciones tiene como propsito entender los
requisitos arquitectnicamente ms significativos o
de ms alto valor al negocio.

Anlisisderequisitosevolutivo

C0ST- or ^ , SCHEDULE many estimates and schedules
are
ESTIMATES
prematurely defined at this
time
but this is the
realistic period for
reliability
0.25x I
_______________ |
_ iter 1 iter 2 - time
Mayor informacin: COCOMQ 2.0
'4.Ox
Planeacinevolutivayadaptativa
Igual que con los requisitos, la planeacin
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
informacin 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)
ElConodeIncertidumbre
EFFORT,

o
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.
Respuesta iterativa a la incertidumbre
o Esto es consistente con otras prcticas administrativas en otros
dominios de desarrollo de nuevos productos, donde es comn
una fase exploratoria inicial, o An ms, se motiva a la planeacin
adaptativa ms que a la planeacin predictiva. o Es decir, una
planificacin detallada no se crea hasta que se ha avanzado ms
all de un breve tiempo, de tal manera que el nivel de detalle y
compromiso se consensa con la calidad de la informacin.

EFFOR
T.
COST,
or
SCHED
ULE
ESTIMA
TES
Phase2FixedPnce
Contratos de precio fijo
o Con respecto a hacer una oferta de
precio fijo y estimaciones evolutivas,
algunos mtodos 11D recomiendan
realizar el proyecto con un contrato
de dos fases, cada uno de mltiples
iteraciones "timeboxed".
Contrato de dos fases
- 3requirementswortshocs
- software ovolopmcot to bu4d a ir architosturo and obtain
formationlorfuturoestimation.
10%Of
thefinal
software
o
- Rcatticaty
only 7S% d the
detailed
requirement,
orle:

Contratodedosfases
o Primera fase:
Un contrato relativamente pequeo de tiempo fijo y precio fijo,
con el objetivo de cumplirse en unas cuantas iteraciones,
haciendo desarrollo temprano (pero parcial) de software y
anlisis evolutivo de requisitos.
o El resultado de la fase - incluyendo el software base- se comparte
con los clientes para el contrato de precio fijo de la segunda
fase, o El refinamiento evolutivo de las especificaciones y cdigo
en la fase uno ofrece datos de mayor calidad para los estimadores
de la fase dos y al mismo tiempo ofrece avances del software.
^Temas

o Motivacin o Desarrollo Iterativo o Planeacin
iterativa dirigida por los riesgos y por el cliente o
El principio de "Time boxing" o Desarrollo
evolutivo y adaptativo


o Entrega evolutiva o Los errores ms comunes
54

2
8
Entrega incremental
oEs la prctica de entregar
repetidamente un sistema a
produccin (o al mercado) en una
serie de capacidades extendidas.
Es una prctica promovida por los
mtodos giles e 11 D.
oLas entregas ncrementales son en un
rango de 3 a 12 meses.

55

Entrega incremental

Esta prctica no debe confundirse con el desarrollo iterativo. Un ciclo de
entrega de 6 meses podra componerse por 10 iteraciones. El resultado de
cada iteracin no se libera al mercado, pero los resultados de una entrega
s
56

iteration1 iteration2
c
3wocks
O
3wooks
iteration1 iteration2

4 weeks 2weeks
Jan-June
Incremental
Delivery1
iteration10
deliver
July-Dec
Incremental
Delivery2
iteration7
deliver
o
o

Entregaevolutiva
Es un refinamiento de la entrega
incremental.
Con la diferencia de que aqu existe un inters
muy marcado por obtener "feedback"
respecto al producto instalado y usar este
"feedback" para guiar la siguiente entrega.
El objetivo es conocer necesidades difciles
de predecir.
Recomendacin: hacer una mezcla de ambas
prcticas.
EntregaIncrementalvs.Evolutiva
o En la Entrega Incremental hay un plan definido para las
entregas futuras (el "feedback" no conduce el plan de
entregas).
o En la Entrega Evolutiva no hay plan (o al menos no uno fijo) de
entregas futuras; cada una es creada dinmicamente en base
a la informacin que va surgiendo.
Temas
o Motivacin o Desarrollo Iterativo o Planeacin iterativa dirigida
^Temas
V o Motivacin

o Desarrollo Iterativo

o Planeacin iterativa dirigida por los


o El principio de "Time boxing"

o Desarrollo evolutivo y adaptativo


[: o tntrega evolutiva

o Los errores ms comunes

57

por los riesgos y por el cliente o El principio de "Time boxing" o
Desarrollo evolutivo y adaptativo o Entrega incremental o
Entrega evolutiva o Los errores ms comunes

31 Dr. Ricardo Quintero
Elerrormscomn
o Lderes de proceso iterativos y giles continuamente ven escenarios as:
Lder: Seguro, nosotros no aplicaremos la cascada- ya sabemos que no funciona.
Adoptaremos el mtodo <X> y estamos ante nuestro primer proyecto. Ya hemos
estado trabajando durante dos meses y hemos terminado prcticamente el
anlisis de los casos de uso y la planificacin y programacin de lo que iremos
haciendo en cada iteracin. Despus de revisar y aprobar los requisitos finales y
la programacin de iteraciones, empezaremos a programar ...
Ups !
Elerrormscomn
o Esta es una profunda falta de entendimiento del
mtodo y una sobreimposicin de los mtodos
de cascada en los mtodos iterativos, o Suele ser
uno de los errores ms comunes. Evtalo.

Mtodositerativos
o Los mtodos iterativos precedieron a los giles, o
Los mtodos iterativos pueden o no ser
considerados giles.
Mtodositerativos
o Ejemplos:
Evo (el primero, inici en los 1960s)
UP (desarrollado a mediados de los 1990s) Microsoft Solutions
Framework, (una descripcin de las mejores prcticas usadas por
Microsoft)
OPEN de Henderson-Sellers, FireSmith y Graham
Modelo de espiral WinWin o Modelo de espiral MBASE de Barry
Bohem.

33
Lecturas recomendadas

The Mythical Man- Month-
Frederick Brooks. La edicin
de plata de este clsico
discute las ventajas de IID,
adems de muchas otros
temas muy interesantes
Rapid Devlopment-
Steve McConell.
Examina variaciones del
desarrollo iterativo.
RAPID
---------------
DEVELOPMENT ^
iihnUn
Steve
McConnell

Agenda
[Desarrollo gil : ~~]
o Clasificacin de los mtodos o Los principios y el manifiesto gil o
Gestin de proyectos giles o Abrazando la comunicacin y la
retroalimentacln o Prcticas y herramientas de proyectos
simples o Procesos empricos VS Procesos definidos y
prescriptivos o Disciplina de sustentabllidad:el roce humano,
o El equipo como un Sistema Complejo Adaptatlvo.

Dr. Ricardo Quintero 2

Desarrollo gil
o Los Mtodos giles aplican: Desarrollo evolutivo e
iterativo timeboxed".
Planeacin adaptativa.
Promueven entregas evolutivas. Incluyen otros valores y
prcticas que motivan la agilidad-respuestas rpidas y flexibles
al cambio.

Desarrollo gil
o No es posible definir exactamente a los Mtodos giles, porque sus
prcticas especficas varan, o Pero las siguientes prcticas son
compartidas por diversos mtodos: Iteraciones pequeas "timeboxed".
Refinamiento adaptativo y evolutivo de planes y objetivos
Desarrollo gil
o Adems los Mtodos giles
promueven prcticas y principios que reflejan una "sensacin de
agilidad" como: simplicidad, ligereza, comunicacin, equipos
autodirigidos, programacin sobre documentacin y ms.
^ Desarrollo gil
HrioSu lema es:

Enfrentar el cambio.

oSu punto estratgico es:

Maniobrabllidad

4

4
Ejemplo de prcticas giles en Serum
o Ejemplos de prcticas giles en Serum (que estudiaremos ms al
detalle posteriormente) son:
Un lugar comn para el proyecto.
Equipos auto-dirigidos que se coordinan a travs de reuniones diarias con
preguntas concretas que cada miembro responde.
Ejemplo de prcticas giles en XP
oEjemplos de prcticas giles en XP (que estudiaremos ms adelante) son:
Usar notas concisas en papel (story cards) para sumarizar requisitos.
Programar en parejas.
Trabajar en un lugar comn con participacin de tiempo completo de
"proveedores de requisitos" para que los requisitos escritos puedan
complementarse con explicaciones verbales.


5
IterativoVSgil
Como concepto de proceso de software,
"gil" es ms nuevo que el enfoque
"iterativo".
Muchos mtodos IID (Evo o UP) no fueron
diseados como giles en su definicin original,
pero se pueden aplicar en un espritu gil.
Aunque podramos imaginar mtodos IID no-
giles, la mayora (por no decir todos) estn
adoptando los valores y prcticas giles -es
raro que alguien promueva la no-agilidad.
Agenda
o Desarrollo gil
o [Clasificacin de los mtodos o Los
principios y el manifiesto gil o Gestin
de proyectos giles
o Abrazando la comunicacin y la retroalimentacin o
Prcticas y herramientas de proyectos simples o
Procesos empricos VS Procesos definidos y
prescriptivos o Disciplina de sustentabilidad:el roce
humano, o El equipo como un Sistema Complejo
Adaptativo.


6 Dr. Ricardo Quintero
Clasificacindelosmtodospor
ceremoniayciclos
Agenda
o Desarrollo gil o Clasificacin de los mtodos o
[Los principios y el manifiesto gil
o Gestin de proyectos giles o Abrazando la
comunicacin y la retroalimentacin o Prcticas y
herramientas de proyectos simples o Procesos empricos
VS Procesos definidos y prescriptivos o Disciplina de

Estrictamente
cascada(secuencial)
El peso del mtodo en
trminos de
documentacin pasos
formales, revisiones, etc.
Pocos documentos
Pocos pasos
Muchos documentos
Muchos Pasos formales
Muchas iteraciones
pequeas (5 das)

sustentabilidad: el roce humano, o El equipo como un
Sistema Complejo Adaptativo.

7
El Manifiesto gil
Manifiesto (segn diccionario RAE):
Escrito en que se hace pblica declaracin de doctrinas o
propsitos de inters general.
El 2001 un grupo interesado en los mtodos giles e iterativos
acuaron el trmino.
Se reunieron para formar la Alianza gil (www.aqilealliance.com)
con un Manifiesto y un conjunto de estatutos de principios.
stos guan la gestin de proyectos giles.
Valores del Manifiesto gil
o "I ndividuos e interacciones sobre procesos y herramientas.
o Software trabajando sobre documentacin de comprensin.
o Colaboracin del cliente sobre negociacin de contrato.
o Respuesta al cambio sobre seguir un plan.
Es decir, si bien existe valor en los segundos elementos, valoramos
los primeros ms


Ejercicio-ElManifiestogil
Lea el Manifiesto Agil 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 "araa" con los puntos ms
importantes que lo justifican. Se pega la "araa" en las
paredes.
Cada equipo expondr al resto su doctrina
correspondiente. Cada equipo comentar su punto de vista
sobre la doctrina. Discusin y comentarios.
Se toman fotos digitales a cada araa y se distribuyen entre
los participantes.
Principios giles (leeremos las
justificaciones en el Manifiesto)
1. Nuestra ms alta prioridad es satisfacer al cliente a
travs de entregas continuas y tempranas de
software valuable.
2. Bienvenidos los cambios de requisitos an 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
Principiosgiles
La gente del negocio y los desabolladores deben
trabajar en conjunto diariamente a lo largo del
proyecto.
Construye el proyecto con gente motivada. Dales
el ambiente y soporte necesario y confa en que
harn bien el trabajo.
El mtodo ms eficiente y efectivo para conllevar
informacin hacia y dentro el equipo de desarrollo
es la conversacin cara-a-cara.

Principiosgiles
Software trabajando es la medida principal de
progreso.
Los procesos giles promueven el desarrollo
sustentable.
Los patrocinadores, desabolladores y usuarios
deben mantener una paz constante
indefinidamente.
Atencin constante a la excelencia tcnica y
el buen diseo aumenta la agilidad.
Principiosgiles
Simplicidad-el arte de maximizar el monto de
trabajo no hecho-es esencial. Las mejores
arquitecturas, requisitos y diseos emergen a
partir de equipos auto-organizados.
A intervalos regulares, el equipo reflexiona sobre
como ser ms efectivo, acorde a lo cual ajusta su
comportamiento.
Agenda
o Desarrollo gil o Clasificacin de los
mtodos o Los principios y el manifiesto gil
o |;(3estin de proyectos giles
o Abrazando la comunicacin y la retroalimentacin o Prcticas
y herramientas de proyectos simples o Procesos empricos VS
Procesos definidos y prescriptivos o Disciplina de
sustentabilidad:el roce humano, o El equipo como un Sistema
Complejo Adaptativo.

Gestin de proyectos giles
o Aunque ms adelante veremos prcticas
concretas de gestin de proyectos giles (en
Serum y XP). Hay generalizaciones comunes a
todos los mtodos, o Veremos dos descripciones
bien conocidas.
Gestin 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.
Gestin de Provectos giles -Hiqhsmith.pdf
Gestin de proyectos gilesJim
Highsmith
6. Utiliza iteraciones cortas timeboxed" para ofrecer
entregas rpidas.
7. Motiva la adaptabilidad.
8. Busca la excelencia tcnica.
9. Enfcate en actividades de entrega, no en
actividades de cumplimiento de procesos.
Gestin de proyectos giles:Augustine and
Woodcock
1. Visin guiada: establece una visin guiada para el
proyecto. Refurzala continuamente a travs de palabras
y acciones.
2. Trabajo en equipo & colaboracin:
facilita la colaboracin y el trabajo en equipo a travs de
relaciones y espritu comunitario.
3. Reglas simples: establece y soporta un conjunto de
prcticas gua, tales como Serum y XP.

Gestin de proyectos qiles:Auqustine and
Woodcock
4. Apertura en la informacin: Ofrece acceso abierto
y visible a la gestin del proyecto y otra
informacin.
5. Roce ligero: Aplica slo el control suficiente para
fomentar comportamiento emergente en equipo
auto-dirigido.
6. Vigilancia gil: Refuerza la visin, sigue o adapta
las reglas, escucha a la gente.
Gestin de proyectos giles:papel del
administrador
o Tanto en Serum como en XP se regresa tanto el
control como la planeacin al equipo, no al
administrador, o El administrador no crea la estructura
de particin del trabajo, la estimacin de tiempos;
todo esto se hace en equipo, o Generalmente el
administrador no dice a la gente lo que har, o El
administrador no define y asigna detalladamente la
mayora de los roles y responsabilidades.
Gestin de proyectos giles:papel del
administrador
o Al contrario:
El rol del administrador del proyecto es
realizar coaching, ofrecer recursos, mantener
la visin, remover impedimentos, promover los
principios giles, etc.

Agenda
o Desarrollo gil
o Clasificacin de los mtodos
o Los principios y el manifiesto gil
o Gestin de proyectos giles
Abrazando la comunicacin y la retroalirnentacin | o
Prcticas y herramientas de proyectos simples oProcesos
empricos VS Procesos definidos y prescriptivos oDisciplina de
sustentabilidad:el roce humano, oEl equipo como un Sistema
Complejo Adaptativo.
Programacin como si la gente
importara
"La gente es ms importante que cualquier
proceso. Buena gente con un buen proceso
superar siempre a buena gente sin ningn
proceso"
Grady Booch (1996)
Programacin como si la gente
importara
o El primer valor del Manifiesto gil es que los I
ndividuos y las interacciones estn sobre los
procesos y las herramientas.
o Nos recuerda que: la programacin es una actividad
humana.
o 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"

Programacincomosilagenteimportara
o Los hbitos correctos de trabajo y conocimiento juegan un
papel significativo en la productividad-el valor de la
educacin constante y del mentoring para desabolladores,
o XP motiva fuertemente la transferencia de habilidades a
travs de la programacin en parejas.
Programacincomosilagenteimportara
o El nfasis en la comunicacin es tambin
importante, especialmente las conversaciones cara-
a-cara, o Las reuniones diarias de Serum y un lugar
comn para el proyecto y en XP la programacin en
parejas y todo el equipo junto son ejemplos.
Agenda
o Desarrollo gil
o Abrazando la comunicacin y la retroalimentacin
{; Prcticas y herramientas de proyectos simples
c Procesos empricos VS Procesos definidos y prescriptivos
o Disciplina de sustentabilidad:el roce humano,
o El equipo como un Sistema Complejo Adaptativo.
Prcticas y herramientas de proyectos
simples
o Muchos mtodos giles promueven el
principio de hacer lo ms simple que
posiblemente funcione - un aforismo*

XP.
* Sentencia breve y doctrinal que se propone como regla en alguna
ciencia o arte (Diccionario RAE)
Prcticas y herramientas de proyectos simples
o Muchos mtodos giles promueven un enfoque
"low-tech, high- touch.
o Low-tech es relativo, si una herramienta Web es lo
ms simple, sala.
Prcticas y herramientas de proyectos simples
Es un malentendido igualar los mtodos giles con falta de
habilidad o auto-disciplina. Un proyecto aplicando todas las
prcticas XP tiene plena estructura y disciplina. Pero -y esto es
quiz el punto clave en los mtodos giles- las prcticas
"disciplinadas" son muy orientadas-a- entregables o de
orientacin-a-calidad-en-el- cdigo. Los desarrolladores
rpidamente ven los beneficios.
Mtodos giles-Scrum y
XP

19
Agenda
o Desarrollo gil
o Prcticas y herramientas de proyectos simples
> Procesos empricos VS Procesos definidos y
prescriptivos __________________________________
o Disciplina de sustentabilidad: el roce humano, o El
equipo como un Sistema Complejo Adaptativo.

37

Procesos Empricos vs. Definidos y
Prescriptivos
Proceso definido (o prescriptivo): tiene un conjunto ordenado
y predefinido de actividades a seguir durante el desarrollo. Util
en dominios predictivos de manufactura. Proceso emprico:
usado para dominios inestables y de alto-cambio. En lugar de
sustentarse en muchas actividades; se basa en mediciones
frecuentes y respuestas dinmicas a eventos variables.
Los mtodos giles promueven los Procesos empricos en lugar
de Procesos definidos.
Ej.- Serum no nos indica las actividades a realizar por
iteracin (salvo una reunin al inicio del da).
Ej.- UP est en un punto medio, lista actividades comunes,
pero el equipo las puede ignorar o hacer en cualquier orden.

38


Procesos empricos VS. Definidos
y Prescriptivos
o Los mtodos giles entienden que el
grado de "peso de un mtodo" y la
predefinicin de actividades
ordenadas estn en funcin del tipo de
proyecto, o Un mtodo o proyecto gil
cae en un continuum" de empirismo,
dirigido por las necesidades.
Basado en Principios VS
Basado en Reglas
o En lugar de considerar un conjunto
predefinido de reglas (roles,
organizacin de equipo,
responsabilidades, etc.) el equipo y el
administrador son guiados por los
principios ms que por las prcticas.

Agenda
o Desarrollo gil
o Prcticas y herramientas de proyectos simples
o Procesos empricos VS Procesos definidos y
prescriptivos ________________________________
\> Disciplina de sustentabilidad: el roce humano. [
o El equipo como un Sistema Complejo Adaptativo.
Disciplinadesustentabilidad:eltoque
humano
o No hay pocas historias de intentos en
adoptar mtodos que requieren disciplina
y esfuerzo, slo para terminar en poco
tiempo con poco apego a los mismos, o
Los factores sociales y psicolgicos
necesarios para la adopcin sustentable
se estn perdiendo.

Disciplina de sustentabilidad: el toque humano
o Los creadores de algunos mtodos giles (XP,
Crystal) reconocen que factores humanos como el
disfrute, la simplicidad, el estmulo a corto plazo, etc;
son ingredientes para crear un suelo frtil para la
auto-disciplina sostenible en las prcticas.
Disciplina de sustentabilidad: el toque humano
o Por ejemplo, el desarrollo dirigido por pruebas
revela sus ventajas rpidamente a aquellos que lo
usan, o Los desabolladores disfrutan la "pequea
victoria" de pasar una prueba y la clarificacin en el
diseo que viene a partir de escribir las pruebas
antes de que el cdigo sea probado (prctica comn
en XP).
Agenda
o Desarrollo gil o Clasificacin de los mtodos o Los principios y
el manifiesto gil o Gestin de proyectos giles
o Abrazando la comunicacin y la retroalimentacin o Prcticas y
herramientas de proyectos simples o Procesos empricos VS
Procesos definidos y prescriptivos o Disciplina de sustentabilidad:
el roce humano.
(> El equipo como un Sistema Complejo daptativ;o; |
El equipo como un Sistema Complejo
Adaptativo
o Algunos mtodos giles (ej. Serum) hablan de un
equipo de desarrollo saludable como un Sistema
Complejo Adaptativo (SCA). o Lo comparan con una

"parvada de pjaros". Cada pjaro tiene reglas de
comportamiento local relativamente simples, pero a
nivel macro exhiben un comportamiento
emergente, o Esto es distinto a una coordinacin
dirigida por un lder.

24
El equipo como un Sistema Complejo
Adaptativo
o Los mtodos giles promueven el valor de que
para proyectos creativos-inventivos una cultura
inspirada en SCA es ms valiosa que el control y
planeacin de los administradores.
Ej.- En Serum los equipos son auto- organizados; la
organizacin a nivel de equipo y adaptacin se realiza en la
Serum meeting.
Mucha promocin gil?
o Visto como un todo los principios y prcticas giles (por
ejemplo de XP o Serum) tienen un "sabor fresco" nuevo, o Se
engloban en:
Abrazar los cambios de requisitos.
La comunicacin.
La auto-organizacin de equipos.
La planeacin adaptativa. Etc.
Y poseen algunas prcticas novedosas como el desarrollo dirigido
por pruebas y la integracin continua.


Mtodos giles especficos
o De acuerdo a una encuesta de Shine, XP y
Serum son los mtodos giles ms ampliamente
utilizados, o Serum: su nfasis distintivo entre los
mtodos es su fuerte promocin a los equipos
auto-organizados, a la medicin diaria de los
equipos y el evitar seguir pasos predefinidos.
Mtodos giles especficos
o XP: es el mtodo gil ms conocido; enfatiza la
colaboracin, rpida y temprana creacin del software; y
buenas prcticas experimentadas de desarrollo. Se
fundamenta en 4 valores:
Comunicacin.
Simplicidad.
Retroalimentacin
Coraje o valor.
Mtodosgilesespecficos
o Familia Crystal: fue desarrollada por Alistair
Cockburn. o Al mismo tiempo que reconoce la
necesidad del ciclo de vida iterativo, en este
grupo de mtodos Cockburn favorece los
aspectos del "peopleware" sobre los procesos:
comunicacin, educacin, etc. o Su definicin del
desarrollo de software: "un juego cooperativo de
invencin y comunicacin.

Mtodosgilesespecficos
o Familia Crystal: diferentes versiones de Crystal
(Clear, Yellow,...) contienen incrementalmente
"peso del mtodo como una funcin del tamao
del staff, criticalidad y prioridad del proyecto, o
Se selecciona el tamao y la criticalidad y se
mapea a una versin particular Crystal con un
"peso del mtodo" recomendado, o Utilizaremos
este modelo para clasificar Scrum y XP.

project types may need quite
different method weights
FamiliaCrystal

Modeladogil
Life (L) 16 L20 L40 X100
Essential money (E) E6 E20 E40 E100
Diserri onaiy money (D) D 6 D20, D40 D100
Comfort (C) C6 C20 C40 C100
Cockburn Scale
Criticality
The Cockburn Scale
1-6 -20 -40 -100 Number
ofpeople

Es un conjunto de principios y prcticas para
el anlisis de requisitos y modelado que
complementa a muchos mtodos 11D.
El Modelado gil promueve la creacin
colaborativa "low-tech, high-touch con
modelos que ayuden ms al entendimiento y
la comunicacin.
Sus prcticas promueven velocidad,
simplicidad y creatividad
XP

Simplicidad
Documentacin
V
005
0tv
voo*J?
or,
PrcticasdelModelado
gil
Refinamiento iterativo
Crea varios modelos
en paralo
Ej. un diagrama de
clases y uno de
secuencia
relacionados
Itera a otros
artefactos
Ej. 5% de un
diagrama de clases,
despus 5% de un
diagrama de
secuencia
Usa la herramienta
ms simple
Ej. pi2arrn blanco
& cmara; video
Despliega los
modelos de forma
simple
Ej. en la pared; no
en una pgina Web

Trabajo en equipo

Descar
ta
modelos temporales
Ej. toma una foto;
borra el pizarrn
Actualiza solo si
vale la pena
Ej. desarrollar el
cdigo es ms
importante que
mantener el
diagrama
Modela con otros
Ej. diagramacin en
parejas
Despliega los
modelos
pblicamente
Ej. Datos de gestin
del proyecto en las
paredes

55

Otrosmtodosyprcticas

Adaptative Software
Development (DSA):
J im Highsmith.
Dynamic Solutions
Delivery Model (DSDM).
Feature-driven
Development (FDD);
J eff De Luca y Peter
Coad.
Lean Development:
Mary and Tom
Poppedieck
Pragmatic programming:
Andy Hunt and Dave
Thomas.
www. praqmaticproqram
mer.com

56

El Desarrollo Iterativo y
Evolutivo: Scrum y XP

Temas
o[Clasificacin de Serum
o Workproducts, roles y prcticas
o Errores comunes, adopcin y
mezcla de procesos, fortalezas y
debilidades

Tema 3: Serum (Dr.
Ricardo Quintero)
1

o Serum es un trmino con
el que se identifica una
jugada de Rugby en la
cual un par de equipos se
disputan la posesin del
baln una vez que se ha
reanudado un juego por
alguna interrupcin
SerumyRugby
Serum:prcticas
clave
o Equipos auto-dirigidos
y auto- organizados.
o Una vez seleccionado, no
se agrega trabajo
adicional a una
iteracin, o Reunin diaria "de pie" con preguntas
especiales, o Iteraciones de 30 das (generalmente), o Demo
a los stakeholders al final de cada iteracin,
o En cada iteracin, planeacin adaptativa dirigida
por los clientes.
3

64
</
>
O
o

Serum en la escala de ciclos y ceremonia
Estrictamente
F lexi ble enelgradode"
5ecuenc131
)
ceremonialidadperoserecomienda"aslittle
ceremony as possi ble".
Pocos documentos Pocos pasos
Ceremonia
Preciso enlalongituddelas
iteraciones(30das),noenel
nmerodeiteraciones.
Muchos documentos Muchos
Pasos formales

Muchas
iteraciones
pequeas (5 das)
Serum en la escala de Cockburn

1-6 -20 -40 -100 -200 Number of People
Scrum I
-----
- f
; .................................................................
. i r~
til?
:

f/
1
L6
Serum
Crystal
Lean
Life (L) L20 L40 L80 L200
r~
E6
DSDM.
E40
XP'N^
E20
AUP\
E200
\
E80
Essential
Money(E)
Discretionar
y Money (D) V

D20 D40 D80 D200
C40 C6 C20^ C80
FDD .
C200
Comfort (C)
4

Agile Software
Development
with Scrum
Tamao de equipos
1 equipo de Serum debe ser de 7 o menos
participantes.
Mltiples equipos pueden formar un proyecto. Pueden
tenerse "Serum de Serums" donde varios equipos
pequeos trabajan juntos y tienen una reunin diaria
con representantes de cada equipo. Serum es
complementario a otras prcticas de tal forma que
puede aplicarse a otros dominios de software (desde
misin crtica hasta ms casuales).
Promueve valores y prcticas de gestin de proyectos
(ms que de requisitos, implementacin, anlisis, diseo,
etc.). Por eso puede combinarse con otros mtodos.
Mayornfasisen
procesosempricos
queenpredefinidos
Ken Schwaber, uno de los
fundadores de Serum cuenta la siguiente historia: "Deseaba entender
porque los procesos de mis clientes (cascada y definidos- detall admente)
no trabajaban para mi compaa de software, as que en 1995 traje varias
metodologas a los expertos de teora de procesos en el DuPont
Experimental Station. Estos expertos, dirigidos por Babatunde Ogannaike,
son los expertos teoristas ms respetados en procesos de control
industrial...
23

Mayor nfasis en procesos empricos que en
predefinidos
o "..Inspeccionaron los procesos de desarrollo de sistemas que les
lleve. Raramente haba 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. Decan que el desarrollo
de sistemas tena mucha complejidad e impredecibilidad por lo que
tena que ser manejado por un modelo de control de procesos que
referan como "emprico". Decan que eso no era totalmente nuevo
y que todos los procesos complejos que no estuvieran
completamente entendidos (o que tenan entradas cambiantes)
requera el modelo emprico (y no un modelo definido de procesos)
..."
Mayor nfasis en procesos empricos que en
predefinidos
o ...[Ogannaike] me dijo que mi negocio era un negocio
intelectualmente intenso que requera 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.."
6

67
Mayornfasisenprocesosempricosque
enpredefinidos
o LaspalabrasdeOgannaikerecuerdanlosprocesos
industrialesdeDemingyShewhartqueposeen
nfasisenciclosPlan-Do-Study-Act para
ambientescomplejosycambiantes.(Elciclo de
Shewart olarueda de Deming).

Ciclo de vida de Serum: 4 fases para
una entrega (release)

Planeacin
(Pre-juego)
Montaje (Pre-
juego)
Desarrollo
(Juego)
Entrega
(pos-juego)
Propsito:
Establecer la visin,
expectactivas y
aseguramiento
financiero
Propsito:
Identificar la mayora de
los requisitos y
priorizarlos para la
primer iteracin.
Propsito:
Implementar un sistema
listo para entregarse en
una serie de iteraciones
(Sprints) de 30 das
Propsito:
-Instalacin
operacional.
Actividades:
-Definir la visin,
presupuesto, Product
Backlog inicial y
estimacin de sus Items.
-Diseo exploratorio y
prototipos.
-Diseo de la
Arquitectura de alto
nivel
Actividades:
-Planeacin.
-Diseo exploratorio y
prototipos.
Actividades:
-Junta de planeacin
para el Sprint
definiendo el Sprint
Backlog y estimaciones.
-Juntas diarias Serum.
-Revisin del Sprint
Actividades:
-Documentacin. -
Entrenamiento. -
Mercadeo & Ventas.
12
Cwign
Plan
'How'
Arfllys
Spedfy
'Wnaf
Shewart"
cycle
Emba
te
Ch*
See"
Execute
Ccnstril
Do
ll
7

68
Daily
Serum
Meeting
Demonstrable
new
functionality
Backlog
tasks
expanded
Sprint BacMog ^ by team
Product BacMog As pnontized by
Product Owner
Ciclo de vida de Serum

13

Ciclo de vida de Serum

Swire:
Alluri
rn
f\\Vi lottarv ff. it-i r J,:
I.U.. Scelta.

Especlflc.
Re>quenim.
Prueba de
Aceptacin
Creadn del
Concepto
Prueba
de
Unidad
Prueba d
Integracin
Prueba
del
Sistema
Diseo Codigo
Pre-Juego
-A-
Pos-Juego
y-. Juego
Planeamienio
Producto
final,
Documentos
Integracin.
Prueba de
Sistema
s PRINT
An*
&0sefo
<xJ*;ap<>
n
Prueba Entrega

i
Release ,
Intermedio/
Qiflo iJ AltP
Nivel /
Arquitectura
7

14
XP
8

Diseo
I mplementacin
Temas
o Clasificacin de Serum
Workproducts,rolesyprcticas
o Errores comunes, adopcin y
mezcla de procesos, fortalezas y
debilidades

15

Workproducts(entregablesno-software)de
lasdiversasdisciplinas
Requisitos
I ncluye todos los tems del
producto.
El Release backlog es un
subconjunto del Product Backlog
(PB).
Incluye: caractersticas. UC.
extensiones, defectos,
tecnologas, etc ______________
Pruebas & Verificacin

16
Gestin del proyecto
Spnn
Backlog
Backlog
Graph
Estimacin del trabajo restante
VS los das restantes.
Tareas para la Iteracin.
Granularidad de 4 a 16 hrs.
Configuracin & Ambiente de Gestin de
Cambios
29

Workproducts (o entregables)
o Adems de los que se mencionan,
Serum permite cualquier Workproduct
quedevaloral proyecto. Los principales
son:
El Product Backlog.
El Sprint Backlog.
El grfico del Sprint Backlog

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

20
Workproducts-EjemplodeProduct
Backlog

Workproducts-ProductBacklog

m

A B C D E I F
1
Product Backlog

2

3 Requirement Hum Category Status Pri Estimate I
4 log credit payments to AR 17 feature underway 5 2
5 process sale-simple cash scenario 232 use case underway 5 60
6 slow credit payment approval 12 issue not
started
4 10
7 sales commission calculation 43 defect complete 4 2
8 lay-away plan payments 321 enhance not
started
3 20
9 PDA sale capture 53 technology not
started
1 100
10 process sale-credit pmt scenario 235 use case underway 5 30
I him c (xiuiuWn I iti I Bv

I finWi <iM.m mi>iihi| 15 141
G*l !< *4 ^llJ Awl m itMAfc.M* 8 Ml
ft.ll li-.mmi

Cri'EJ(IK*iinj IS TG

F nun *i h(c-'T at cad xa 160 T&
K-jl. C Hi*3 (/-p AI^MI MC
EIIIM<* M*|IM imirti
7
8
h i h inaili 21
21
141
AM
Nnmm 4 .M

n mmwrmMdhmniinili*, *> *cw ip >n n me pet In
ir lowor 1/2 ti aiNy^s tit
CUM*
to! Ufi lMOir^
0 IG
ii l TLA
12 C<lj rf turbe iWn 10 *>) xgitd rwtoci 1 rt*.
It Hmroalil c/(Wlnj U riA
l'cpullllMI iMMIIn
11 Mi'll' *33 TiM
15 Ojerf Tic 0 !4M
ii .'43 IlM
17 Ju VMU MU|tf .*3 IV,<
13 333 T4M
111 lllionln vl.loiM
(* ll'i i- Maiiit^i
33 wimrmniMiii 4

l*cl ill 11'.:**'* e> ir. (> <*> <.
1 il n 1)5111]
0 T*A
-0| Cvteta *trgi i?] 4 riA
11

Aspectos prcticos-Product Backlog
o Plantilla bsica propuesta. (Se recomienda
como un archivo compartido en la red, para
que los interesados lo pueda compartir y
modificar) o Ejemplo 1 en Excel, o Ejemplo 2
en Excel, o El SprintOmeter.
Workproducts-Sprint Backlog
(Project Management)
Sprint Backlog: Es la lista de Tareas que el
Serum Team se compromete para el Sprint actual. Los
"tems" del Sprint Backlog se obtienen a partir del
Product Backlog (de
acuerdo a las prioridades definidas por el Product
Owner).
Es crtico que el equipo seleccione los tems y
el tamao del Sprint Backlog, porque ellos son los que
estarn 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 algn
responsable comn.
Se puede definir en Excel.
12

73
Workproducts-SprintBacklog

m
23
Workproducts-SprintBacklog

24

A B C D E LJ
W
E
J
1
Sprint Backlog

Task Description Origi Respon Status Hours of work remaining
2

nator sible

3

6 7 8 9 10 '
4

362 322 317 317 306 ;
5
Meet to discuss the goals and JM JM/SR Completed
20 10 0 0 0
6
Move Calculations out of TL AW Not Started
8 8 8 8
81
7
Get GEK Data

TN Completed
12 0 0 0
0
8 Analyse GEK Data - Title

GP In Progress 24
20
30 25 20
9
Analyse GEK Data - Parcel

TK Completed 12
12
12
12 12
1
0'
Define & build Database

BR/DS In Progress 80 80 75 60 S2
D.ty* Left in Sprint 15 113 1 10 1 8 1

/S' /sv

/\ 9
/
m/s/
Wlio Dotciiption
A

ToMl Elm.*t><l Hnmv 554 45
8
36
2
27
0
0
IKRIS Gulile -
SM Start on Study Variable chapter first ifraft 16 1G 16 15
SM Import chapter first draft 40 24 6 6
SW Enport chafier first cteft 24 24 24 6
Misc. Small Bi9*
JM FIX comedicn leak 40
JM 0*ete queries 0 8
JM Oekte analysis 8 8
TG Fix uai-off metsagirg bug 8 a
JM View pedigree for kndred column in a result set 2 2 2 2
AM Cerrnrd kindtd validation 8
Environment
TG Install CVS 16 16
TBO Move cod into CVS 40 40 40 41
TBD Mtms to JDK 1 4 8 8 8 8
Ddt.llulS
KH killing Orscte sesiion* a 8 8 ::
KH Ftnish 2 2C6 database patch 8 2
KH Make a 2 207 database patch 8 8 8 8
KH Figure out wtiy 461 indeies are created 4
13

j

Aspectos prcticos-Sprint Backlog
o Plantilla bsica propuesta. (Puede
ser un archivo compartido en la red)
o Ejemplo 1 en Excel,
o El SprintOmeter.

m

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 clocala en la pared.

XP
15

Aspectosprcticos-SprintBacklogde
hombre pobre"
3. Ahora dibuja las lneas y coloca las HU y Tareas:

hombre pobre"

So.fl tul nobody
wrt Vi'crt: on any
mo<
MeruaNy ptol a r*n point ar>
iti bur*do*n vay ai fl' me
daly scrurr
$*j ral rotoi*
orijrg cu
V
NOT
CXCtO l
SMW $0Al
Offi Ffsl all o:lnity wandw h A-ay
st=rl - n
Ttmn IIIM IIIIH UfJ^kitjHlMinfjiiii tu OWM
m
28
CHECHEO OJT OONP. :0?
Sluf somebcd
01V.1r.30n day
Y
C^LWNCO ITEM*
NE
XT
XP
15

or
CHECHEO
OT
CHECHEO
OUT
TOO.
UtfUtfNEO ITEMS
hombre pobre"
4. Despus de la primer junta Serum:

29
hombre pobre"
4. Despus de algunos das:
OoME! :)
SPflNT OCAL: SETA-EADY eleuse!

II

NEXT

MTHOMU

M
t
o
d
o
s
g
il
e
s
-
S
c
r
u
m

y
X
P
15

30
17

m
Owe I SWT
CC
de hombre pobre"
4. El diagrama de BurnDown:
SUNOOWN
70
ESTIMATEDUOSK^;CEMAlhlINQ.
(croey points)..
'
1
M
1 11
fi .
Auflusrl 2 3 4 sja 9 10 11 12|1516 17 IB 1S|
DATE
de hombre pobre"
5. Monitoreando el proyecto (Scrum Master)

OUCH! Team is doing stuff in the wrong order. ar>d neglecting
EQthe top-pnonty items!
m

17

Workproducts-grficoSprintBacklog
o Grfico Sprint Backlog: es un resumen visual
de la estimacin de tiempo restante de las
tareas del Sprint Backlog.
o Es considerado el dato ms crtico del
proyecto.
o Recomendacin:
Colocar en la pared y actualizar diariamente una versin de
este Workproduct para la junta diaria de Serum.

AWorkproducts-grficoSprintBacklog
r
Sprint^
r

|

OayoMor*/
34
18

79
3
6
Workproducts-grficoSprintBacklog

35

Roles

Progress Notse 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)

snn
h 800
o
700
= 60D
o
500
LU
4UU
? yuu
i VIIII
* mn
cu
n

1
J2_
\
\

y25^1
*rW4
:0
Customer
Una persona responsable de
crear y priorizar el PB.
A partir del PB selecciona los
objetivos del siguiente Sprint.
Junto con los stakeholders.
revisa el sistema al finalizar el
Sprint.
Development
Trabaja en el Sprint Backlog
(iteracin).
Cada miembro es, solamente, un
"miembro del equipo (team
member).
Cu*toroer
J J
SerumT&tm J
Product Owntr
Other Management
50% desabollador, no slo
administrador.
Conoce y refuerza la visin y objetivos del
proyecto e iteracin.
Asegura que los valores y prcticas se sigan.
Media entre la administracin y el Serum
team.
Monitorea el avance y elimina
obstculos.
Conduce la reunin diaria de Serum. Conduce
la revisin del Sprint (demo).
Chic Kons
Todos los dems pueden
observar, pero no interferir o
hablar durante una iteracin
j
Serum Uatfer

19

r
I mplementacin
H
( valores)
-U-
Prcticas-una puede soportar mltiples disciplinas
Requisitos

Pruebas & Verificacin
/ Spnm j

Gestin del proyecto
Cticfcons I /f're Gain I and
Pqs I
Configuracin & Ambiente de
Gestin de Cambios

Dedonsi GtocfcGono|
In I Hour | -tOn | |
T
17
I

Core practices-Requisitos
o Pre-juego Planeacin y montaje:
Todos los stakeholder pueden contribuir para
crear una lista de caractersticas, UC, extensiones,
defectos, etc y registrar en el Product Backlog.
Se designa un Product Owner y las solicitudes
se hacen a travs del mismo.
En esta sesin se genera el trabajo para, al
menos, la primer iteracin.
Se identifica el Release Backlog, un
subconjunto del Product Backlog que definir al
siguiente producto operacional.
23

Corepractices-Requsitos
o Planeacin 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 seleccionarlos objetivos de la
siguiente iteracin, dirigidos por valor del negocio o riesgo.
2) El Serum Team y el Product Owner se
renen 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 planeacin.

o Planeacin de Sprint:
Conforme la iteracin procede, el Sprint Backlog se
actualiza, es comn que sea diario durante la parte
inicial de la iteracin, conforme nuevas tareas se
descubren.
Al paso del tiempo (y con experiencia), el equipo
mejora en la elaboracin del Sprint Backlog.
m
PlaneacindelSprint-Aspectosprcticos
o Es, quiz, el evento ms importante de Serum. Una mala
planeacin puede llevar al fracaso todo el Sprint. o
Resultados de la planeacin:
El objetivo del Sprint.
Una lista de los miembros del equipo y sus niveles de
compromiso.
El Sprint backlog.
Una fecha definida para el Sprint demo.
Una hora y lugar definidos para la junta diaria de Serum.
23

m
PlaneacindelSprint-Aspectosprcticos
o El Product Owner la debe atender. De no hacerlo, el
mtodo se ver seriamente comprometido en su xito, o El
tiempo del reunin debe respetar el principio de time-
boxing (al principio puede ser difcil e incluso no lograrse
una reunin satisfactoria, pero an as persiste, la prxima
reunin se vern presionados a dar resultados en el
tiempo estipulado).
m
24

Planeacin del Sprint-Aspectos
prcticos
o 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
Serum. Se dividen las HU en Tareas.
Core practices-Requisitos
o Revisin de Sprint:
Al finalizar cada iteracin, hay una reunin de
revisin (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 funcin del
producto, diseo, fortalezas, debilidades,
esfuerzo del equipo y futuros puntos de
problema.
H
o Revisin de Sprint:
Se motiva al feedback" y a la lluvia de ideas sobre las
direcciones futuras, pero no se establecen
compromisos. En la siguiente reunin de Sprint
planning, los stakeholders y el equipo harn los
compromisos.
23

Prohibido presentaciones en Power Point. El
nfasis en la presentacin es en mostrar el
producto.
m
RevisindeSprint-Aspectosprcticos
o Asegrate de presentar claramente el objetivo
del Sprint. Si en la reunin hay gente que no sabe nada del producto,
da alguna explicacin, o Enfcate en presentar el producto, no
presentaciones en PowerPoint, o Procura que tu demo sea sobre
escenarios fciles y giles de presentar (ms que cuestiones estticas), o
Manten la demo a nivel de funcionalidad (el Qu?)y no tecnicismos (el
Cmo?), o Si es posible, trata que el auditorio pruebe el producto.
o No muestres arreglos o caractersticas pequeas. Enfcate en lo
importante.
4
24

Corepractices-ProjectManagement
o No agregar a una iteracin:
Durante una iteracin, la administracin 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 iteracin el Product Owner
y la administracin tienen el derecho y la
responsabilidad de re-priorizar el Product Backlog e
indicar que hacer en la siguiente iteracin, de tal
forma que la requisicin de trabajo no exceda los
recursos.
I
o Cerdos y gallinas:
Durante la Serum meeting, slo el Serum Team puede
hablar (the Pigs). Los dems pueden atender a la
reunin, pero se mantienen en silencio (the chickens),
an el jefe.
Slo se les permite "feedback" para puntos de
explicacin relevante del negocio para el trabajo
del equipo.
"Huevos con jamn-Quin est involucrado y quien
comprometido? El cerdo o la gallina?"
o Serum Master firewall:
El Serum 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 Serum Master debe asegurarse de que el
mtodo de Serum se aplique, removiendo
obstculos, proveyendo recursos y tomando
decisiones.
Debe tomar la iniciativa cuando ve que las reuniones
no estn completando su trabajo o si el equipo no
est participando (hablando, por ej.)
24

I
Serum diario:
Cada da de trabajo en el mismo lugar y hora, se tiene
una reunin con los miembros del equipo (en crculo),
en el que se realizan las preguntas especiales Serum
para cada miembro: i) Qu hiciste desde el ltimo Serum?
2i Qu hars desde ahora y hasta el siguiente Serum?
3i Qu obstculos tienes para alcanzar los objetivos?
i) Alguna tarea a agregar al Sprint Baeklog? s) Haz aprendido
o decidido algo nuevo, de relevancia para alguno de los
miembros del equipo?
1
o Serum diario:
La reunin es mejor manejarla en crculo para
motivar a la brevedad.
En promedio 15 a 20 minutos para 7 a 10
personas. Reuniones ms largas pueden tenerse al
inicio de la iteracin.
Miembros que no son del equipo (chickens) estn
fuera del crculo.
Se maneja junto a un pizarrn en el cual las tareas
y obstculos se van escribiendo.
El Serum Master borra los obstculos slo cuando
han sido removidos
1
Serum diario:
24

Puede existir alguna forma de comunicacin
externa para miembros no presentes.
El Serum Master asegura que las reglas se sigan y
prepara el lugar para una reunin eficiente.
Debe empezar a la hora.
Ninguna otra discusin se permite que las 5
preguntas. El Serum Master tiene la autoridad de
reenfocar la discusin.
Si otros aspectos necesitan discusin, se pueden tener
reuniones secundarias inmediatamente despus del
Serum meeting con subconjuntos del Serum team.
1
27

Serum diario-Aspectos prcticos
o 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 slo al Serum Master, ser mucho
trabajo:

1
Serum diario-Aspectos prcticos
Qu hacer con los impuntuales? Puede pagar una
"multa" y usar luego el dinero para algn evento social
Qu hacer con los que no saben que hacer el da
actual"? Se les escucha (sin discutir) y luego se lleva a
todo el equipo al Sprint Backlog para que adecen o
agreguen nuevas tareas. Con el SB actualizado se les pide
a los "susodichos" que seleccionen lo que harn el da de
hoy. En ocasiones, si esto no funciona, el Serum Master
tendr que realizar coaching ms personal (incluso decidir
si vale la pena seguir con ese miembro o no en el equipo).
1
Core practices-Project Management
o Decisiones en 1 hora:
Los bloqueos reportados en el Serum Meeting y que
requieren decisin del Serum Master deben
decidirse, idealmente, inmediatamente o dentro de
1 hora.
Write

Write

Write
failing

failing

failing
2d test

test
3d

24 test , 34
28

Se promueve el valor de "Es mejor tomar malas
decisiones a no decidir. Las malas decisiones se
pueden revertir"
I
o Remocin de bloqueos en 1 da:
Los bloqueos reportados en el Serum Meeting
deben removerse idealmente antes de la siguiente
reunin.
1
29

o Equipos de 7:
Serum se puede escalar a proyectos
grandes, pero recomienda tener un
mximo de 7 miembros.
Proyectos ms grandes se manejan
como multi-equipo.

57

o Serum of Serums:
Se pueden manejar para multi-equipos reuniones de Serum
de Serums.

VA,YA

33

o Sprint:
El trabajo generalmente se organiza en
iteraciones de 30 das de calendario; cada una
llamada un Sprint.
o Equipos auto-dirigidos y auto- organizados:
Se empodera al equipo con autorizacin y recursos de
tal forma que caminen a su ritmo y resuelvan sus
problemas.
El Serum Master y la administracin proveen recursos y
remueven obstculos.
Es el reto ms fuerte para la adopcin de Serum.
m
Core practices-configuracin &
Ambiente de Gestin de Cambios
o Cuarto comn del proyecto:
Idealmente el equipo trabajo junto en un espacio
comn para el proyecto, en lugar de oficinas
separadas o cubculos.
Para otras actividades se pueden considerar los
espacios separados y privados.
Se han reportado casos de xito con equipos
31

geogrficamente dispersos que participan mediante
comunicacin virtual.
i
Core practices-configuracin &
Ambiente de Gestin de Cambios
o Construccin diaria:
Al menos una integracin diaria y una prueba
de regresin a todo lo largo del cdigo
verificado.
Ms adelante veremos la prctica de
Integracin Continua de XP que es an mejor.
1
32

ValoresquepromueveSerum
Compromiso:
Dado que el Serum Team se compromete a metas
definidas por iteracin y se le da la autonoma y
autoridad para decidir como alcanzarla.
Dado que la Administracin y el Serum Manager se
comprometen a no introducir nuevo trabajo, eliminar
obstculos y proveer recursos.
El Product Owner se compromete a definir y priorizar
el Product Backlog, guiar los objetivos por iteracin y
revisar y ofrecer "feedback" iteracin a iteracin.
o Enfoque:
Dado que el Serum Team se enfoca en los
objetivos establecidos de la iteracin, sin
distracciones.
El Serum Master y la administracin se enfocan
en proveer recursos, remover obstculos y
evitar interrupciones al equipo con solicitudes
adicionales.
o Apertura:
El Product Backlog est disponible para
visualizar el trabajo y las prioridades. Las
Daily Serums hacen visible el estado general de
los individuos y sus compromisos. La velocidad
del trabajo y su tendencia es visible con el
Backlog graph.
33

Respeto:
Ms 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 (ms que el administrador), mediante
auto-organizacin y direccin, adopta la actitud de
resolver problemas "individuales" mediante la
exploracin grupal de soluciones dndole los recursos y
la autoridad para reaccionar a los retos (tal como traer
un experto consultor para compensar sus carencias de
expertise).
Valores que promueve Serum
o Coraje:
a La administracin 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-direccin y la auto-gestin.
Temas
o Clasificacin de Serum o Workproducts, roles y
prcticas

Errores comunes y malos entendidos
o No ser equipo auto-dirigido; los administradores o el Serum
Manager dirige u organiza el equipo, o No actualizar
diariamente el Sprint Backlog. o Agregar nuevo trabajo
individual o a la iteracin, o El Product Owner no se involucra
o no decide, o No hay Sprint Review. o Muchos masters.
o La documentacin es mala: no se habl de documentacin,
(Errores comunes, adopcin y
mezcla de procesos,
debilidades
fortalezas y

34

pero el principio ya se ha comentado -aquella que
agregue valor al proceso-.
Errores comunes y malos entendidos
o El diseo o la documentacin es mala: lo mismo
que la documentacin, o Serum meetings muy
largas o no enfocadas, o La iteracin no termina en
un producto parcial integrado y probado, o Cada
iteracin termina en un release de producto.
o Planeacin predictiva. Planeacin tipo PERT.
Mezcla de procesos: Scrum+UP
o Las prcticas de Serum son guales o
especializaciones de las prcticas de UP o son
adiciones consistentes.
o Aunque Serum no promueve orden en las
actividades, se puede aprovechar el orden de UP
para los Sprints.
o Cuando estudiemos XP veremos su mezcla con
Serum

Estrategias de adopcin
o En contraste a la recomendacin precautoria de UP (un
proyecto piloto), los creadores de Serum motivan a las
organizaciones para adoptarlo en su proyecto ms difcil y
crtico, o Esta recomendacin atrevida la sustentan en la
visin que tienen los creadores de que es una medicina
fuerte con una alta razn de xito.
Estrategiasdeadopcin
o Despus de que inicia el primer proyecto, pero no antes de
la segunda iteracin (es decir, cuando todas las prcticas
se han probado) administracin ajena al proyecto y
clientes potenciales se les puede invitar para observar los
Serum meetings, Sprint Planning y Sprint Reviews.
o Los proyectos de segunda generacin de Serum 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.
34

Ejercicio
o Realizaremos un ejercicio de Serum, o
Se formaran 3 equipos (no ms de 7
integrantes),
o Este es el Product Backloq.
o Este es el ejercicio.
^Lecturasrecomendadas
o La biblia de Serum es: Agile Software
Development with Serum

Agile Software
Development with
Scrum
red
yellow

blue
red

yellow

blue
KenSchwaber MIkeBeedie

74
100

c. Cul es
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?
el propsito de los mtodos 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. Escrbalas en una sola lnea:

b ________________________________________________________
c. ________________________________________________________________
d. _________________________________________________________________
e. ________________________________________________________________
f. _________________________________________________________________
g ------------------------------------------------------------------------------------
3) TAREA: En casa lea el resto del artculo. Escriba sus comentarios sobre el disfraz que es
necesario colocar a nuestro proceso de desarrollo de software.
101
1

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 Scicnce 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 irrational. 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 considered "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.
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
102
2

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

------------- y
para que lo que
______ adecuado.
_____ es lo ms
y
EJERCICIO - Timeboxing
LECTURA: Timeboxing for top team performance
1) Lea la INTRODUCCIN. Conteste las siguientes preguntas:
a. Segn el autor Cul es la definicin de un proyecto exitoso?
b. Complete:
Timebox: Define y establece un
despus se ajusta el ____________
se desea entregar se entregue en Esto asume que
importante y frecuentemente lo es. Hay otros aspectos a
considerar tambin:

.. Ms
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 Tringulo de hierro por su relacin inmutable. El autor menciona dos
ejemplos de esta relacin. De acuerdo a su experiencia, proporcione un ejemplo ms:
EJEMPLO: _________________________________________________________________
Lea: THE LAST FEATURES y conteste: Cul es
la mejor estrategia de TimeBoxing?
4) 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? _____________________________________________________________
5) Lea: THE RIGHT FEATURES. Conteste Como seleccionar las caractersticas que
primero se deben entregar en un
sistema? __________________________________________________________
104

6) Lea: INCREMENTAL RELEASES. Mencione los pasos que sigue la estrategia de Jim
McCarthy de Microsoft para entregas incrmentales: (gotta have=consigue tener; should
have= debera tener; nice to have=sera bueno tener)
a. ______________________________________________________________
b ____________________________________________________
c. _____________________________________________________________
d . ____________________________________________________________
e. ________________________________________________________________
f. ________________________________________________________________
7) Lea: STOP APOLOG1ZING Cul fue la enseanza que Bill Gunther le ense al
autor cuando era un joven ingeniero de Sistemas de
IBM? __________________________________________________________________
Cul es tu opinin al respecto?
105
Timeboxing For Top Team Performance
by
Rick Zahniser
Whats 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 didnt give us enough time.
They didnt 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 Im 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. Lets 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 youve put that team together,
youve 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.
Timeboxing for Top Team Performance Pgina 1 de 5
http://www.belizenorth.com/articlesATIMEBOX.htm 22/06/2005

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 Worlds 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 dont understand how much it will cost them. Id like
to acquaint you with the facts, so you can feel good about leaving some features out when youre approaching the
end of your timebox.
The last features
Those latest and greatest features cost more than you expect, and heres 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 its true. As we approach 100% complete, our progress slows down
drastically. This is because were making tough decisions in the face of uncertainty. Moreover, theyre 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.
Paretos 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
106
give each group a different 20%, but its reasonable to expect that we can please the vast majority of our users with 80-
90% of the features. Sooner or later, were going to deliver those last features, but not right now!
The right features
Making Paretos 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 Ive 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.
Heres 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 its a prototype, you wont 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 youre 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, weve 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
http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005

Schedule
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.
Thats 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 youll simply manage the iron triangle properly. And timeboxing is a good way to do
that.
## Go to top Go to sidebar
FIGURES
Schedule

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

Figure 3. Feature Priority Matrix

Feature Customer
Rank
Delivery
Cost
Priority
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...


109

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 80s. 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 Rackos 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 Zacharys 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.
(Its 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
1

S 9 ID 11 12 13 H IS 16 17 1S 19
Figure 4. Defects found vs. Defects fixed.
111
7

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 experience. 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.
Well have to break commitments.
We wont 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.
Chapter: 8
112

But projects are not so simple that a few constraints and artifacts can reliably prevent error. As
errors continue to be made, vve 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 dont 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.
Chapter: 12
113

Alistair Cockburn
Kent Beck Ward
Cunningham Andrew
Hunt Robert C.
Martin
Mike Beedle Arie van Bennekum
Martin Fowler James Grenning
Ron Jeffries Jon Kern
Steve Mellor Ken Schwaber
Jim Highsmith
Brian Marick
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 doesnt 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 dont 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 control 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. Dont assume youve outgrown a tool until you tried it and found you
cant 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 youve outgrown 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 commit to the top-shelf behemoth database system, try flat files. Dont 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 documentation 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 produces and keeps
in sync from month to month. But I want that document to be short and
9 Chapter :
114

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 members, 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 fundamentally 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 contract stated that the payout would be made for a block when the
block passed the customer'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
11 Chapter : :
115

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 governed 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 completed. 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, certain 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 resolution parts of the plan can be changed with relative ease.
Principles
The above values inspired the following twelve principles. These principles are the characteristics 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 number of practices that had a
significant impact upon the quality of the final system. One was a strong correlation between

1 Product-Development Practices Thai Work: How Internet Companies Build Software . MIT Sloan Management Review. Winter 2001. Reprint
number 4226
116
13 Chapter: :

quality, and the early delivery of a partially functioning 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 frequent 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 rudimentary system
within the first few weeks of the start of the project. And we strive thereafter 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 deliveries. Our eye is on
the goal of delivering software that satisfies the customers needs.
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 environment 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.
Chapter: 12
117

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 infrastructure 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 themselves. They dont
allow themselves to get too tired. They dont borrow tomorrows 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.
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 producing 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.
Simplicitythe art of maximizing the amount of work not doneis 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 dont anticipate tomorrows problems and try to defend
against them today. Rather they do the simplest and highest 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 spiral of process inflation is culpable for at least
118
13 Chapter: :

some of this failure. The principles and values 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.
1

02/11/2009
118
Product Backlog para un Sprint de 59 minutos
Este backlog posee un nmero de items a considerar para completar un
Sprint (iteracin).
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 ms 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 tpicos mayores para el turismo marciano.
Describir el tour "El Arte en Europa".
Describir un tour basado en el folklore.
Esquematizar una expedicin a las 7 maravillas del mundo antiguo".
Definir los mensajes de waming" (gravedad, oxgeno, etc.)
Sugerir opciones de vestuario.
Explicar las opciones de viaje hacia/desde Marte.
Describir un tour "Deportes humanos".
Esquematizar la poltica de devoluciones.
Sugerir servicios relacionados.
Definir los medios de publicacin.
Definir una campaa de 12 meses.
Establecer la forma de obtener ms informacin.
Definir los precios de los tours.

Métodos Ágiles

Cargado por

Copyright:

Formatos disponibles

Métodos Ágiles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Métodos Ágiles

Cargado por

Copyright:

Formatos disponibles

Mtodos giles-Scrum y XP

Object-Oriented Technology Training

También podría gustarte