¿El software que funciona por encima de la documentación exhaustiva?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Uno de los mitos sobre Scrum es "no hace falta documentar...". Los documentos son importantes ya que permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero ¿son más importantes que los productos que funcionan? y, ¿aportan valor al producto? o ¿quizá solo aporte la documentación justa y al 100% necesaria?

Tal como dice el segundo valor del Manifiesto Ágil, los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con prototipos, o el feedback estimulante y enriquecedor sobre partes elaboradas del producto que genera ideas imposibles de concebir en un primer momento.

Desde la perspectiva ágil los documentos deben ser cortos y centrarse en lo esencial, y deben de constituir la documentación necesaria que debe de ser mantenible, compartida y generada por todos mediante un flujo solapado con las demás fases de inicio a final del proyecto. Por tanto esta se escribe a lo largo de todo el proyecto, es viva y sólo recoge aquello que es de utilidad para alguien.

No olvidemos que la documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio, y por tanto, siempre que sea posible, debe preferirse y reducir al mínimo indispensable el uso de documentación, ya que genera trabajo que no aporta un valor directo al producto y al cliente.

Un ejercicio interesante para detectar qué documentación de nuestra empresa aporta valor es preguntar al equipo completo (desde negocio al equipo técnico, analistas, usuarios...) quién escribe algún documento, para luego preguntar por quienes son los lectores de cada uno de esos documentos. Si descubrimos documentos de "solo escritura" habremos dado con posible desperdicio y deberemos de preguntarnos si no es preferible invertir el tiempo en el producto que estamos construyendo en vez de escribirlos.

Como anécdota contar que un colaborador mío incluyó la receta de la tortilla de patatas en la documentación de usuario para averiguar si alguien se daría cuenta. 2 años después un becario al que le dieron a leer un montón de documentos en su primer día, descubrió la receta durante la primera semana, jajaja.

Otro punto crítico se produce cuando la empresa y los equipos se comunican a través de documentos, cuando además de perder la riqueza que da la interacción con el producto, los documentos se convierten en barreras entre personas y departamentos. Un documento escrito es un dibujo incompleto de las ideas de quién lo escribe, y cuando lo lee un lector, este crea otra abstracción que está a dos pasos de distancia de lo que se escribió originalmente. No es sorprendente que de esta manera se generen malentendidos, haya peloteos que van y vienen (muy comunes en la comunicación por email) y se acaben empleando los documentos de forma defensiva.

Mi agradecimientos a Fernando por la receta de tortilla de patatas :-P