0 évaluation0% ont trouvé ce document utile (0 vote)
75 vues3 pages
El documento habla sobre el backlog de producto, que es una lista priorizada de requisitos y tareas pendientes para completar un proyecto de desarrollo. Incluye requisitos funcionales y no funcionales documentados como historias de usuario u otros formatos. Cada elemento en la lista se llama entrada de backlog. Un buen backlog está estimado, priorizado, detallado apropiadamente y es emergente para adaptarse a los cambios. Se revisa periódicamente para reflejar cambios en los requisitos.
El documento habla sobre el backlog de producto, que es una lista priorizada de requisitos y tareas pendientes para completar un proyecto de desarrollo. Incluye requisitos funcionales y no funcionales documentados como historias de usuario u otros formatos. Cada elemento en la lista se llama entrada de backlog. Un buen backlog está estimado, priorizado, detallado apropiadamente y es emergente para adaptarse a los cambios. Se revisa periódicamente para reflejar cambios en los requisitos.
El documento habla sobre el backlog de producto, que es una lista priorizada de requisitos y tareas pendientes para completar un proyecto de desarrollo. Incluye requisitos funcionales y no funcionales documentados como historias de usuario u otros formatos. Cada elemento en la lista se llama entrada de backlog. Un buen backlog está estimado, priorizado, detallado apropiadamente y es emergente para adaptarse a los cambios. Se revisa periódicamente para reflejar cambios en los requisitos.
El resultado de la seleccin de requisitos candidatos es una lista
de los requisitos priorizados y estimados que se tendrn en cuenta para el proyecto. Scrum, uno de los mtodos giles ms populares, da el nombre de backlog de producto a esta lista. El backlog es una lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo. El contenido ms habitual de un backlog son los requisitos funcionales. Habitualmente, en los proyectos giles, estos requisitos se documentan en forma de historia de usuario; pero tambin se pueden documentar en forma de caso de uso o utilizando cualquier otra tcnica de documentacin de requisitos funcionales. Adems, un backlog tiene que incluir los requisitos no funcionales y, en general, cualquier otra tarea necesaria para finalizar el proyecto, como por ejemplo, tareas de preparacin del entorno, tareas de lanzamiento, etc. Se denomina entrada de backlog a cada uno de los elementos que forman un backlog de producto, ya sean historias de usuario, casos de uso, otros requisitos funcionales o no funcionales o tareas que se deban hacer. De hecho, no es necesario que todas las entradas del backlog sean homogneas. Se puede tener un backlog donde se describen los requisitos funcionales como historias de usuario y donde tambin se describe un requisito de usabilidad, por ejemplo, mediante un pequeo esbozo a mano alzada de las pantallas. Ciertos especialistas en el tema establecen que, adems de estar estimado y priorizado, un buen backlog tiene que tener las cualidades de estar detallado apropiadamente y de ser emergente. Un backlog est priorizado, habitualmente, porque las entradas que contiene se ordenan de ms a menos prioridad. En algunos casos, sin embargo, puede ser til etiquetar cada entrada con un nmero o descripcin que indique la prioridad. Un backlog est estimado porque todas las entradas estn estimadas de tal modo que, para cada una, se tiene una estimacin del costo de desarrollo que aquella entrada implica. Un backlog est detallado apropiadamente cuando usa niveles de detalle diferentes para las entradas que contiene (y el nivel de detalle es el adecuado para
cada entrada). Un backlog es emergente porque puede evolucionar a
medida que cambia el conocimiento que se tiene sobre las necesidades de los stakeholders y las tareas que hay que hacer en cada momento.
El backlog y otros documentos de requisitos
El uso de un backlog no excluye al equipo de desarrollo de usar cualquier otro documento de requisitos complementario que considere necesario. As, adems del backlog, un equipo puede usar un modelo del dominio en forma de diagrama de clases UML, esbozos de las pantallas a mano alzada, mapas navegacionales para interacciones elaboradas entre el usuario y el sistema en forma de diagramas de estados UML, o cualquier otro artefacto que sea til para comunicar requisitos.
Los cambios en el backlog
Cuando los requisitos cambien, habr que aadir, modificar o eliminar entradas del backlog para reflejar estos cambios. As, cuando se descubran nuevos requisitos habr que aadirlos como entradas en el backlog (estimndolos y priorizndolos). Si un requisito cambia, puede ser necesario reestimarlo o repriorizarlo. Finalmente, se puede descubrir que un antiguo requisito deja de serlo y habr que eliminar la entrada de backlog pertinente. Por todos estos motivos es importante dedicar cierto tiempo en cada iteracin a revisar y mantener el backlog, aadiendo, quitando o modificando las entradas que haga falta a medida que los diferentes factores de cambio (sean internos o externos) provoque cambios en los requisitos o en la estimacin de su costo o valor. Adems, el backlog tiene que reflejar el trabajo hecho hasta la fecha en el desarrollo. Si una entrada de backlog ha sido ya desarrollada y verificada, se eliminar del backlog e, inmediatamente, la siguiente entrada ms prioritaria pasar a ocupar su lugar. As, a medida que se completan entradas, las que eran menos prioritarias van ganando prioridad relativa, en el sentido de que van avanzando hacia arriba en la lista y pasan a ocupar las primeras posiciones. Por otro lado, tambin se dice que el backlog tiene que estar detallado apropiadamente. La finalidad de esto es no dedicar esfuerzos a las entradas que tienen ms probabilidades de sufrir cambios (las menos prioritarias, que son las que estn ms lejanas en el tiempo).
As, las entradas ms prioritarias tienen que ser requisitos con
objetivos de ms bajo nivel, de granularidad ms fina. Estas son entradas que se tendrn en cuenta antes. A medida que tienen menos prioridad, las entradas tienen que tener niveles de objetivo ms generales, tienen que tener una granularidad ms gruesa. Se dice que el backlog tiene que tener forma de iceberg, donde la parte de arriba contiene las entradas sobre las que se est trabajando actualmente, pequeas, de granularidad muy fina, y la parte de abajo, a medida que se aleja de la punta, contiene entradas de granularidad cada vez ms gruesa, con menos nivel de detalle y, por lo tanto, ms grandes.
El objetivo de esta manera de detallar el backlog es no destinar
demasiado tiempo a detallar unas entradas de backlog que an no se usarn porque no son suficientemente prioritarias. A medida que se van consumiendo entradas de backlog, se van descomponiendo, y detallando cada vez solo las entradas ms prioritarias que quedan en el backlog.