Video: Contratación y Gestión de Proyectos de Sofware

¡Los invito a ver este video sobre un #CastorSinFiltro en el que comparto reflexiones sobre los desafíos en la contratación y gestión de #ProyectosdeSoftware:

• En ocasiones, los #contratos y #RFP son asignados por áreas de #costos, priorizando la #eficiencia o el #ahorro en el #precio, lo cual va en detrimento de la excelencia técnica y el rendimiento del software.
• Muchos proyectos son #gestionados por profesionales excelentes que tienen poca o ninguna experiencia en el desarrollo de software, lo que lleva a ignorar la #complejidad inherente. A menudo se percibe erróneamente el desarrollo de software como una línea de producción, donde hacer una pieza es igual a hacer otra. Sin embargo, el software es inherentemente impredecible y preciso. Dos piezas aparentemente similares y "pequeñas" pueden requerir tiempos de desarrollo completamente diferentes. Una bien construida puede ser rápida de desarrollar, mientras que otra, en un entorno #hipercomplejo, puede llevar hasta seis veces más tiempo o incluso más.

Es importante recordar que desarrollar software no es una tarea ni predecible ni exacta: Dos tareas aparentemente iguales y "pequeñas" pueden requerir tiempos completamente distintos. Una puede estar bien construida y tomar poco tiempo, mientras que la otra puede encontrarse en un entorno hipercomplejo y requerir hasta 6 veces más tiempo que la primera.

¡Comparte tus comentarios! ¿Qué desafíos has enfrentado en la contratación o gestión de proyectos de software?

Presentación: Contratos Ágiles - Agile Contracts. Actualización 2023-05-27

FORO "COLABORACIÓN CON EL CLIENTE SOBRE NEGOCIACIÓN CONTRACTUAL" #AgilesCo2020

¡La base de los contratos ágiles es la confianza! 🤝

Comparto las notas visuales del Foro Colaboración con el cliente sobre Negociación Contractual, en @AgilesColombia 2020, edición Online.#agilesco2020 #contratosagiles #graphicrecording pic.twitter.com/nFdEzWPVPO

— Juliana Betancur (@julibetancur) August 22, 2020

Tabla Comparativa de la Triple Restricción (Alcance, Tiempo y Presupuesto) y su Compatibilidad para Contratos Ágiles

Hola a todos

Desde hace un tiempo tenía este pendiente, estas fichas técnicas y tabla comparativa de la triple restricción (alcance, tiempo y presupuesto) en un contrato y como esta puede ser usada para entornos de contratación ágil.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto= fijo		baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el tiempo y presupuesto determinado. Entre más grande el proyecto o iniciativa peor será este impacto.		- Un alcance fijo no es buena práctica en un mundo VUCA(1). - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto=Variable		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas. - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, tiempo determinado Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio. - Es posible que por contar con presupuesto ilimitado trate de cerrarse el proyecto o iniciativa por fuerza bruta, pero es probable que "ni todo el dinero del mundo" ni los recursos alcancen a cerrarlo en la fecha pactada

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo=Variable Presupuesto=fijo		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el presupuesto pactado. Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= variable Presupuesto=variable		Media-alta
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	-Posiblemente no se logre resolver el problema pues el alcance fijo no garantiza que se construya lo que resuelve el problema		'- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= fijo Presupuesto=fijo		Alta-baja
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el tiempo o el presupuesto, construyó lo de mayor valor primero	-Posiblemente no se logre resolver el problema con esas dos restricciones		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance = variable Tiempo= variable Presupuesto=fijo		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solución para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el presupuesto, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable Tiempo= fijo Presupuesto=variable		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el el tiempo, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción. Es posible que como se cuentan con presupuesto sin restricciones, se trate de cerrar el proyecto o iniciativa en la fecha pactada, pero ni aun así se logre el objetivo		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= variable Presupuesto=variable		Alta-alta
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* constantemente las funcionalidades al momento de construirlas, que se garantice el mayor impacto	- No realizar una ejecución ágil del proyecto o iniciativa		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

* Se sugiere emplear la técnica de WSJF - weighted shortest job first

Puedes descargar en formato PDF aquí

Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.


Notas, Aclaraciones, Comentarios, Referencias y  Observaciones.

1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en  https://es.wikipedia.org/wiki/VUCA

Algunos ANS (Acuerdos de niveles de servicio) y Penalidades sugeridas en el Mundo del Desarrollo Ágil de Software

Hola a todos

