Contratos Ágiles
Pamplona, Enero 2011
© 2010 Proyectalis Gestión de Proyectos S.L.

Ángel Medinilla
 Teleco, informático vocacional
 13+ años en TIC, principalmente
como Project Manager y consultor
senior
 Emprendedor, bloguero
 Moto, Aikido, videojuegos, libros,
viajar, musica, cocina gourmet,
vinos, comics…
 Certified Scrum Master - Miembro
PMI – Cofundador Agile Spain
angel.medinilla@proyectalis.com
http://twitter.com/angel_m
http://es.linkedin.com/in/angelm
http://slideshare.net/proyectalis
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Consultoría en Gestión de Proyectos
TIC
Nuestra misión es mejorar los resultados de nuestros
clientes, así como su calidad de vida
© 2010 Proyectalis Gestión de Proyectos S.L.

Nuestro
negocio es
crear
diferencias…
© 2010 Proyectalis Gestión de Proyectos S.L.

… Y mejorar la
ventaja competitiva
© 2010 Proyectalis Gestión de Proyectos S.L.

Cromos:
© 2010 Proyectalis Gestión de Proyectos S.L.

¡Un placer!
© 2010 Proyectalis Gestión de Proyectos S.L.

Ground
Rules
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

**
*
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Tomad notas
© 2010 Proyectalis Gestión de Proyectos S.L.

Open Mind
© 2010 Proyectalis Gestión de Proyectos S.L.

Mmmmm…
Almuerzo…
© 2010 Proyectalis Gestión de Proyectos S.L.

"What" ain't no
country I ever
heard of! They
speak English in
"What"?
Sorry for the english!
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Suficiente para empezar
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio: En realidad todo va bien,
¿No?
© 2010 Proyectalis Gestión de Proyectos S.L.

Agile
© 2010 Proyectalis Gestión de Proyectos S.L.

Standish
68% proyectos
Group fallidos o problemáticos
59¢ valor por
cada $ de software
64%
funcionalidades no
usadas
© 2010 Proyectalis Gestión de Proyectos S.L.

Shine
Technologies 88%
reportan mejora
en la
productividad
93%
reportan mejora
en la calidad
83%
reportan mejora
en la satisfacción
49%
reportan
reducción de
costes
© 2010 Proyectalis Gestión de Proyectos S.L.

Valores
Principios
Procesos Prácticas
Roles Artefactos
Herramientas
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Principios:
1. Satiface a tu cliente
2. Adaptate al cambio
3. Entrega frecuentemente
4. Trabajad juntos cotidianamente
5. Mide SW entregado
6. Excelencia técnica
7. Mantenlo simple
8. Diseño emergente
9. Motivación
10. Cara a cara
11. Paso sostenible
12. Retrospectivas
© 2010 Proyectalis Gestión de Proyectos S.L.

EJERCICIO:
1. Satiface a tu cliente
2. Adaptate al cambio
3. Entrega frecuentemente
4. Trabajad juntos cotidianamente
5. Mide SW entregado
6. Excelencia técnica
7. Mantenlo simple
8. Diseño emergente
9. Motivación
10. Cara a cara
11. Paso sostenible
12. Retrospectivas
© 2010 Proyectalis Gestión de Proyectos S.L.

Reglas
© 2010 Proyectalis Gestión de Proyectos S.L.

Primera regla
Tiempo Alcance
?
Recursos
Bueno, bonito, barato… ¡Elije dos!
© 2010 Proyectalis Gestión de Proyectos S.L.

Incertidumbre
© 2010 Proyectalis Gestión de Proyectos S.L.

Cono de incertidumbre
© 2010 Proyectalis Gestión de Proyectos S.L.

La paradoja de la predictibilidad
“La mejor manera de lograr predictibilidad en el software es comenzar
pronto, aprender constantemente, diferir el compromiso y entregar
pronto. Esto puede parecer contrario al uso general de la gestión de
proyectos, que supuestamente proporciona resultados más predecibles
y gestionables. Pero la predictibilidad es algo gracioso: no puedes
construir con confianza sobre unos cimientos cambiantes. El problema
con las aproximaciones tradicionales es que asumen que los
cimientos son firmes, luego tienen poca tolerancia para los cambios.”
Mary Poppendieck
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Scope Creep
 Mala gestión del proyecto
 Funcionalidad no definida
 Clientes acostumbrados a “barra
