Artefactos Descripción
Backlog del Sprint. _El Backlog del Sprint consiste en las tareas necesarias para realizar la versión final aceptada de elementos del Backlog del producto seleccionados. El equipo lo usa para sincronizar sus actividades.
_Entre los sprints, todas las partes envueltas y el equipo de ingeniería se reúnen para determinar qué trabajo puede completarse en el próximo sprint.
Backlog del producto
El Backlog del Producto lista cualquier entrega requerida. Su contenido es ordenado por valor del negocio. La prioridad de elementos del backlog podría cambiar, los requisitos pueden agregarse y removerse- así el Backlog del Producto es un plan mantenido continuamente hacia un crecimiento del valor del negocio.
O sea que es una lista priorizada de todo el trabajo que será completado anterior a la liberación del producto:
_Sólo una persona mantiene y prioriza la lista del backlog. _ Cualquier parte interesada puede solicitar que cierta tarea sea incluida en el backlog.
Sprint Un estallido corto de trabajo que dura aproximadamente 30 días durante el cual un ejecutable y otras entregas se construyen por el equipo de ingeniería, como lo indica el backlog asignado (backlog del sprint).
Las características fundamentales de un sprint son: _Un sprint dura no más de 30 días.
_Un Sprint se emprende por un equipo funcional cruzado que consiste de no más de 9 miembros.
_Cada Sprint tiene una meta específica.
_Un ejecutable demostrando el objetivo se completará por el equipo durante el sprint.
_Una vez que el sprint está en ejecución, nuevos elementos del backlog no pueden agregarse a menos que el "scrum master" determina que un nuevo elemento del backlog reforzará la viabilidad del producto, está en alineación con el sprint, se fundamenta en el ejecutable del sprint, y puede completarse dentro del marco del sprint.
_Si fuerzas externas determinan que el sprint está trabajando en mal sentido, puede detenerse y reiniciarse con un nuevo
backlog y propósito. Backlog de
impedimentos
El Backlog de Impedimentos lista cualquier problema o cuestión que tiene que ser resuelto dentro o acerca del equipo. El usuario "ScrumMaster" asegura que los elementos del Backlog de impedimentos sean asignados y se trabaje en ellos. Backlog del
Producto Seleccionado.
Es el resultado de la Planeación del Sprint. Define la cantidad de trabajo que el equipo ha aceptado y permanece inalterado durante el Sprint entero.
Actividades Propósito
Primera
planeación del Sprint.
_Definir los Objetivos del sprint y los elementos del backlog del producto seleccionados.
_ Acordar y preparar los elementos del backlog del producto para la Segunda planificación del Sprint en la que ya se crean las tareas concretas.
Segunda
planeación del sprint
_Definir tareas concretas para crear el Backlog del sprint y cumplir con los objetivos del sprint.
Encuentro de Scrum diario.
_Se comparte el “status” entre los miembros del equipo de desarrollo. Ayuda al equipo a organizarse por sí mismo. Es un encuentro de sincronización entre los miembros del equipo. Tiene lugar todos los días a la misma hora, y en el mismo lugar. La reunión dura no más de 15 minutos.
Revisión del Sprint
_Repasar todos los elementos del Backlog que el equipo ha completado en el Sprint y chequear si los objetivos del sprint fueron logrados.
Durante este encuentro el equipo presenta resultados y demuestra la nueva funcionalidad. Si el cliente quiere cambiar algún rasgo o si una nueva idea surge se agrega un nuevo elemento al backlog del producto, si el equipo reporta un impedimento se agrega un elemento a la lista del “Backlog de Impedimentos”.
Encuentro de Estimación
El cliente del producto y el equipo trabajan en la estimación del Backlog del Producto entero suministrando la base para la Liberación y Planificación de los Sprints.
Retrospectiva del sprint.
La inspección y adaptación es una parte fundamental de Scrum. Durante la Retrospectiva el equipo analiza el sprint anterior para identificar historias de éxito e impedimentos y así retroalimentarse.
Anexo 3. Repositorio de artefactos, Disciplinas con sus tipos de
actividades y Roles en el PU.
Disciplina: Modelación del Negocio.
Los propósitos de la modelación de negocio son:
_Entender los problemas actuales en la organización "objetivo" e identificar las mejoras potenciales.
_Evaluar el impacto del cambio organizacional.
_Asegurar que clientes, usuarios finales, desarrolladores, y otras partes tengan una comprensión común de la organización.
_Derivar los requisitos de sistema de software necesitados para apoyar la organización "Objetivo".
_Entender cómo el sistema de software a-ser-desplegado encaja dentro de la organización.
Se necesita modelar el negocio para localizar los problemas o identificar las oportunidades de mejoras.
Artefactos Producidos
Descripción
Glosario del negocio Este documento sólo se desarrolla si usted necesita guardar las términos necesarios para entender la modelación del negocio separado de los términos usados durante el esfuerzo de ingeniería del software consecuente
Modelo de casos de uso del negocio.
Es un modelo de los objetivos del negocio y funciones deseadas. Es usado como una entrada esencial para identificar roles y entregas en la organización.
Modelo de análisis del negocio.
Describe la realización de los casos de uso del negocio mediante la interacción de los trabajadores y las entidades del negocio. Sirve como una abstracción de cómo los trabajadores y entidades del negocio necesitan ser relacionadas y cómo ellos necesitan colaborar para realizar los casos de uso del negocio.
Metas del negocio. Es un requerimiento que debe satisfacerse por el negocio. Las Metas del negocio describen el valor deseado de una medida particular en algún punto del futuro y pueden usarse por consiguiente para planear y manejar las actividades del negocio.
Valoración de la Organización.
Describe el estado actual de la organización en que el sistema será desplegado. La descripción es en términos de los procesos actuales, herramientas, las competencias del personal, las actitudes del personal, clientes, competidores, tendencias técnicas, problemas, y áreas de mejora.
Visión del negocio Define el conjunto de metas y objetivos al cual el esfuerzo del modelado del negocio apunta.
Documento de Arquitectura del Negocio.
Proporciona una apreciación global comprensiva de los aspectos arquitectónicos significativos del negocio desde varias perspectivas diferentes.
Especificaciones suplementarias del negocio
Presenta cuantificadores del negocio no incluidos en el Modelo de Casos de Uso del Negocio o el Modelo de Análisis del Negocio, o restricciones que el negocio debe cumplir.
Regla del Negocio. Es una declaración de política o una condición que deben satisfacerse.
Caso de Uso del Negocio
Cada caso de uso del negocio es una sucesión de acciones que producen un resultado de valor a un actor en particular. Son procesos del negocio que se enmarcan en los límites de la organización.
Actor del negocio. Representa un papel jugado con respecto al negocio por alguien o algo.
Realización de Caso de Uso
Describe como los trabajadores, entidades y eventos del negocio colaboran para ejecutar un Caso de Uso en particular.
un propósito específico y definen un conjunto de responsabilidades con las cuales ese propósito puede lograrse. Entidad del Negocio Representa un pedazo significante y persistente de información
que se manipula por los trabajadors y actores del negocio. Estas son pasivas; es decir, ellos no inician interacciones por sí solas. Trabajador del
negocio
Es una abstracción de un humano o sistema de software que representan un role dentro de las realizaciones de los casos de uso del negocio. Colabora con otros trabajadores, es notificado por eventos del negocio y manipula las entidades del negocio para realizar sus responsabilidades.
Evento del negocio Representa una ocurrencia significante en las actividades del negocio que requiere la acción inmediata.
Actividades Propósito Artefactos
Evaluar Organización
9 Describir el estado actual de la organización en que la aplicación se desplegará.
9 Motivar el por qué la organización debe ser objeto de ingeniería.
9 Identificar clientes para la modelación del negocio. Entrada: Descripción de la organización y sus procesos. Salida: Target-Organization Assessment Establecer y ajustar Objetivos
9 Delimitar esfuerzo de modelación del negocio.
9 Visión de organización futura .
9 Establecer expectativas realistas en los clientes. Entrada: Business Case Stakeholder Requests Target-Organization Assessment Vision
Salida: Business Vision Captura de vocabulario común del negocio
_Definir un vocabulario común que puede usarse en todas las descripciones textuales del negocio, sobre todo en las descripciones de casos del uso del negocio.
Entrada: Business Vision Salida: Business Glossary Búsqueda de actores y casos de uso del negocio
_ Definir los limites del negocio a ser modelado.
_ Definir quién y qué interactuará con el negocio.
_esbozar los procesos del negocio. _ Crear diagramas del modelo de casos
de uso del negocio.
_ realizar sondeo del modelo de casos de uso del negocio
Entrada:
Business Glossary Business Vision
Project Specific Guidelines
Salida:
Business Actor Business Use Case Business Use Case Model Supplementary Business
Specification
Sostener reglas del negocio
_ Definir qué reglas de negocio considerar en el proyecto.
_ Dar a las reglas del negocio definición detallada.
Entrada:
Business Analysis Model ,Business Architecture Document, Business Glossary ,Business Use Case Model
,Business Vision, Supplementary
Business Specification Salida: Business Rule Definir arquitectura del sistema
_Entender las fuerzas que afectan significativamente el negocio.
_Definir los patrones, mecanismos claves, convenciones de modelación para el negocio
Entrada: Business Analysis Model , Business Glossary , Business Use Case Model ,
Business Vision, Supplementary
Business Specification
Salida:Business Architecture
Estructurar el Modelo de Casos de Uso del Negocio
_Extraer el comportamiento en los Casos de Uso del negocio que necesita ser considerado como Casos de Uso Abstractos del Negocio
_Encontrar actores abstractos que definen roles que son compartidos por varios actores.
Entrada:
Business Actor , Business Glossary, Business Use Case , Business Use Case Model , Project Specific Guidelines, Supplementary Business Specification
Salida:
Business Actor Business Use Case
Business Use Case Model
Identificar Metas del Negocio.
_Identificar los objetivos con los cuales el negocio pueda ser planeado y manejado
_Traducir la estrategia de negocio en acción.
_Proveer una base para la medida y mejora de las actividades del negocio.
Entrada:
Business Architecture Document
Business Goal
Business Use Case Model Business Vision
Project Specific Guidelines
Salida:
Business Goal
Detallar caso de uso del negocio
_ Describir el flujo de trabajo del caso de uso del negocio en detalle.
_Garantizar que caso de uso del negocio soporta la estrategia del negocio.
_ Asegurar que los clientes, usuarios, y apostadores puedan entender el flujo de trabajo del caso del uso del negocio.
Entrada:
Business Actor
Business Glossary
Business Goal Business Use Case Business Use Case Model Business Vision
Project Specific Guidelines
Salida:
Business Use Case Supplementary Business
Specification
Buscar
Trabajadores y entidades del negocio
_ Identificar todos los roles, entregas y eventos del negocio.
_ Describir cómo las realizaciones de casos de uso del negocio se realizan por los trabajadores y entidades del negocio.
Entrada:
Business Architecture Document
Business Glossary Business Use Case Model Project Specific Guidelines Supplementary Business Specification
Salida:
Business Analysis Model Business Entity Business Event Business Use-Case Realization Business Worker Definir requerimientos automáticos
_ Entender cómo pueden usarse las nuevas tecnologías para hacer a la organización “objetivo” más eficaz. _ Definir el nivel de automatización de
la organización.
_ Derivar requisitos de sistema de los artefactos de modelación del negocio.
Entrada:
Business Analysis Model Business Architecture Document
Business Glossary Business Use Case Model Supplementary Business Specification Target-Organization Assessment Salida: Analysis Model Supplementary Specifications Use-Case Model
del negocio comportamiento requerido.
_Identificar los eventos del negocio disparados por la entidad del negocio.
_evaluar las relaciones estructurales de la entidad de negocio.
Business Analysis Model Business Entity Business Rule Business System Business Use Case
Business Use-Case Realization
Project Specific Guidelines Supplementary Business Specification Salida: Business Entity Business Event Detallar trabajador del negocio
_Describir las responsabilidades del trabajador
_ Identificar sus requerimientos de competencia.
_Garantizar que el trabajador del negocio es capaz de desarrollar sus responsabilidades.
Entrada:
Business Analysis Model Business Rule
Business System Business Use Case
Business Use-Case Realization
Business Worker Project Specific Guidelines Supplementary Business Specification Salida: Business Worker Revisar modelo de Casos de Uso del Negocio
_Verificar que los resultados de una modelación de caso de uso del negocio se ajusta a la visión de los clientes o apostadores del negocio.
Entrada:
Business Glossary, Business Use Case , Business Use Case Model , Project Specific Guidelines , Supplementary Business Specification
Salida:
Revisar Modelo de Análisis del negocio
_Verificar que los resultados de una modelación de análisis del negocio se ajusta a la visión de los clientes o apostadores del negocio.
Entrada:
Business Analysis Model , Business Entity , Business Event , Business Glossary , Business Rule , Business System , Business Use-Case Realization , Business Worker ,
Project Specific Guidelines
Salida:
Review Record
Disciplina: Requerimientos.
Los propósitos de la disciplina Requerimientos son:
_Establecer y mantener el acuerdo con los clientes y otros apostadores en lo que el sistema debe hacer.
_Proporcionar a los desarrolladores del sistema una mejor comprensión de los requisitos del sistema.
_Definir los límites (delimitar) del sistema.
_Suministrar una base para la planeación de los contenidos técnicos de las iteraciones. _Suministra una base para la estimación de costo y tiempo para desarrollar el sistema. _Definir una interfaz de usuario para el sistema, enfocándose en las necesidades y metas de los usuarios. Artefactos producidos Descripción Plan de manejo de requerimientos
Describe los artefactos, la descripción, y los atributos del requerimiento, especificando la información a ser recopilada y los mecanismos a ser usados para medición, reporte, y controlar los cambios a los requerimientos del producto. Glosario Define términos importantes usados en el proyecto.
perspectiva de requisitos. Especificaciones
Suplementarias
Captura requerimientos de sistema que no se capturan en los artefactos de requerimientos de comportamiento como las especificaciones de casos de uso.
Requerimientos de apostadores
Contiene cualquier tipo de requerimeinto de los apostadores (cliente, usuario final, personal de "Marketing", etc...). También puede contener las referencias a cualquier tipo de fuentes externas a que el sistema deba acceder.
Visión Define la vista de los apostadores sobre el producto, expresado en términos de necesidades claves y rasgos. Provee la base contractual para requerimientos técnicos más detallados.
Modelo de Casos de Uso
Es un modelo de las funciones deseadas del sistema y su ambiente, y sirve como un convenio entre el cliente y los diseñadores. El modelo de casos de uso se usa como una entrada esencial a las actividades en el análisis, plan, y prueba.
Tabla de eventos Es una descripción lógica y conceptual de funcionalidad del sistema para un escenario específico, incluye la interacción requerida entre los usuarios del sistema y el sistema. Nos "Cuenta una historia específica" .
Caso de Uso Define un conjunto de instancias del caso de uso dónde cada instancia es una sucesión de acciones que un sistema realiza y que rinde un resultado de valor observable a un actor particular.
Especificación de requisitos de software
La Especificación de Requisitos de Software (SRS) captura los requisitos del software para el sistema completo, o una porción de ese sistema.
Paquete de casos de uso
Es una colección de casos del uso, actores, relaciones, diagramas, y otros paquetes; se usa para estructurar el modelo
de casos de uso dividiéndolo en partes menores. Requerimiento de
software
La especificación para una condición o capacidad a que un sistema debe ajustarse.
Actor Define un conjunto coherente de papeles que los usuarios del sistema pueden jugar al interactuar con él. Una instancia del actor puede ser desempeñada por un individuo o un sistema externo.
Actividad Propósito Artefactos
Captura de vocabulario
común.
_Definir un vocabulario común que puede usarse en todas las descripciones textuales del sistema, sobre todo en las descripciones de casos del uso.
Entrada:
Business Analysis Model , Business Case , Business Rule , Business Use Case Model , Stakeholder Requests , Use Case , Use- Case Model , Vision
Salida: Glossary Desarrollar plan de gestión de requerimientos.
_desarrollar un plan para documentar requerimientos, sus atributos y pautas para el rastreo y gestión de los requerimientos del producto.
Entrada:
Iteration Plan, Requirements , Management Plan , Software Development Plan Salida: Requirements Management Plan Desarrollar Documento Visión.
_Ganar consenso en qué problemas necesitan ser resueltos.
_Identificar apostadores para el sistema. _Define los limites del proyecto.
Entrada:
Business Analysis Model , Business Case , Business Rule , Business Rule , Business Use Case
Stakeholder Requests ,Vision Salida: Requirements Attributes , Vision Evocar requerimientos de apostadores.
_entender quienes son los apostadores del proyecto.
_colectar demandas de cuales necesidades el sistema debe satisfacer.
_priorizar demandas de los apostadores.
Entrada:
Business Case , Change Request , Iteration Plan , Iteration Plan , Vision
Salida: Stakeholder Requests, Storyboard Búsqueda de actores y casos de uso.
_ definir quien y en que medida va a interactuar con el sistema.
_Definir el alcance del sistema—lo que se manejará por el sistema y lo que se manejará fuera del sistema.
_Esbozar la funcionalidad del sistema.
Entrada:
Business Analysis Model , Business Case , Business Use Case Model , Glossary , Iteration Plan , Project Specific Guidelines , Stakeholder Requests , Vision
Salida:
Actor , Supplementary Specifications , Use Case ,
Use-Case Model
Manejo de dependencias
_Usar atributos y rastreo de los requisitos del proyecto para asistir en el manejo del alcance del proyecto y manejar los requisitos cambiantes.
Entrada:
Change Request, Design
Model , Requirements Attributes , Requirements Management Plan , Risk List , Stakeholder Requests , Supplementary Specifications
, Use-Case Model , Vision Salida: Requirements Attributes, Requirements , Management Plan , Vision Estructurar Modelo de Casos de Uso.
_Extraer el comportamiento en casos de uso que necesitan ser considerados como casos de uso abstractos. Ejemplos de tal conducta son el comportamiento común, comportamiento opcional, comportamiento excepcional, y comportamiento que será desarrollado en próximas iteraciones.
_Búsqueda de nuevos actores abstractos que definen "roles" o "papeles" compartido por varios actores.
Entrada:
Glossary , Iteration Plan , Project Specific Guidelines , Supplementary Specifications , Use Case , Use-Case Model , Use-Case Package
Salida:
Use Case, Use-Case Model ,
Use-Case Package
Priorizar Casos de Uso
_ Definir el conjunto de escenarios y casos del uso que serán analizados en la iteración actual.
_Definir el conjunto de escenarios y casos de uso que representan alguna funcionalidad significativa y central.
_Definir el conjunto de escenarios y casos de uso que tienen una cobertura arquitectónica sustancial o que enfatizan o ilustran un punto específico y/o delicado de la arquitectura.
Entrada:
Iteration Plan , Requirements Attributes , Risk List , Software Architecture Document , Software Requirement , Use-Case Model , Vision Salida: Software Architecture Document , Software Requirement Detallar caso de uso
_Describir uno o más flujo de eventos del caso del uso en el detalle suficiente para permitir el comienzo del desarrollo en este. _Describir la especificación de caso de uso
Entrada:
Glossary, Iteration Plan , Requirements Management Plan , Stakeholder Requests , Storyboard , Supplementary
cliente. Use-Case Model , Vision
Salida:
Supplementary Specifications, Use Case
Detallar los requerimientos de software.
_Coleccionar, detallar y organizar el conjunto (el paquete) de artefactos que completamente describen los requisitos de software del sistema o subsistema.
Entrada:
Glossary,Iteration Plan , Requirements Management Plan , Supplementary
Specifications, Use Case,
Use-Case Model , User- Interface Prototype , Vision
Salida: Software Requirement , Software Requirements Specification Revisar requerimientos.
_Formalmente verificar que los resultados de requerimientos se adecuan a la vista del cliente acerca del sistema.
Entrada:
Business Case, Change
Request , Glossary Iteration Plan
Project Specific Guidelines