Documentación ágil: equilibrando la velocidad y la retención del conocimiento

Publicado: 2022-03-11

Los diversos documentos, artefactos y procesos relacionados con su generación son algunos de los principales símbolos del modelo Waterfall. Tomando prestado de Lean, Agile considera una gran cantidad de documentación como "desperdicio" que debe erradicarse para optimizar el ciclo de vida del desarrollo.

Para muchos gerentes de proyecto, no es difícil entender cómo las fases de Waterfall se convierten en sprints: se logra el mismo trabajo; simplemente está organizado de una manera diferente. Sin embargo, la eliminación de la mayor parte de la documentación es una píldora más difícil de tragar, ya que subraya una forma de trabajar completamente diferente. Requiere aflojar las riendas del control, aceptar lo desconocido y capacitar al equipo de entrega para que tome decisiones en el acto.

El enfoque tradicional de la documentación está siendo cuestionado

En la metodología Waterfall, se dedica mucho tiempo a documentar los requisitos del proyecto y detallar las soluciones. Este proceso funciona cuando los requisitos son completamente claros y estamos seguros de que nada cambiará de lo que se ha capturado y línea base. Sin embargo, las experiencias de la mayoría de las empresas en las últimas décadas han demostrado que esto casi nunca es cierto. En el mundo actual, el ritmo de cambio es tan dinámico que las necesidades del cliente cambian considerablemente en el momento en que completamos la fase de documentación.

El enfoque de Agile es hacer las cosas y agregar valor a las partes interesadas. Está construido de tal manera que el modelo desalienta trabajar en los periféricos y en actividades que no agregan valor directa e inmediatamente al cliente.

Documentación en Waterfall vs. Agile

Cada empresa tiene un nivel de documentación diferente, que puede diferir incluso a nivel de proyecto. Pero así es como se ven los procedimientos típicos de documentación en los proyectos Waterfall y Agile:

Cascada Ágil
La documentación es obligatoria la mayor parte del tiempo. Ningún trabajo avanza a menos que la documentación esté completa. Solo se recomienda la documentación básica para comprender lo suficiente para comenzar a trabajar.
Los documentos se someten a un largo proceso de revisión y deben ser aprobados por varias partes. No existe un proceso formal de revisión y aprobación y el director del proyecto es quien toma las decisiones clave.
Se deben seguir las plantillas estandarizadas. No hay plantillas formales para la documentación; en su lugar se utilizan las mejores prácticas.
Se requieren varios tipos de documentos en diferentes fases: acta de constitución del proyecto, declaración de la visión, documento de requisitos comerciales, requisitos funcionales y no funcionales, documentos de diseño de alto nivel (HLD) y de diseño de bajo nivel (LLD), etc. Solo se requieren los documentos que se necesitan para entregar la funcionalidad en el próximo sprint.
Los cambios en la documentación son difíciles porque todos los documentos están entrelazados. Los cambios en la documentación son mucho más fáciles.
Se necesita un sistema o proceso para gestionar una gran cantidad de documentos. La documentación es mínima, por lo que es fácil de gestionar.

El caso de la documentación

Waterfall promueve un enfoque mucho más estricto de la documentación, lo que puede parecer excesivo. Pero antes de que descartemos esto como "desperdicio", aquí hay varios beneficios de tener procedimientos de documentación sólidos.

Oportunidad para el Pensamiento Estratégico

Aquellos que fallan en planificar, planifican para fallar. La documentación obliga a un gerente de proyecto a sentarse y pensar las cosas y luego encontrar las mejores soluciones. Las personas a veces malinterpretan el valor Agile del software en funcionamiento sobre la documentación completa para significar que no se requiere documentación. Luego salen corriendo al mercado, un movimiento que Paul Adams, vicepresidente de productos de Intercom, describe como tirar cosas a la pared y ver qué se pega. Diseñar soluciones, crear planes, deliberar acciones: estas actividades crean valor al ahorrar tiempo al no desarrollar cada idea de función que se te ocurra.