libre”
 Mala comunicación
 Equipos inmaduros
 Falta de sponsorización
 Mala gestión de cambios
© 2010 Proyectalis Gestión de Proyectos S.L.

Tradicional vs. Ágil
Fijar: Alcance Coste Tiempo
Orientación
a Valor
Orientación
a Plan
Estimar: Coste Tiempo Alcance
© 2010 Proyectalis Gestión de Proyectos S.L.

Buffers de proyecto
60% proyecto consumido
80% proyecto consumido
Buffer
Min T Max T
 Monitorizar velocidad de consumo del buffer
 Aprendemos sobre el “global” del proyecto
 Los “paddings” no quedan ocultos
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio:
burning man project
© 2010 Proyectalis Gestión de Proyectos S.L.

Scrumbam
Pending Selected. Dev. Valid. Integration Done! Sprint Burn-down:
COMMITTED
Fire!
Buffer burndown:
PRIO
ASAP
© 2010 Proyectalis Gestión de Proyectos S.L.

V Scrum V Kanban
80 20
85 20
75 30
70 35
75 25
80 25
? ?
¿Vuestra predicción?
© 2010 Proyectalis Gestión de Proyectos S.L.

V Scrum V Kanban
80 20 Uuuh… Buenos, de
media hacemos algo así
85 20 como 75 scrum points
75 30 por sprint. Supongo que
70 35 nos podemos
comprometer a eso
75 25 mientras mantengas el
80 25 Kanban bajo control…
? ? Eso significa no
pasar de 25
¿Vuestra predicción? kanban points
© 2010 Proyectalis Gestión de Proyectos S.L.

V Scrum V Kanban
80 20
85 20
75 30
70 35
75 25
! 80 25
60 50
Yaaargh!
¡Habéis faltado
a vuestra
promesa!
© 2010 Proyectalis Gestión de Proyectos S.L.

V Scrum V Kanban
80 20 No, de hecho hemos
85 20 conseguido 110 puntos
de velocidad agregada,
75 30 que no está nada mal.
70 35 TÚ nos priorizaste 50
puntos Kanban durante
75 25
! 80 25
el Sprint y nos hiciste
fallar el objetivo
60 50
Eso significa que
nosotros somos
Yaaargh! geniales y tu eres lo
¡Habéis faltado peor. Quizás
a vuestra deberíamos discutirlo
promesa! con el CEO 
© 2010 Proyectalis Gestión de Proyectos S.L.

Velocidad
V Scrumban
V Kanban +.
V Scrum
V Kanban -
© 2010 Proyectalis Gestión de Proyectos S.L.

Estimación de alcance: 200
puntos
Velocidad: 16 – 20 puntos por
sprint
Min V: 12,5 sprints
Max V: 10 sprints
© 2010 Proyectalis Gestión de Proyectos S.L.

Min. V Esto seguro que lo hacemos
Probablemente acabemos en
algún sitio por aquí
Max. V
¿Te estás quedando conmigo o qué?
© 2010 Proyectalis Gestión de Proyectos S.L.

Proyectos sin estimación
© 2010 Proyectalis Gestión de Proyectos S.L.

Segunda regla
El cambio es la única constante
© 2010 Proyectalis Gestión de Proyectos S.L.

Cambios
 Clasificar cambios en arreglos,
aclaraciones y añadidos.
 Arreglos están incluidos en el precio
 Aclaraciones pueden -o no- estar
incluidas - negociart
 Añadidos deben ser objeto de una re-
estimación o un nuevo contrato
© 2010 Proyectalis Gestión de Proyectos S.L.

Cambios en los proyectos
 Ubicación en buffer
 Cambio por otra funcionalidad de
