110115 contratos agiles

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

ShineTechnologies 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.

Principios:1. Satiface a tu cliente2. Adaptate al cambio3. Entrega frecuentemente4. Trabajad juntos cotidianamente5. Mide SW entregado6. Excelencia técnica7. Mantenlo simple8. Diseño emergente9. Motivación10. Cara a cara11. Paso sostenible12. Retrospectivas © 2010 Proyectalis Gestión de Proyectos S.L.

EJERCICIO:1. Satiface a tu cliente2. Adaptate al cambio3. Entrega frecuentemente4. Trabajad juntos cotidianamente5. Mide SW entregado6. Excelencia técnica7. Mantenlo simple8. Diseño emergente9. Motivación10. Cara a cara11. Paso sostenible12. Retrospectivas © 2010 Proyectalis Gestión de Proyectos S.L.

La paradoja de la predictibilidad“La mejor manera de lograr predictibilidad en el software es comenzarpronto, aprender constantemente, diferir el compromiso y entregarpronto. Esto puede parecer contrario al uso general de la gestión deproyectos, que supuestamente proporciona resultados más predeciblesy gestionables. Pero la predictibilidad es algo gracioso: no puedesconstruir con confianza sobre unos cimientos cambiantes. El problemacon las aproximaciones tradicionales es que asumen que loscimientos son firmes, luego tienen poca tolerancia para los cambios.” Mary Poppendieck © 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.

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.

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

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.

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.

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

EjercicioLas 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.

EjercicioLas 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.

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.

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.

LitigaciónEl dijo… Ella dijo…El sistema no funciona El cliente cambió de ideaNo podemos usarlo Los usuarios no están formadosNos deberían haber avisado No nos hubieran escuchadoEl sistema está lleno de bugs Los datos estaban corruptosMal asesoramiento Malas decisionesDesarrolladores no cualificados Interlocutores inadecuadosMal proceso de desarrollo Cliente no involucradoEl sistema no funcionó en campo El cliente no adaptó sus procesosEntregaron tarde Añadieron cambios © 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.

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.

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.

4.6 Control de cambiosLas partes reconocen que habrá cambios de alcance durante el proyecto. El cambio será incorporadosiempre 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, historiasentregadas pero aun no aceptadas o historias aceptadas.Cualquier cambio que afecte a historias que ya hayan sido entregadas usualmente conllevará trabajoadicional que se considerará como nuevas historias. Los cambios a los requisitos definidos por lashistorias y pruebas de historias definidas en el anexo A de este acuerdo de trabajo o que afecten decualquier otra forma al alcance (en puntos de historia a entregar) del proyecto deben ser aprobadosmediante el proceso de solicitud de cambios que se describe a continuación.4.7 Proceso de cambiosLos únicos elementos de decisión exigidos serán el Product Owner del cliente y el Scrum Master delproveedor. 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 dedicha historia deberá ser completada por el Product Owner del cliente. El análisis de dicho cambio serealizará 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 historiaimplementada, el coste de retrabajo requerido se incluirá en esta estimación. El Product Owner del clientedeberá 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 elcambio.- 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.

Time and materials“Desde el punto de vista del cliente, esto es como si un constructor ledijera que no sabe cuánta casa podrá construir por $100.000, peroque usará a cinco personas durante cinco meses, construirá unahabitació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.

“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.

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.

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 aprecio, tiempo y alcance cerrados.Implementad Scrum, duplicad vuestraproductividad, aceptad el contrato aprecio de industria y embolsaos ladiferencia”Jeff Sutherland © 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.

110115 contratos agiles

by Proyectalis on Feb 03, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

110115 contratos agiles — Presentation Transcript