Una cooperativa de salud había tenido problemas con el paquete de software utilizado para administrar sus operaciones. Esto causó problemas operativos y daños a su imagen. Su administración decide establecer una compañía subsidiaria con la misión de desarrollar su propia solución de software que mejor se adapte a sus necesidades.
La metodología para desarrollar la nueva solución fue Scrum. La necesidad de rendición de cuentas de la nueva empresa y los requisitos de transparencia en el proceso son incompatibles con las métricas técnicas basadas en los ítems del backlog del equipo.
El backlog del equipo es constituido por tres tipos de ítems. Básicamente, pequeñas historias de usuarios; actividades arquitectónicas; y épicos imposibles de medir por las mismas técnicas utilizadas para las historias.
¿Cómo satisfacer A LA EMPRESA SOBRE LA EFIENCIA EN usar sus recursos sin compromentar las ganancias enel desarrollo ágil?
Resultado
La meta de productividad fue definida en un aterrizaje de 19% superior a la línea base.
El establecimiento de la meta fue con base en la medición en puntos de función de los releases entregados, de la colecta del esfuerzo invertido con su compatibilidad considerando el alcance de actividades con referencias de benchmarking y objetivos de mejora.
Los objetivos de mejora surgieron del descubrimiento de algunos delincuentes de productividad, hasta ahora ocultos al no tener una métrica que aislara la medición de la producción de la forma en que el equipo organiza los sprints y los elementos atrasados.
Los squads continúan autogestionándose al priorizar la acumulación del backlog del equipo y del backlog del sprint. Utiliza sus propios métodos para estimar en la micro gestión de cada sprint (o ni siquiera estimar según el caso). Cada 3 sprints, se lanza una nueva release.
Con cada release, la productividad global se calcula y evalúa en términos de la meta. El equipo puede evaluar su progreso desde una perspectiva más alta en el espacio entre releases a partir del factor de conversión de puntos de la historia a puntos de función actualizados con cada release. Es un foro para descubrir nuevas oportunidades de mejora, obstáculos durante el desarrollo de la release y soluciones alternativas.
Hay una mayor transparencia sobre cómo se aplican los recursos; las discusiones sobre posibles problemas en la eficiencia operativa permiten la identificación y solución tempranas. El retrabajo se reduce a lo necesario para un ciclo de experimentación, feedback y aprendizaje, y existe la preocupación de organizar mejor el backlog en este sentido.
Como las partes fueron integradas
Nuestro Centro de Presupuesto ha desarrollado un sistema para brindar visibilidad externa al controlador al establecer metas de productividad en puntos de función para planificar y monitorear el desarrollo a nivel de roadmap.
Aplicamos tecnologías de Analytics and Machine Learning para establecer relaciones estadísticas entre las métricas del squad, similar al story point, y la medición en puntos de función a nivel de roadmap. Utilizamos técnicas de regresión lineal, análisis de varianza (ANOVA) y pruebas estadísticas.
Nuestra Fábrica de Métricas realizó las mediciones de los releases usando el Análisis de Puntos de Función – IFPUG – por profesionales certificados CFPS.
Todas las herramientas de seguimiento gerencial fueron implementadas en planillas de planeación, monitoreo y control.
El cliente fue entrenado en los cursos de Capacitación en Análisis de Puntos de Función y realizó algunos Talleres de Medición en Puntos de Función con el propósito de mejor entender la métrica y ser capaz de auditar, si fuera necesario.
