Objetivos: Sistemas de Información 2. Objetivos. Objetivos:

Transcripción

1 Sistemas de Información 2 L06: Desarrollo Ágil Ingº Manuel Peñaloza Figueroa DAI Departamento Académico de Informática Modificado por última vez: 31/Oct/2010 Objetivos: Explicar cuando usar un enfoque adaptativo para el SDLC en lugar de un SDLC más predictivo y tradicional. Describir los 2 enfoques generales usados para controlar el desarrollo de software: Modelo de Control de Procesos Definido Modelo de Control de Procesos Empírico Describir las características claves de la tendencias actuales en el desarrollo de sistemas: la Programación extrema (XP), y Scrum. 2 3 Objetivos Describir la metodologías ágiles, la Programación extrema y Scrum. Objetivos: E Problema: Cómo Controlar el Desarrollo de Software? Cómo puede describirse mejor el desarrollo de software? 2 opiniones: Madurez vs. Agilidad 1. A través de la madurez organizacional (Humphrey) Procesos repetitivos. Modelo de Madurez y Capacidad (CMM) 2. A través de la agilidad (Schwaber) Grandes partes del desarrollo de software son empíricos por naturaleza; no puede ser modelado con un proceso definido Cómo controlar el desarrollo de software? El desarrollo de software es un proceso determinista con un modelo de control de procesos definido El desarrollo de software es un proceso no-determinista con un modelo de control de procesos empírico

2 Problema: Cómo Controlar el Desarrollo de Software? Modelo de Control de Procesos Definido: Los modelos de control de procesos definidos asumen que el desarrollo de software es un proceso determinista: Dado un conjunto bien-definido de entradas, las mismas salidas son generadas cada vez desviaciones son vistas como errores que necesitan ser corregidos todos los modelos del ciclo de vida del software orientados-a-la-actividad introducidos en las clases previas son modelos de control de procesos definidos Precondición para aplicar el modelo de control de procesos definido: cada pieza de trabajo puede entenderse completamente todas las actividades y tareas están bien definidas para proporcionar repetibilidad y previsibilidad Si las precondiciones no son satisfechas: muchas sorpresas (con frecuencia demasiado tarde), la pérdida del control, productos del trabajo incompletos ó erróneos Problema: Cómo Controlar el Desarrollo de Software? Modelo de Control de Procesos Empírico: El modelo de control de procesos empírico asume que: Muchos aspectos del desarrollo de software son mejor descritos como un proceso no-determinista no todas las piezas de trabajo necesitan entenderse completamente ó pueden entenderse desviaciones son vistas como oportunidades que necesitan ser investigadas el proceso empírico "espera lo inesperado" El control se ejerce a través de inspecciones frecuentes inspecciones diarias en Scrum Condiciones cuando aplicar este modelo: cuando cambios frecuentes se esperan durante el proyecto, cuando las entradas son impredecibles y las salidas irrepetibles Problema: Cómo Controlar el Desarrollo de Software? 2 ejemplos de modelos de control de proceso empíricos: XP (extreme Programming = Programación Extrema) Scrum... Ambos también son ejemplos de metodologías ágiles Metodologías ágiles usan un modelo de proceso empírico para describir el ciclo de vida del software. 7 9 Metodologías: (repaso) Temas a ser abordados por una metodología: Las metodologías proporcionan: orientación (ó guía) principios generales estrategias para seleccionar métodos y herramientas en un entorno de proyecto determinado Cuestiones claves para las que las metodologías proporcionan orientación: Cuánta participación del cliente? Cuánta planificación? Cuánta reutilización? Cuándo modelar antes de codificar? Cuánto proceso? Cuánto control y monitoreo? Desarrollo Ágil: Adopción Escenario 1: (desarrollo tradicional) Figura: Desarrollo tradicional estilo cascada. Desarrollo Ágil: Adopción Escenario 1: (desarrollo tradicional) Un equipo de proyectos pequeño (por decir 5 personas) Le tomaría 2 a 3 meses registrar todos los requerimientos en detalle Luego el equipo analizaría los requerimientos El análisis de requerimientos sería seguido por un diseño del sistema, incluyendo la arquitectura. Para este momento, el cliente habría introducido los primeros cambios, que harían entrar al proceso de Gestión del Cambio. El proceso de Gestión del Cambio en si mismo requeriría un pequeño retrabajo de requerimientos, otro análisis, y posiblemente más diseños Después de 6 ó 7 meses, el equipo finalmente estaría listo para implementar. Como puede suponer, el cliente podría necesitar cambios adicionales que podrían pasar de nuevo por el proceso de Gestión del Cambio

3 Desarrollo Ágil: Adopción Escenario 1: (desarrollo tradicional) Nota: Sin embargo, hay situaciones donde probablemente este es el único proceso posible - tal como los sistemas de misión crítica ó de apoyo a la vida. Desarrollo Ágil: Adopción Escenario 2: (desarrollo ágil) Figura: Primera iteración en un proceso de desarrollo ágil. Desarrollo Ágil: Adopción Escenario 2: (desarrollo ágil) Si el equipo (de proyectos pequeño (por decir 5 personas)) hubiera estado usando un enfoque ágil: Habría toscamente esbozado los requerimientos, pero de un modo que permitía a los propietarios del proyecto priorizarlos. Luego los propietarios del proyecto y desarrolladores juntos habrían seleccionado un grupo pequeño de características de los requerimientos y los diseñaría e implementaría en una serie de iteraciones de 2 a 3 semanas de duración cada una. Con un par de iteraciones, habrían desarrollado una versión que trabaja, que se puede ejecutar de la aplicación, y los propietarios del proyecto podrían haber comenzado probando ó usando la aplicación. Después de un par de iteraciones mas, la aplicación habría tenido sus funciones básicas y estar lista para el lanzamiento Desarrollo Ágil: Manifiesto Desarrollo Ágil: Desarrollo Ágil: Manifiesto para el Desarrollo de Software Ágil Nosotros estamos descubriendo mejores maneras de desarrollar software con hacerlo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar: Los individuos e interacciones sobre los procesos y las herramientas Software que trabaja sobre documentación exhaustiva Colaboración del cliente sobre la negociación de contratos Responder al cambio sobre seguir un plan Es decir, mientras hay valor en los ítems de la derecha, nosotros valoramos más los ítems a la izquierda. Firman: Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Un grupo de metodologías centradas-en-laprogramación que se enfocan en hacer más eficiente (ó racionalizar) el SDLC. Incluye comunicación en persona (ó frente-a-frente). Esta categoría se enfoca en hacer más eficiente el SDLC eliminando: gran parte de la modelización y de los gastos generales de la documentación (y) el tiempo dedicado a esas tareas. Los proyectos hacen énfasis en un desarrollo de aplicaciones sencillo, e iterativo

