“Eso” que rodea a SPRINTS y BACKLOGS

…o “¿dónde están todos los requerimientos?”…

En nuestra poca experiencia en SCRUM hemos tenido un problema de “desorden” que donde se nota es al final de los proyectos, en las entregas, no de los sprints, sino de las releases.

En las entregas nos encontramos con que algunos requerimientos no los habíamos implementado. No por no haberlos recogido o analizado, sino porque los medios donde recogíamos los requerimientos eran “diversos”… correos-e, documentos de requisitos, notas de reuniones (actas). Y no es la diversidad de “artefactos” lo que hacía que se extraviaran algunos requisitos, sino la indisciplina de, una vez recogidos, no pasarlos, centralizarlos en un medio común.

Lo peor de todo es que algunos de esos requisitos no implementados (que finalmente encontramos), el cliente los consideraba importantes, y en ningún momento los incluimos en las planificaciones.

Achaco este desorden a no tener definida una herramienta donde recoger los requisitos, donde centralizarlos. Teníamos una, pero no la utilizábamos bien… la “vista” que utilizábamos era “guay” pero no “útil”. Una lista en grid, donde se puedan ordenar, priorizar, ponerles el estado, compartir, es la mejor opción.

Pero sólo utilizar una. La opción de pasarlos en Excel para enviarlos al cliente no es válida. La opción de pasarlos en Word temporalmente y luego ya los pasaré a la herramienta de requisitos tampoco. La opción es pasarlos a la herramienta y luego exportarlos a donde necesitemos.

Mi objetivo de los últimos días es disciplinarnos, centralizarnos, compartirnos y actualizarnos… y, claro, encontrar la herramienta. Es sabido que no existe la herramienta “mágica”. Que hasta con archivos de texto podríamos realizar este trabajo. Pero en el proceso de scrumización, la disciplina es importante y la herramienta ayuda mucho a mantener la disciplina, facilitando el trabajo a aquellas personas que tienen que mantener la información asociada al proyecto. Si una herramienta no facilita el trabajo, sino que lo entorpece, tendemos a no usar la herramienta, a dispersarnos y a usar cada uno la suya. Vaya… lo mismo que pasa con las aplicaciones que hacemos.

Ahora… que tengo un punto más sobre el que trabajar, mientras lo desarrollo, me pongo con el siguiente punto: los tests. En la charla de “Gestión Ágil con TFS, SCRUM y buenas prácticas” que nos dio Rodrigo Corral en las sesiones Microsoft ALM ‘09 de Madrid, comentó una cosa que hizo temblar una vez más… dijo una de aquellas frases que son como un golpe de puño en la mesa: de nada sirve la metodología sin tests unitarios, gestión del código fuente, builds automatizadas.

Voy a atacar a los tests, pero, ¿qué va primero: el huevo o la gallina? ¿Implementar un proceso de testeo o implementar una metodología que permita definir qué validan los tests? Esperemos haber decidido la metodología de antemano no haya sido del todo incorrecto… que las dos cosas tengan que ir a la par, y que incluir los tests en el proceso no sea un trabajo de titanes: aprender, concienciar e implementar.

Os iré contando.