Contratos ágiles en desarrollo de software

Contratos Ágiles
Madrid, Marzo 2012

Licensed Trainer

2012 Proyectalis Gestión de Proyectos S.L. – presentaciones en slideshare.net/proyectalis

World Agile Conference


¡Un placer!


Suficiente para empezar


Agile


Valores

Principios

Procesos Prácticas

Roles Artefactos

Herramientas


Agile101
Estimate

Ouch!
R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

Agile101
- quipo auto-organizado y motivado
E
Estimate - rabajando a paso sostenible
T
- olaborando con cliente y personal de
C
negocio de forma cotidiana
- omunicándose cara a cara
C
- ersiguiendo la excelencia técnica
P
- eflexionando sobre como mejorar y
R
Ouch! eliminar el desperdicio

R1.0 ¿R2.0?
Estimate BV


Agile101
- quipo auto-organizado y motivado
E
Estimate - rabajando a paso sostenible
T
- olaborando con cliente y personal
C
de negocio de forma cotidiana
- omunicándose cara a cara
C
- ersiguiendo la excelencia técnica
P
- eflexionando sobre como mejorar y
R
Ouch! eliminar el desperdicio

R1.0 ¿R2.0?
Estimate BV


La idea del Contrato


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


Dilema del prisionero


El cuadrante de estupidez
(Carlo Maria Cipolla)


La visión
occidental del
contrato…


El problema…


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


Visión Oriental


Contratos en Software


Contrato

Tiempo Alcance

?
Recursos

Bueno, bonito, barato… ¡Elije dos!


De un pliego real…
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.

Dudas!
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?
 …


Complejidad
Requisitos

Tecnología


Incertidumbre


Cono de incertidumbre


Precisión vs. esfuerzo
Precisión

Esfuerzo estimación


Precisión vs. esfuerzo
Precisión
100% precisión

50-70% precisión

Suficiente

Esfuerzo estimación


Enfoque Tradicional vs. Ágil

Fijar: Alcance Coste Tiempo

Orientación
a Valor

Orientación
a Plan

Estimar: Coste Tiempo Alcance


Buffers de proyecto
60% proyecto consumido

80% proyecto consumido

Buffer

Min T Max T


Ley de Hofstadter: "siempre tarda
más tiempo del que estimas,
incluso cuando tienes en cuenta la
Ley de Hofstadter”


Incertidumbre, complejidad…

El cambio es la única constante

Cambios en
Software


Ley de Berard - “Andar sobre las aguas y
desarrollar software contra especificaciones
escritas es fácil si ambas están congeladas”


Ley de Humphrey: El
usuario no sabrá lo que
quiere hasta que el sistema
esté en producción


 Ley de Ziv: Las especificaciones nunca se entenderán
completamente


completamente
 Lema de Wegner: un sistema interactivo nunca puede ser
totalmente especificado ni totalmente testado


completamente
 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


Ley de Contratos Software de
Medinilla: cuarenta mil líneas de
código no caben en veinte folios
de pliego


Iterativo e Incremental

@ Jeff Patton - www.agileproductdesign.com/

Walking Skeleton


Contrato Ágil


Contrato Ágil

?

Contrato Ágil

MVP /
MMFS


Contrato Ágil

MVP /
MMFS

Scope
Creep


Contrato 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
 Incorpora feedback frecuente del cliente al proyecto
 Proporciona información veraz de avance del proyecto
 Los retrasos son menos críticos


En resumen…
“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, así que tienen poca tolerancia para los cambios.”

Mary Poppendieck

Modelos de Contratos


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
 Favorece proveedor
“optimista” (¿desesperado?) – crea el
juego de…


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)


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”: 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


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
 Problema en España - LCSP


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.


1.4: Inception
 También conocido como “Sprint cero” o contrato de consultoría
 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


1.4: Inception

-- Incertidumbre


1.4: Inception

…..


…..


Histograma


Histograma
Norma


Histograma
Norma

95% SLA
80% SLA


Proyectos dispares

 Con tallas de camiseta (para
tamaño de peticiones)
 Distintos histogramas:
 XS – 3 días
 S – 40 días
 M – 90días
 L – 150 días
 XL – 220 días


1.5: Money for nothing, change for
free
 Xebia + Sutherland
 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, proveedor gana 20% por no hacer nada)


free
¡Pero yo no quiero
abortar el
contrato!


free
 Change for free: cualquier funcionalidad puede cambiarse por