En el pasado Ágiles 2019, presente la charla "Tips para una PMO perdida en el Mundo Ágil" - clic aquí -  y uno de los puntos en los cuales hay una constante inquietud por parte de las organizaciones tradicionales es:

¿Cuáles son las ANS (acuerdos de niveles de servicio )(1)  y penalidades aplicarían en un contrato de desarrollo ágil?

Responsabilidades en el Desarrollo Ágil

Para empezar, establezcamos responsabilidades bajo el esquema ágil

• el cliente es responsable del producto que esta requiriendo, o seá,
• tener claro el ¿para qué?
• ¿el Qué? 
• y que sea el producto correcto
• el equipo (que puede ser un proveedor externo) es responsable de la calidad técnica y funcional del producto que esta construyendo, es decir:
•  ¿Cómo esta construido? o
• ¿Construir el producto de forma correcta?
• el facilitador, líder, coach, Scrum Master, Agile Coach, que acompaña a cliente y equipo es responsable de la mejora continua de ambos y de lograr la mayor fluencia, es decir, la menor fricción entre cliente, equipo, y el entorno para ser exitosos, es decir:
• ¿Cómo interactuamos mejor?
• ¿Cómo podemos dar mejor resultado, y más rápido?

Los ANS Sugeridos y Deseables

Con este contexto, y habiendo clarificado que la responsabilidad del equipo es sobre "como construye el producto" les comparto algunos ANS, que se sugieren y que son deseables para el mundo ágil:

Tomado de (2)

Sugeridas

• Nivel de cumplimiento de los sprint (historias finalizadas/ historias de usuario acordadas). Valor sugerido>=80% (suponiendo que el marco de desarrollo sea Scrum)
• Calidad de los entregables (Defectos encontrados en Producción/Pruebas unitarias y de aceptación). Valor sugerido<=10%
• Efectividad de las pruebas (defectos encontrados en Producción/Cantidad de defectos). Valor sugerido<=10% 
• Deuda técnica (validación estática de código). Valor a acordar 

Descripción Objetivo Formula Medición Unidad Medición Valores Aceptación Peso Nivel de cumplimiento en los Sprints Controlar que las historias de usuario acordadas en cada sprint sean finalizadas por cada uno de los equipos (Historias de Usuario finalizadas por en cada sprint / total de Historias de Usuario comprometidas por en cada sprint) *100 % sprint  >= 80% xx% Calidad de los entregables Promover la calidad general del producto Cantidad de defectos encontrados en producción una vez se instale funcionalidades de un sprint  (Cantidad de defectos encontrados / Casos de pruebas unitarias + aceptación)*100 % sprint <=10% xx% Efectividad de las pruebas   Promover la calidad general del producto Porcentaje de defectos identificados en producción sobre el total de defectos encontrados (Número de defectos en producción / Total de defectos en fase de pruebas (Incluido unitarias, aceptación Y Producción))*100 % sprint <=10% xx% Deuda Técnica Promover la calidad técnica del producto % de deuda técnica identificada por el validador estático de código % sprint Valor a acordar (depende del producto) xx%

Deseables (Depende de la madurez en DevOps de la organización contratante y el equipo de desarrollo) 

• % de cobertura de pruebas unitarias. Valor a acordar 
• % de cobertura de pruebas funcionales automatizadas. Valor a acordar

Descripción Objetivo Formula Medición Unidad Medición Valores Aceptación Peso Cobertura de pruebas unitarias Promover la calidad técnica del producto del producto Cobertura de pruebas unitarias al código en % % sprint >= 80% xx% Cobertura de pruebas funcionales automatizadas Promover la calidad técnica y funcional del producto (Total de casos de pruebas funcionales automatizados/ Total de casos de pruebas funcionales) *100 % sprint >=70% xx%

Y las Penalidades

Las dejo a su consideración, realmente no estoy de acuerdo con el DPS (o Desarrollo Punitivo de Software) donde en el esquema de desarrollo tradicional o cascada se activan cantidades y cantidades de penalidades, tantas que como proveedor puedes terminar pagando económicamente al cliente cuando debería ser al contrario. Nadie se mete a hacer desarrollo de software (o a cualquier negocio) para terminar pagándole a su cliente.

Soy mas partidario de lo que comparto en la charla de contratos ágiles(3), tener esquemas de finalización anticipada, y si el cliente o el proveedor no dan la talla (el tema es mutuo), simplemente terminar la relación comercial sin penalidad alguna, con la ventaja que en el mundo ágil y específicamente con Scrum siempre tienes software de valor funcionando cada mes o menos (por lo general cada dos semanas).