UX y consistencia funcional

A medida que las empresas crecen de unos pocos fundadores a cientos o miles de empleados, muchos equipos diferentes comienzan a trabajar en el mismo producto o en productos relacionados. El equipo A podría pensar que en lo que están trabajando no está relacionado con lo que está trabajando el equipo B, pero para el usuario final, todo es el mismo producto. En lugar de que los equipos multifuncionales hagan lo suyo, la documentación clara sobre la experiencia del usuario y los niveles funcionales evita un flujo de usuarios inconexo.

La documentación se puede convertir en guías de usuario

En Waterfall, se dedica mucho tiempo a detallar las soluciones y cómo se utilizarán. Se crean imágenes de diseños de alta fidelidad para desarrolladores front-end. Todos estos activos requieren menos trabajo para convertirse en guías de usuario internas o externas que crearlos desde cero.

Cómo Agile reduce las necesidades de documentación

Un factor que surge repetidamente como excusa para exigir la documentación es la rotación de empleados. Los gerentes temen perder el conocimiento institucional cuando la gente se va y se incorporan nuevos para reemplazarlos. ¿Cómo sabrán lo que se ha implementado y cómo funciona? ¿Cuánto tardarán en ponerse al día? ¿El equipo actual tendrá el ancho de banda para manejar a los nuevos miembros del equipo?

La esperanza es que una buena documentación haga que los nuevos empleados que trabajan en su mayoría de forma independiente se pongan al día rápidamente. Sin embargo, Agile reduce inherentemente la necesidad de documentación a través de técnicas de colaboración que, al mismo tiempo, reducen el tiempo de incorporación. Aquí hay algunas formas en que Agile reduce la necesidad de documentación.

Interacción regular entre equipos de productos y miembros de equipos ágiles

El Manifiesto Ágil promueve “individuos e interacciones sobre procesos y herramientas”. Dado que los requisitos tienden a cambiar durante un proyecto y surgen nuevas ideas, Agile garantiza la aclaración de los requisitos directamente desde la fuente en lugar de depender de artefactos escritos que necesitan una actualización constante.

La preparación y la planificación compartimentan las tareas

La preparación del trabajo pendiente y la planificación de sprints dividen las funciones en partes específicas e implementables que se entienden fácilmente y se pueden trabajar de forma independiente. Esto crea una oportunidad para que los nuevos empleados sean productivos desde el principio, aunque aún no comprendan completamente el panorama general de todo el proyecto.

Las historias de usuarios proporcionan una documentación eficiente

Plantilla de historia de usuario para documentación ágil.

El formato simple de las historias de usuario permite a los gerentes de proyecto capturar los requisitos mínimos que crean un entendimiento compartido entre todos los miembros del equipo. Incluso si una historia de usuario no se convierte en un sprint, el desperdicio de crear este artefacto de documentación es muy bajo. A medida que las historias de los usuarios pasan a los sprints, se pueden desarrollar y complementar con otra información necesaria, como esquemas, diseños, criterios de aceptación, etc. Este proceso brinda una entrega de documentación muy eficiente que es altamente desechable y se produce en las etapas de desarrollo más adecuadas.

Reducción de la necesidad de documentación del código

Técnicas como la programación en pares y la revisión de código crean oportunidades constantes para difundir el conocimiento técnico en todo el equipo, especialmente entre los nuevos miembros del equipo. La retroalimentación constante conduce a un entendimiento compartido que también tiene la flexibilidad de adaptarse a nuevas circunstancias en lugar de quedar obsoleto rápidamente en un documento en alguna parte.

Ceremonias ágiles