otra de igual peso (exchange en lugar de change)


free
 Regla: yo corto, tu eliges


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 proveedor acuerden 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


free
 Sutherland, Agile 2008 – “Agile
Contracts”:
 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

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”


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 y ser eficiente – incluir
SLA’s!!
 Tiempo invertido no significa
necesariamente valor entregado
 Puede eternizarse
 Gran nivel de confianza requerido


2.1: Bolsa de horas / mantenimiento
evolutivo
M
 T&M con una tasa o ratio (por
ejemplo, entre 180 y 240 horas al
mes) hasta un total dado (2000).
O
 Importante marcar SLA’s (impedir que
el cliente quiera consumir todas las
horas en el último mes) S
 También SLA de entregas (velocidad
mínima medida como producto
funcional) C

 Puede incluir funcionalidad objetivo
(MOSCoW) basada en min. V / max. V W


2.1 Bolsa de horas (+alcance
objetivo)

Min. V Esto seguro que lo hacemos

Probablemente acabemos en
algún sitio por aquí
Max. V

Sigue soñando…


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


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 presupuesto, 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


2.3: precio por punto-historia
 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


2.4: puntos + horas
 Robert C. Martin (Uncle Bob)
 Alcance fijo / horas variables
 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
 Si hay un exceso de horas,
podemos incrementar levemente
el precio
 Si lo hacemos en menos horas,
ganamos más (incentivo)

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


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


Modelo 3:
Compromiso
Agile


