090603 Contratos áGiles

Vendiendo ‘Agile’
Una breve reflexión sobre clientes, contratos y desarrollo Ágil

Madrid, Junio 2009

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

Ángel Medinilla
 Teleco
 Doce años en TIC, nueve como
Project Manager
 Emprendedor, Blogger
 Motos, Aikido, libros, música,
viajes, cocina, cine, comics,
padel…
 Certified Scrum Master -
miembro PMI - en proceso de
CSP

angel.medinilla@proyectalis.com


Consultoría en Gestión de
Proyectos de Telecomunicaciones
y Tecnologías de la Información

Nuestra misión es mejorar los resultados de
las iniciativas y proyectos desarrollados por
nuestros clientes

Nuestro
negocio es
crear
diferencias
…

…Y aumentar la Ventaja
Competitiva


Algunas referencias


Fin de la cuña publicitaria…

…Let’s go!


 Intro
 Primer acto: principios
 Segundo acto: modelos
 Tercer acto: vencer y convencer
 Epílogo
 Coloquio / debate


Un ejercicio…
 Fixed time, fixed money
 Fixed everything
 Time and Materials
 UCR3
 Not to exeed / Fixed Fee
 Target cost
 PS 2000 Noruega
 Keiretsu
 (Si Ud. ha llegado hasta aquí,
puede abandonar la sala ;-)


Primer acto: principios


Primer principio:

Tiempo Alcance

?
Recursos

Bueno, bonito, barato…¡Escoja dos!


Segundo principio:

“La única constante del Universo es el cambio”

Tercer principio:

Es complejo (¿imposible?) caracterizar
perfectamente y a priori un sistema software

Tercer principio
Incertidumbre

La incertidumbre se reduce con el tiempo
tiempo
© Jeff Patton


Tercer principio
The Predictability Paradox

“The best way to achieve predictable software development outcomes is
to start early, learn constantly, commit late, and deliver fast. This may
seem to cut against the grain of conventional project management
practice, which is supposed to give more managed, predictable results.
But predictability is a funny thing; you cannot build with confidence on a
shifting foundation. The problem with conventional approaches is that
they assume the foundation is firm; they have little tolerance for
change.”

Mary Poppendieck


¿Estamos condenados?
 Proyectos cancelados: 31%
 Proyectos problemáticos: 53%
 Proyectos exitosos: 16%

 Funcionalidades no usadas: 64%
 Usadas rara vez: 16%
 Usadas: 20%

Resultado directo de ignorar los principios (y
no aplicar una adecuada gestión de proyecto)

La necesidad de un nuevo
modelo

Enfoque empírico (inspección y adaptación)
Desarrollo iterativo e incremental
Comunicación con el cliente
Flexibilidad en los cambios
Fixed time + fixed money = variable functionality

O podemos “hacer lo de siempre
y esperar resultados diferentes”


Segundo acto: modelos


El cuadrante de estupidez
(Carlo Maria Cipolla)
Proveedor
++

MALVADO INTELIGENTE
(daño y ganancia) (beneficio y ganancia)
-- ++
Cliente

ESTUPIDO INCAUTO
(daño y pérdida) (beneficio y pérdida)

--


Win-Win

 100% empatía
 Asumir intención
positiva
 Confianza mutua
 “Agree to disagree
agreeably”


Modelo 1: Fixed everything


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
 Exceso de funcionalidad “por si las
moscas” (YAGNI)
 Favorece proveedor “optimista”
(¿desesperado?)
 Ejecución exige adelgazar tareas (tirar
calidad)

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?


a)

b)
Opciones:

c)


Win-Win?


Variante 1.1 : fixed everyting
+ collaboration
 “Buena fe”
 Scope inicial sujeto a re-
negociación
 Problema: demasiado
difuso
 Problema: la rana y el
escorpión


1.2: fixed time - fixed money
M  “Target scope”
 Definimos una duración
y coste máximos (limita
O el riesgo para el cliente)
 Problema: funcionalidad
S mínima desarrollada
(confianza en el
proveedor)
C
 Los cambios no son
bienvenidos
W


1.3: fixed everything progresivo
(“UCR3”)
 Divide el proyecto en 3
o 4 partes
 Ejecuta la primera en
fixed everything
 Redefine las siguientes
 Iterar
 Ventaja: obtención de
información fidedigna
sobre el sistema


Modelo 2: time and materials


Time and materials
“From a client’s perspective, this is like a contractor
saying he’s not sure how much of a house can be
built for $100,000, but they’lll use five people for
three months, build one room at a time and see how
far he can get.”
Bruce Eckfeldt and Rex Madden, “Selling Agile: target cost contracts”


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
 Gran nivel de confianza
requerido (a veces funciona)


2.1: time and materials iterativo
e incremental (“True Agile”)
 Entregas funcionales a
final de cada sprint
 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


2.2: precio por punto-función
 Incentiva la entrega de
software funcional cuanto
antes
 Puede acompañarse con un
