Si una organización está regulada, debe pasar la auditoría y demostrar que ha implementado una "trazabilidad de requisitos". Lo que significa que ha documentado la ruta desde un requisito específico hasta un cambio de código y un producto funcional en producción. Al menos así lo entiendo yo.
¿Cómo funciona esto en Agile/Scrum? Actualmente, la única forma en que vi que esto se implementa es la siguiente:
Como persona XP, encuentro esto extremadamente sofocante. Si tuviera que encontrar un lugar para hacer una mejora, necesitaría pasar por todo ese proceso para implementarlo. Este proceso puede llevar fácilmente días o incluso semanas (es decir, en tiempo real, sin esfuerzo, mucho tiempo de espera entre preparación, planificación e implementación). Incluso cuando el cambio en sí puede tardar 30 minutos. Entiendo la necesidad de este tipo de documentación, pero no estoy lo suficientemente versado en esta ley específica para poder determinar si esto es aceptable o no.
¿Es correcta mi comprensión de este problema? ¿Existen otras formas de implementar la trazabilidad de los requisitos para una organización regulada que no tenga una sobrecarga tan grande? ¿O es algo con lo que debería aprender a vivir?
Su comprensión de la trazabilidad es correcta. La idea es rastrear la funcionalidad desde el origen hasta la implementación y el despliegue para determinar si el sistema implementa la funcionalidad requerida.
Cualquier cambio, por grande o pequeño que sea, debe tener un ticket en un rastreador, como Jira.
Esto es algo correcto. Las herramientas como Jira que tienen integración con los sistemas de control de versiones y las herramientas de documentación facilitan la trazabilidad debido a esas integraciones, pero la trazabilidad no requiere herramientas específicas. Posiblemente, puede mantener los requisitos en un documento o una hoja de cálculo y usar ID únicos para realizar un seguimiento de las confirmaciones y las solicitudes de extracción.
Este ticket debe tener todas las necesidades de una especificación, antes de que se implemente. Esto significa cosas como criterios de aceptación detallados y estimaciones de tiempo.
El nivel de especificación en el elemento de trabajo varía. No se requieren estimaciones para la trazabilidad de los requisitos. Esperaría que el problema en el sistema de seguimiento de problemas sea autónomo y brinde un fácil acceso a cosas como los criterios de aceptación, ya sea por inclusión o referencia. Consideraría las características de los buenos requisitos y los criterios INVEST .
Cuando se implemente, todos los cambios en el código deben incluir la identificación del rastreador del requisito.
Esto no suele ser un requisito. Por ejemplo, Jira otorga a cada problema una identificación única. Jira también permite vincular el problema a la solicitud de extracción y la solicitud de extracción de nuevo a los problemas. La vinculación es lo importante. Si puede ver una línea de código, busque la confirmación que la introdujo, vaya a la solicitud de confirmación o extracción donde se agregó y busque el problema que representa el requisito para ese trabajo (y viceversa, del requisito a las líneas del código), la trazabilidad está satisfecha.
El ticket en el rastreador debe seguir un proceso predefinido de pasos desde Preparación, En desarrollo, En control de calidad y, finalmente, Listo.
Aunque esto es útil, el flujo de trabajo en el sistema de seguimiento de problemas debe reflejar el proceso real y ser útil para el equipo. Herramientas como Jira mantienen un historial para cada problema: quién actualizó qué campos, comentarios y debates, vínculos entre problemas relacionados para mostrar dependencias y descomposición.
Como persona XP, encuentro esto extremadamente sofocante. Si tuviera que encontrar un lugar para hacer una mejora, necesitaría pasar por todo ese proceso para implementarlo. Este proceso puede llevar fácilmente días o incluso semanas. Incluso cuando el cambio en sí puede tardar 30 minutos. Entiendo la necesidad de este tipo de documentación, pero no estoy lo suficientemente versado en esta ley específica para poder determinar si esto es aceptable o no.
¿Es correcta mi comprensión de este problema? ¿Existen otras formas de implementar la trazabilidad de los requisitos para una organización regulada que no tenga una sobrecarga tan grande? ¿O es algo con lo que debería aprender a vivir?
Si está utilizando herramientas configuradas de manera adecuada y correcta que facilitan el proceso, no veo por qué la trazabilidad de los requisitos debería llevar "días o incluso semanas". Dependiendo de su elección de herramientas, algunos aspectos de la trazabilidad pueden simplemente "desviarse" de la forma en que usa las herramientas.
El desarrollo impulsado por el comportamiento (BDD) puede ser una buena forma de reducir la sobrecarga de la trazabilidad de los requisitos.
El enfoque es el siguiente:
Usando este enfoque, es relativamente simple agregar la trazabilidad de los requisitos.
Puede argumentar que la naturaleza de autodocumentación de BDD es suficiente o que aún necesita agregar ID si su organización lo requiere.
Todavía hay esfuerzo involucrado, por supuesto, pero es un esfuerzo útil que ayuda a producir requisitos desarrollados, para permitir pruebas de regresión exhaustivas y producir código autodocumentado con el que es más fácil trabajar.
eufórico
Tomas Owens
Hans Martin Mosner
Tomas Owens
deuda del sistema