“Compromiso Agile”

 Varios nombres y enfoques (“target cost”, “not to exceed/fixed
fee”,”shared profit”, “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


No confío en el proveedor Confío en el proveedor

Todo Fijo Riesgo compartido Time & Materials

 Alcance se fija a alto nivel
 Existe un objetivo de coste / tiempo y un margen de
variabilidad
 Es necesario un mecanismo para que ni proveedor ni cliente
abusen de dicha variabilidad


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 = 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


Posible mecánica:
 Dev Days = 48  Mala estimación inicial : Hacen falta 58
 Plan Days = 6 días de desarrollo (+10) = +4 sobre target.
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
 Target t = 60 días
 Margen = 20% (12)
 Max t = 72 días


Posible mecánica:
 Dev Days = 48  Estimación inicial optimista: solo hacen
 Plan Days = 6 falta 44 días de desarrollo (-4) = -10 sobre
target. Se reparte el buffer entero. Ganamos 7
días (4 + 3 de buffer) y cliente añade 3 días
 Buffer 10% = 6 de desarrollo gratis.
 Target t = 60 días
 Margen = 20% (12)


Posible mecánica:
 Dev Days = 48  Desastre total: hacen falta +24 días (nos
 Plan Days = 6 comemos 6 de buffer, los 12 hasta max. y
 Min t = 54 días otros 6 más). Cliente retira 6 unidades (por
encima de Max todo es nuestro), nosotros
 Buffer 10% = 6
asumimos 12 (6 max y 6 más). Vamos a
 Target t = 60 días coste.
 Margen = 20% (12)


Otro ejemplo:
 Dev Days = 48
 Mala estimación inicial : Hacen falta 58
 Plan Days = 6 días de desarrollo (+10) = +4 sobre target.
 Min t = 54 días Asumimos la mitad y cliente retira 2 días de
 Buffer 10% = 6 desarrollo. Coste final =6.2KS$, beneficio
 Target t = 60 días 1,3KS$. Cliente pierde algo de funcionalidad,
 Coste/ día: 100S$
proveedor algo de beneficio.
 Target cost = 6KS$
 Beneficio (25%) = 1.5K$
 Presupuesto = 7.5KS$


Otro ejemplo:
 Dev Days = 48
 Estimación inicial optimista: solo hacen
 Plan Days = 6 falta 44 días de desarrollo (-4) = -10 sobre
 Min t = 54 días target. Repartimos el buffer. Ganamos 7 días
 Buffer 10% = 6 (4 + 3 de buffer) y cliente añade 3 días de
 Target t = 60 días desarrollo gratis. Coste final: 5KS$, beneficio
 Coste/ día: 100S$
2.5KS$ - y cliente obtiene funcionalidad
 Target cost = 6KS$
 Beneficio (25%) = 1.5K$
extra.
 Presupuesto = 7.5KS$


Otro ejemplo:
 Desastre total: hacen falta +24 días. Nos
 Dev Days = 48 comemos todo el buffer – cliente retira 3 días
 Plan Days = 6
de funcionalidad, nosotros asumimos 3. Una
 Buffer 10% = 6 vez quitados los 6 días, siguen faltando 21.
 Target t = 60 días Nos comemos el beneficio del proyecto (15
 Coste/ día: 100S$ días, cliente asume la mitad) – otros 7.5 días
 Target cost = 6KS$ menos de funcionalidad. El resto lo
 Beneficio (25%)=1.5KS$ asumimos nosotros. Aun quitando 10.5 días
 Presupuesto = 7.5KS$ de funcionalidad (3 de buffer, 7.5 de
margen), son necesarios (48+24+6-10.5) =
67,5 días = 6.75kS$. El beneficio del
proyecto es de 0,75KS$ (12.5%, la mitad), la
funcionalidad del proyecto es (48+24-10,5) /
(48+24) = 85%. Cliente recibe 15% menos,
proveedor gana 50% menos.

Otra forma:

Alcance objetivo Buffer cliente Buffer Proveedor

 ‘Joe’s bucket’ (Thoughtworks): buffer para cliente y
proveedor – cada uno maneja el riesgo que mejor
puede manejar
 Buffer cliente acomoda alcance no previsto
 Buffer proveedor ubica reestimaciones y tareas no
identificadas

Otra forma:

PRESUPUESTO GLOBAL = 6.4KS$


 Dev Days = 48  10% scope  10%
creep incertidumbre
 Plan Days = 6
 48*0,1 ≈ 5  48*0,1 ≈ 5
 Min t = 54 días días días
 Min cost = 5.4KS$  Cost= 0,5KS$  Cost=0,5KS$


Otra forma:
0.1KS$ cliente
PRECIO FINAL = 6.3KS$ (-0,1KS$)


 Dev Days = 48  4 días de  4 días
funcionalidad reestimaciones
 Plan Days = 6 añadida  Cost= 0,4KS$
 Min t = 54 días  Cost= 0,4KS$
 Min cost = 5.4KS$

0.1KS$ proveedor


Otra forma:
0.5KS$ cliente


 Dev Days = 48  Sin  8 días
 Plan Days = 6 añadida  Cost= 0,8KS$
 Min t = 54 días  Cost= 0
-0.3KS$ proveedor


Otra forma:


 Dev Days = 48  5 días  0 días
 Plan Days = 6 añadida  Cost = 0
 Min t = 54 días  Cost= 0,5kS$
0.5KS$ proveedor


Resumen


Still no silver bullets…


Proyectos “fijos”
 Mayor riesgo proveedor – peor a largo plazo
 Buffers para incertidumbre
 Realización / contratación progresiva
 “Inception” - colaboración
 Mecanismos para manejar cambios
 Incentivar finalización del proyecto
 Vigilar cambios


Proyectos “variables”
 Mayor riesgo cliente
 Limitar riesgo - alcance o importe limitado
 Entregas periódicas – “terminado, terminado”
 Priorización por valor
 Incentivar entregas y valor
 SLA’s de velocidad


Aproximación Ágil
 Riesgo / beneficio compartido
 Inception – Pila de Producto
 Alcance definido a alto nivel
 Alcance / coste / tiempo objetivo
 Colaboración
 Incetivo a terminar
 Incentivo a entregar


Retos


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”)


Equipo de desarrollo
 Trato con el cliente
 Diseño iterativo e incremental
 Aceptar la incertidumbre – embrace change!
 Rechazar cambios no contemplados (en determinados tipos de
contrato)


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”


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…)


Jeff Sutherland, Agile 2008


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…


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 la
documentación al final del proyecto)
 Plan de proyecto priorizado por valor de
negocio – desarrollo iterativo incremental
 Reuniones quincenales de seguimiento
(mostrando producto funcional)
 Vigilancia estricta de los cambios (Money
for nothing / change for free)
 Reporte diario (excel o similar)
 Introducción gradual de otras prácticas (CI,
TDD, retrospectivas conjuntas…)


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


Be Agile, My
Friend…


Debate y
preguntas

angel.medinilla@proyectalis.com

Gracias!


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


Contratos ágiles en desarrollo de software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Contratos ágiles en desarrollo de software

Similaire à Contratos ágiles en desarrollo de software (20)

Plus de Proyectalis / Improvement21

Plus de Proyectalis / Improvement21 (20)

Dernier

Dernier (20)

Contratos ágiles en desarrollo de software