¿Cómo mantienen actualizadas sus especificaciones las empresas de desarrollo ágil?

Sé que voy a recibir algunas críticas por mi posición sobre esto. Pero también sé que no estoy solo. Así que aquí vamos …

La mayoría de los profesionales ágiles dicen que la biblioteca de prueba es su mejor fuente de comportamiento esperado del sistema. Y eso es verdad. Sin embargo, el comportamiento del sistema no es toda la historia. Si no conoce las reglas y requisitos comerciales implementados por el sistema, no sabrá por el caso de prueba por qué se espera el resultado específico. Entonces, cuando ingresa para hacer un cambio o extender la funcionalidad, realmente no lo comprenderá y podría romperlo. Por ejemplo, el sistema usa un algoritmo específico para generar algunos resultados. El algoritmo no se menciona en el caso de prueba, solo las entradas y salidas esperadas para ejercerlo. Puede revisar varios casos de prueba que cubren valores límite, casos límite y flujo normal, y eventualmente derivan la regla comercial subyacente. ¿Pero por qué deberías hacer eso?

Cuando mi organización decidió adoptar scrum, nuestro entrenador dijo “¡no más requisitos! ¡Solo historias de usuarios y condiciones de aceptación! ”Como si esto nos hiciera felices a todos. Pero me preguntaba cómo sabríamos qué implementamos meses después cuando los “requisitos” estaban en ese montón de historias de usuarios completadas. Así que seguí manteniendo los requisitos en un modelo funcional. Durante cada sprint mientras el equipo completaba una historia de usuario, capturé la funcionalidad en forma de requisitos. Hubo considerablemente más decisiones sobre la funcionalidad realizada durante cada sprint que lo que se especificó en los CoAs.

Después de aproximadamente medio año, el gerente de control de calidad se acercó a mí y me preguntó: “¿Cuál era la regla sobre XYZ? Mi equipo tiene un PBI para hacer un cambio y no puedo recordar por qué está haciendo lo que hace en ciertos casos ”. Fui alegremente a mi modelo de requisitos, encontré esa área de funcionalidad y encontramos la regla que estaba buscando. Solo por diversión, busqué a través de la lista de pedidos completada y encontré la historia de usuario original. La regla no estaba documentada allí, había sido una decisión de mitad de carrera.

He tenido clientes que piden ver especificaciones de requisitos para el producto que están comprando. Debido a que tengo un modelo de requisitos funcionalmente organizado, puedo generar uno. Las solicitudes de propuestas a menudo tienen preguntas que pueden responderse mediante una revisión de los requisitos. Nuestro modelo de requisitos también tiene una matriz de rastreo. Puedo rastrear desde un conjunto de códigos registrado hasta los requisitos funcionales que implementa y los casos de prueba que lo ejercen.

Hoy superviso a cuatro equipos scrum que utilizan modelos de requisitos para realizar un seguimiento de sus productos en evolución. Los BA capturan los requisitos a medida que se implementan. Los probadores vinculan los casos de prueba a ellos. Y los codificadores recurren a ellos cuando tienen preguntas granulares que no están cubiertas por los CoAs en el PBI. Somos una tienda de Microsoft, por lo que estamos utilizando TFS y Visual Studio (y complementos variados) para la gestión de elementos de trabajo, control de origen, gestión de pruebas y compilación / implementación. Utilizamos IBM Rational DOORS para los modelos de requisitos y Rational Publishing Engine para generar documentos cuando sea necesario. Si bien casi todos tienen una licencia para TFS, tenemos solo un puñado de licencias de DOORS flotantes y solo una licencia de RPE, por lo que la inversión no es enorme.

La “especificación” del producto se convierte esencialmente en una lista cada vez mayor de inglés simple, criterio de aceptación de prueba ensamblable. Cada historia de usuario tiene sus criterios de aceptación específicos adjuntos. Idealmente, QA ha establecido pruebas funcionales automatizadas que incorporan nuevos criterios de aceptación y luego hace afirmaciones de prueba en su contra para que la última versión siempre esté de acuerdo con las “especificaciones” actuales, pero siempre cambiantes.

Si el objetivo es mantener a todos alineados con el resultado esperado durante el desarrollo, mantenga a los miembros del equipo, incluido el propietario del producto, cerca uno del otro. Para el proceso, tener criterios de aceptación bien definidos y una cobertura de prueba automatizada ayuda con la documentación y el mantenimiento futuro.