igual peso
 Coste por cada añadido / Cambio
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Iterativo e Incremental
© 2010 Proyectalis Gestión de Proyectos S.L.

Iterativo e Incremental
 Reduce el riesgo: SIEMPRE hay algo
funcional
 Permite mayor libertad al cliente: puede
decidir cuándo poner en producción o
parar el proyecto
 Los retrasos son menos críticos
© 2010 Proyectalis Gestión de Proyectos S.L.

Mapas de historias
“Épicas”
Tiempo
Necesidad
Historias
© 2006-2008 Jeff Patton, www.agileproductdesgin.com
© 2010 Proyectalis Gestión de Proyectos S.L.

Mapa de historias
Tiempo
Necesario
Release one
Menos opcional
Release two
necesidad
Más opcional Release three
© 2006-2008 Jeff Patton, www.agileproductdesgin.com
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio
Las Comunidades
 La sección de comunidades es un espacio nuevo en la Web en
el que se habilitarán entornos de trabajo colaborativos a
diferentes comunidades definidas por la organización.
 Es importante destacar que se deben establecer roles de
responsables de gestión de contenidos para cada comunidad
que administren, actualicen y dinamicen el espacio Web.
 Cada uno de estos espacios debe proporcionar herramientas
que posibiliten las prácticas habituales en redes sociales, el
trabajo colaborativo, la generación de conocimiento, etc. En
este sentido caben herramientas del tipo Blog, Foro,
Repositorios de documentos, gestores de tareas, etc.
 Se podrán crear tantas comunidades como considere necesario
siendo todas similares salvo la personalización de aspecto, en
base a colores y logos.
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio
Las Comunidades
 ¿Los espacios son compartidos?
 ¿Hay diferentes roles?¿Cuáles?
 ¿Qué significa “administrar”? ¿Y “actualizar”? Por ejemplo, ¿incluye actualizar el
software y hacer backups? ¿Cambiar el look&feel?
 ¿Cuáles son las “prácticas habituales” en redes sociales? ¿Qué significa “etcétera”?
¿Qué se entiende por “generación de conocimiento”?
 ¿”Caben” significa que son opcionales?
 ¿Cuáles son las funcionalidades de un repositorio de documentos? ¿Incluye un
buscador? ¿Todo el mundo puede subir documentos? ¿Todo el mundo puede
descargar documentos? ¿Toda clase de documentos pueden almacenarse? ¿Qué
tamaño? ¿Se pueden subir por HTTP, FTP, WEBDAV…? ¿Cada usuario puede
tener su repositorio? ¿El repositorio es de cada comunidad?
 ¿Cuáles son las funcionalidades del foro? ¿Permite avatares? ¿Tiene iconos?
¿Permite código HTML? ¿Tiene seguimiento por RSS? ¿Se pueden crear subforos?
 ¿Qué es un gestor de tareas? ¿Incluye alarmas personalizadas? ¿gestión de
proyectos? ¿Filtro por tipo de tareas? ¿Calendario? ¿buscador?
 La creación de comunidades, ¿es automática? La personalización del aspecto ¿es
automática? Los colores y logos, ¿son los mismos en todas las vistas de la
comunidad?¿Cómo se indexan las comunidades? ¿cómo se enlazan en la web?
 …
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio
 ¿Cuánta incertidumbre?
 ¿Cómo saber que hemos terminado?
 ¿Quién decide cuándo paramos?
© 2010 Proyectalis Gestión de Proyectos S.L.

Tercera regla
Requisitos
Tecnología
Es complejo (quizás imposible) caracterizar perfectamente a
priori un sistema software
© 2010 Proyectalis Gestión de Proyectos S.L.

Sistemas complejos
 Ley de Ziv: Las especificaciones nunca se entenderán
completamente
 Ley de Humphrey: El usuario no sabrá lo que quiere hasta que
el sistema esté en producción
 Lema de Wegner: un sistema interactivo nunca puede ser
totalmente especificado ni totalmente testado
 Lema de Langdon: el software evoluciona más rápidamente
conforme nos acercamos a la región del caos
© 2010 Proyectalis Gestión de Proyectos S.L.

