090603 Contratos áGiles

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

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

Madrid, Junio 2009


Á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 deCSP

[email protected]


Consultoría en Gestión deProyectos de Telecomunicaciones

y Tecnologías de la Información

Nuestra misión es mejorar los resultados delas iniciativas y proyectos desarrollados por

nuestros clientes


Nuestronegocio es

creardiferencias

…


…Y aumentar la VentajaCompetitiva


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:

Bueno, bonito, barato…¡Escoja dos!

?Tiempo Alcance

Recursos


“La única constante del Universo es el cambio”

Segundo principio:


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

Tercer principio:


Tercer principio

tiempoLa incertidumbre se reduce con el tiempo

Ince

rtidu

mbr

e

© Jeff Patton


Tercer principioThe Predictability Paradox

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

Mary Poppendieck


¿Estamos condenados?

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

Proyectos cancelados: 31% Proyectos problemáticos: 53% Proyectos exitosos: 16%

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


La necesidad de un nuevomodelo

Enfoque empírico (inspección y adaptación)Desarrollo iterativo e incremental

Comunicación con el clienteFlexibilidad en los cambios

Fixed time + fixed money = variable functionality


O podemos “hacer lo de siemprey esperar resultados diferentes”


Segundo acto: modelos


El cuadrante de estupidez(Carlo Maria Cipolla)

ProveedorProveedor

ClienteCliente

INTELIGENTEINTELIGENTE

(beneficio y ganancia)(beneficio y ganancia)

INCAUTOINCAUTO

(beneficio y p(beneficio y pérdida)érdida)

ESTUPIDOESTUPIDO

(daño y p(daño y pérdida)érdida)

MALVADOMALVADO

(daño y ganancia)(daño y ganancia)

----

---- ++++

++++


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 paraperder dinero (al menosno por mucho tiempo)

Las compañías grandesaceptan sistemáticamenteestos contratos

Ergo las compañíasgrandes ganan dinero…

¿Cómo?


Opciones:

a)

b)

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

“Target scope” Definimos una duración

y coste máximos (limitael riesgo para el cliente)

Problema: funcionalidadmínima desarrollada(confianza en elproveedor)

Los cambios no sonbienvenidos

M

O

S

C

W


1.3: fixed everything progresivo(“UCR3”)

Divide el proyecto en 3o 4 partes

Ejecuta la primera enfixed everything

Redefine las siguientes Iterar Ventaja: obtención de

información fidedignasobre el sistema


Modelo 2: time and materials


Time and materials

“From a client’s perspective, this is like a contractorsaying he’s not sure how much of a house can bebuilt for $100,000, but they’lll use five people forthree months, build one room at a time and see howfar he can get.”

Bruce Eckfeldt and Rex Madden, “Selling Agile: target cost contracts”


Time and materials

Inconvenientementeconsiderado 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 iterativoe incremental (“True Agile”)

Entregas funcionales afinal de cada sprint

Excelente ingeniería(pueden venir cambios enel futuro)

Posibilidad de terminar elcontrato en cualquiermomento con o sin coste(incentivo proveedor)

Leve compartición deriesgos o beneficios

© Jeff Patton


2.2: precio por punto-función Incentiva la entrega de

software funcional cuantoantes

Puede acompañarse con unporcentaje por horasconsumidas (horas+puntos)

Los cambios sonbienvenidos si se pagan

Problema: puede sernecesaria una auditoríaexterna

Problema: puede producirsoftware no deseado


Modelo 4:CompromisoAgile


“Compromiso Agile”

Varios nombres y enfoques (“target cost”, “not toexceed/fixed fee”, “Lean Approach”…)

Como siempre, lo importante son los principios, nolas herramientas



Progresivo (iterativo eincremental)

Riesgo compartido,beneficios compartidos,incentivos al biencomún(win-win)

Asume intención positiva,colaboración con el cliente(Agile)

Limita el oportunismo



