Gestion de requerimientos en scrum Tradicionalmente se ha tendido a tratar la captura y la gestin de requisitos de una manera que, cada vez ms,

se demuestra errnea. Se ha entendido la captura de los requisitos del proyecto como una fase temprana del mismo que una vez se completaba nos daba la fotografa 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 producan el cliente asumiese el coste econmico 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. Adems 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. Adems nuestros clientes a menudo necesitan ver lo que somos capaces de hacer y como resolvemos sus necesidades a nivel tcnico para poder descubrir nuevas necesidades u oportunidades que desconocan 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 vern el desarrollo del proyecto como algo rgido que no se adapta a sus necesidades y que si lo hace es repercutiendo costes aadidos al presupuesto del proyecto. 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 gestin de requisitos nos permite atajar los problemas relacionados con la gestin de requisitos que antes hemos descrito. Aunque construir y mantener el Product Backlog es una tarea ardua, es mucho ms 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 sern 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 inversin 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 tamao que permita estimarlos sin tener demasiadas incertidumbres sobre cul es el alcance concreto del requisito, aunque cierto nivel de incertidumbre siempre va a existir. Evidentemente antes de su implementacin 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 implementacin nos permite que cuando realizamos esta actividad tengamos en cuenta de nuevo las necesidades del cliente que pueden haber cambiado y contar con la informacin que hemos ganado durante la implementacin de otros requisitos, de esta manera, al

contar con ms informacin tendremos muchas ms 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 estimacin y, en consecuencia, su planificacin. Los cambios en los requisitos ocurren, por mucho que tratemos de combatirlos. En Scrum y en las metodologas 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 gestin 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 segn se descubren y priorizndolos en funcin de las necesidades del cliente y el retorno de la inversin que el cliente recibir de su implementacin. 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 sern implementados ms tarde o incluso quedarn 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 estn implementadas aquellas partes de proyecto que ms valor le aportan y contar con la seguridad de que en el caso de que algo quede fuera del mbito del proyecto sern aquellos requisitos que menor valor tienen para el. El Producto Backlog nos permite gestionar de manera gil y sencilla los requisitos de nuestro proyecto, refinndolos cuando tenemos informacin suficiente, priorizndolos segn el valor que aportan a nuestro cliente. Elaboracion de la pila de productos (backlog) El backlog de productos es el corazon del scrum, es una lista priorizada de requisitos funcionales que pueden ser historias de usuario, cosas que el cliente quiere con su terminologia, esta lista puede contener varios campos para cada item o producto, estos serian ID el cual es el identificador unico del producto, su nombre, la importancia que le da el dueo del producto, la estimacion en horas, como se puede probar que la funcionalidad esta cubierta y nota, se pueden agregar mas campos, categoria de actividad (analisis,diseo etc.), usuario de la actividad etc. En base a las historias reunidas se seleccionan conforme a varios criterios (alcance, estimacion, importancia) las que van a ir en el sprint, en base a estas se definen las actividades que darian cumplimiento a esas historias , se descomponen en sub-actividades etc Se pueden elaborar tarjetas de producto en papel, comunmente se ordenan en un tablero y se van marcando las que se van cumpliendo Historias de usuario Las historias de Usuario no son requerimientos detallados, pueden obtenerse durante las iteraciones, como una experiencia de uso del sistema resultado de una iteracin, deben usar la terminologa del usuario , un lenguaje de negocios , no la de un desarrollador, adems de ser cortas.

Aspectos de las historias de usuario Una Historia de Usuario describe una funcionalidad, un propsito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos 1. Que describa la historia y como un plan y como recordatorio Story Card Un usuario puede mandar su resumen a travs de una pagina Web Un usuario puede buscar empleo Una compaa puede publicar nuevas ofertas de trabajo Un usuario puede limitar a quien pueda ver sus resmenes Un ejemplo de una mala nota, una historia de usuario mal hecha pudiera ser El programa podra conectarse a la base de datos a travs de una conexin

Es un mal ejemplo porque denota una funcionalidad del programa muy especifica 2. Conversaciones que puedan servir para reflejar detalles de la historia Los detalles de las historias de usuario estn en las conversaciones, las conversaciones tratan de responder preguntas acerca de la historia de usuario un ejemplo de preguntas a contestar para la historia de usuario 1 (bsqueda de empleo) pudiera ser : Qu caractersticas del empleo busca el usuario ? ciudad?estado? Qu informacin debe ser desplegada acerca del empleo? Puede guardarse el resultado de la bsqueda de empleo del usuario? Necesita ser miembro de la pagina el usuario ?

3. Test que puedan documentar cuando una historia ha sido completada Estas descripciones son cortas e incompletas, mas pruebas puedes ser sumadas con el tiempo, el objetivo es enviar informacin a los desarrolladores para que sepan cuando una historia es cubierta, es el conocer las expectativas del cliente acerca de la historia una vez finalizada

Bibliografia http://www.mountaingoatsoftware.com/scrum/product-backlog http://www.mountaingoatsoftware.com/topics/user-stories http://www.scrumalliance.org/pages/what_is_scrum http://www.scrum.org/scrumresources/ http://www.scrum.org/top-scrum-online-resources http://www.agile-spain.com/tema/requisitos_y_planificacion http://www.navegapolis.net/content/view/713/ http://geeks.ms/blogs/rcorral/archive/2007/11/12/exprimiendo-scrum-scrum-y-la-gesti243-n-de-requisitos.aspx http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html http://agilediary.wordpress.com/2009/02/21/one-product-owner-only-or-more-than-one/ http://www.romanpichler.com/blog/roles/demystifying-the-product-owner-role/ http://www.agile-peru.net/articulos/scrum/experiencias-con-scrum-requerimientos.html

http://www.monografias.com/trabajos6/resof/resof2.shtml