4 Desarrollo Ágil: Desarrollo Ágil: Las metodologías de desarrollo ágil son procesos ligeros que buscan minimizar el tiempo que transcurre entre identificar los requerimientos y la entrega de un código que trabaje. Los requerimientos de alto nivel se capturan como declaraciones generales de la funcionalidad deseada ó como historias de usuario que describen en forma narrativa como el sistema se utiliza para alcanzar una meta. Los requerimientos se formalizan como casos de prueba para la implementación así que el desarrollo progresa hacia la aprobación de los casos de pruebas, de ese modo entregando la funcionalidad requerida con tan pocos gastos generales del proceso como posible. XP Los procesos de desarrollo ágil son usualmente ejecutados en pequeños fragmentos de unas cuantas historias de usuario ó requerimientos a la vez. El cronograma es básicamente un método de caja de tiempo que define el periodo de tiempo para una iteración y los requerimientos que deberían completarse dentro de ese marco de tiempo. Cada iteración debería ser lo suficientemente grande para entregar al menos 1 aspecto funcional significante de la aplicación pero no tan grande que diluya el enfoque del equipo. Figura: Esquema del método ágil XP: Historia Elenco original de contribuidores: Kent Beck, Ron Jeffries, Ward Cunningham (quien también creó Wiki) Aplicación de XP en el proyecto "Chrysler Comprehensive Compensation" (Proyecto C3) en 1995 Mucho entusiasmo inicial pero después un montón de problemas: Daimler de hecho cerró el Proyecto C3 en el 2000 e inclusive prohibió XP por algún tiempo. XP XP asume que el cambio es normal XP supone que el desarrollador de software tiene que ser capaz de reaccionar a los requerimientos que cambian en cualquier punto durante un proyecto XP es una metodología de software ágil porque: Pone mayor prioridad sobre adaptabilidad ("modelo de control de procesos empírico") que sobre previsibilidad ("modelo de control de procesos definido") XP prescribe un conjunto de prácticas del día-a-día para los administradores y desarrolladores para abordar el cambio. XP: Valores XP se basa en valores. Las reglas que se examinaran son la extensión natural y la consecuencia de maximizar los valores Comenzar con los valores listados aquí: Simplicidad Comunicación Realimentación Respeto Coraje (listado como un nuevo valor) (luego agregar los suyos)

5 XP: El Proceso de Software Modelo de ciclo de vida iterativo muy simple con actividades: Planificación ocurre al comienzo de cada iteración Gestión Diseño Codificación Pruebas ocurren incrementalmente en sucesión rápida Asimismo: el código fuente se integra continuamente en la rama principal, 1 contribución a la vez Las pruebas de unidad para todas la unidades integradas se usan para las pruebas de regresión. XP: El Proceso de Software Actividades del marco de trabajo también llamada actividades claves Planeación Administración Diseño Codificación Pruebas XP: El Proceso de Software Restricciones sobre estas actividades: Primero los tests: Las pruebas de unidad son escritas antes de las unidades. Ellas son escritas por el desarrollador Se generalizó a la programación conducida por pruebas Escribir tests por cada bug nuevo: Cuando se descubren los defectos, una prueba de unidad se crea para reproducir el defecto. Después que el defecto se repara, todas las pruebas de unidad se ejecutan nuevamente. Refactorizar antes de extender: para asegurar que el diseño no decaiga a medida que se agregan nuevas características XP: Actividades del marco de trabajo XP: Actividades del marco de trabajo Planificación: Comienza con la creación de "historias de usuario" El equipo ágil evalúa cada historia y le asigna un costo Historias son agrupadas para un incremento entregable Un compromiso es hecho sobre la fecha de entrega XP: Actividades del marco de trabajo Gestión: Número reducido de reuniones formales: El estado ó status del proyecto se comunica en el equipo en una reunión diaria estando de pie. Solo se comparte información, no hay discusiones para mantener la reunión breve. Después del primer incremento la "velocidad del proyecto" se usa para ayudar a definir las fechas de las subsiguientes entregas para los otros incrementos Figura: El proceso de XP

6 XP: Actividades del marco de trabajo Diseño XP: Sigue el principio KIS ("Keep It Simple") Fomenta el uso de tarjetas CRC Para problemas de diseño difíciles, sugiere la creación de "soluciones spike" - un prototipo de diseño Fomenta la "refactorización" - un refinamiento iterativo del diseño interno del programa. Codificación XP: Recomienda la construcción de un test de unidad para una historia antes que la codificación comience Fomenta "la programación en parejas" XP: Actividades del marco de trabajo Pruebas XP: Todas los tests de unidades son ejecutados diariamente Los "test de aceptación" son definidos por el cliente y ejecutados para evaluar la funcionalidad visible por el cliente XP: Prácticas del día-a-día ("Mantras") XP ha sido reducido a 5 principios claves: 1. Realimentación rápida 2. Simplicidad 3. Cambio incremental 4. Acoger el cambio 5. Trabajo de calidad XP: Prácticas del día-a-día ("Mantras") 1. Realimentación rápida: Enfrentando los problemas al principio resulta en más tiempo para resolver los problemas. esto se aplica tanto a la realimentación del cliente como a la realimentación a partir de las pruebas 2. Simplicidad: El diseño debería enfocarse en los requerimientos actuales. Diseños simples son más fáciles de entender y cambiar que los complejos. 3. Cambio incremental: 1 cambio a la vez en vez de muchos cambios concurrentes Ese "1 cambio a la vez" debería integrarse con la línea de base actual XP: Prácticas del día-a-día ("Mantras") 4. Acoger el cambio: El cambio es inevitable y frecuente en los proyectos XP El cambio es normal y no una excepción que necesita ser evitada 5. Trabajo de calidad: Enfocarse en proyectos rápidos donde el progreso se demuestra con frecuencia Cada cambio debería ser implementado con cuidado y completamente. XP: Reglas El aspecto más sorprendente de XP son sus reglas simples. La Programación Extrema es mucho como un rompecabezas. Hay muchas piezas pequeñas. Individualmente la piezas no tienen sentido, pero cuando combinadas juntas se puede ver un cuadro completo Las reglas: definen un entorno que promueve la colaboración y la potenciación del equipo. en XP: Reglas Prácticas

