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
