contratos agiles 2.1

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

Contratos Ágiles Madrid, Marzo 2012

Licensed Trainer

World Agile Conference

¡Un placer!

Suficiente para empezar

Valores

Principios

Procesos

Herramientas

Artefactos

Prácticas

Agile101 Estimate

Estimate

Replan R1.0 ¿R2.0?

R1.0 ¿R2.0?

Agile101 Estimate

Estimate

Replan R1.0 ¿R2.0?

R1.0 ¿R2.0?

- Equipo auto-organizado y motivado - Trabajando a paso sostenible - Colaborando con cliente y personal de negocio de forma cotidiana - Comunicándose cara a cara - Persiguiendo la excelencia técnica - Reflexionando sobre como mejorar y eliminar el desperdicio

Agile101 Estimate

Estimate

Replan R1.0 ¿R2.0?

R1.0 ¿R2.0?

- Equipo auto-organizado y motivado - Trabajando a paso sostenible - Colaborando con cliente y personal de negocio de forma cotidiana - Comunicándose cara a cara - Persiguiendo la excelencia técnica - Reflexionando sobre como mejorar y eliminar el desperdicio

La idea del Contrato

Gane cuanto pueda

X X X X = -10 -10 -10 -10 X X X Y = +10 +10 +10 -30 X X Y Y = +20 +20 -20 -20 X Y Y Y = +30 -10 -10 -10 Y Y Y Y = +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

Bueno, bonito, barato… ¡Elije dos!

Tiempo Alcance

Recursos

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 R

Tecnología

Incertidumbre

Cono de incertidumbre

Precisión vs. esfuerzo Precisión

Esfuerzo estimación

Precisión vs. esfuerzo

Suficiente

50-70% precisión

100% precisión Precisión

Esfuerzo estimación

Enfoque Tradicional vs. Ágil

Fijar:

Estimar:

Alcance

Coste Tiempo

Orientación a Plan

Orientación a Valor

Buffers de proyecto

Buffer

80% proyecto consumido

60% proyecto consumido

Min T Max T

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

El cambio es la única constante

Incertidumbre, complejidad…

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

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

MVP / MMFS

Contrato Ágil

MVP / MMFS

Contrato Ágil

MVP / MMFS

Scope Creep

Contrato Ágil

MVP / MMFS

Scope Creep

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?

Opciones:

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

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)

¡Pero yo no quiero abortar el contrato!

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

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

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

T&M con una tasa o ratio (por ejemplo, entre 180 y 240 horas al mes) hasta un total dado (2000).

Importante marcar SLA’s (impedir que el cliente quiera consumir todas las horas en el último mes)

También SLA de entregas (velocidad mínima medida como producto funcional)

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

2.1 Bolsa de horas (+alcance objetivo)

Min. V

Max. V

Esto seguro que lo hacemos

Sigue soñando…

Probablemente acabemos en algún sitio por aquí

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)

Leve compartición de riesgos o beneficios

Agile Contrac.ng -‐ ADP 2008 -‐ Chris Spagnuolo and Rachel Weston

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.

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

“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

“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

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

Todo Fijo Time & Materials Riesgo compartido

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

“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

Min Max Target

Compartimos beneficio Compartimos coste

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 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 58 días de desarrollo (+10) = +4 sobre target. Asumimos la mitad y cliente retira 2 días de desarrollo. El beneficio pasa de 12 a 10.

Posible mecánica:

Estimación inicial optimista: solo hacen 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 de desarrollo gratis.

Posible mecánica:

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.

Otro ejemplo: Dev Days = 48 Plan Days = 6 Min t = 54 días Buffer 10% = 6 Target t = 60 días Coste/ día: 100S$ Target cost = 6KS$ Beneficio (25%) = 1.5K$ Presupuesto = 7.5KS$

Mala estimación inicial : Hacen falta 58 días de desarrollo (+10) = +4 sobre target. Asumimos la mitad y cliente retira 2 días de desarrollo. Coste final =6.2KS$, beneficio 1,3KS$. Cliente pierde algo de funcionalidad, proveedor algo de beneficio.

Otro ejemplo: Dev Days = 48 Plan Days = 6 Min t = 54 días Buffer 10% = 6 Target t = 60 días Coste/ día: 100S$ Target cost = 6KS$ Beneficio (25%) = 1.5K$ Presupuesto = 7.5KS$

Estimación inicial optimista: solo hacen falta 44 días de desarrollo (-4) = -10 sobre target. Repartimos el buffer. Ganamos 7 días (4 + 3 de buffer) y cliente añade 3 días de desarrollo gratis. Coste final: 5KS$, beneficio 2.5KS$ - y cliente obtiene funcionalidad extra.

Otro ejemplo: Dev Days = 48 Plan Days = 6 Min t = 54 días Buffer 10% = 6 Target t = 60 días Coste/ día: 100S$ Target cost = 6KS$ Beneficio (25%)=1.5KS$ Presupuesto = 7.5KS$

Desastre total: hacen falta +24 días. Nos comemos todo el buffer – cliente retira 3 días de funcionalidad, nosotros asumimos 3. Una vez quitados los 6 días, siguen faltando 21. Nos comemos el beneficio del proyecto (15 días, cliente asume la mitad) – otros 7.5 días menos de funcionalidad. El resto lo asumimos nosotros. Aun quitando 10.5 días 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:

‘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

Alcance objetivo Buffer cliente Buffer Proveedor

Otra forma:

Dev Days = 48 Plan Days = 6 Min t = 54 días Min cost = 5.4KS$

10% scope creep

48*0,1 ≈ 5 días

Cost= 0,5KS$

10% incertidumbre

48*0,1 ≈ 5 días

Cost=0,5KS$

PRESUPUESTO GLOBAL = 6.4KS$

Otra forma:

4 días de funcionalidad añadida

Cost= 0,4KS$

4 días reestimaciones

Cost= 0,4KS$

0.1KS$ cliente

0.1KS$ proveedor

PRECIO FINAL = 6.3KS$ (-0,1KS$)

Otra forma:

Sin funcionalidad añadida

Cost= 0

Cost= 0,8KS$

0.5KS$ cliente

-0.3KS$ proveedor

Otra forma:

5 días funcionalidad añadida

Cost= 0,5kS$

Cost = 0

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

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!

angel.medinilla@proyectalis.com

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

http://creativecommons.org/licenses/by-nc-nd/3.0/

contratos agiles 2.1

Business

Agiles 2010

Herramientas agiles

DOCUMENTAÇÃO DE SUPORTE AOS CONTRATOS DE … 2014... · 1.9 Contratos de afretamento ... 2.1 Contratos de transporte

110115 contratos agiles

Metodologias Agiles

Agiles Testing

Métodos agiles

Metodos agiles

Contratos Agiles Scrum Gathering Peru 2016

Met Agiles

Pruebas Agiles

2. CONTRATOS TRASLATIVOS DE DOMINIO. 2.1. Compraventa. El

AGILES PROJEKTMANAGEMENT

Agiles Projektportfoliomanagement

Agiles bpm

Metodologías agiles

Agiles Management

2.1. Crédito à habitação e contratos conexos

Agiles Projektmanagement …

Methodes agiles