Exprimiendo Scrum: Scrum y la gestión de requisitos
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 produjesen cambios 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 que hemos 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 para poder 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 al presupuesto 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 es cambiante 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 tarea ardua, 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. Los requisitos 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 la inversió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 refinar en 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 información que hemos ganado durante la implementación de otros requisitos, de esta manera, al contar con más información tendremos muchas más posibilidades de actuar correctamente a la hora de describir y estimar en detalle los requisitos. El fundamento para lo anteriormente expuesto es claro, es posible definir y estimar las actividades de nuestro proyecto cercanas en el tiempo con un buen margen de confianza, pero es muy complejo hacerlo con actividades cuyo momento de comienzo se encuentra lejano en el tiempo. La actividades cercanas en el tiempo tienen una probabilidad mucho menor de sufrir cambios en su alcance que obliguen a cambiar su estimación y, en consecuencia, su planificación. No me extiendo más en esto pero si os invito a leer algunos de mis anteriores post sobre estimación: El difícil problema de la estimación, Estimación y planificación detallada, Recibiendo estimaciones y Estimando (no practicando la brujería).
Los cambios en los requisitos ocurren, por mucho que tratemos de combatirlos. En Scrum y en las metodologías ágiles en general, asumimos que estos cambios van a ocurrir y tratamos de gestionar estos cambios como oportunidades de que los clientes obtengan lo que necesitan. Evidentemente para que esto funcione la gestión del Product Backlog debe reaccionar de manera continua para reflejar las prioridades de nuestro cliente. El Product Owner (propietario del producto) es el encargado de gestionar el Product Backlog, introduciendo nuevas requisitos según se descubren y priorizándolos en función de las necesidades del cliente y el retorno de la inversión que el cliente recibirá de su implementación.
Utilizando el Product Backlog, cada vez que el cliente cambia sus prioridades o el alcance de un requisitos ve de manera explicita y visual (recordemos que se trata de una lista ordenada) que otros requisitos ven afectada su prioridad, de manera que serán implementados más tarde o incluso quedarán fuera del alcance del proyecto si este está establecido de antemano, como ocurrirá en los proyectos con precio o fecha cerrados. La clave está en que en cualquier caso, el cliente irá consiguiendo de manera paulatina que estén implementadas aquellas partes de proyecto que más valor le aportan y contará con la seguridad de que en el caso de que algo quede fuera del ámbito del proyecto serán aquellos requisitos que menor valor tienen para el.
Vemos como el Producto Backlog nos permite gestionar de manera ágil y sencilla los requisitos de nuestro proyecto, refinándolos cuando tenemos información suficiente, priorizándolos según el valor que aportan a nuestro cliente.