porcentaje por horas
consumidas (horas+puntos)
 Los cambios son
bienvenidos si se pagan
 Problema: puede ser
necesaria una auditoría
externa
 Problema: puede producir
software no deseado

Modelo 4:
Compromiso
Agile


“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

 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


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

Posible mecánica:
 Definir historias con el cliente
 Estimamos en puntos / días
 Añadimos tiempo de reuniones,
planificación… (factor foco) = Min t
 Añadimos buffer (10% clientes
conocidos, 30% clientes “hostiles”) =
Target t
 Añade beneficio = Max t
 Si tardo más que Target, comienzo a
perder beneficio
 Si tardo menos que Target, gano más


Posible mecánica:
 Dev Days = 48  Mala estimación inicial : Hacen falta 58
días de desarrollo (+10) = +4 sobre
 Plan Days = 6
target. Asumimos la mitad y cliente
 Min t = 54 días retira 2 días de desarrollo.
 Buffer 10% = 6  Estimación inicial optimista: solo hacen
 Target t = 60 días falta 40 días de desarrollo (-8) = -14
 Margen = 20% (12) sobre target. Ganamos 11 días y cliente
 Max t = 72 días 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,
nosotros asumimos 18 (el beneficio del
proyecto eran 12 y el buffer 6, perdemos
0 días, vamos a coste)

Importante en este modelo
 Clasificar cambios en
arreglos, aclaraciones y
añadidos.
 Arreglos están incluidos en
el precio
 Aclaraciones pueden -o no-
estar incluidas
 Añadidos deben ser objeto
de una re-estimación o un
nuevo contrato


Tercer acto:
vencer y convencer


Paradigmas atacados
 “No podemos producir nada
funcional en un mes”
 “Mi cliente nunca aceptará esto”
 “Mi competencia aceptará los
términos de mi cliente”
 “El modelo es muy complicado”


Proactividad (hábito 1)
 Hay que ser Agile para vender
Agile
 Otros muchos lo están
haciendo - ¿por qué tú no?
(pista: la suerte no es toda la
historia)
 Todos pensamos que nuestro
entorno /empresa /jefe
/cliente es el peor (tengo buenas
y malas noticias… ;)


Los cambios requieren tiempo
 Paso 1: buffers normalizados
(CCPM) en lugar de padding
 Paso 2: entregas frecuentes
 Paso 3: flexibilidad en los
cambios
 Paso 4: pagos incrementales
 Paso 5: compartir beneficios
 Paso 6: habla con tu cliente
 Paso 7: forma a tu cliente


¿Y si soy el comprador?
 Paso 1: contratos más
pequeños e incrementales
 Paso 2: desarrollo iterativo
(hitos, reuniones, demos)
 Paso 3: pagos incrementales
contra sistema funcional
 Paso 4: desarrolla a los
proveedores Ágiles
 …
 Paso N: RFP’s basadas en
competencia de proveedores
sobre prototipo


Epílogo…


#1 : Be Agile,
My Friend


#2: Tu cliente
debe ser tu
mayor Fan


#3: Tu mente crea el mundo

#4: No
existen
comidas
gratuitas


#5: Uuuuups!
Olvidamos
los SLA!!!


Referencias:
 Alistair Cockburn, “Agile Contracts”
 Mary Poppendieck, “Agile
contracts”, “Lean Development and
The Predictability Paradox”
 Bruce Eckfeldt and Rex Madden,
“Selling Agile: target cost contracts”
 Christine Moore: “Fixed Price
Contract & Agile Software
Development - An Experience
Report”
 Scrum Alliance, Serge
Beaumont,“Agile & Contracts”


¿Preguntas?

angel.medinilla@proyectalis.com

Backup Slides


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

Buffers de proyecto
 Deseable si no
contamos con un
contrato “fixed
time, fixed money”
 Dimensionar el
buffer:
 50% de duración de
tareas en estimación
“peor caso”
(Goldratt)
© Mike Cohn
 Aproximación
mínimo-cuadrática
/ wide-band delphi
(Cohn):

Manifiesto Ágil
Interacción entre personas frente a procesos y herramientas
Productos que funcionan frente a documentación extensiva
Colaboración con el cliente frente a negociación de contrato
Responder al cambio frente a seguir el plan

Frente a ≠ En vez de

Principios:
1. Satisfacer al cliente
2. Aceptar cambios
3. Trabajar como equipos
4. Entregas frecuentes
5. Calidad excelente
6. Keep It Simple, Stupid
7. Diseño evolutivo
8. Motivación
9. Cara a cara
10. Retrospetivas
11. Medimos lo que llevamos hecho
12. Paso sostenible

¿Cómo suena?


Pero no es esto…


Ni esto:


090603 Contratos áGiles

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a 090603 Contratos áGiles

Semelhante a 090603 Contratos áGiles (20)

Mais de Proyectalis / Improvement21

Mais de Proyectalis / Improvement21 (20)

Último

Último (20)

090603 Contratos áGiles