7 XP: Reglas XP: Reglas XP: Reglas Planificación: Las Historias de usuario se escriben. La planificación de la versión crea el cronograma de la versión. Hacer frecuentes versiones pequeñas. El proyecto se divide en iteraciones. La planificación de la iteración arranca cada iteración. Gestión: Dar al equipo un espacio de trabajo abierto dedicado. Establecer un ritmo sostenible. Una reunión estando de pie comienza cada día. Se mide la Velocidad del Proyecto. Rotar a la gente. Corregir XP cuando se quiebra. Diseño: Simplicidad. Elegir una metáfora del sistema. Utilizar tarjetas CRC para las sesiones de diseño. Crear soluciones "spike" para reducir los riesgos Ninguna funcionalidad se agrega al principio. Refactorizar cuando y donde sea posible Codificación: El cliente siempre está disponible. Código se tiene que escribir con los estándares acordados. Codificar el test de unidad primero. Todo el código de producción es programado en parejas. Sólo 1 pareja integra el código en un momento. Integrar con frecuencia. Configurar una computadora de integración dedicada. Utilizar propiedad colectiva. Pruebas: Todo el código tiene que tener pruebas de unidad. Todo el código tiene que pasar todas las pruebas de unidad antes que pueda ser entregado. Cuando un bug se encuentra se crean tests. Las pruebas de aceptación se ejecutan con frecuencia y la puntuación se da a conocer XP: Prácticas "core" Las 12 prácticas "core" de XP, agrupadas en 4 categorías son: (1/?) Realimentación a escala fina: Desarrollo Conducido por Pruebas (TDD) vía Tests del Programador y Tests del Cliente (las Pruebas de Unidad & las Pruebas de Aceptación) El Juego de la Planificación = Reunión de Planificación de la Versión Equipo Total (el Cliente in-situ) Programación en parejas Proceso continuo en lugar del proceso por lotes: Integración continua Mejoramiento del diseño (la Refactorización "sin piedad") Releases pequeños XP: Prácticas "core"...: (2/?) Entendimiento compartido Diseño simple (Hacer las Cosas Simples, Ud. No los Va a Necesitar, Una Vez y Solamente Una Vez, Simplificar Vigorosamente) Metáfora del Sistema Propiedad Colectiva del Código Codificación estándar ó Convenciones para la Codificación Bienestar del programador: Ritmo Sostenible (nombre original: Semana de 40 horas) XP: Prácticas "core": El Juego de la Planificación: Crea un poco de distancia emocional de la planificación tradicional al tratarlo como un juego (de ahí su nombre). El juego tiene: una meta piezas de juego jugadores (y) reglas para los movimientos permitidos

8 XP: Prácticas "core": El Juego de la Planificación:... Piezas: La pieza de juego básica es la Historia de Usuario. Cada Historia es escrita en una Tarjeta de Índice. Las Historias tiene un valor y un costo,... Meta: La meta del juego es poner el valor mas grande posible de historias en producción durante la vida del juego Jugadores: Los jugadores son el Negocio (el Cliente) y el Desarrollo (el Desarrollador). Movimientos: Escribir Historias, Estimar Historias, Hacer compromisos,..., Cambiar valor,..., Dividir historias, XP: Prácticas "core": El Juego de la Planificación: Movimientos: (1/?) Escribir Historias: Estimar Historias Hacer Compromisos Compromisos Conducidos por Historias Compromisos Conducidos por Fechas Valor y Riesgo Primero En Primer Lugar Valor y Riesgo Recuperación del Sobre Compromiso Cambiar Valor Introducir Nueva Historia Dividir Historias Spike Volver a estimar 44 XP: Prácticas "core": El Juego de la Planificación: Movimientos: (2/?) Escribir Historias: el Cliente (el Negocio) puede escribir una historia nueva en cualquier momento. al escribir una Historia se le asigna un valor la Historia tiene que tener información suficiente para que el Desarrollador le asigne un costo. 45 XP: Prácticas "core": El Juego de la Planificación: Movimientos: (2/?) Estimar Historias: el Desarrollador (el Desarrollo) toma cada historia y le estima (le asigna) un costo de 1, 2, ó 3 semanas de Tiempo de Programación Ideal. este tiempo de desarrollo ideal es cuanto tiempo tomaría implementar la historia en código si no hubiera distracciones, ni otras asignaciones, y se conoce exactamente que hacer. Si la estimación es más de 3 semanas, el Cliente (el Negocio) divide la historia. Si la estimación es menos de 1 semana, el Negocio lo combina con otra historia. significa que se está en un nivel demasiado detallado. alrededor de 0 historias de usuario +/- 20 es un número perfecto para crear un plan de release durante la planificación del release. XP: Prácticas "core": El Juego de la Planificación: Movimientos: (4/?) Hacer Compromisos: el Cliente (el Negocio) y el Desarrollador (el Desarrollo) trabajan juntos para decidir que historias constituyen la siguiente versión y cuando estará listo para ponerlo en producción. Hay 2 modos para manejar el compromiso, Conducido por Historias y Conducido por Fechas. Compromisos Conducidos por Historias El Negocio comienza poniendo las Historias para la siguiente versión sobre la mesa. A medida que cada Historia se introduce, el Desarrollo calcula y anuncia la fecha de entrega. Este movimiento se detiene cuando el Negocio esta convencido que las Historias sobre la mesa tienen sentido como la siguiente versión. XP: Prácticas "core": El Juego de la Planificación: Movimientos: (5/?) Compromisos Conducidos por Fechas el Negocio escoge una fecha de entrega. el Desarrollo calcula y anuncia el costo acumulado de Historias que pueden cumplir entre ahora y la fecha. el Negocio escoge las Historias cuyo costos suman hasta ese número. Valor y Riesgo Primero En Primer Lugar el Valor y el Riesgo el Desarrollador (el Desarrollo) ordena las Historias de un compromiso así: un sistema que completamente trabaja pero muy básico se ha de completar inmediatamente (como en un par de semanas) las Historias más valiosas se trasladan al principio en el cronograma (el Valor del Negocio Primero) las Historias más riesgosas se trasladan al principio en el cronograma (Las Peores Cosas Primero)