“Target time” para MOSCOW, mínimo y máximoagresivos (“double worst case scenario”)

Por debajo del mínimo, proveedor gana. Por encima delmáximo, proveedor pierde

En el medio, compartimos costes o beneficios al 50% Incentivo a cliente Y proveedor para terminar cuanto

antes

Min MaxTarget

Compartimos beneficio Compartimos coste


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 Plan Days = 6 Min t = 54 días Buffer 10% = 6 Target t = 60 días Margen = 20% (12) Max t = 72 días

Mala estimación inicial : Hacen falta 58días de desarrollo (+10) = +4 sobretarget. Asumimos la mitad y clienteretira 2 días de desarrollo.

Estimación inicial optimista: solo hacenfalta 40 días de desarrollo (-8) = -14sobre target. Ganamos 11 días y clienteañade 3 días de desarrollo gratis.

Desastre total: hacen falta +24 días (noscomemos 6 de buffer, los 12 hasta max.y otros 6 más). Cliente retira 6 unidades,nosotros asumimos 18 (el beneficio delproyecto eran 12 y el buffer 6, perdemos0 días, vamos a coste)


Importante en este modelo

Clasificar cambios enarreglos, aclaraciones yañadidos.

Arreglos están incluidos enel precio

Aclaraciones pueden -o no-estar incluidas

Añadidos deben ser objetode una re-estimación o unnuevo contrato


Tercer acto:vencer y convencer


Paradigmas atacados

“No podemos producir nadafuncional 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 venderAgile

Otros muchos lo estánhaciendo - ¿por qué tú no?(pista: la suerte no es toda lahistoria)

Todos pensamos que nuestroentorno /empresa /jefe/cliente es el peor (tengo buenasy 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áspequeños e incrementales

Paso 2: desarrollo iterativo(hitos, reuniones, demos)

Paso 3: pagos incrementalescontra sistema funcional

Paso 4: desarrolla a losproveedores Ágiles

… Paso N: RFP’s basadas en

competencia de proveedoressobre prototipo


Epílogo…


#1 : Be Agile,My Friend


#2: Tu clientedebe ser tumayor Fan


#3: Tu mente crea el mundo


#4: Noexistencomidasgratuitas


#5: Uuuuups!Olvidamoslos SLA!!!


Referencias:

Alistair Cockburn, “Agile Contracts” Mary Poppendieck, “Agile

contracts”, “Lean Development andThe Predictability Paradox”

Bruce Eckfeldt and Rex Madden,“Selling Agile: target cost contracts”

Christine Moore: “Fixed PriceContract & Agile SoftwareDevelopment - An ExperienceReport”

Scrum Alliance, SergeBeaumont,“Agile & Contracts”


¿Preguntas?

[email protected]


Backup Slides


Buffers de proyecto

Monitorizar velocidad de consumo del buffer Aprendemos sobre el “global” del proyecto Los “paddings” no quedan ocultos

Buffer

80% proyecto consumido

60% proyecto consumido

Min T Max T


Buffers de proyecto

Deseable si nocontamos con uncontrato “fixedtime, fixed money”

Dimensionar elbuffer: 50% de duración de

tareas en estimación“peor caso”(Goldratt)

Aproximaciónmínimo-cuadrática/ wide-band delphi(Cohn):

© Mike Cohn


Manifiesto Ágil

Interacción entre personas frente a procesos y herramientasProductos que funcionan frente a documentación extensivaColaboració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 cliente2. Aceptar cambios3. Trabajar como equipos4. Entregas frecuentes5. Calidad excelente6. Keep It Simple, Stupid7. Diseño evolutivo8. Motivación9. Cara a cara10. Retrospetivas11. Medimos lo que llevamos hecho12. Paso sostenible


¿Cómo suena?


Pero no es esto…


Ni esto:

090603 Contratos áGiles

Business

Transcript of 090603 Contratos áGiles