“Andar sobre las aguas y desarrollar software
contra especificaciones escritas es fácil si
ambas están congeladas” – Ley de Berard
© 2010 Proyectalis Gestión de Proyectos S.L.

Contratos
© 2010 Proyectalis Gestión de Proyectos S.L.

Gane cuanto pueda
 XXXX= -10 -10 -10 -10
 XXXY= +10 +10 +10 -30
 XXYY= +20 +20 -20 -20
 XYYY= +30 -10 -10 -10
 YYYY= +10 +10 +10 +10
© 2010 Proyectalis Gestión de Proyectos S.L.

Waterfall vs Agile
Contrato
Waterfall
Contrato
Ágil
Requisitos
a
priori
Los
requisitos
evolucionan
Mecanismos
de
control
de
cambios
Los
cambios
en
los
requisitos
son
parte
del
proceso
Análisis,
diseño,
desarrollo
y
tes;ng
Pequeñas
iteraciones
acotadas
en
;empo,
ocurren
de
forma
secuencial
ciclo
concurrente
de
diseño
y
desarrollo
Tes;ng
como
herramienta
contractual
Tes;ng
es
una
parte
integral
del
proeso
de
desarrollo
Medición
contra
requisitos
solamente
Múl;ples
métricas
para
medir
el
nivel
de
produc;vidad
y
calidad
del
código
Contrato
basado
en
la
entrega
de
bienes
Contrato
basado
en
provisión
de
servicio
© 2010 Proyectalis Gestión de Proyectos S.L.

Dilema del prisionero
© 2010 Proyectalis Gestión de Proyectos S.L.

El cuadrante de estupidez
(Carlo Maria Cipolla)
© 2010 Proyectalis Gestión de Proyectos S.L.

Litigación
El dijo… Ella dijo…
El sistema no funciona El cliente cambió de idea
No podemos usarlo Los usuarios no están formados
Nos deberían haber avisado No nos hubieran escuchado
El sistema está lleno de bugs Los datos estaban corruptos
Mal asesoramiento Malas decisiones
Desarrolladores no cualificados Interlocutores inadecuados
Mal proceso de desarrollo Cliente no involucrado
El sistema no funcionó en campo El cliente no adaptó sus procesos
Entregaron tarde Añadieron cambios
© 2010 Proyectalis Gestión de Proyectos S.L.

Win-Win
 100% empatía
 Asumir intención positiva
 Confianza mutua
 “Agree to disagree
agreeably”
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Contratos
 Limitar oportunismo
 Ofrecer incentivos
 El riesgo debería ser soportado
por la parte con mayor capacidad
para gestionarlo
 Alcance – cliente
 Tecnología - proveedor
© 2010 Proyectalis Gestión de Proyectos S.L.

Modelo 1: Fixed everything
© 2010 Proyectalis Gestión de Proyectos S.L.

Fixed everyting
 Vulnera todos los principios
 Todo el riesgo al proveedor
 No hay incentivo para el cliente (¿por
qué aceptar las entregas?)
 Asume conocimiento perfecto del
sistema
 Gran tiempo gastado en RFP
 RFP no suele incluir tolerancias, el
cliente es el que estima
 Favorece proveedor
“optimista” (¿desesperado?) – crea el
juego de oferta baja / coste por
cambios
© 2010 Proyectalis Gestión de Proyectos S.L.

Fixed everyting
 No da los costes más bajos
(proveedores competentes incluirán el
coste del riesgo – buffer en la
propuesta).
 Si todo va bien, el cliente paga de
más.
 Si va mal, exige adelgazar tareas (tirar
calidad)
 Exceso de funcionalidad “por si las
moscas” (YAGNI)
© 2010 Proyectalis Gestión de Proyectos S.L.

Lo que el ojo no ve:
 Nadie está en esto para perder
dinero (al menos no por mucho
tiempo)
 Las compañías grandes aceptan
sistemáticamente estos
contratos
 Ergo las compañías grandes
ganan dinero…
 ¿Cómo?
