En un proyecto ágil NO se documenta… ¿Seguro?

«Cuando los documentos son en su mayoría para pasarse el testigo de unos a otros, son malos. Cuando capturan una conversación que es mejor no olvidar, son valiosos «.

— Mike Cohn y Tom Poppendieck

Uno de los más populares firmantes del manifiesto ágil, Fowler, tiene entre sus más destacados libros uno sobre UML (el UML Distilled, para mí, el mejor libro de UML), sobre cómo “escribir” diseños, adecuadamente. Otro destacado firmante, Robert C. Martin (aquí tienes la entrevista que le hice Entrevista en el blog: Robert C. Martin -Uncle Bob-), habla en uno de sus populares libros, Clean Code, sobre cómo documentar código correctamente. De los cuatro valores del manifiesto ágil, el único que menciona explícitamente el tema de la documentación es el “Working software over comprehensive documentation”, no hay más que leerlo para ver que no dice que no se documente, dice que es preferible poner los mayores esfuerzos en cosas más útiles, pero no dice que no se documente.
Valgan los anteriores ejemplos para dejar claro que la agilidad no dice que no se documente, eso sí, de la misma, y de su filosofía, si que se interpreta que si hay que documentar… que se documente de manera eficiente, útil y no desperdiciando tiempo y papel.

La agilidad no dice que NO se documente, pero «invita» a que si se documenta se haga bien, sin perder tiempo y tirar papel

Hace un tiempo, desde una perspectiva más global, tratamos este tema, en el post de el coste de la burocracia en una empresa tecnológica, donde te comentaba que según los estudios realizados por Caper Jones, “documentar” es la segunda “fase” que más tiempo se lleva de media a la hora de desarrollar software, y no han sido pocos aquellos que han alertado sobre el impacto negativo (económico, productivo, motivacional, etc.) del exceso de documentación, desde DeMarco en el antiguo Peopleware, al propio Jones, el movimiento Lean (que mete a la sobre-documentación en la categoría desperdicio), etc.
Si este tema se lleva al ámbito nacional, donde como buenos españoles todo lo llevamos del blanco al negro, hoy nos encontramos proyectos que apenas documentan (problema) y otros que se pasan (problema). Si bien, en mi opinión, el exceso de documentación es peor que la carencia, supone una “hemorragia de tiempo”, que se pierde (1) documentando y (2) manteniendo documentación.
Dicho esto, el reto, y el arte, está ahora en saber documentar correctamente, ágilmente. Hay quien dice que una buena regla es documentar lo esencial (al nivel de detalle justo, sin excesos, yendo a lo mínimo), valioso (documentar sólo cuando realmente lo necesitamos) y de manera oportuna (cuando realmente lo necesitamos).

Implanta el Paper – Boxing

Hace un tiempo que pensé que al igual que existe la buena práctica de “Time Boxing”, que se basa en que todo “tiempo” en un proyecto debe tener un máximo, conocido por todas las personas del equipo (destacado las reuniones) debería haber un “Paper Boxing”, que frente a cada documentación limitara el número de páginas y el tiempo máximo dedicado a escribir.
Algo similar al caso que te contaba de Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos), y como en aquella ocasión se destinaba un máximo de 10 min para hacer los planes de prueba, eso si, para ello se evita la prosa, se recuerda que un plan de pruebas no es un documento de marketing o ventas, es para ingenieros, y que no a más texto mejor documento, si no es importante o no se puede hacer, no lo pongas en el plan.