Scrum

Tradicionalmente se ha tendido a tratar la captura y la gestión de requisitos de una manera que, cada vez más, se demuestra errónea. Se ha entendido la captura de los requisitos del proyecto como una fase temprana del mismo que una vez se completaba nos daba la fotografía exacta de que necesitaba nuestro cliente. Luego la única labor del gestor del proyecto era tratar de evitar que se produjesencambios en el conjunto de requisitos y tratar que, cuando estos se producían el cliente asumiese el coste económico de los mismos. Supongo que a todos os suena este planteamiento.

El problema que todos hemos vivido es que el esfuerzo que supone hacer una captura detallada de todos los requisitos de un proyecto es enorme. Tan enorme que rara vez justifica el resultado. Además otra realidad quehemos descubierto es que casi nunca nuestro cliente conoce sus propias necesidades con la profundidad suficiente como para definirlas a priori y a esto se une que, a menudo, durante la vida del proyecto, las necesidades y prioridades de nuestros clientes cambian. Además nuestros clientes a menudo necesitan ver lo que somos capaces de hacer y como resolvemos sus necesidades a nivel técnico parapoder descubrir nuevas necesidades u oportunidades que desconocían que éramos capaces de implementar. Podemos tratar de protegernos de estos cambios estableciendo mecanismos de control, pero este enfoque a menudo nos lleva a clientes poco satisfechos, que verán el desarrollo del proyecto como algo rígido que no se adapta a sus necesidades y que si lo hace es repercutiendo costes añadidos alpresupuesto del proyecto.

Vistos estos problemas, ¿qué aproximación propone Scrum?.

En Scrum los requisitos se expresan como elementos del Product Backlog. El Product Backlog es una lista viva de requisitos funcionales y no funcionales priorizados por su valor para el cliente. Al decir que se trata de una lista viva, dejamos claro que los requisitos que en ella aparecen y el orden de los mismos escambiante a lo largo de la vida del proyecto. En Scrum, los requisitos se van abordando en Sprints en el orden en que aparecen en el Product Backlog.

Utilizar el Product Backlog como principal artefacto para la gestión de requisitos nos permite atajar los problemas relacionados con la gestión de requisitos que antes hemos descrito.

Aunque construir y mantener el Product Backlog es una tareaardua, es mucho más simple que hacer una captura de requisitos tradicional. El motivo es simple, solo hay que expresar a grandes rasgos en que consiste el requisito, no es necesario un nivel de detalle muy elevado. Solo es necesario el nivel de detalle suficiente que nos permita estimar los requisitos y priorizarlos. A menudo se utilizan historias de usuario para expresar estos requisitos. Losrequisitos que aparecen el en Product Backlog deben ser independientes, negociables, evaluables, estimables y no demasiado grandes. Deben ser independientes pues el orden en el que serán implementados puede cambiar. Deben ser negociables en el sentido de que son un punto de partida para comenzar en desarrollo no un contrato cerrado. Deben ser evaluables desde el punto de vista del retorno de lainversión que proporcionan a nuestros clientes. Deben ser estimables pues es imposible priorizar algo de lo que se desconoce la magnitud.Y, por último, deben ser de un tamaño que permita estimarlos sin tener demasiadas incertidumbres sobre cuál es el alcance concreto del requisito, aunque cierto nivel de incertidumbre siempre va a existir.

Evidentemente antes de su implementación será necesario refinaren mayor detalle los requisitos. En Scrum esto es algo que posponemos hasta que planeamos el Sprint en el que vamos a abordar esos requisitos en concreto. Posponer el refinado detallado de los requisitos hasta un momento cercana a su implementación nos permite que cuando realizamos esta actividad tengamos en cuenta de nuevo las necesidades del cliente que pueden haber cambiado y contar con la...