9 XP: Prácticas "core": El Juego de la Planificación: Movimientos: (6/?) Recuperación del Sobre Compromiso: por ejemplo, el Desarrollo había predicho que podían hacer 150 unidades de historias entre ahora y la fecha límite. Basados en la medición de la Velocidad del Proyecto, encuentran e inmediatamente anuncian que pueden solo hacer 100. el Negocio selecciona las100 unidades de Historias a continuar, aplazando las otras Historias para una versión futura (ó altamente improbable, el Negocio decide aplazar la fecha límite para obtener el extra de 50 unidades hechas). Cambiar Valor: el Cliente (el Negocio) cambia el valor de una Historia en respuesta, el Desarrollador (el Desarrollo) puede cambiar el orden de las Historias todavía no completadas. XP: Prácticas "core": El Juego de la Planificación: Movimientos: (7/?) Introducir Nueva Historia: el Cliente (el Negocio) escribe una nueva Historia. el Desarrollador (el Desarrollo) lo estima. el Cliente (el Negocio) difiere las Historias en el actual Compromiso cuyo costo acumulado es el costo de la nueva Historia. el Desarrollador (el Desarrollo) reevalúa el Valor y el Riesgo Primero Dividir Historias: el Cliente (el Negocio) divide una Historia en 2 ó mas. el Cliente (el Negocio) asigna un valor a c/u, y el Desarrollador (el Desarrollo) asigna un costo a c/u. típicamente esto es hecho porque los recursos no permiten que la historia total sea hecha lo suficientemente pronto XP: Prácticas "core": El Juego de la Planificación: Movimientos: (/?) Spike: el Negocio puede de desviar recursos del Proyecto para hacer un Spike desechable para "combatir un incendio" ó probar un concepto. si este Spike es algo más que un arreglo temporal, el Negocio hace una Historia de Usuario para dar cuenta de ello. Esa Historia se cronograma conforme al Valor y al Riesgo primero. Spikes regulares, especialmente los que "combaten incendios", afectarán el Factor de Carga. Volver-a-estimar: el Desarrollo estima las historias restantes en el Compromiso nuevamente. esto puede provocar una Recuperación del Sobre-compromiso XP: Prácticas "core": El Juego de la Planificación: XP: Modelos Modelo basado en historias: Las Historias generan código fuente Historias class... class... class... Código Fuente Refactorización: El código fuente es transformado conforme a las reglas de refactorización (transformación del programa). XP: Historias de Usuario Son escenarios ó casos de uso de alto nivel que comprenden un conjunto de características coherentes. (existe una discusión respecto a este tema) Las Historias de Usuario son escritas por los clientes como cosas que el sistema necesita hacer para ellos. Están en el formato de unas 3 frases de texto escritas por el cliente en la terminología de los clientes sin sintaxis técnica. Las historias de usuario también conducen la creación de los tests de aceptación

10 XP: Historias de Usuario Una Historia de Usuario describe funciones que un usuario desearía tener en el software. Las Historias de Usuario describen características que son de valor para el usuario. Las Historias de Usuario trabajan mejor si los usuarios las escriben. Ellos conocen el lenguaje del negocio. Cuando la técnica de la historia de usuario fue desarrollada, cada historia era escrita en una tarjeta, así fueron llamadas tarjetas de historias. XP: Historia de Usuario: Ejemplos Aplicación de Planificación Financiera: Listado 1: Un usuario agrega un nuevo presupuesto al sistema para comenzar la planificación financiera El requerimiento es que un usuario tienen que poder agregar un nuevo presupuesto al sistema. Esta historia plantea algunas cuestiones, tales como; El usuario tiene que haber iniciado sesión? Qué valores son almacenados acerca del presupuesto? El título? Plazo de ejecución? Nombres de personas? Quién es el responsable del presupuesto? XP: Historia de Usuario: Ejemplos Aplicación de Planificación Financiera: Listado 2: Pruebas para la historia de usuario Añadir un nuevo presupuesto con el título "Presupuesto para el 2011" Añadir un nuevo presupuesto con la persona responsable "Juan Pérez" Añadir un nuevo presupuesto con el título vacío Añadir un nuevo presupuesto con un título realmente largo Según se vaya a través de los requerimientos con el cliente, se comienza a formar una lista de requerimientos. Para el caso de Scrum, la lista puede ser tratada como el backlog del producto, que tiene que ser priorizada y luego dividida en sprints XP: Historia de Usuario Las Historias de Usuario son frases que expresan los requerimientos del cliente. Las historias de usuario se enfocan en lo que el cliente necesita; no especifican los detalles de la implementación La siguiente estructura es un buen marco de trabajo para escribir historias de usuario: Como un <tipo ó rol de usuario> (el quien) Yo deseo <ejecutar/llevar a cabo alguna tarea> (el que) A fin de/de modo que Yo pueda <alcanzar alguna meta> (el porque) XP: Historia de Usuario Figura: Una épica descompuesta en múltiples historias de usuario. Épicas: son historias de usuario que hablan acerca de características ó funcionalidades pero en un alto nivel. XP: Historia de Usuario Ejemplo: Herramienta de Planificación Financiera basada en Web: Historias iniciales: Como un líder del equipo Yo deseo: Registrarme en el sistema para comenzar la planificación financiera para mi compañía Administrar las personas que pueden editar nuestros planes financieros Actualizar nuestra subscripción para obtener más funciones. Como un usuario Yo deseo: Mantener mis planes financieros Modificar la estructura (grupos y filas) de mi plan financiero Ingresar y modificar los datos en mis planes financieros Ejecutar reportes de mis datos para analizar los datos financieros

