Resolución de divergencias
La contestación en mediciones de software y la resolución de divergencias están presentes en todo tipo de medición. O sea, mediciones de una perspectiva interna, por ejemplo, el conteo de líneas de código, o externa, por ejemplo, el análisis de puntos de función, están sujetas a eso.
El anállisis estática de código fuente y otros itens de configuración son la base de las métricas internas. Herramientas como SonarQube, por ejemplo, las derivan automaticamente. Por tanto, permiten mediciones con poca margen para divergencias o contestación. Al final, los objetivos considerados en la medición son concretos y exigen cero interpretación. Cuando hay divergencias, son problemas cuanto a la interpretación de las reglas de conteo o de escape en que se aplican, que las motivan.
Las mediciones en una visión externa de negocio, en especial la medición de puentes de puntos de función, se basan en representaciones imperfectas y con mayor nivel de abstracción. Por eso, es natural que surjan divergencias entre mediciones. Es, el monitoreo de su frecuencia y naturaleza permite identificar oportunidades y problemas.
Corregir práticas equivocadas de medición
Son varios los casos de malas aplicaciones de las reglas de medición. De esta forma, su presencia promueve divergencias de medición; y las partes deben resolverlas. Por ejemplo, el desarrollador medir cada tabla del banco de datos como un archivo lógico; o entonces, incluir en el alcance de la medición funcionalidades ya existentes en el producto y cuyos requisitos funcionales no fueron alterados en aquella Release.
Mejor alinear el análisis y gestión de los requisitos a los objetivos
Los requisitos, en sus diferentes representaciones son uno de los principales insumos para medición. Problemas en la entrada, promueven problemas en la salida. Por ejemplo, las historias de usuario en Jira son mal elaboradas.
Subdividir una historia, inicialmente próxima a una funcionalidad del usuario no es en si un problema; tiene hasta nombre: Story-splitting. Pasa a ser un problema cuando deja de preservar la propiedad de que cada historia del usuario debe tener, separadasmente, valor de negocio mesurable. La medición acaba promoviendo la identificación de problemas de esta naturaleza, por ejemplo.
Si el análisis y gestión de requisitos son importantes en el desarrollo ágil y transformación digital, entonces ellos son fundamentales en el desarrollo tradicional. El privilegia la previsibilidad y los requisitos son clave para este fin. O sea, ese papel de divergencia como instrumentos de diagnóstico de problemas subyacentes de análisis y gestión de requisitos es más crítico aún.
Mejor alinear los objetivos de la medición a partir de casos concretos.
Diferentes son los niveles de evolución de software en que la medición o la aproximación del tamaño se inserta conforme los objetivos asociados.
Por ejemplo, la gestión de un contrato evaluar el desempeño del desarrollador con base en la aproximación del tamaño derivado de la documentación en etapas iniciales del desarrollo de una Release. En este caso, se debe considerar como insumos las historias del usuario usadas como entrada en el desarrollo para medición o aproximación del tamaño. En otro caso, la gestión del contrato evalua el desempeño con base en la medición del producto final entregado y usa como insumos los refinamientos derivados de aquellas historias originalmente incluidas en la Release.
Considerar a medição de um cenário em outro promoverá divergências e o problema está na falta de alinhamento sobre qual tipo de insumos considerar na medição naquele contexto em especial. Observe que em todos os casos podem ser histórias de usuário… No entanto, em que nível de refinamento?
La resolución de divergencias y mejores productos
Las divergencias en mediciones a partir de una visión externa no lo hacen peor que las mediciones en una visión interna. Eso sería como culpar al termómetro por la fiebre. La gestión de software debería considerar ambas en sus procesos y no como alternativa a la otra. Cada una cumple un propósito diferente; aborda diferentes ejes en la medición.
Los mejores productos de software son desarrollados por aquellos que entienden su propósito y el proceso de negocio en el cual se inserta. Para ese fin, alinear el flujo operacional en que la solución de software se inserta entre todos los desarrollados es un paso importante. Si la medición se inserta en el desarrollo ágil o en el contexto de transformación digital, entonces, la resolución de divergencias es una optima oportunidad para eso.
La resolución de divergencias esta lejos de necesariamente indicar un problema en si. Además de promover objetivos de eficiencia operacional y transparecnia, ella potencializa la entrega de mejores productos.
Una visión general de la resolución de divergencias en MESUR
Uno de los objetivos de Mesur © es de subsituir las planillas en las mediciones. En consecuencia, eso incluye el proceso de validación, calibrando o resolución de divergencias en mediciones de puntos de función.
Primero, se recomienda tener una visitón general sobre el papel de calibrador y como MESUR soporta su actuación en la evolución de validación y resolución de divergencias de una medición en el siguiente video.
En seguida, presentamos cuatro casos de uso del Calibrador en las resoluciones de divergencia con MESUR:
- El calibrador concuerda integralmente con un item de medición y quiere registralo como convergido en la validación y resolución de divergencias.
- El calibrador discrepa y justifica de la evaluación de un item en la medición por el analista; sin embargo, el calibrador concuerda con la presencia de aquel item en el alcance de la medición.
- El calibrador discrepa de la presencia de un item en el alcance de la medición; o sea, el analista incluye una funcionalidad más de lo que es necesario.
- El calibrador indica la ausencia de un item en el alcance de la medición; o sea, el analista dejó de incluir una funcionalidad necesaria.