© 2010 Proyectalis Gestión de Proyectos S.L.

a)
b)
Opciones:
c)
© 2010 Proyectalis Gestión de Proyectos S.L.

Win-Win?
© 2010 Proyectalis Gestión de Proyectos S.L.

Variante 1.1 : fixed everyting +
collaboration
 “Buena fe”: alcace inicial sujeto a re-
negociación
 Trabajamos en items más
importantes al principio, si al final no
llegamos pueden desecharse items
o firmarse ampliación de contrato
 Problema: demasiado difuso
 Problema: la rana y el escorpión
© 2010 Proyectalis Gestión de Proyectos S.L.

1.2: fixed everything progresivo
(“UCR3”, “VC”)
 Unified Commitment – Rule of
3rds, Venture Capital
 Divide el proyecto en 3 o 4 partes
 Ejecuta la primera en fixed
everything – entrega producto
funcional mínimo (sin
funcionalidad optativa / adicional)
 Permite al cliente redefinir las
restantes fases una vez
entregada la primera.
 Ventaja: obtención de
información fidedigna sobre el
sistema
© 2010 Proyectalis Gestión de Proyectos S.L.

1.3: Sprint Competitivo (“Lean
Approach”)
 UCR3, pero contratamos primera
fase a varios proveedores a la
vez
 Concepto heredado del enfoque
concurrente de Toyota
 Seleccionamos un proveedor e
incorporamos todo lo que
hayamos aprendido del resto.
© 2010 Proyectalis Gestión de Proyectos S.L.

1.4: Inception
 Contrato de una semana para realizar la Pila de Producto
 A partir de esta información podemos dar una previsión más
acertada de qué, cuanto y cuando
 Puede incluir un primer sprint o dos: mayor confianza: plan a
largo plazo basado en velocidad real comprobada
© 2010 Proyectalis Gestión de Proyectos S.L.

1.5: Money for nothing, change for
free
 Money for nothing: el cliente puede cancelar el proyecto en
cualquier momento pagando al proveedor un 20% del alcance
cancelado (cliente ahorra 80% si considera que la funcionalidad
actual es suficiente)
© 2010 Proyectalis Gestión de Proyectos S.L.

1.5: Money for nothing, change for
free
 Change for free: cualquier funcionalidad puede cambiarse por otra
de igual peso (exchange en lugar de change)
© 2010 Proyectalis Gestión de Proyectos S.L.

4.6 Control de cambios
Las partes reconocen que habrá cambios de alcance durante el proyecto. El cambio será incorporado
siempre que el número total de puntos de historia no exceda el total recogido en el anexo 5.
No se realizarán cambios a las historias que se vayan a entregar en el Sprint en curso, historias
entregadas pero aun no aceptadas o historias aceptadas.
Cualquier cambio que afecte a historias que ya hayan sido entregadas usualmente conllevará trabajo
adicional que se considerará como nuevas historias. Los cambios a los requisitos definidos por las
historias y pruebas de historias definidas en el anexo A de este acuerdo de trabajo o que afecten de
cualquier otra forma al alcance (en puntos de historia a entregar) del proyecto deben ser aprobados
mediante el proceso de solicitud de cambios que se describe a continuación.
4.7 Proceso de cambios
Los únicos elementos de decisión exigidos serán el Product Owner del cliente y el Scrum Master del
proveedor. Una vez un cambio sea aceptado, se seguirán los siguientes pasos:
- Para cada cambio que el cliente y el proveedoracuerden definir como una nueva historia, la definición de
dicha historia deberá ser completada por el Product Owner del cliente. El análisis de dicho cambio se
realizará durante el siguiente Sprint Planning.
Este análisis definirá el coste en puntos de historia de la nueva historia. Si el cambio afecta a una historia
implementada, el coste de retrabajo requerido se incluirá en esta estimación. El Product Owner del cliente
deberá asistir a esta sesión.
- El Product Owner del cliente deberá tomar una decisión acerca del cambio de entre dos opciones:
Aceptar el cambio y decidir qué historia (o historias) se eliminan de la Pila de Producto, o rechazar el
cambio.
- Finalmente, el Product Owner del cliente deberá priorizar la nueva historia dentro de la Pila de Producto.
http://coactivate.org/projects/agile-contracts/sample-fixed-price-agile-contract
© 2010 Proyectalis Gestión de Proyectos S.L.