11 XP: Historia de Usuario Ejemplo: Herramienta de Planificación Financiera basada en Web: Historias iniciales: Como un administrador del sistema Yo deseo: Ver la estadísticas del sistema Ejecutar reportes para nuestra oficina de contabilidad El propietario del producto (es decir el negocio) prioriza la lista conforme a su punto de vista. XP: Historia de Usuario Discusión: Como un líder del equipo Yo deseo registrarme en el sistema para comenzar la planificación financiera para mi compañía, para gestionar las personas que pueden editar nuestros planes financieros,...: Con el fin de guardar los datos de usuario y luego volver a ella, el sistema tiene que reconocer el usuario, por lo que el registro en el sistema, es necesario. El usuario puede agregar más usuarios que acceden a los datos de la empresa, así la persona a quien se registra se le da un rol. Durante el registro, el usuario debería ingresar sólo los datos necesarios, tales como nombre, , la contraseña, y posiblemente el país. Toda la otra información del usuario debería manejarse usando las preferencias del usuario después en la aplicación.... XP: Historia de Usuario Discusión: Como un usuario Yo deseo mantener mis planes financieros,...: Puede haber más de 1 versión de mi presupuesto, ó el presupuesto puede consistir de varios presupuestos (por ejemplo, uno para cada línea de producto). Cuando los usuarios crean un nuevo presupuesto, deberían ser capaces de copiar un presupuesto existente para usarlo como base para el nuevo XP: Historia de Usuario XP: Historia de Usuario XP: Historia de Usuario Muestras de un website de viajes: Tarjeta de Historia de Usuario para descargar un documento: Otra forma de tarjeta de historia: está en uso? Historia de Usuario Número: 1 Usuario: Autor Nombre: Enviar artículo Modificación de Historia Nº: Prioridad en Negocio: Alta (Alta / Media / Baja) Iteración Asignada: 2 Puntos Estimados: Riesgo en Desarrollo: Puntos Reales: (Alto / Medio / Bajo) Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, , afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Observaciones:

12 XP: Velocidad del Proyecto La velocidad del proyecto es una medida de cuanto trabajo se está realizando en su proyecto. Para medir la velocidad del proyecto simplemente se suman las estimaciones de las historias de usuario que se terminaron durante la iteración. También se totalizan las estimaciones para las tareas terminadas durante la iteración. Ambas mediciones se utilizan para la planificación de la iteración. XP: Velocidad del Proyecto Durante la Reunión de Planificación de la Iteración, se permite a los clientes elegir el mismo número de historias de usuario igual a la velocidad del proyecto medida en la iteración anterior. Estas historias son desglosadas en tareas técnicas y se permite al equipo inscribirse en el mismo número de tareas que sea igual a la velocidad del proyecto de la iteración anterior. XP: Iteración XP: Tarjetas CRC Utilizar las Tarjetas CRC (Clase, Responsabilidades, y Colaboraciones) para diseñar el sistema como un equipo. El valor más grande de las tarjetas CRC es permitir que las personas rompan con el modo procedural del pensamiento y más plenamente aprecien la tecnología de objetos. Las tarjetas CRC permiten al integro de los equipos de proyecto contribuir al diseño. A mas personas que pueden ayudar a diseñar el sistema mayor el número de buenas ideas incorporadas. XP: Tarjetas CRC Responsabilidades: Son los atributos y operaciones encapsuladas por la clase. Dicho de manera más simple es "cualquier cosa que la clase sabe ó hace" [Ambler]. XP: Tarjetas CRC Modelamiento CRC: El modelamiento CRC provee un medio simple para identificar y organizar las clases que son relevantes para los requerimientos del sistema ó del producto. Ambler describe el modelamiento CRC de la siguiente manera: Un modelo CRC en realidad es una colección de fichas (ó tarjetas de índice) estándar que representan clases. Las tarjetas se dividen en 3 secciones: a lo largo de la parte superior de la tarjeta se escribe el nombre de la clase. en el cuerpo de la tarjeta se listan las responsabilidades de la clase a la izquierda y las clases colaboradoras a la derecha

13 XP: Tarjetas CRC Modelamiento CRC: XP: Tarjetas CRC Otro ejemplo: XP: Tarjetas CRC Clase: Clase: Descripción: Clase: Descripción: Clase: PlanoPlanta Descripción: Responsabilidad: Descripción: Colaborador: Responsabilidad: Colaborador: Responsabilidad: Colaborador: Responsabilidad: Colaborador: define el nombre / tipo del plano de planta administra el posicionamiento del plano de planta escala ó ajusta el plano de planta para visualización incorpora paredes, puertas y ventanas Pared muestra posición de las cámaras de vídeo Cámara Clase: Buzón de Correo Descripción: Responsabilidad: administrar el código de acceso administrar los saludos administrar los mensajes nuevos y guardados Colaborador: Cola de Mensajes XP: Tareas de Programación El esfuerzo necesario para realizar las historias de usuario inicialmente se estima en términos de semanas ideales. Los desarrolladores luego descomponen cada historia de usuario en términos de tareas de desarrollo que son necesarios para realizar las características requeridas por la historia. Los desarrolladores estiman la duración de cada tarea en términos de días XP: Tareas de Programación Contexto: Una reunión de planificación de la iteración se llama al comienzo de cada iteración. se debe producir el plan de tareas de programación de esa iteración. Cada iteración es 1 a 3 semanas. Las Historias de Usuario son elegidas para esta iteración por el cliente del plan de release. se eligen primero las mas valiosas para el cliente. Los tests de aceptación fallidos a ser corregidos también son seleccionados. El cliente selecciona historias de usuario con estimados que totalizan hasta la velocidad del proyecto de la última iteración. XP: Tareas de Programación Las historias de usuario y las pruebas fallidas son desglosadas en tareas de programación. Las tareas se anotan en fichas ( tarjetas de índice) al igual que las historias de usuario. Mientras las historias de usuario están en el lenguaje del cliente, las tareas están en el lenguaje del desarrollador Las tareas duplicadas pueden ser retiradas Estas tarjetas de tareas serán el plan detallado para la iteración

14 XP: Tareas de Programación Cada tarea debería ser estimada como 1, 2, ó 3 días de programación ideal (agregar ½ día si es necesario). Los días de programación ideal son cuanto tiempo le tomaría completar la tarea si no hubiera distracciones. Las tareas que son más cortas que 1 día se pueden agrupar juntas. Las tareas que son mas largas que 3 días deberían ser desglosadas aún mas. XP: Tareas de Programación Tarjetas de tareas para descargar un documento: XP: Organización del Equipo El código de producción es escrito en pares (programación en parejas) La persona que tipea se llama el conductor. La persona que revisa el código se llama el observador ó navegador Los desarrolladores individuales pueden escribir prototipos para experimentos ó prueba de conceptos, pero no código de producción. Las parejas son rotadas con frecuencia para permitir una mejor distribución del conocimiento a lo largo del proyecto. Los 2 programadores conmutan los roles con frecuencia, posiblemente cada 30 minutos XP: La Programación Conducida por Pruebas Codificar primero la Prueba de Unidad Ninguna entrega antes que todas las pruebas de unidad pasen Escribir una prueba de unidad por cada bug descubierto, Integrar un par (ó pareja) a la vez. XP: La Programación Conducida por Pruebas Pruebas de Unidad: Son una de las piedras angulares de XP. Se necesita un framework de pruebas unidad se debe crearlo ó descargarlo Se deben testear todas las clases del sistema. Las pruebas de unidad son entregados dentro del depositario de código junto con el código que ellas prueban. Código sin las pruebas no puede ser entregado. Si se descubre que una prueba de unidad falta tiene que ser creada en ese momento. Las pruebas de unidad también permiten la propiedad colectiva y la refactorización. XP: La Programación Conducida por Pruebas Frameworks de Pruebas de Unidad: xunit JUnit estándar para probar unidades en Java AS2Unit Framework de Pruebas de Unidad para Action Script 2 CFUnit Pruebas de Unidad de ColdFusion NUnit Lenguajes.Net PyUnit Pyton Revisar el siguiente enlace:

