Presentación en la que se navega sobre los diferentes tipos de contrato y que tanto permiten que surja la agilidad en ellos. Es una compilación realizada de Ángel Medinilla, Ágiles Paraná, Wilmar Hincapie y Leonardo Agudelo
Product discovery con frameworks de ux y agile inceptionGiovanny Cifuentes
Presentacion de varios marcos de trabajo donde se aplican diferentes practicas de co-creacion utilizando Design Thinking, Lean UX y Agile Inception para el descubrimiento de productos en entornos digitales mostrando procesos y herramientas unificadas que se pueden llevar a la practica.
This is a quick guide to the 6 core roles required for Agile Project Management.
The presentation includes an overview of the 5 characteristics needed to make an agile project successful.
YouTube Link: https://youtu.be/te8mOO-wVPk
** Edureka Certification Training: https://www.edureka.co **
This Edureka video on "SAFe Certification Exam Requirements" discusses the most popular SAFe certification, Leading SAFe 4.6 Certification exam requirements. The topics discussed in this course are listed below:
SAFe Certifications
Leading SAFe: SAFe Agilist Certification
SAFe Agilist Certification Exam Requirements
SAFe Certification Kit
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
Product discovery con frameworks de ux y agile inceptionGiovanny Cifuentes
Presentacion de varios marcos de trabajo donde se aplican diferentes practicas de co-creacion utilizando Design Thinking, Lean UX y Agile Inception para el descubrimiento de productos en entornos digitales mostrando procesos y herramientas unificadas que se pueden llevar a la practica.
This is a quick guide to the 6 core roles required for Agile Project Management.
The presentation includes an overview of the 5 characteristics needed to make an agile project successful.
YouTube Link: https://youtu.be/te8mOO-wVPk
** Edureka Certification Training: https://www.edureka.co **
This Edureka video on "SAFe Certification Exam Requirements" discusses the most popular SAFe certification, Leading SAFe 4.6 Certification exam requirements. The topics discussed in this course are listed below:
SAFe Certifications
Leading SAFe: SAFe Agilist Certification
SAFe Agilist Certification Exam Requirements
SAFe Certification Kit
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
This presentation highlights the benefits of using agile methodologies.
It also describe what is agility and how different it is from waterfall approach. What are the different agile methodologies and what is Scrum the most used agile methodology world wide.
This is a presentation I put together for a conference in 2011. It gives a fast, high level view of where Agile Software Development came from, its core values and principles, and its core practices. It is structured as 7 PechaKucha decks in a row, with short breaks in between, which requires high energy, intensity, and a sense of humor. :)
Where can Kanban be embedded in the organizational context? Sounds like an easy question, however, it is not always easy to answer - especially in bigger organizations. In this session I will introduce the Kanban Flight Levels model which provides an overview of the different fields of application of Kanban and helps to understand the implications for the organizational context. Furthermore, the model helps to clarify where to start with your Kanban change initiative: on team level, on the value stream, or on portfolio level - every level has it's own challenges, pros and cons.
Guía del seminario sobre métodos ágiles (Scrum, Kanban, Lean y XP) impartido en Septiembre de 2011en La Salle (Universidad Ramon Llull, Barcelona. Parte de una presentación de Agile-Spain con slides específicos de proyectosagiles.org y uno de Henrik Kniberg (crisp.se).
Introducción a métodos ágiles y Lean realizada en el Breakfast La Salle del 14 de febrero de 2012 sobre Agile en PYMEs. Video de la mesa redonda: http://www.youtube.com/watch?v=tL7sWkROOuA
Klasiskā un iteratīvā projektu vadīšanas metode - atšķirības un kopīgaisWhiteflo
Prezentācija aplūko populārākās klasiskās projektu vadīšanas metodes, kā arī iteratīvās metodes. Vai abas pieejas savietojamas, un kas tām ir atšķirīgs? Jautājums ir, vai tās var apvienot vienā projektā.
Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User ...Jorge Hernán Abad Londoño
Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se comparten los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton
Project failure tends to be embedded in a project from the start. There is a spectrum of failures from complete collapse to a range of lesser failures associated with behind schedule and over budget. The reasons are all too well known. Yet the lessons from project failures are not being learned and the behaviours that give rise to failures continue to persist. Project failures will continue to occur until the reasons and behaviours are explicitly understood, acknowledged and addressed.
The reasons for project failure across project phases include:
Requirements
• Poor initial requirement definition
• Poor requirements validation
• Poor management of requirements
• Requirements not linked to business benefits
Solution Design
• Solution design not validated
• Solution design not linked to business needs
• Solution design too complex
• Solution design does not capture necessary complexity
• Solution design based on unproven technology
• Solution not implementable
• Underlying business processes not defined adequately
Estimation
• Errors due to limitations in estimating procedures
• Failure to understand and account for technical risks
• Deliberate underestimation/misrepresentation of costs
• Poor inflation estimates
• Top down pressure to reduce estimates
• Lack of valid independent cost estimates
Project Management
• Lack of program management expertise
• Mismanagement/human error
• Over optimism
• Schedule concurrency
• Program stretch outs to keep production lines open
• Lack of communication
• Poor management of change and scope creep
Development and Implementation
• Lack of competition when selecting suppliers, poor supplier selection process
• Poor supplier engagement
• Poor contract design
• Inconsistent contract management/administration procedures, too much or too little oversight
• Waste
• Excess profits by supplier, supplier overstaffed
• Supplier indirect costs unreasonable
• Inadequate resource allocation and prioritisation
• Organisation cannot handle change
Finance and Budgeting
• Business case incomplete
• Funding instabilities caused by trying to fund too many projects
• Funding instabilities caused by management decisions
• Inefficient production rates due to stretching out programmes
• Failure to fund for contingency
• Failure to fund projects at realistic cost
Prioritization Techniques for Agile TeamsTarang Baxi
Have you ever been in a prioritization discussion where the only priorities are High, Higher, and Highest? Or tried using MoSCoW to prioritize user stories only to find
that 80% of the cards are 'Must Have'?
In this tutorial, we introduce a gamut of different prioritization methods, ranging from simple techniques like stacked ranking or MoSCoW that classify items along a single dimension to multi-dimensional techniques like priority quadrants, Story Maps, and Innovation Games®. We cover pruning feature trees, spending fake currency, and using visual metaphors, while truly identifying what the most important stuff really is. This was most recently presented at the Agile India 2013 conference in Bangalore.
This presentation highlights the benefits of using agile methodologies.
It also describe what is agility and how different it is from waterfall approach. What are the different agile methodologies and what is Scrum the most used agile methodology world wide.
This is a presentation I put together for a conference in 2011. It gives a fast, high level view of where Agile Software Development came from, its core values and principles, and its core practices. It is structured as 7 PechaKucha decks in a row, with short breaks in between, which requires high energy, intensity, and a sense of humor. :)
Where can Kanban be embedded in the organizational context? Sounds like an easy question, however, it is not always easy to answer - especially in bigger organizations. In this session I will introduce the Kanban Flight Levels model which provides an overview of the different fields of application of Kanban and helps to understand the implications for the organizational context. Furthermore, the model helps to clarify where to start with your Kanban change initiative: on team level, on the value stream, or on portfolio level - every level has it's own challenges, pros and cons.
Guía del seminario sobre métodos ágiles (Scrum, Kanban, Lean y XP) impartido en Septiembre de 2011en La Salle (Universidad Ramon Llull, Barcelona. Parte de una presentación de Agile-Spain con slides específicos de proyectosagiles.org y uno de Henrik Kniberg (crisp.se).
Introducción a métodos ágiles y Lean realizada en el Breakfast La Salle del 14 de febrero de 2012 sobre Agile en PYMEs. Video de la mesa redonda: http://www.youtube.com/watch?v=tL7sWkROOuA
Klasiskā un iteratīvā projektu vadīšanas metode - atšķirības un kopīgaisWhiteflo
Prezentācija aplūko populārākās klasiskās projektu vadīšanas metodes, kā arī iteratīvās metodes. Vai abas pieejas savietojamas, un kas tām ir atšķirīgs? Jautājums ir, vai tās var apvienot vienā projektā.
Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User ...Jorge Hernán Abad Londoño
Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se comparten los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton
Project failure tends to be embedded in a project from the start. There is a spectrum of failures from complete collapse to a range of lesser failures associated with behind schedule and over budget. The reasons are all too well known. Yet the lessons from project failures are not being learned and the behaviours that give rise to failures continue to persist. Project failures will continue to occur until the reasons and behaviours are explicitly understood, acknowledged and addressed.
The reasons for project failure across project phases include:
Requirements
• Poor initial requirement definition
• Poor requirements validation
• Poor management of requirements
• Requirements not linked to business benefits
Solution Design
• Solution design not validated
• Solution design not linked to business needs
• Solution design too complex
• Solution design does not capture necessary complexity
• Solution design based on unproven technology
• Solution not implementable
• Underlying business processes not defined adequately
Estimation
• Errors due to limitations in estimating procedures
• Failure to understand and account for technical risks
• Deliberate underestimation/misrepresentation of costs
• Poor inflation estimates
• Top down pressure to reduce estimates
• Lack of valid independent cost estimates
Project Management
• Lack of program management expertise
• Mismanagement/human error
• Over optimism
• Schedule concurrency
• Program stretch outs to keep production lines open
• Lack of communication
• Poor management of change and scope creep
Development and Implementation
• Lack of competition when selecting suppliers, poor supplier selection process
• Poor supplier engagement
• Poor contract design
• Inconsistent contract management/administration procedures, too much or too little oversight
• Waste
• Excess profits by supplier, supplier overstaffed
• Supplier indirect costs unreasonable
• Inadequate resource allocation and prioritisation
• Organisation cannot handle change
Finance and Budgeting
• Business case incomplete
• Funding instabilities caused by trying to fund too many projects
• Funding instabilities caused by management decisions
• Inefficient production rates due to stretching out programmes
• Failure to fund for contingency
• Failure to fund projects at realistic cost
Prioritization Techniques for Agile TeamsTarang Baxi
Have you ever been in a prioritization discussion where the only priorities are High, Higher, and Highest? Or tried using MoSCoW to prioritize user stories only to find
that 80% of the cards are 'Must Have'?
In this tutorial, we introduce a gamut of different prioritization methods, ranging from simple techniques like stacked ranking or MoSCoW that classify items along a single dimension to multi-dimensional techniques like priority quadrants, Story Maps, and Innovation Games®. We cover pruning feature trees, spending fake currency, and using visual metaphors, while truly identifying what the most important stuff really is. This was most recently presented at the Agile India 2013 conference in Bangalore.
Comentamos sobre Continuous Delivery usando VSTS y Azure, centrandonos en los nuevos Deployment Groups que permiten el despliegue simultaneo de aplicaciones a multiples maquinas destino.
Esta es la presentación de la Charla/Taller que compartí en Agiles 2017. Si queres encontrar una forma de motivarte cada día entra, acá hay una idea!!! :-D Energía!!!
Desarrollo equipos basado en Modelo tuckman #Agiles2017Rose Restrepo
Taller creado por Rose Mery Restrepo, Milton Mahecha, Virginia Rosello, Claudia Toscano, basado en el modelo Tuckman en el marco del Agile Team Coach- de Martin Alaimo-Kleer
Presentación hecha el 7 de abril de 2017 en el marco del Scrum Day Perú, donde trato de explicar las incertidumbres y malinterpretaciones al enfoque DevOps (empezando por creer erróneamente que es un "rol") y las opciones para tratar de encontrar el camino
Slides for the talk conducted by Angel Medinilla at Scrum Gathering Barcelona on how to choose, train and develop great Scrum Masters. The video should be available soon at http://vimeo.com/user3469010
Presentacion como ser agil y no morir en el intento v2Luis Consiglieri
Charla sobre como empezar con técnicas ágiles en un proyecto o negocio. La primera versión se expuso en el ULIMA Agile Day 2010 en la Universidad de Lima. La segunda versión se presentó en la charla "Un proyecto ágil de inicio a fin" en el Agile Open LIma VII el 21 de Abril del 2013 en la Pontificia Universidad Católica del Perú.
¿Cómo evito que mi proyecto se inunde de cambios?Software Guru
Cualquier proyecto tendrá cambios en su desarrollo, lo importante será administrarlos de la forma adecuada, el problema radica cuando nuestro proyecto pierde estabilidad por una avalancha de cambios que no dejan que el proyecto pueda seguir su curso y arriesgan el éxito del mismo.
Cambios radicales y constantes al alcance de proyecto lo que suele provocar es cansancio en el equipo de trabajo, una baja en la motivación del mismo, disminución de entusiasmo por parte del sponsor, aumentando las probabilidades de fracaso de nuestro proyecto.
Todo proyecto software está sujeto a 3 grandes verdades. No se puede luchar contra ellas, se debe convivir con ellas. En este artículo intento mostrar esas 3 verdades y algunas soluciones para que no afecten a tu proyecto.
Contratos y presupuestos en proyectos Drupal - Drupal Camp Spain 2014Atenea tech
En esta sesión me gustaría exponer dos maneras de gestionar un proyecto: agilismo y predictivo. Dentro de estas dos maneras de trabajar, es imprescindible plantear el cómo realizar presupuestos, ya que estos pueden implicar que la relación con el cliente sea fluida y que el proyecto sea un éxito, o por el contrario, encontrarnos en un callejón sin salida con un proyecto sobredimensionado y mal pagado.
Hablaré sobre las diferentes formas de hacer presupuestos, algunos consejos prácticos, así como dar importancia a la responsabilidad que tenemos al firmar un acuerdo.
Se comparten varios tips que promueven al mejora del rendimiento de los equipos ágiles, es decir los que cumplen con el manifiesto ágil, tipo scrum, scrumban, xp, kanban
Hola a todos,
Mientras escribo el post, quisiera compartirles esta imagen, sobre lo que REALMENTE significa pruebas unitarias, he observado que el término es mál empleado por DESARROLLADORES, TESTER, GERENTES DE PROYECTO, SCRUM MASTER, AGILE COACHES.
Es un pequeño servicio social.
Esperando con el resolver muchas dudas al respecto.
Hola a todos
A finales del pasado tuve la oportunidad de brindar un Seminario-Taller sobre Transformación Ágil para una prestigiosa universidad de la ciudad de Medellín dirigido específicamente a una importante organización del sector energético.
Hoy quiero compartirles TODO el material que elaboré y trabajamos; sin restricciones.
Pero también he observado que por más bueno que sea el material, sin la explicación y heridas de guerra del experto, queda incompleto; por lo tanto, si estas interesad@ en ir más allá del material y participar en un Webinar que dictaré:
• Cuándo: en el mes de Julio de 2020
• Intensidad: 3 sábados
• Duración: 9 horas (3 horas cada sesión)
• Inversión: 90 dólares
diligencia el siguiente formato y te estaré contactando para los siguientes pasos.
https://docs.google.com/forms/d/e/1FAIpQLSfJkIU1LyJO3cCKIkgzXhAMNRJHNZpyeEBv148jKZEFeJ4zuA/viewform
Saludos ágiles
Jorge Abad.
Publicado en : http://www.lecciones-aprendidas.info/2020/05/diapositivas-seminario-taller-sobre-transformacion-agil.html
Conferencia "Agile marketing para hacer frente a los cambios"
Todo el mundo busca ser ágil. Ahorrar tiempo, minimizar recursos y duplicar los resultados. Sin embargo, ¿es algo que nace innato o se puede entrenar?
En la mayoría de los casos la agilidad puede trabajarse. Y en marketing en concreto, existe una tendencia que aporta las claves para hacerlo: el Agile Marketing.
En esta presentación se describen tips para que las PMO comiencen con sus pilotos ágiles y algunas estrategias para que se comience a agilizar el portafolio de proyectos y productos.
4. What is Agile?
•The ability to create and respond
to change in order to succeed in an
uncertain and turbulent
environment.
Agile Alliance
https://www.agilealliance.org/agile101/
5.
6. And we also…
And I'm pretty sure there's more
Now the Banks are IT Companies
8. Requirements like an unstable radioactive atom
"Recent studies, led by Al Goerner at the
University of Missouri, Kansas City, demonstrate
that the inherent value in Output-Based
Requirements erodes exponentially over time.
This rate of decay has been likened to the half-life
of an unstable radioactive atom. The 'half-life' is
the measure of the period of time it takes for the
substance undergoing decay to decrease by half.
According to the studies carried out by the
University of Missouri, the half-life of the value of
the Output-Based Requirements has been
rapidly decreasing. In 1980 this was around 10-
12 years, by 2000 it had fallen to 2-3 years, and it
is currently running at about 6 months.”
"Software Development: How the Traditional Contract Model Increases the Risk of Failure"
Susan Atkinson y Gabrielle Benefield
http://www.infoq.com/articles/contract-model-failure
10. Hoy en día no podemos darnos el lujo de
perder tiempo, dinero, recursos y costo de
oportunidad ya sea haciendo el producto
incorrecto, o construyendo producto de
desperdicio.
11. What is Agile?
•The ability to create and respond
to change in order to succeed in an
uncertain and turbulent
environment.
Agile Alliance
https://www.agilealliance.org/agile101/
21. Hacer software es…
• Saber trabajar REALMENTE en equipo
• Que los riesgos saltan y se materializen por
doquier
• Convivir con la incertidumbre, y saber como
reaccionar a ella.
• Saber que no vamos a tenerlo TODO
definido, pero se va definiendo de forma
gradual
• Aprender de las fallas y corregir el camino
(Inspección y Adaptación)
22.
23. Necesitamos un nuevo modelo
• Que nos permita hacer inspección y
adaptación
• Que nos permita compartir el riesgo
• Flexible a los cambios
• Centrado en la colaboración
• Tiempo Fijo + Costo Fijo pero con
Alcance Variable
31. Las reglas incorrectas pueden ser perjudiciales para el
éxito del proyecto
Precios irreales --- Tiempos muy cortos o con demasiada holgura
Esperanzas funcionales irrealizables
33. ¿Qué información se debe incluir en un
contrato?
• Objetivos del proyecto
• Esquema de la estructura del proyecto
• Personas clave
• Pago y facturación, incluyendo bonos y cláusulas de penalidad
• Terminación temprana y normal
• Detalles legales
• ¿Qué más?
34. ¿Cómo saber si una forma de contratación
permite el agilismo?
• Enfocados en maximizar la colaboración Cliente-Proveedor
• Orientados a Ganar-Ganar
• Abierto a los cambios
• No establecen un Alcance Fijo
• Iteraciones Cortas
• El cliente revisa el trabajo hecho y prioriza restante
• Reflejan aspectos de finalización anticipada
• Requieren de confianza
• Buscan tener riesgo compartido
• Debido a que son ágiles el cronograma no incluye reservas de tiempo y costo
(colchones)
35. ¿Es necesario incluir el alcance en los
contratos?
Si el alcance es fijo, se vuelve
inflexible, ¿no?
36. Formas de contratos
• Alcance variable
• Tiempo y materiales
• Tiempo y materiales con alcance variable y límite en el costo
• Alcance fijo
• Precio fijo / alcance fijo
• Tiempo y materiales con alcance fijo y límite en el costo
• Variaciones
• Desarrollo por fases, ganancias fijas, bonos y cláusulas de penalidad, dinero
por nada – cambios gratis, Joint ventures (empresas conjuntas)
39. Contrato - Sprint
Calidad Alcance
Costo Tiempo
• Acuerdo Product Owner y Equipo durante el Sprint.
• Un proyecto basado en sprints son miniproyectos con los
siguientes parámetros fijos:
– Tiempo (duración del sprint)
– Alcance (Sprint Backlog))
– Calidad (Definition of done)
– Costo (valor del equipo durante el sprint)
40. Un proyecto Scrum sería una serie de
miniproyectos a alcance y tiempo fijos
13/07/2017 40
• Apenas aparece la
confianza, podría ser
reemplazado con
tiempo y materiales
con restricciones de :
– Costo límite
– Costo límite por
trimestre
– Proximo release
41. • Estructura: Trabajo por un mes y al final se envía la factura. Es el
paraíso para los proveedores.
• Riesgo: 100% del cliente. El proveedor tiene poco incentivo por
tener los costos bajos.
• Relación: Indiferente. El proveedor se siente muy contento pues
a mayor trabajo mayor dinero.
• Tip: Sugerido donde el cliente es mejor manejando el riesgo que
el proveedor. Por lo general hay un tope en los costos. Por lo
general degenera en «cara yo gano, sello usted pierde el
contrato», por lo tanto existe mucha presión sobre el valor hora.
Tiempo y Materiales
42. • Estructura: Mismo tiempo y materiales pero el costo esta limitando el
riesgo finaciero del cliente
• Riesgo: El presupuesto puede terminarse sin alcanzar el valor de
negocio. El cliente puede quedar insatisfecho pues no obtuvo todo lo
que quería.
• Relación: Cooperativa. La combinación de presupuesto limitado y
alcance variable, enfoca a cliente y proveedor en alcanzar el VALOR
con el presupuesto disponible
• Tip: Se ajusta al contrato-Sprint , el cual debe ser escrito al inicio de
cada sprint
Tiempo y Materiales con Alcance Variable y
Límite en el costo
44. Si cae cara yo gano, si cae sello tu pierdes.
«Yo fabrico mi
suerte».
Harvey Dent
«El cliente fabrica su
suerte»
Esquema tradicional
45. • Estructura: Acuerdo en los entregables y el precio de los mismos.
Una falsa seguridad es brindada al cliente.
• Riesgo: El riesgo del lado del proveedor
• Si el proyecto es mal estimado, se perderá dinero.
• Se cae en el juego de los controles de cambio.
• Relación: Competitiva a indiferente.
• El cliente generalmente quiere más y el proveedor hacer menos.
• El proveedor siempre quiere tener al cliente contento
• Tip: Forma actual de trabajo.
Precio fijo, Alcance Fijo, Tiempo Fijo
(todo fijo)
46. • Estructura: Mismo que precio fijo y costo fijo pero con la diferencia
que si el proyecto cuesta menos el esfuerzo actual es cobrado.
• Riesgo: Parece ser «el mejor de los dos mundos» pero siempre
beneficiará al cliente.
• Relación: Dependiente. Para el ciente es desventajoso pues no sabrá
con exactitud cuando completó el alcance esperado.
Tiempo y Materiales con Alcance Fijo
y Límite en el costo
47. • Estructura: Financiación por avance trimestral, y se logra
financiación luego de que cada Release trimestral es aprobado
• Riesgo: El riesgo del cliente es limitado a un trimestre.
• Relación: Cooperativa. Cliente y proveedor trabajan juntos para
lograr un Release aprobado para conseguir más financiación.
• Tips: Capitalistas de riesgos trabajan en esta forma.
Desarrollo por Fases
48. • Estructura: Se fija un beneficio para el proveedor en el proyecto.
Luego de allí se facturará sin margen para el proveedor, solo cubrirá
sus costos.
• Riesgo: Compartido.
• Si el proyecto termina rápido el cliente paga poco
• Si el cliente excede el presupuesto , se cobrará solo los costos, pero el
proveedor obtendrá el margen pactado.
• Relación: Cooperativa. Ambos están incentivados a terminar
rápidamente.
• El cliente ahorra dinero
• Y el proveedor tiene más margen
• Tip: Esto es frecuentemente combinado con un contrato de alcance
variable
Beneficio Fijo
49. • Estructura: El proveedor recibe incentivo si el proyecto termina
antes y paga penalidad si termina tarde. La cantidad de incentivo
o penalidad está en función del rango del tiempo.
• Riesgo: ¿El cliente tiene un incentivo para una temprana
terminación? El ROI lo es.
• Relación: puede llegar a ser cooperativa, pero degenerar en
indiferente si el cliente no piensa que requiere el software para
una determinada fecha.
• Tips: Aplica para proyectos de construcción, túneles, carreteras,
etc.
Bonos y Cláusulas de Penalidad
53. • Estructura: Consiste en tiempo y materiales con un costo objetivo. El
cliente premia al proveedor por alcanzar el valor mas rápido.
• Riesgo: Compartido. Ambas partes están interesadas en terminar el
proyecto rápido.
• Alcance: Puede ser cambiando. Reemplazado por funcionalidades no
implementadas de otras historias de usuario del mismo tamaño.
• Relación: Cooperativa.
• Tips: Si el presupuesto es excedido, las reglas de beneficio limitado o
límite en los costos puede aplicar.
Money for nothing, changes for free
54. • Estructura: Se pagará un valor hora si se termina antes, otro si se
termina dentro del rango de terminación y otro si se excede
• Riesgo: Compartido. Ambas partes están interesadas en
terminar el proyecto rápido.
• Relación: Cooperativa.
• Tips: Si el presupuesto es excedido, las regla límite en los costos
puede aplicar.
Contrato a precio fijo graduado
55. • Estructura: Los dos socios invierten en un producto de mutuo
interes.
• Riesgo: Compartido.
• Relación: Cooperativa.
• Tips: Considere el proyecto como una empresa a parte.
Joint ventures
58. Precio por punto de función o punto de historia de
usuario entregado
• Estructura: solo se pagará por punto de función o
de historia entregado (no estimado). Promoverá
la entrega de buen producto por parte del cliente
• Riesgo: Compartido.
• Relación: Cooperativa.
• Tips: Considere el proyecto como una empresa a
parte.
60. Bolsa de horas consumida
por estimaciones cortas
• Estructura: Se contrata una bosa de horas la cual es
consumida a petición del cliente por incrementos de
desarrollo. En este esquema:
– el Proveedor levanta los requisitos a tiempo y materiales
– Y luego con el detalle de lo que se desea hacer estima a
tiempo y costo fijo el desarrollo.
• Riesgo: Compartido.
• Relación: Cooperativa.
• Tips: Si lo que se desea realizar es muy grande el
riesgo comienza a aumentar y se puede caer en
proyectos a tiempo y costo fijo. Se recomienda para
desarrollos de máximo 2 meses.
61. Idea de Bob Martin. Precio por
punto de función o punto de
historia de usuario entregado,
pero se paga por hora si el
desarrollo es más lento (aplica
para el inicio del proyecto)
62. ¿Y si soy el proveedor?
1. No entregue relleno, entregue valor
2. Entregue frecuentemente
3. Sea flexible a los cambios
4. Pagos incrementales
5. Comparta beneficios
6. Hable con su cliente
7. Forme a su cliente
63. ¿Y si soy el comprador?
• Contratos pequeños e incrementales
• Desarrollo iterativo, con hitos frecuentes funcionando en ambiente
de calidad
• Pagos incrementales contra software funcionando
• Desarrolle a sus proveedores
64. Alguna vez escuche…
No me pague los primeros dos
sprints, pero si le gusta
seguimos trabajando así y me
los reconoce.
Beneficios:
Genera confianza y establece
como principio la
transparencia
65. Resumen Contratos Ágiles
Aspectos Claves
• Enfocados en maximizar la
colaboración Cliente-Proveedor
• Orientados a Ganar-Ganar
• Abierto a los cambios
• No establecen un Alcance Fijo
• Iteraciones Cortas
• El cliente revisa el trabajo hecho y
prioriza restante
• Reflejan aspectos de finalización
anticipada
• Requieren de confianza
• Buscan tener riesgo compartido
• Debido a que son ágiles el
cronograma no incluye reservas de
tiempo y costo (colchones)
Tipos de Contrato
• Bolsa de horas consumida por estimaciones cortas: Máximo dos sprints
• Contrato-sprint
• Contrato por fase o por reléase (máximo 3 meses de trabajo)
• Beneficio fijo: Se fija un beneficio y luego de allí se factura sin margen
• Valor hora graduado: Se paga un valor hora si se termina antes de una fecha y
otro valor hora si se termina después
• Precio por paquete de trabajo con opción de reestimarlo (ver)
• Precio por punto de historia con un valor hora mínimo a reconocer cuando el
desarrollo es lento
• Requieren confianza cliente-proveedor
• Tiempo y materiales
• Tiempo y materiales limitados por el costo
• Tiempo y materiales limitados por el tiempo
• Tiempo y materiales con alcance fijo y límite en el costo
68. ¡GRACIAS!
Jorge H. Abad L.
jorge.abad@gmail.com
@jorge_abad
Blog http://www.lecciones-aprendidas.info/
69. Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador
Anexos
70. Estas presentación contiene algunas diapositivas
e ideas de
• Ángel Medinilla - @angel_m
• Agiles Paraná -@agilesparana
• Agustin Villena -@agustinvillena
• Leonardo Agudelo @sweepnoise
• Wilmar Hincapie - @wilmarhincapie
• Nota: Trate de dar crédito a todos, pero consideras que faltaste por que no te
referencié o debo modificar algo de tu propiedad por favor no dudes en
hacérmelo saber, contactándome al email: jorge.abad@gmail.com
71. Aviso de Copyright
• Usted es libre de:
• Compartir- copiar, distribuir y trasmitir el trabajo
• Modificar- adaptar el trabajo
• Bajo las siguientes condiciones
• Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero
de ninguna manera que sugiera que ellos aprueban su uso del trabajo).
• Nada de lo dispuesto en esta licencia menoscaba o restringe los
derechos morales del autor.
• Para más información ver http://creativecommons.org/licenses/by/3.0/