Recientemente he estado dando formación sobre Scrum a un grupo de profesionales del departamento de desarrollo de uno de los principales periódicos españoles. Se trataba más de gente que gestionaba desarrollo que de gente que desarrollase ellso mismo. Me ha encantado este curso por un motivo: la aproximación crítica que han tenido hacia lo que yo le he estado enseñando sobre Scrum. Alguno de los asistentes al curso dijo ‘yo estoy haciendo de abogado del diablo, aunque Scrum me gusta y nos puede servir, quiero buscarle las cosquillas’. Este enfoque, compartido por varios de los asistentes hizo que yo tuviese que exprimir al máximo las capacidades de Scrum y mis conocimientos sobre el tema para dar soluciones a las interesantes cuestiones que se plantearon.
También estoy actualmente ayudando a implantar Scrum y Team System a una importante editorial de temas jurídicos, y muchas de las cuestiones que voy a comentar en esta serie de artículos han sido planteadas por ellos. En este segundo caso se trata de un grupo de desarrolladores, más que de un grupo de gestores de proyectos y las cuestiones que plantean son en general de tipo más práctico, menos organizativo. No deja de sorprenderme que Scrum sea mucho más fácil de enseñar, diría yo más natural para desarrolladores que para gestores. Es increíble con que naturalidad estos han asumido Scrum como metodología.
Entre estos dos grupos de personas, se han planteado un motón de dudas que me van a permitir ‘exprimir Scrum’ en una serie de post.
Una de las personas del primer grupo que comentaba antes, conoce RUP. En RUP los artefactos juegan un papel esencial en el ciclo de vida del proyectos. RUP describe alrededor de uno 100 artefactos, aproximadamente la mitad de ellos son documentos. Queda claro que en RUP la documentación a generar es un aspecto central de la metodología. De hecho todo proyecto debe empezar por seleccionar cuales de los artefactos vamos a utilizar y adaptarlos a nuestras necesidades, pues evidentemente 50 documentos suponen una burocracia insostenible para la grandísima mayoría de proyectos de desarrollo de software. Aunque el volumen de documentos es mucho menor el enfoque en MSF es en cierto modo similar a el de RUP.
Una vez dicho esto, creo que ya todos podéis adivinar cual fue una de las primeras preguntas que esta persona hizo después de que yo contase en que consiste Scrum: con cierto tono de sorpresa y desconfianza preguntó, ¿no dice nada Scrum sobre que documentos se deben generar?. Mi respuesta fue: No. Y claro para alguien que ‘viene’ de RUP esto es inconcebible. Pero, logicamente, este no que yo di por respuesta tiene muchos matices. Scrum no impone ni sugiere ninguna documentación ni ningún circuito de documentación. No son documentos los que marcan el ciclo de vida, sino las actividades del equipo y la diferentes reuniones que mantienen.
Entendiendo como documentación la relativa a la arquitectura, desarrollo, mantenimiento, operación y despliegue del sistema desarrollado. Si que existen en Scrum algunos artefactos que suelen tener un soporte documental asociado: el Product Backlog, el Sprint Backlog, o un acta que recopile las cuestiones comentadas durante el Sprint Review, pero no tienen una forma estándar ‘impuesta’ por la metodología.
El planteamiento en Scrum, como metodología ágil que es, se basa en el principio del Manifiesto Ágil que dice: ‘Valorar más el software que funciona que la documentación exhaustiva’. Solo lo que hace el software y lo bien que lo hace es medida del progreso del proyecto.
El enfoque en en Scrum (y en el resto de metodologías ágiles) es asumir que el código es la única fuente de verdad sobre un proyecto de software a nivel de detalle, y el nivel de detalle es el único valido para modificar, extender o mantener un programa. Se entiende aquí como código, no solo el código ‘compilable’ sino, la documentación directamente asociada al mismo o embebida en él (comentarios que permitan generar documentación por ejemplo, con NDoc o JDoc) o aquella que se genera de manera automática desde el mismo (por ejemplo diagramas de clases que solo son otra vista del código). Baste recordar lo que todos hemos hecho para comprender un sistema del que disponíamos de su código fuente y que debíamos mantener o extender: leer el código, aunque exista documentación. Los desarrolladores preferimos leer código por que no es ambiguo y que siempre está actualizado. Lo que realmente tiene valor es contar con información directamente generada desde el código y sus comentarios en formato textual y descriptivo.
Otra documentación que no emana del código fuente directamente y que es de gran utilidad, si no imprescindible, es la relativa a arquitectura. Es necesario que un nuevo desarrollador o aquel que resucita el proyecto tras un tiempo pueda comprender que decisiones de alto nivel guiaron el desarrollo. Esta documentación si que es valiosa puesto que sirve para comprender por que se tomaron determinadas decisiones que no se cambian con facilidad a lo largo del proyecto y proporciona una primera aproximación que siempre es necesaria. La arquitectura de una aplicación no suele cambiar a menudo, lo que cambia es la implementación, el código. Documentar la arquitectura y que alguien la comprenda es algo que se hace perfectamente en lenguaje textual y utilizando algunos diagramas. Esta documentación es simple de mantener porque es mucho más estática que la de diseño detallado. Además algo especialmente valioso de la documentación de arquitectura es que establece el lenguaje común, la nomenclatura propia y el estilo que va a guiar del desarrollo. Scrum no te dice que debes hacer tales o cuales diagramas, pero nada cierra la puerta a tener un documento, que, a grandes rasgos, explique la arquitectura de tu proyecto.
La principal fuente de información sobre que hace una pieza de software esta el nombre de los componentes, de las clases y de las funciones. La principal documentación con la contamos es el estilo de nomenclatura, la coherencia a la hora de nombrar cosas y una arquitectura general coherente. La principal fuente de información del software debe emanar de una serie de patrones que se repiten a lo largo del proyecto, tanto a nivel arquitectónico como de diseño y estos patrones donde viven es en el código. Además es fácil mantener una base de conocimiento sobre nuestro proyecto, basada en artículos cortos y con ejemplos, tipo «knowledge base», de manera que sean fácilmente buscables. Por eso los wikis se están popularizando tanto como repositorios de información sobre proyectos, no imponen una estructura, son ágiles de mantener, fácilmente actualizables, fácilmente buscables y soportan muchos tipos diferentes de contenido.
No es que Scrum propugne que no hay que documentar nada. La idea en Scrum es no tener que quitar y ajustar artefactos, sino crear aquellos que nos sean útiles en cada momento, para nuestras necesidades puntuales. La idea es evitar caer en el error de generar documentos (y con ellos el coste de escribirlos y mantenerlos) solo porque la metodología lo exige, si generamos un documento debe ser porque es imprescindible, claramente útil para una actividad determinada. No todos los proyectos y equipos de desarrollo necesitan el mismo tipo de documentación.
En Scrum (y en el resto de metodologías ágiles) se tiende a sustituir la documentación por la comunicación: Es mucho más útil y más ágil discutir en torno a una pizarra un diseño, que escribirlo en papel y que alguien revise el documento. Si alquien tiene una duda sobre como implementar un requisito nada mejor que hablar con el Producto Owner para aclarar el tema.
También se tiende a sustituir la documentación por la refactorización: Si una pieza de software es compleja, tenemos dos posibles estrategias a la hora de hacerla entendible. La primera es documentarla, la segunda es, a base de refactorización y de mejorar el diseño, simplificarla para hacerla más clara. Se puede ganar mucho en la legibilidad de nuestro software simplemente eligiendo buenos nombres, evitando la funciones enormes, utilizando la documentación XML, limpiando la variables no utilizadas… La ventaja de este enfoque es que mejora objetivamente el software, haciéndolo más mantenible, más claro y que no necesita un artefacto externo que puede fácilmente quedar desactualizado.
Otro problema que Scrum no resuelve del todo es como documentar la captura detallada de requisitos, algo que siempre es un quebradero de cabeza. Si que define claramente en que momento del proyecto se refina los requisitos: durante el Sprint Planning Meeting. En ocasiones, aunque en las menos, el Product Backlog puede ser insuficiente. Por ejemplo, nuestro software, puede tener que hacer complejas operaciones de negocio que tendremos que entender en detalle y refinar para poder implementarlas. Nada impide en estos casos usar el mecanismo que más nos convenga para gestionar la situación: historias, sesiones JAD, casos de uso, escenarios, etc… Resumiendo, en nuestra mano queda el seleccionar aquellos artefactos que en cada situación pueden sernos útiles. Por ejemplo yo creo, aunque Scrum no dice nada al respecto, un documento de visión del proyecto de una o dos páginas puede sernos de un valor inestimable a lo largo de proyecto, no tiene un coste de realización alto y no quedará obsoleto pronto, luego ¿por qué no hacerlo siempre?
Otra cuestión es que a la hora de hacer documentos Scrum no nos proporciona plantillas, gracias a proyectos como ReadySet esto es un problema menor. Además si yo creo que un documento de visión puede ayudar, siempre podemos tomarlo prestado de RUP, MSF o de ReadySet y ajustarlo a nuestras necesidades.
‘Scrum in five minutes‘ del que ya hable en este blog no hace mucho. Si buscas algo en castellano a nivel introductorio no hay nada mejor que el excelente y reciente post de mi compañero Jorge Serrano titulado ‘Explicando Scrum a mi abuela‘. Solo espero que se trate de un recurso literario y que realmente no se lo haya explicado a su abuela, aunque conociendo al bueno de Jorge… es capaz de haberselo explicado y que encima su abuela lo haya entendido!!! 
Ayer mi ex-compañero de Panda y amigo 
Paul Stovell ha implementado un