15 XP: Pruebas Descripción de un caso de prueba: XP: Pruebas Pruebas de Aceptación: Son creadas a partir de las historias de usuario. Durante una iteración las historias de usuario seleccionadas durante la reunión de planificación de la iteración se traducirán en pruebas de aceptación. El cliente especifica los escenarios a probar cuando una historia de usuario ha sido correctamente implementada. Una historia puede tener 1 ó muchas pruebas de aceptación. Son pruebas de caja negra del sistema. Cada test de aceptación representa algún resultado esperado del sistema. Los clientes son responsables de verificar la exactitud de las pruebas de aceptación y revisar los resultados de la prueba para decidir que test fallidos son los de la mas alta prioridad XP: Pruebas Pruebas de Aceptación: También son usados como pruebas de regresión previo a la versión de producción. Una historia de usuario no se considera completa hasta que ha pasado sus pruebas de aceptación. Esto significa que nuevas pruebas de aceptación tienen que ser creadas en cada iteración ó el equipo de desarrollo reportará progreso cero. El resultado de la prueba de aceptación es dado a conocer al equipo XP: El Proyecto XP: Resumen XP: Resumen Planificación: Historias de Usuario: Son escritas por los clientes. Conducen la creación de los Tests de Aceptación. Los desarrolladores estiman cuanto tiempo las historias podrían tomar para implementarse. cada historia obtendrá una estimación de 1,2, ó 3 semanas en "tiempo de desarrollo ideal". Alrededor de 0 +/- 20 historias de usuario es un número perfecto para crear un Plan de Versión durante la Reunión de Planificación de la Versión. Reunión de Planificación de la Versión: Se crea el Plan de la Versión. este plan se usa luego para crear el Plan de Iteración para cada iteración individual. Plan de la Versión: Especifica que historias de usuario van a ser implementadas para cada versión del sistema y la fecha de entrega de esa versión. Recomendación: Dividir el cronograma de desarrollo en mas ó menos una docena de iteraciones de 1 a 3 semanas de duración

16 XP: Resumen XP: Resumen XP: Resumen: Planificación de la versión Iteración: Cada iteración es 1 a 3 semanas de duración. elección recomendada: 1 semana Al comienzo de cada iteración se llama a una Reunión de Planificación de la Iteración. 91 Reunión de Planificación de la Iteración: Se escogen: las historias de usuario elegidas por el cliente del Plan de la Versión. los Tests de Aceptación fallidos, estimaciones hu VP sh hu = historias de usuario, sh = semanas de historia Las Historias de Usuario y las Pruebas de Aceptación fallidas a su vez se dividen en Tareas de Programación. Tareas de Programación: Se estiman en 1, 2, ó 3 días de "días de programación ideal" (+ ½ día si fuera necesario), estimaciones tp VP dt tp = tareas de programación, dt = días de tarea 92 Historias de Usuario Iteración 1 Iteración 2 Iteración N Última Iteración 1 a 3 días 1 a 3 semanas entrega <= 3/? meses 93 se toma en cuenta la Velocidad del Proyecto (VP) versión Scrum: Scrum: Historia SCRUM 196: Hirotaka Takeuchi & Ikujiro Nonaka Enero Febrero 196 The New Product Development Game Harvard Business Review

17 Scrum: Historia Scrum: Scrum: Porqué? 1995: Jeff Sutherland y Ken Schwaber analizan los modelos del ciclo de vida del software existentes. Conclusión: no es adecuado para procesos empíricos, no predecibles y no repetibles. Propuesta de Scrum. Mejoramiento de Scrum por Mike Beedle Combinación de Scrum con la Programación Extrema (XP). 1996: Introducción de Scrum en OOPSLA. (OOPSLA = Object-Oriented Programming, Systems, Languages & Applications) 2001: Publicación de Agile Software Development with Scrum por Ken Schwaber & Mike Beedle. Los fundadores también son miembros de la Alianza Ágil que publicó el Manifiesto para el Desarrollo de Software Ágil. Definición (Rugby): Un Scrum es una manera de reiniciar el juego después de una interrupción. Los delanteros de cada lado se unen en una formación apretada y luchan para ganar posesión del balón cuando este se arroja en medio de ellos. Los métodos tradicionales son como las carreras de relevo (el trabajo se realiza de forma secuencial). Los métodos ágiles son como el rugby (el trabajo se realiza en paralelo) Scrum: Por que? No debería ser todo ó nada Scrum: Es un "marco-de-trabajo" para la gestión de proyectos Pertenece a la escuela de desarrollo "ágil" Específicamente no aborda los otros aspectos del desarrollo incluyendo las pruebas Pero generalmente es usado con técnicas de XP (extreme Programming) Scrum: en 2 palabras Scrum es un proceso ágil que permite enfocarse en entregar el valor de negocio más alto en el menor tiempo. Permite rápidamente y repetidamente inspeccionar software concreto en operación (cada 2 semanas a 1 mes). El negocio fija las prioridades. Los equipos se auto organizan para determinar la mejor manera de entregar las características de más alta prioridad. Cada 2 semanas a 1 mes cualquiera puede ver software real funcionando y decidir entregarlo como está ó seguir mejorándolo en otro sprint

