«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 «.
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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Se podría decir que documentar es como limpiar el cuarto de baño, a nadie le apetece hacerlo pero el resultado es una experiencia mejor para uno mismo y para los invitados.
Una frase genial de Ryan Campbell que suena genial pero luego llega la realidad y es cuando tus tareas son infinitas y van contra reloj con lo cual tienes que decidir si usar tiempo en documentar para solventar futuros problemas o resolver los problemas inmediatos.
Que un proyecto tiene que estar documentado es impepinable pero también lo es que las empresas exigen que las cosas salgan para ayer.
Antes de educarnos en no malgastar el tiempo cuando documentamos tal vez tendríamos que educar a algunas empresas sobre la necesidad de documentar un proyecto.
Para un programador, por lo menos para mi, la mejor documentación es la que acompaña al código. Y como documentación del proyecto, ¿qué mejor que unas buenas historias de usuario bien definidas y testeadas? 🙂 Puede parecer que la documentación en un proyecto ágil sea sencilla de generar, pero la realidad es que es más compleja pues se trata de sintentizar y de buscar lo justamente necesario. Lo fácil, aunque más pesado, es soltar la «parrafada», muy aprodiada para las auditorías.
salu2