1.5: Money for nothing, change for
free
 1/3 de las organizaciones admiten
ser demasiado disfuncionales para
poder emplear esta aproximación
 Incapaces de crear una buena
Pila de Producto
 Incapaces de priorizar
funcionalidades por valor
 Incapaces de confiar en los
equipos de desarrollo
 El proveedor sigue soportando los
costes de retraso si la estimación es
incorrecta o los alcances iniciales no
son bien entendidos
© 2010 Proyectalis Gestión de Proyectos S.L.

Modelo 2: time and materials
© 2010 Proyectalis Gestión de Proyectos S.L.

Time and materials
“Desde el punto de vista del cliente, esto es como si un constructor le
dijera que no sabe cuánta casa podrá construir por $100.000, pero
que usará a cinco personas durante cinco meses, construirá una
habitación tras otra y verá hasta donde llega”
Bruce Eckfeldt and Rex Madden, “Selling Agile: target cost contracts”
© 2010 Proyectalis Gestión de Proyectos S.L.

Time and materials
 Inconvenientemente considerado el
“contrato Ágil” (ley del péndulo)
 Todo el riesgo al cliente
 Puede ser más rentable emplear
personas
 No incentiva al proveedor a
entregar
 No incentiva al proveedor a ser
eficiente
 Tiempo invertido no significa
necesariamente valor entregado
 Puede eternizarse
 Gran nivel de confianza requerido
© 2010 Proyectalis Gestión de Proyectos S.L.

2.1: Bolsa de horas / mantenimiento
evolutivo
M
 T&M con una tasa o ratio (por
ejemplo, entre 180 y 240 horas al
mes) O
 Importante marcar SLA’s (impedir
que el cliente quiera consumir todas S
las horas en el último mes)
 Puede incluir funcionalidad objetivo
(MOSCoW) basada en min. V / max. C
V
W
© 2010 Proyectalis Gestión de Proyectos S.L.

2.2: time and materials iterativo e
incremental (“True Agile”)
 Entregas funcionales a
final de cada sprint, coste
por Sprints
 Excelente ingeniería
(pueden venir cambios en
el futuro)
 Posibilidad de terminar el
contrato en cualquier
momento con o sin coste
(incentivo proveedor)
© Jeff Patton  Leve compartición de
riesgos o beneficios
© 2010 Proyectalis Gestión de Proyectos S.L.

Agile Contracting/Proposal
- En nuestra aproximación Ágil, el presupuesto y el tiempo determinan
el alcance que podrá entregarse. Nuestros clientes tienen el control
último del proyecto y pueden declarar en cualquier momento del
proceso de desarrollo su satisfacción con la aplicación como un todo.
Nuestros clientes pueden decidir que, aunque quede preupuesto, el
equipo ha cumplido con sus objetivos y declarar el proyecto finalizado.
- Por otra parte, aunque todo el presupuesto del proyecto se consuma,
puede que todos los elementos de la Pila de Producto no sean
entregados. Aun así, nuestros clientes cuentan con la garantía de
tener funcionalidad en producción del máximo valor para ellos debido
a la constante inspección y adaptación de la Pila de Producto.
Agile
Contrac;ng
-­‐
ADP
2008
-­‐
Chris
Spagnuolo
and
Rachel
Weston
© 2010 Proyectalis Gestión de Proyectos S.L.

2.3: precio por punto-función
 Incentiva la entrega de
software funcional cuanto
antes
 Los cambios son
bienvenidos si se pagan
 Problema: puede ser
necesaria una auditoría
externa (¿qué es un
punto?)
 Problema: puede producir
software no deseado
© 2010 Proyectalis Gestión de Proyectos S.L.