18 Scrum: Scrum: El Marco-de-trabajo de Scrum en 30 segundos Scrum: Flujo meta del Sprint backlog del Producto backlog del Sprint 24 horas Sprint 2-4 semanas Incremento del producto potencialmente entregable El propietario del producto crea una lista de deseos priorizada llamada un backlog del producto. Durante la planificación del sprint, el equipo saca un trozo pequeño de la parte superior de esa lista de deseos, un backlog del sprint, y decide como implementar esas piezas. El equipo tiene una cierta cantidad de tiempo, un sprint, para completar su trabajo - usualmente 2 a 4 semanas - pero se reúne cada día para evaluar su progreso (scrum diario). En el camino, el Maestro Scrum mantiene al equipo enfocado en su meta. Al final del sprint, el trabajo debería ser potencialmente entregable, como cuando listo para: entregarlo a un cliente, ponerlo en un estante de la tienda, ó mostrarlo a un interesado. El sprint termina con una revisión del sprint y una retrospectiva. A medida que el siguiente sprint comienza, el equipo elige otro trozo del backlog del producto y comienza a trabajar de nuevo. El ciclo se repite hasta que suficientes ítems en el backlog del producto han sido completados, el presupuesto se agota, ó llega la fecha límite. Artefactos y Reuniones: Scrum: Características Equipos que se auto-organizan El producto progresa en una serie de "sprints" de 1 mes de duración. Los requerimientos son capturados como ítems en una lista de "backlog del producto". Ninguna práctica de ingeniería específica prescrita. Utiliza reglas generativas para crear un entorno ágil para la entrega de proyectos. 1 de los "procesos ágiles". Scrum: Elementos Sprints Marco de trabajo Roles Propietario del Producto, Maestro Scrum, Equipo Scrum Reuniones (Reunión de) Planificación del Sprint (Reunión) Scrum diaria (Reunión de) Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog (ó lista de pedidos acumulados) del producto Backlog (ó lista de pedidos acumulados) del Sprint Gráfica del trabajo-restante vs. tiempo (ó burn down chart) del Sprint Scrum: Sprints Un periodo fijo de tiempo (típicamente 30 días) para desarrollar un producto entregable Incluye: Diseño Codificación Pruebas (y) documentación Una vez iniciado, solo el equipo de scrum puede agregar ó quitar ítems en el Backlog del Sprint Se termina en forma anormal cuando la meta del Sprint ya no tiene sentido

19 Scrum: Sprints Los proyectos Scrum avanzan en una serie de "sprints". La duración típica es de 2-4 semanas ó un mes calendario como máximo. Una duración constante conduce a un mejor ritmo. El producto es: diseñado codificado y probado durante el sprint. 109 Scrum: Sprints Desarrollo Secuencial vs. Superpuesto: Requerimientos Diseño Código Pruebas Fuente: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 196. En lugar de hacer todo de una cosa a la vez......el equipo Scrum hace un poco de cada cosa todo el tiempo 110 Scrum: Sprint Sin cambios durante un sprint: Planificar la duración del sprint en torno a cuanto tiempo Ud. puede comprometerse a mantener el cambio fuera del sprint. Cambio 111 Scrum: Framework (Marco de trabajo) Roles Propietario del producto Maestro Scrum El equipo Reuniones Planificación del Sprint Reunión scrum diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog del producto Backlog del sprint Gráficas burn down 112 Scrum: Roles Roles Propietario del producto Maestro Scrum El equipo Reuniones Planificación del Sprint Reunión scrum diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog del producto Backlog del sprint Gráficas burn down 113 Scrum: Roles: Propietario del Producto Propietario del Producto: Responsable de comunicar la meta Establece el cronograma de desarrollo dando prioridad al backlog (ó cartera de pedidos) 1 persona en este rol asegura que solo 1 conjunto de requerimientos conduce el desarrollo Puede ser influenciado por comisiones, gerencia, clientes, personal de ventas, pero es la única persona que prioriza Trabaja con otros para estimar los ítems en el Backlog del Producto Elimina confusión de múltiples jefes, opiniones diferentes, e interferencia Gerente de Productos, CTO/CEO, u otro interesado de alto-nivel

20 Scrum: Roles: Propietario del producto Propietario del producto: Define las características del producto. Decide sobre la fecha de publicación y el contenido. Es responsable por la rentabilidad del producto (ROI) Prioriza las características de acuerdo al valor de mercado Ajusta las características y la prioridad de cada iteración, según sea necesario Acepta ó rechaza los resultados del trabajo. Scrum: Roles: Maestro Scrum Maestro Scrum: responsable por el éxito de Scrum representa a la administración en el proyecto protege al equipo se resiste a agregar nuevas características remueve los obstáculos establece las prácticas y las reglas asegura que todos jueguen con las reglas asegura que las inspecciones de código sucedan se encarga de las reuniones de Scrum diarias Scrum: Roles: Maestro Scrum El Maestro Scrum: Representa a la gestión en el proyecto. Responsable de representar los valores y prácticas de Scrum Remueve los impedimentos Asegura que el equipo es totalmente funcional y productivo. Permite cooperación estrecha entre todos los roles y funciones. Protege al equipo de interferencias externas Scrum: Roles: Equipo Scrum Equipo Scrum: auto-organizado interdisciplinario sin roles todos los miembros llevan a cabo todas las funciones (análisis, diseño, pruebas, documentación) 7 ± 2 comprometido autorizado para hacer lo que sea necesario para cumplir con el compromiso permanece enfocado en la tarea asignada prueba completamente su código propio solicita ayuda cuando "barricadas" son encontradas refactoriza el código Log de tiempo cada día, incluyendo tiempo estimado restante para completar cada tarea comprueba en su propio código diariamente, ó con más frecuencia. 11 Scrum: Roles: El Equipo El Equipo: Típicamente 5-9 personas Interdisciplinario: Programadores, probadores, diseñadores de la experiencia del usuario, etc. Miembros deberían ser a tiempo completo Puede haber excepciones (e.g. administrador de base de datos) Los equipos se auto-organizan Idealmente, sin títulos pero en contadas veces una posibilidad. Membresía debería cambiar solo entre sprints. 119 Scrum: Roles: Miscelánea Pollos y Cerdos: Los Cerdos están comprometidos a entregar la Meta del Sprint: Propietario del Producto Maestro Scrum (Facilitador) El equipo 120 Los Pollos están involucrados pero no comprometidos: Interesados (clientes, vendedores,...) Gerentes asisten a las reuniones Scrum como observadores pueden también "consultar" (proveer información y asesoramiento) 20

