|
|
| (20 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| __NOTOC__ | | __NOTOC__ |
| *Pila del producto: (product backlog) lista de requisitos de usuario que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo. | | Los '''artefactos''' de scrum son sus herramientas, sus bloques de construcción elementales. Ayudan a los [[roles]] durante los [[eventos]]. |
| *Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. | | ==Artefactos más extendidos== |
| *Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso por tiempos prefijados (time boxing). | | [[File:Artefactos-scrum.png|250px|thumb|right]] |
| *Incremento: resultado de cada sprint.
| | Los artefactos del marco de scrum técnico son: |
| | *'''[[Pila del producto]] (''product backlog''):''' lista de requisitos de usuario, que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo. |
| | *'''[[Pila del sprint]] (''sprint backlog''):''' lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. |
| | *'''[[Incremento]]:''' resultado de cada ''sprint''. |
|
| |
|
| [[File:Ciclo scrum.jpg|550px|center]]
| | ==Otros artefactos== |
| | | *[[Gráfico_de_avance|'''Gráfico de avance o ''Burn down chart'':''']] indica el trabajo pendiente y la velocidad a la que se están completando las tareas para deducir si se completarán todas en el tiempo estimado. Los desarrolladores lo actualizan a diario. |
| Otro elemento propio del modelo estándar de Scrum es el [[gráfico de avance]] o gráfico burn down que el equipo actualiza a diario para comprobar el avance. Este elemento, junto con la práctica de estimación de póquer y el gráfico de producto o burn up se encuentra incluido en los contenidos de Métricas.
| | *[[Gráfico_de_producto|'''Gráfico de producto o ''Burn up chart'':''']] si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado. |
| | | *[[A_punto|'''''Definition of Ready'' (DoR):''']] acuerdo que define cuándo una historia de usuario se considera «lista» para ser descompuesta en tareas, estimada e incluida en un ''[[sprint]]''. |
| | | *[[Definición_de_hecho|'''''Definition of Done'' (DoD):''']] acuerdo sobre los criterios para considerar que una parte del trabajo (tarea, historia…) está terminada. |
| ==Pila del producto y pila del sprint: los requisitos en desarrollo ágil== | | <br> |
| La ingeniería del software clásica diferencia dos áreas de requisitos:
| | [[File:Standard scrum framework.png|800px|thumb|center]] |
| | | </br> |
| *Requisitos del sistema | | ==Véase también== |
| *Requisitos del software
| | *[[Eventos]]. |
| | | *[[Roles]]. |
| Los requisitos del sistema forman parte del proceso de adquisición (ISO 12207), y por tanto es responsabilidad del cliente la definición del problema y de las funcionalidades que debe aportar la solución.
| | *[https://www.scrummanager.com/website/c/info/docs-media.php Scrum Manager website: Libro ''Scrum Master''.] |
| | | [[Category:Standard scrum]] [[Category:Glosario de términos]] |
| No importa si se trata de gestión tradicional o ágil. La descripción del sistema (pila del producto) es responsabilidad del cliente, aunque se aborda de forma diferente en cada caso.
| |
| | |
| [[File:Requisitos completos incrementales.png|550px|center]]
| |
| | |
| *En los proyectos predictivos, los requisitos del sistema suelen especificarse en documentos formales; mientras que en los proyectos ágiles toman la forma de pila del producto o lista de historias de usuario.
| |
| *Los requisitos del sistema formales se especifican de forma completa y cerrada al inicio del proyecto; sin embargo una pila del producto es un documento vivo, que evoluciona durante el desarrollo.
| |
| *Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniería de requisitos a través del proceso de obtención (elicitación) con el cliente. En Scrum la visión del cliente es conocida por todo el equipo (el cliente forma parte del equipo) y la pila del producto se realiza y evoluciona de forma continua con los aportes de todo el equipo.
| |
| | |
| Scrum, aplicado al software, emplea dos formatos para registrar los requisitos:
| |
| *Pila del producto (Product Backlog)
| |
| *Pila del sprint (Sprint Backlog)
| |
| | |
| La pila del producto refleja los requisitos vistos desde el punto de vista del cliente. Un enfoque similar al de los requisitos del sistema de la ingeniería tradicional. Está formada por la lista de funcionalidades o "historias de usuario" que desea obtener el cliente, ordenadas por al prioridad que el mismo le otorga a cada una.
| |
| La pila del sprint refleja los requisitos vistos desde el punto de vista del equipo de trabajo. Está formada por la lista de tareas en las que se descomponen las historias de usuario que se van a llevar a cabo en el sprint.
| |
| En el desarrollo y mantenimiento de la pila del producto lo relevante no es tanto el formato, sino que:
| |
| *Las funcionalidades que incluye den forma a una visión del producto definida y conocida por todo el equipo.
| |
| *Las funcionalidades estén individualmente definidas, priorizadas y pre-estimadas. | |
| *Estén realizados y gestionados por el cliente (propietario del producto).
| |
| | |
| ==Pila del producto: los requisitos del cliente==
| |
| | |
| La pila del producto es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de los sucesivos sprints.
| |
| Representa todo aquello que esperan el cliente, los usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe realizar el equipo debe estar reflejado en esta pila.
| |
| Estos son algunos ejemplos de posibles entradas a una pila de producto:
| |
| *Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
| |
| *Reducir el tiempo de instalación del programa.
| |
| *Mejorar la escalabilidad del sistema.
| |
| *Permitir la consulta de una obra a través de un API web.
| |
| | |
| | |
| A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completada; está en continuo crecimiento y evolución.
| |
| Habitualmente se comienza a elaborar con el resultado de una reunión de “tormenta de ideas”, o "fertilización cruzada", o un proceso de “Exploración” (eXtreme Programming) donde colabora todo el equipo partiendo de la visión del propietario del producto.
| |
| El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, u otros.
| |
| Sin embargo, sí es importante disponer de una visión real, comprendida y compartida por todo el equipo.
| |
| La pila evoluciona de forma continua mientras el producto está en el mercado, incrementando su valor de forma permanente, manteniéndolo útil y competitivo.
| |
| | |
| | |
| Para dar comienzo al desarrollo se necesita una visión de los objetivos de negocio que se quieren conseguir con el proyecto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila para llevar a cabo el primer sprint.
| |
| | |
| ===Formato de la pila del producto===
| |
| | |
| El desarrollo ágil prefiere la comunicación verbal o de visualización directa, a la escrita.
| |
| La pila del producto no es un documento de requisitos, sino una herramienta de referencia para el equipo.
| |
| Si se emplea formato de lista, es recomendable que al menos incluya la siguiente información en cada línea:
| |
| *Identificador único de la funcionalidad o trabajo.
| |
| *Descripción de la funcionalidad/requisito, denominado “historia de usuario”.
| |
| *Campo o sistema de priorización.
| |
| *Estimación del esfuerzo necesario.
| |
| Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:
| |
| *Observaciones.
| |
| *Criterio de validación.
| |
| *Persona asignada.
| |
| *Nº de Sprint en el que se realiza.
| |
| *Módulo del sistema al que pertenece. | |
| *Entre otros.
| |
| Es preferible no adoptar ningún protocolo de trabajo de forma rígida. Los resultados de Scrum no dependen de la rigidez en la aplicación del protocolo, sino de la institucionalización de sus principios y la implementación en un formato adecuado a las características de la empresa y del proyecto. He aquí un sencillo ejemplo de pila de producto:
| |
| | |
| | |
| [[File:Ejemplo pila producto.png|550px|center]] | |
| | |
| ==Pila del Sprint==
| |
| | |
| La pila del sprint (o sprint Backlog) es la lista que descompone las funcionalidades de la pila del producto (historias de usuario) en las tareas necesarias para construir un incremento: una parte completa y operativa del producto.
| |
| La realiza el equipo durante la reunión de planificación del sprint, autoasignando cada tarea a un miembro del equipo, e indicando en la misma lista cuánto tiempo o esfuerzo falta para terminarla. Es útil porque descompone el proyecto en unidades de tamaño adecuado para monitorizar el avance a diario, e identificar riesgos y problemas sin necesidad de procesos de gestión complejos.
| |
| Es también una herramienta para la comunicación visual directa del equipo.
| |
| | |
| | |
| '''Condiciones''' | |
| *Realizada de forma conjunta por todos los miembros del equipo.
| |
| *Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint. | |
| *Sólo el equipo lo puede modificar durante el sprint.
| |
| *El tamaño de las tareas debe ser tal que se puedan realizar en un día.
| |
| *Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo.
| |
| | |
| | |
| '''Formato y soporte''' | |
| | |
| Las opciones habituales son:
| |
| *Hoja de cálculo.
| |
| *Pizarra física o pared.
| |
| *Herramienta colaborativa o de gestión de proyectos.
| |
| | |
| Y sobre la que mejor se adecue a las características del proyecto, oficina y equipo, lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:
| |
| *Incluir la siguiente información: Pila del sprint, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.
| |
| *Incluir sólo la información estrictamente necesaria.
| |
| *Debe servir de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea.
| |
| *Facilitar la consulta y la comunicación diaria y directa del equipo.
| |
|
| |
| | |
| Ejemplo de una pila de sprint en una hoja de cálculo:
| |
| | |
| [[File:Ejemplo pila sprint.png|550px|center]] | |
| | |
| Durante el sprint, el equipo actualiza sobre la pila del sprint, a diario, los tiempos pendientes de cada tarea. Al mismo tiempo, con estos datos traza el gráfico de avance o “burn-down”, que se describe en los temas de métricas ágiles.
| |
| | |
| ==El Incremento== | |
| | |
| El incremento es la parte de producto producida en un sprint, y tiene como característica el estar completamente terminada y operativa, en condiciones de ser entregada al cliente final.
| |
| No se deben considerar como Incremento a prototipos, módulos o submódulos pendientes de prueba o integración.
| |
| Idealmente en Scrum:
| |
| | |
| *Cada elemento de la pila del producto se refiere a funcionalidades entregables, no a trabajos internos del tipo “diseño de la base de datos”. | |
| *Se produce un “incremento” en cada iteración. | |
| | |
| | |
| Sin embargo suele ser una excepción habitual el primer sprint. En el que objetivos del tipo “contrastar la plataforma y el diseño” pueden resultar necesarios, e implican trabajos de diseño o desarrollo de prototipos para contrastar las expectativas de la plataforma o tecnología que se va a emplear. Teniendo en cuenta esta excepción habitual:
| |
| | |
| {{Párrafo_enmarcado|texto=Incremento es la parte de producto realizada en un sprint potencialmente entregable: terminada y probada.}}
| |
| | |
| Si el proyecto o el sistema requiere documentación, o procesos de validación y verificación documentados, o con niveles de independencia que implican procesos con terceros, éstos también tienen que estar realizados para considerar que el producto está “terminado”.
| |
| | |
| [[Category:Scrum I]] | |
