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