Hasta acá este compartir

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. También conocidos como SLA - Service Level Agreement, por sus siglas en inglés.
2. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 
3. Hablemos de contratos ágiles - http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Un tipo de Contrato que te permitirá trabajar en mundo Ágil - Contratos Ágiles

Hola a todos

Considerando que frecuentemente me preguntan cual es el tipo de contrato que mejor se lleva con la agilidad, y le es natural al cliente trabajar con el, les comparto estos slides de mi presentación de Contratos Ágiles (clic aquí):

----

---

---

Tomado de: http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Más sobre contratos ágiles en: http://www.lecciones-aprendidas.info/search/label/contratos%20agiles

Hablemos de Contratos Ágiles - Reloaded

Hablemos de Contratos Ágiles - Agile Contracts (Reloaded) from Jorge Hernán Abad Londoño

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?)

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde del punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

• El alcance no puede ser fijo en estos tiempos de alta disrupción (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2) 
• El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor. 
• Tal vez (la verdad, muy seguramente) te obligues a construir lo innecesario. 
• Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
• Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
• Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones. 
• Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad. 
• Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente. 
• La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas. 
• Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente. 

Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.

• De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades. 
• Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución 
• Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan 
• Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto) 
• Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil. 
• Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.

Soluciones

• Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
• Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso. 
• En un contrato ágil nunca pongas el alcance fijo. 
• Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria. 

Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios


Saludos Ágiles

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Referencias, comentarios, notas y aclaraciones

1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html
3. Este artículo fue escrito a cuatro manos, y fue publicado en el Gazafatonario IT en http://www.gazafatonarioit.com/2018/11/por-que-no-debes-contratar-en-cascada.html

Hangout ¿Cómo Contratar un proyecto ágil? (o filosofemos sobre contratos Ágiles)

Tip sobre Proyectos y Contratos Ágiles

"Hacer un Producto/Proyecto Ágil con un contrato tradicional (alcance, tiempo y costo fijos) es un completo dolor de cabeza para todos -cliente y proveedor-. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance."

_

Hacer un producto/proyecto #Agile con un contrato tradicional (alcance, tiempo y costo fijos) es un dolor de cabeza para todos. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance https://t.co/M2FkrzODN2

— Jorge Hernán Abad L. (@jorge_abad) October 24, 2018

Datos, Hechos y Beneficios de Agile+DevOps en una Empresa Pública de Colombia

Hola a todos

Aunque cada vez es menos frecuente la incredulidad hacia Agile, siempre es bueno contar con casos de éxito y en especial con una colección de métricas capturadas en un entorno empresarial, para compartirlas con personas y empresas que se están acercando al concepto.

A continuación les comparto este Tweet de Claudia Toscano quien trabaja en área de TI de Empresas Públicas de Medellín (empresa con sede en Medellín - Colombia), con una hermosa colección de métricas como resultado de aplicar Agile y DevOps en su entorno.

Aunque parece obvio, importante resaltar que corresponden a datos de una Empresa Pública.

---

Cuando son ellos quienes te buscan para trabajar con esos marcos ágiles y automatizar pruebas y despliegues, sabes que hiciste bien la tarea! #epmagile @ricardorq85 @sperezj @RoseRestrepoV @EPMestamosahi @kleer_la @Intergrupo @10pines @techandsolve @CeibaSoftware pic.twitter.com/HJyodXFDAP

— Claudia Toscano Varg (@claudytoscano) July 31, 2018

---

---

---

Nota Importante: Si como empleado público (o empleado privado) insistes en contratar proyectos de desarrollo de software en cascada (waterfall, o tradicional, es decir: una fase larga de levantamiento de requisitos, luego otra de desarrollo, luego una tortuosa de pruebas y por fin una entrega tardía y un contrato con alcance, tiempo y costo fijo) es muy probable que estés incurriendo en algo que en Colombia le llamamos Detrimento Patrimonial - es decir, estas haciendo mal uso de los recursos del Estado - o de tu organización - y estas probablemente derrochando probablemente un valor cercano al 50% del valor del contrato-, pues existen numerosos estudios que demuestran que hacer proyectos en cascada genera desperdicios en funcionalidades que no serán usadas cercanos al 50%. Anexo resultados de un estudio muy conocido "el Manifiesto del Caos  del 2013(ver Página 6)":

Te comparto algunos links que aun funcionan:

• http://fliphtml5.com/scht/mwde/basic
• https://es.scribd.com/document/198550543/Chaos-Manifesto-2013

Saludos ágiles

Jorge Abad