Las reuniones diarias, las revisiones de sprint y las retrospectivas crean amplias oportunidades para resolver problemas y tomar decisiones cara a cara en lugar de depender del correo electrónico y los documentos. El marco de tiempo limitado de todas las ceremonias garantiza que solo se priorice la información más importante en lugar de dedicar tiempo a documentarlo todo, incluso si es probable que nunca se use.

Todo lo anterior, directa o indirectamente, reduce la documentación y prioriza la entrega de los objetivos del proyecto al tiempo que garantiza que nada se pierda realmente por la falta de documentación.

Enfoques híbridos para la documentación

Algunas empresas todavía prefieren tener algo de documentación, incluso en un entorno ágil. Agile no es prescriptivo, porque cada proyecto es diferente y tiene un conjunto único de circunstancias que deben abordarse.

A continuación, se muestran algunos ejemplos de cómo Agile se puede combinar con métodos de documentación más intensivos en tiempo.

Combinando UML y Agile

Ejemplo de diagrama UML

Considere usar un lenguaje de modelado estándar como el Lenguaje de modelado unificado (UML), que está muy estructurado y tiene entidades definidas para visualizar un sistema. Esto ayuda a mantener el contenido muy simple y centrado en lo que se necesita y garantiza un uso mínimo del lenguaje escrito. Herramientas como StarUML y Draw.io, entre muchas otras, son opciones convenientes.

Generadores de documentación de código

Otro enfoque es asegurarse de que el código sea mucho más legible mediante la introducción de comentarios más estructurados y detallados como parte de los detalles de la clase, los detalles del método, el uso de parámetros, las dependencias, etc. Existen muchas herramientas que automatizan el proceso de generación de documentos útiles a partir del código fuente y se denominan generadores de documentación. Van desde los genéricos hasta los específicos del lenguaje de programación.

Diseño Detallado y Documentos UX

La definición de requisitos utilizando wireframes, maquetas, diagramas de flujo de usuario, diagramas de secuencia, etc. ayuda a simplificar los flujos del proyecto y deja explícitamente claro para el equipo técnico lo que se debe desarrollar. Los documentos de diseño son una excelente manera de tener un nivel variable de documentación más rígida. Hay varias herramientas de wireframing y UX para elegir para estas tareas.

Herramientas de gestión de proyectos Automatización de la documentación

La gestión de proyectos más potente y las herramientas relacionadas, como JIRA, Confluence, Asana y Basecamp, brindan una manera de mantener toda la información relacionada con el proyecto en un solo lugar. Las tareas se pueden vincular, etiquetar, anidar y asignar a diferentes miembros del equipo, quienes luego pueden dejar comentarios e informar cualquier problema. Todas estas acciones, junto con la flexibilidad para adaptar esas herramientas, pueden crear una cantidad sustancial de documentación con poco o ningún esfuerzo.

Además, históricamente, parte de las necesidades de documentación provienen de los requisitos de información. Las partes interesadas quieren acceder al rendimiento del equipo u otras métricas relevantes. Las herramientas de administración de proyectos facilitan la automatización de paneles y vistas personalizados que reflejan el progreso del proyecto y se vinculan a la documentación relevante dentro de la herramienta.

La gestión de la documentación es un acto de equilibrio

Los creadores del Manifiesto Ágil escriben que valoran "el software funcional sobre la documentación completa". Sin embargo, también agregan un descargo de responsabilidad de que "si bien hay valor en los elementos de la derecha, [ellos] valoran más los elementos de la izquierda". Agile no sugiere eliminar toda la documentación, porque alguna documentación obviamente proporciona valor; simplemente sugiere que la prioridad debe estar en el software que funcione y agregar documentación solo según sea necesario según las circunstancias del proyecto y sin obstaculizar en gran medida el progreso del desarrollo.

Los gerentes de proyecto deben lograr un acto de equilibrio entre dedicar menos tiempo a la documentación y dedicar más tiempo a la entrega de software que funcione y, de hecho, averiguar dónde se necesita algún tipo de documentación para el éxito a largo plazo.