2.4: puntos + horas
 Robert C. Martin (Uncle Bob)
 Calcula puntos y velocidad
 Calcula coste del proyecto en
base a horas
 Reduce el precio de horas y
pon el resto en precio de
puntos
© 2010 Proyectalis Gestión de Proyectos S.L.

2.4: puntos + horas
 Ej: 1000 puntos, 100 puntos
por semana (10 semanas)
con un equipo de 5 personas
(5x40=200 horas). 40€/h 
80.000€. Cobra la hora a 10€/
h y el punto a 60€
 Si nos vamos a 12 semanas,
coste de proyecto es
1000x60 + 2400x10 = 84.000
 Si nos quedamos en 8
semanas, 1000x60 +
1600x10 = 76.000
© 2010 Proyectalis Gestión de Proyectos S.L.

2.5: IDIQ
 Indefinite Delivery / Indefinite Quantity
 Queremos AL MENOS 1000 puntos
de funcionalidad
 Querremos entregas entre 4
semanas y 6 meses
 Siempre avisaremos con 4 semanas
de antelación de que queremos una
entrega
 Esencialmente T&M, pero con alguna
estimación de demanda y plazos
© 2010 Proyectalis Gestión de Proyectos S.L.

Modelo 4:
Compromiso
Agile
© 2010 Proyectalis Gestión de Proyectos S.L.

“Compromiso Agile”
 Varios nombres y enfoques (“target cost”, “not to exceed/fixed fee”,
“Lean Approach”…)
 Como siempre, lo importante son los principios, no las
herramientas
© 2010 Proyectalis Gestión de Proyectos S.L.

“Compromiso Agile”
 Progresivo (iterativo e incremental)
 Riesgo compartido, beneficios
compartidos, incentivos al bien
común(win-win)
 Asume intención positiva,
colaboración con el cliente (Agile)
 Limita el oportunismo
© 2010 Proyectalis Gestión de Proyectos S.L.

“Compromiso Agile”
Compartimos beneficio Compartimos coste
Min
Target Max
 “Target time” para MOSCOW, mínimo y máximo
agresivos (“double worst case scenario”)
 Por debajo del mínimo, proveedor gana. Por encima del
máximo, proveedor pierde
 En el medio, compartimos costes o beneficios al 50%
 Incentivo a cliente Y proveedor para terminar cuanto
antes
© 2010 Proyectalis Gestión de Proyectos S.L.

“Compromiso Agile”
Alcance objetivo Buffer cliente Buffer Proveedor
 Otra forma de verlo: buffer para cliente y proveedor
 Buffer cliente acomoda alcance no previsto
 Buffer proveedor ubica reestimaciones y tareas no identificadas
 Si estimamos bien, ganamos más dinero
 Si cliente no añade más funcionalidad, proyecto sale más barato
 Exceso funcionalidad: cliente acomoda
 Exceso estimación: proveedor asume
© 2010 Proyectalis Gestión de Proyectos S.L.

Posible mecánica:
 Definir historias con el cliente
 Estimamos en puntos / días = Min t
 Añadimos buffer (10% clientes
conocidos, 30% clientes “hostiles”) =
Target t
 Añade beneficio = Max t (por
encima de esto, pierdo dinero)
 Si tardo más que Target, comienzo a
perder beneficio
 Si tardo menos que Target, gano
más
© 2010 Proyectalis Gestión de Proyectos S.L.

Posible mecánica:
 Dev Days = 48  Mala estimación inicial : Hacen falta 58
días de desarrollo (+10) = +4 sobre target.
 Plan Days = 6
Asumimos la mitad y cliente retira 2 días de
 Min t = 54 días desarrollo. El beneficio pasa de 12 a 10.
 Buffer 10% = 6  Estimación inicial optimista: solo hacen
 Target t = 60 días falta 40 días de desarrollo (-8) = -14 sobre
 Margen = 20% (12) target. Ganamos 11 días (8 + 3 de buffer) y
 Max t = 72 días cliente añade 3 días de desarrollo gratis.
 Desastre total: hacen falta +24 días (nos
comemos 6 de buffer, los 12 hasta max. y
otros 6 más). Cliente retira 6 unidades (por
encima de Max todo es nuestro), nosotros
asumimos 12 (6 max y 6 más). Vamos a
coste.
© 2010 Proyectalis Gestión de Proyectos S.L.

