Documento de análisis en Scrum

Estoy en una agencia web que está tratando de implementar desde Waterfall a Scrum, por lo que tenemos viejos hábitos que necesito cambiar para adoptar una forma más Scrum.

Uno de mis problemas es el documento de análisis funcional en el que se basan mis desarrolladores y QA. Tenemos un analista funcional comprometido a tiempo completo para escribir esos documentos, hacer que los propietarios de productos los aprueben y luego transferir la información a los desarrolladores, quienes a su vez hacen muchas preguntas tanto al analista funcional como a los propietarios de productos. El QA escribe sus casos de prueba de acuerdo con el análisis funcional.

¿Cómo puedo reemplazar su necesidad de documentación y deshacerme del documento de análisis manteniendo la aprobación del cliente?

Más tarde estoy pensando en el contrato ágil y/o el documento DOD, pero me gustaría saber qué sugerirían otros en una situación similar.

Recomendaría leer "User Stories Applied" de Mike Cohn. Cubre todo el tema de trabajar con los problemas.

Respuestas (2)

Reemplace los documentos con conversaciones y busque la comprensión compartida en lugar de la transferencia de conocimientos.

Mi equipo (Devs, Analyst, QA, PO) se reúne durante 30 minutos todos los días para hablar sobre las próximas historias, sus criterios de aceptación y cómo vamos a probarlas. Esto les da a todos la oportunidad de hacer preguntas y que el propietario del producto tenga la confianza de que todos entienden lo que están preguntando.

Estoy de acuerdo en que también es bueno involucrar a los desarrolladores en la actividad de análisis, particularmente en cualquier reunión con las partes interesadas.

La clave es preguntar qué propósito cumplen los documentos. La aprobación del alcance, la transferencia de conocimientos a los desarrolladores y la entrada de control de calidad en las pruebas se pueden manejar involucrando al cliente en discusiones con los desarrolladores/evaluadores y asegurándose de que los requisitos se capturen en forma de criterios de aceptación.

Si hay otras razones para que existan los documentos, es bueno intentar examinar por qué son necesarios y, cuando sea posible, entregar el valor del documento de una manera más colaborativa.

Eso no siempre es fácil con terceros con disponibilidad limitada. Un analista puede ser un buen representante del cliente en estos casos. Hacer que se emparejen con desarrollo/control de calidad es mejor que hacer que escriban un documento.

No estoy seguro de que el reemplazo completo de la documentación tenga algún beneficio en el caso de @Stef. Muy a menudo, debe mostrar una lista de características, pruebas de aceptación e informes de prueba al cliente.
¡Me quedé sin caracteres en el comentario, así que lo agregué a mi respuesta!
Gracias ahora lo veo. Estoy de acuerdo en que el propósito es imprescindible y esto es lo que la gente olvida con mayor frecuencia.

Son los desarrolladores quienes finalmente hacen el desarrollo de todas las funcionalidades. Por lo tanto, siempre se recomienda que los desarrolladores realicen el análisis funcional.

De esta manera, también está aumentando el atributo multifacético de los desarrolladores. Y no necesitan reiterar entre el analista funcional y el gerente para aclarar las cosas durante el desarrollo.

Pero después de que los desarrolladores realicen el análisis funcional inicial, la persona designada siempre puede ratificar el resultado. De esta forma cada uno desarrolla la visión dimensional del producto que está desarrollando.