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

Los ANS y la agilidad

"En muchos casos los ANS (Acuerdos de Niveles de Servicio) parecen estar ahí más para destruir valor que para construirlo

Recomendación:
Vea el ANS como el peor tiempo de su servicio, no como el estándar a cumplir." pic.twitter.com/VR2RXof5wB

— Jorge Hernán Abad L. (@jorge_abad) March 14, 2019

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones

Hola a todos

En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:

• El equipo deberá mejorar un 1% cada sprint su velocidad 
• Ganará el RFP el proveedor que proponga el menor tamaño de sprint 
• Ganará el RFP  el proveedor que proponga menos sprints
• Ganará el RFP el que haga historias de usuario en menos tiempo

Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:

• deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
• por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
• Por cada error en producción se descontará $xx.xxx.xxx
• entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)

Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles

• Esté mal asesorado
• No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).

Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.

Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.

Clausula o ANS propuesto Observaciones el equipo deberá mejorar un 1% cada sprint su velocidad  Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible, Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides) O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora. Ganará el RFP el proveedor que proponga el menor tamaño de Sprint El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint. Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve. Ganará el RFP  el proveedor que proponga menos sprints Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso.  Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve Ganará el RFP el que haga historias de usuario en menos tiempo Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así. Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve

¿Cómo resolver esto?

• Opción 1: Prueba de Concepto

Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:

• tiene buen manejo de la metodología
• si equipo esta preparado y experimentado
• tiene gestión de la deuda técnica
• tiene prácticas técnicas
• su scrum master es preparado y con experiencia
• entregan software funcionando cada dos semanas

Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.

¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).

• Opción 2: Referencias

Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.

Lecturas Recomendadas

Recomiendo para la mejor comprensión y ayuda estos dos post

• Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2) -clic aquí- 
• Hablemos sobre Contratos Ágiles - clic aquí -

Bienvenido el feedback

Saludos ágiles
Jorge Abad