21 Scrum: Reuniones Scrum: Reuniones Scrum: Reuniones: Planificación del Sprint Roles Propietario del producto Maestro Scrum El equipo Reuniones Planificación del Sprint Reunión scrum diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog del producto Backlog del sprint Gráficas burn down Capacidad del equipo Backlog del producto Condiciones del Negocio Producto actual Tecnología Reunión de planificación del Sprint Priorización del Sprint Analizar y evaluar backlog del producto Seleccionar meta del sprint Planificación del Sprint Decidir como lograr la meta del sprint (diseño) Crear backlog del sprint (tareas) a partir de los ítems del backlog del producto (historias de usuario / características) Estimar backlog del sprint en horas Meta del Sprint Backlog del Sprint Planificación del Sprint: El equipo selecciona los ítems del backlog del producto que ellos pueden comprometerse a completar. Se crea el backlog del sprint: Las tareas se identifican y se estima c/u (1-16 horas) En colaboración, no es hecho solo por el Maestro Scrum Diseño de alto-nivel es considerado Como un un planificador de vacaciones, Yo deseo ver las fotos de los hoteles. Codificar el nivel intermedio ( horas) Codificar la interfase de usuario (4) Escribir las partes integrantes del test (4) Codificar la clase foo (6) Actualizar los tests de rendimiento (4) Scrum: Reuniones: Planificación del Sprint Planificación del Sprint: (1/3) Con la asistencia de los clientes, usuarios, la gerencia, el Propietario del Producto, el equipo Scrum En realidad 2 reuniones consecutivas: 1. Establecer las metas 2. Planificar las tareas. Crear la lista de backlog del sprint Scrum: Reuniones: Planificación del Sprint Planificación del Sprint: (2/3) Agenda: Duración de la reunión: limitado, posiblemente hasta un día Revisar el Backlog del Producto Seleccionar un Meta alcanzable del Sprint con el Propietario del Producto Determinar cual podría ser el número de características que su equipo puede completar Pensar acerca de las asignaciones iniciales Elaborar un Backlog del Sprint en la hoja de trabajo del equipo Scrum: Reuniones : Planificación del Sprint Planificación del Sprint: (3/3) Reunión para fijar la próxima meta del Sprint Backlog del Producto Capacidades del Equipo Condiciones del Negocio Estabilidad de la Tecnología Incremento del Producto Ejecutable Revisar Considerar Organizar Próxima Meta del Sprint Backlog del Sprint

22 Scrum: Reuniones: Scrum diario Scrum: Reuniones: Scrum diario Scrum: Reuniones: Scrum diario El scrum diario: Parámetros Diario 15 minutos de a pie No para resolver problemas Todo el mundo es invitado Solo los miembros del equipo, el Maestro Scrum, el propietario del producto, pueden hablar Ayuda a evitar otras reuniones innecesarias Todo el mundo responde 3 preguntas: Qué hiciste ayer? Qué harás hoy? 3 Hay obstáculos en tu camino? Estas no son del reporte de estado para el Maestro Scrum Son compromisos en frente de los pares 1 2 Scrum diario: Reunión diaria de 15 minutos del status (timeboxed) El equipo decide castigos por las tardanzas (e.g. dinero, lagartijas, colgar el pollo de goma alrededor del cuello,...) La misma hora y lugar cada día El equipo se encuentra en circulo enfrentándose el uno al otro Todos son bienvenidos, pero solo los "pigs" pueden hablar Cada miembro del equipo responde 3 preguntas: Qué ha hecho Ud. desde el último Scrum? Qué hará Ud. entre ahora y el siguiente Scrum? Qué entorpece su forma de hacer el trabajo? Para la sincronización no para la resolución de problemas! Scrum: Reuniones: Revisión del Sprint Scrum: Reuniones: Revisión del Sprint Scrum: Reuniones: Retrospectiva del Sprint La revisión del Sprint: El equipo presenta lo que logró durante el Sprint Típicamente toma la forma de un demo de características nuevas ó de la arquitectura subyacente. Informal Regla de tiempo de 2 horas de preparación Sin slides El equipo completo participa Se invita a todo el mundo Revisión del Sprint: Celebrada al final de cada ciclo de Sprint Durante esta reunión el equipo presenta a la gestión, los clientes, los usuarios y el Propietario del Producto el incremento del producto que ha sido construido durante el Sprint El equipo cuenta la historia de su travesía durante el Sprint Presentar el trabajo completo a los interesados (a.k.a. "el demo") Trabajo incompleto no puede ser demostrado Presentaciones en PowerPoint son prohibidas! Límite de tiempo de 4 horas. Retrospectiva del sprint: Periódicamente echar una vistazo a lo que está y a lo que no está funcionando. Típicamente minutos Hecho después de cada sprint El equipo completo participa Maestro Scrum Propietario del producto El equipo Posiblemente clientes y otros

23 Scrum: Reuniones: Retrospectiva del Sprint Celebrada al final de cada ciclo de sprint Todos los miembros del equipo y el Propietario del Producto (PO) (ningún invitado no invitado) Todos hablan Reflexionan sobre el sprint pasado Buscan sugerencias concretas para mejorar el proceso 2 cuestiones principales: Qué estuvo bien? Qué puede ser mejorado en el siguiente sprint? Límite de tiempo de 3 horas. Scrum: Reuniones: Retrospectiva del Sprint Comenzar / Parar / Continuar: El equipo completo se reúne y analiza lo que les gustaría. Empezar a hacer Esta es solo una de las muchas maneras de hacer una retrospectiva del sprint. Dejar de hacer Continuar haciendo Scrum: Artefactos Roles Propietario del producto Maestro Scrum El equipo Reuniones Planificación del Sprint Reunión scrum diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog del producto Backlog del sprint Gráficas burn down Scrum: Artefactos: Backlog del Producto Scrum: Artefactos: Scrum: Artefactos: Backlog del Producto Este es el backlog del producto Son los requerimientos Una lista de todo el trabajo deseado en el proyecto Expresado idealmente tal que cada ítem tiene valor para los usuarios ó clientes del producto. Priorizado por el propietario del producto Repriorizado al inicio de cada sprint. Backlog del Producto: Lista priorizada del trabajo a ser realizado sobre un producto e.g. características requeridas, ítems de la "lista de deseos" Cualquiera puede contribuir con los ítems del backlog El Propietario del Producto es responsable por la priorización, se basa en el valor de negocio Los miembros del equipo son responsables por estimar el esfuerzo de desarrollo Típicamente mantenido como una hoja electrónica Muestra: Ítem del backlog Permitir a un invitado hacer una reservación Como un invitado, Yo deseo cancelar una reservación. Como un invitado, Yo deseo cambiar las fechas de una reservación Como un empleado del hotel, Yo puedo ejecutar reportes RevPAR (ingresos por habitación disponible) Mejorar el manejo de excepciones Estimación