Documentación en Métodos Ágiles

Todavía existen muchas preguntas sobre cómo gestionar adecuadamente la documentación en métodos ágiles, y la respuesta, siendo honestos, no es tan simple.

Comencemos por el más conocido: Scrum moderno

La diferenciación entre los métodos ágiles no es insignificante, ya que si intentan respetar uno de los 4 valores del Manifiesto Ágil, la interpretación de esta oración puede diferir fácilmente.

Valor del Manifiesto Ágil:

« Software en funcionamiento más que documentación exhaustiva »

Si comenzamos desde la historia de usuario, en la generalidad de los proyectos de Scrum, los equipos comienzan la documentación con la implementación de historias de usuario (una práctica que proviene de Extreme Programming).

¿Qué poner en nuestras historias de usuario?

Algunos equipos desarrollan aplicaciones a partir de historias de usuario que caben en una hoja pequeña. Sin embargo, en una gran cantidad de proyectos, temo que esta práctica carezca de precisión y pueda resultar costosa en el futuro: ¿cómo asegurar las reglas de gestión? ¿Cómo encontrarlas más tarde?

Para garantizar una comprensión perfecta de la historia de usuario, parece esencial alimentarla con reglas de gestión, esquemas, escenarios de prueba u otros elementos complementarios, ya que no existe un formato perfecto.

¿Es suficiente la historia de usuario?

Una pequeña frase que escuché en el pasado: « lo ágil dice que no se necesitan documentos exhaustivos, así que no hacemos documentación… ». La interpretación es simplista y alejada de la idea del manifiesto ágil; el problema es que algunas personas leen el comienzo de la oración « Software en funcionamiento más que » para entender toda la filosofía sobre el tema.

« En lugar de » significa que no excluimos la documentación (incluso exhaustiva si exageramos la interpretación), pero se prefiere el software. De hecho, la documentación se crea a partir del software y no al revés; esto es diferente a los métodos de gestión de proyectos como el Ciclo V u otros modelos en cascada. A diferencia de Scrum, algunos métodos ágiles crean documentos esenciales antes del desarrollo (aunque no son documentos exhaustivos).

En algunos contextos, la historia de usuario no es suficiente porque su historización puede convertirse rápidamente en un rompecabezas.

De hecho, en el ámbito ágil, puedes crear documentos completos o no debes privarte, pero generalmente después del desarrollo. Hacer documentación después del desarrollo hace que la documentación esté mucho más cerca del producto terminado.

Puede que necesites documentación técnica sobre la base técnica del producto, documentación de usuario y documentación funcional. No te prives de ello, sería un error.

Solo la documentación necesaria

La documentación en el mundo ágil es incremental; un proyecto mejora con la retroalimentación de los clientes, por lo que hacemos la documentación justo a tiempo.

Si esta forma de trabajar cambia el trabajo de los equipos, eso no elimina la necesidad de documentación esencial para la sostenibilidad del producto. A diferencia de los métodos de gestión de proyectos como el Ciclo V, es necesario que un proyecto vea cómo se crea su documentación a medida que avanza, de lo contrario, una parte de ella será una pérdida de tiempo innecesaria.

Hacer documentación simple

Aquí tienes un consejo que te doy; no dudes en simplificar al máximo tu documentación para que encaje en la filosofía KISS (Mantenlo simple, estúpido), que también se puede aplicar a la documentación.

Simplificar la documentación tendrá buenos resultados: será más fácil de mantener y dará al producto más posibilidades de evolucionar, ya que los futuros miembros del equipo la entenderán mejor…

Para las historias de usuario, la recopilación de historias de usuario por Épica (y por tema en el nivel superior) puede ayudar a simplificar la documentación funcional tanto como sea posible; esto es suficiente para representar la documentación funcional del producto.

Sin embargo, esto implica una descomposición muy buena de las historias de usuario y el uso de Épicas y Temas (el mapeo de historias realmente ayuda en la gestión).

Tu documentación funcional podría ser un Jira con el complemento Story-mapping de forma sencilla. Pero sin eso, buscar las reglas de gestión sobre las características en el futuro será un verdadero dolor de cabeza.

¿Y la parte técnica?

Para aquellos que hacen el storyotype para emprender otras solicitudes que no son historias de usuario (a menudo esenciales aunque a menudo olvidadas) con solicitudes de tipo: tarea técnica, spike, errores… será muy difícil usarlos en vivo para documentarlos.

Conocido que la agilidad centra su desarrollo en el valor empresarial (para usuarios clave de manera funcional), la parte técnica es completamente desestructurada en estos documentos.

Te recomiendo encarecidamente que utilices un wiki o equivalente para hacer documentos sobre la parte técnica; debes ser KISS con estos documentos.

Ten en cuenta que esto no impide la documentación del código para que los futuros desarrolladores puedan entender de un vistazo cada parte del código. Esto es especialmente importante en caso de errores complejos.

¿Qué dicen algunos métodos ágiles?

Esta parte es más para tu cultura ágil, pero los métodos ágiles que no se usan en Francia pueden contener cosas muy interesantes.

Recuerda que Scrum no habla de una fase de inicialización a diferencia de otros métodos ágiles. Por ejemplo, el DSDM recomienda hacer un Informe de Factibilidad y un Plan de Desarrollo Global durante el estudio de viabilidad, que se definen en forma de documentos.

No hablamos de documentación exhaustiva, sino de documentación bien enfocada en temas específicos.

En este método también se habla de la creación del documento llamado Definición del Dominio Industrial y el documento llamado Definición de la Arquitectura del Sistema durante el estudio de negocio del DSDM.

Como puedes ver, otros métodos ágiles son mucho más documentales que Scrum o, al menos, de la interpretación que queríamos dar.

NO, los métodos ágiles no prohíben la documentación, pero favorecen poner esfuerzo en el software en funcionamiento y no en la documentación.

Conclusión: Documentación en Métodos Ágiles

Espero que este artículo te brinde una visión más clara de la documentación en los métodos ágiles. Probablemente haya otras recomendaciones, pero espero que las que te presento aquí te ayuden en tus proyectos.