Necesito ayuda: documentación para personas no técnicas que usan Agile

TL;RD

No hay bala de plata. Sin embargo, es probable que su organización necesite adoptar un conjunto más completo de herramientas y prácticas ágiles para reducir la documentación innecesaria o engorrosa.

Las prácticas ágiles a menudo ofrecen una mejor documentación

Es posible que su pregunta sea demasiado amplia para responderla, pero me arriesgaré y supondré que su organización ha hecho una transición reciente a "Ágil" (lo que sea que la organización crea que eso significa) sin haber adoptado realmente el marco completo, o sin implementando prácticas ágiles comunes como Test-Driven Design (TDD) o Behavior-Driven Development (BDD). Esta es probablemente la fuente de su problema.

Los marcos ágiles valoran los productos de trabajo por encima de la documentación extensa. El Manifiesto Ágil dice:

Software funcional sobre documentación completa...[E]aquí hay valor en los elementos de la derecha, [pero] valoramos más los elementos de la izquierda.

Esto no significa que los equipos ágiles no documenten nada. De hecho, los equipos ágiles y de DevOps de alto rendimiento a menudo producen documentación más útil que antes de adoptar prácticas ágiles. Esto generalmente se debe a que:

1. La "documentación viva", como el código bien comentado y refactorizado con frecuencia, suele ser más precisa que los jeroglíficos de árbol muerto del brumoso amanecer de los tiempos cuando probablemente se generaron los requisitos iniciales.
2. Cuando se escriben correctamente, las pruebas TDD/BDD/ATDD se leen como documentación en lenguaje natural y, a menudo, incorporan términos y conceptos del dominio comercial del producto y el punto de vista del usuario.
3. La integración continua mediante buenas pruebas garantiza que su documentación se mantenga actualizada y precisa , algo en lo que la mayoría de los proyectos tradicionales fallan estrepitosamente.
4. La documentación del usuario final o del sistema (cuando sea necesario) a menudo se compila mediante programación a partir de comentarios de código, pruebas ejecutables, firmas de API, etc. Nota: Esto requiere buenas prácticas y buenas herramientas.
5. Cualquier documentación necesaria que no sea autogenerada debe ser parte de la Definición de Terminado para cada Elemento de la Lista de Producto (PBI) y el Incremento de la iteración.

En Scrum, debe tener incrementos demostrables de trabajo en cada iteración. A menudo, esto es más valioso que los árboles muertos, porque representa un incremento potencialmente entregable y algo que las partes interesadas pueden ver (y, a menudo, tocar).

Maximice la cantidad de trabajo no realizado eliminando la documentación innecesaria y concéntrese en implementar prácticas que reduzcan las tareas de documentación verdaderamente esenciales a proporciones manejables.

FRD es una forma de documentar (en forma de cascada) cuáles son los requisitos funcionales previstos . Esto no suele documentar la implementación real . Usando métodos ágiles, puede comunicar mejor al personal no técnico lo que realmente se está entregando. Aquí hay algunas sugerencias para permitir una documentación completa mientras se mantiene ágil y productivo:

1. Haga que los redactores técnicos formen parte del equipo del proyecto y creen documentación técnica y no técnica del producto de forma iterativa. Puede agregar "documentación del producto completada" como criterio de aceptación para sus historias de usuario. La documentación oficial del producto puede ser su documento vivo.
2. Realice una demostración de alto nivel previa al lanzamiento (a través de su gerente de producto). Esta demostración de alto nivel puede ayudar a los gerentes de departamento, ventas y marketing a comprender lo que se está entregando. Puede agregar esto a sus procesos de revisión de sprint.
3. Agregue consideraciones de capacitación interna más detalladas a su lista de verificación de entrega de lanzamiento para que pueda considerarla para cada sprint o lanzamiento. Puede marcar epopeyas o historias que requieren capacitación interna y quién debe ser responsable de realizar la capacitación.
4. Realice capacitaciones internas más detalladas (es decir, capacite al capacitador) para las partes interesadas internas interesadas (como atención al cliente y capacitadores). Grábelos y tenga el video disponible para aquellos que estén interesados ​​en hacer referencia. Agregue un enlace del video a la documentación de referencia de su proyecto. La capacitación interna puede ser muy útil para identificar tendencias en preguntas que quizás desee responder dentro de la documentación oficial del producto.

Desde el principio puedo pensar en 3 formas de comunicar resultados y requisitos:

1. Invite a las partes interesadas a Sprint Review o tal vez a Daily Stand Up
2. Muestra a los Stakeholders la Información de tu producto Radiadores

3. Actualice el canal wiki/Slack del producto :

   • Tener una visión general de los resultados/KPI/requisitos del Producto conocidos desde el principio (con diapositivas o cualquier otra documentación)

   • Enfocar las descripciones generales en la entrega de valor (ganar: $/información de usuario/etc. y reducir: costos) y compartir según sea necesario

   • Pida a los miembros del equipo que agreguen detalles adicionales y descripciones generales de las funciones a medida que el producto evoluciona y surge nueva información.

Si Agile es nuevo en su cultura, asegúrese de que la comunicación con las partes interesadas pase por el propietario del producto y/o el Scrum Master . Esos 2 roles garantizarán que los extraños no descarrilen al equipo de desarrollo.

¡Buena suerte!