Retos
© 2010 Proyectalis Gestión de Proyectos S.L.

Participación del cliente
 JAD, colaboración cotidiana
 Reuniones
 Definición de funcionalidad a alto nivel, incluyendo testabilidad
 Entregas, Aceptación (¡bloqueos!)
 Procesos y requisitos de cliente (“listas de tareas y horas”)
© 2010 Proyectalis Gestión de Proyectos S.L.

Equipo de desarrollo
 Trato con el cliente
 Diseño iterativo e incremental
 Aceptar la incertidumbre
 Rechazar cambios no contemplados (en determinados tipos
de contrato)
© 2010 Proyectalis Gestión de Proyectos S.L.

Equipo comercial
 Involucrar a equipo en propuestas
 Enfocar propuestas de forma Ágil
 Vender Agile
 Cuidar el lenguaje (“fallar deprisa”,
“alcance variable”, “incertidumbre”,
“cambios”…)
 No vender la “bala de plata”
© 2010 Proyectalis Gestión de Proyectos S.L.

Para convencer…
 Prueba por Sprint
 Casos de éxito: burn-downs,
comentarios de anteriores clientes,
métricas
 Ejemplos de empresas usando Agile
(especialmente líderes y
competencia)
 Sigue el dolor: ¿qué es lo que no
funciona ahora? ¿Cómo lo soluciona
Agile?
 Comparte las retrospectivas
 Ofrece herramientas y métricas
Ágiles (dashboards, gestor de
fuentes…)
© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

© 2010 Proyectalis Gestión de Proyectos S.L.

Jeff Sutherland, Agile 2008
© 2010 Proyectalis Gestión de Proyectos S.L.

En el peor caso…
 No podemos hacerlo
 Suena bonito en teoría, pero no es
realista
 Mi cliente no me deja
 Mi proveedor no me deja
 Mi empresa no me deja
 Mi jefe no me deja
 Mis compañeros no me dejan
 Mi Mamá no me deja…
© 2010 Proyectalis Gestión de Proyectos S.L.

En el peor caso…
 Utilización de buffer en función de la
incertidumbre histórica
 Documentos iniciales más genéricos,
menos nivel de detalle (o difiere
documentación al final del proyecto)
 Plan de proyecto priorizado por valor de
negocio
 Reuniones quincenales de seguimiento
(mostrando producto funcional)
 Reporte diario (excel o similar)
 Introducción gradual de otras prácticas (CI,
TDD, retrospectivas conjuntas…)
© 2010 Proyectalis Gestión de Proyectos S.L.

Un último consejo
“Dejad de quejaros de los contratos a
precio, tiempo y alcance cerrados.
Implementad Scrum, duplicad vuestra
productividad, aceptad el contrato a
precio de industria y embolsaos la
diferencia”
Jeff Sutherland
© 2010 Proyectalis Gestión de Proyectos S.L.

#1 : Be Agile,
My Friend
© 2010 Proyectalis Gestión de Proyectos S.L.

Gracias!
angel.medinilla@proyectalis.com
© 2010 Proyectalis Gestión de Proyectos S.L.

Ejercicio: resumen del curso y plan
de acción
© 2010 Proyectalis Gestión de Proyectos S.L.

Retrospectiva
del curso
angel.medinilla@proyectalis.com
© 2010 Proyectalis Gestión de Proyectos S.L.

http://creativecommons.org/
licenses/by-nc-nd/3.0/
This presentation is based upon
the ideas and work of many
people. And while I’ve tried to
recognize copyrights and give
credit and attribution where
possible, I cannot possibly list
them all, so if you feel like
there’s something that should be
added, changed or removed
from this presentation, please
drop me an e-mail at
angel.medinilla@proyectalis.com
© 2010 Proyectalis Gestión de Proyectos S.L.