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

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

Programación Extrema. Ing. Sebastian Priolo

Programación Extrema. Ing. Sebastian Priolo Programación Extrema Ing. Sebastian Priolo Metodologías Ágiles Menos orientadas a los documentos. Orientadas al código. El cambio es bienvenido. Procesos que cambian NO son predictivos Son adaptables Ejemplos

Más detalles

Scrum. Helder Marques

Scrum. Helder Marques Scrum Helder Marques Gerencia de proyectos Es como el helado; viene en varios sabores ( Y muchas veces engorda ) Gerencia de proyectos Gerencia de proyectos Gerencia de proyectos Un poco de historia...

Más detalles

Ingeniería de Sistemas I

Ingeniería de Sistemas I Ingeniería de Sistemas I Metodologías Ágiles 1 Agenda Metodologías Ágiles, Origen Valores y Principios de las Metodologías Ágiles Ejemplos de Metodologías Ágiles SCRUM XP SCRUM y XP Agilidad o Disciplina?

Más detalles

Manifiesto Ágil: Historia

Manifiesto Ágil: Historia Agile Manifesto and agile principles andmanifestoagile Nombre del Paper: agileprinciples. Fecha de publicación: Febrero 2001 Publicación: www.agilemanifesto.org Autores: ( XP ) 1.Kent Beck ( XP 2.Mike

Más detalles

Universidad ORT Uruguay

Universidad ORT Uruguay Facultad de Ingeniería Metodología SCRUM Cátedra de Ingeniería de Software. Docente Responsable: Gastón Mousqués. Autor: Adriana Peralta 123357 2003 ÍNDICE GENERAL Introducción 2 Principales características

Más detalles

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles.

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Autor: Manuel Trigás Gallego Director de Proyecto: Ana Cristina Domingo Troncho Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Qué es un

Más detalles

Introducción a las Metodologías Ágiles. Introducción a Scrum. Roles Ceremonias Artefactos Métricas

Introducción a las Metodologías Ágiles. Introducción a Scrum. Roles Ceremonias Artefactos Métricas Introducción a las Metodologías Ágiles Introducción a Scrum Roles Ceremonias Artefactos Métricas Mauricio Silclir Ingeniero en Sistemas de Información (UTN FRC) Scrum Master del Centro de Desarrollo de

Más detalles

Scrum. una descripción. Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013

Scrum. una descripción. Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013 Scrum una descripción Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013 v 2012.12.13 2012 Scrum Alliance, Inc. 1 Scrum Principios de Scrum Valores del Manifiesto Ágil

Más detalles

Ingeniería de Software II Primer Cuatrimestre de 2008

Ingeniería de Software II Primer Cuatrimestre de 2008 Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 14: Introducción a Scrum Buenos Aires, 12 de Mayo de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento (formación fija) en Rugby.

Más detalles

Introducción a la implementación de Scrum

Introducción a la implementación de Scrum Introducción a la implementación de Scrum Jorge Iván Meza Martínez http://www.jorgeivanmeza.com/ Jorge Iván Meza Martínez - 1 Contenido Introducción. Historia. Qué es un proyecto. Gestión

Más detalles

The Agile Manifesto. Que es el Manifiesto Ágil?

The Agile Manifesto. Que es el Manifiesto Ágil? Que es el Manifiesto Ágil? Lista de principios y valores Declaración de conceptos que guían el desarrollo de software Creado en Febrero del 2001 por la alianza ágil. 17 personas representantes de: Extreme

Más detalles

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Desarrollo Ágil Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Coordinación de Ciencias Computacionales INAOE 2011 Preguntas

Más detalles

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

Más detalles

Ingeniería de Software II Segundo Cuatrimestre de 2008

Ingeniería de Software II Segundo Cuatrimestre de 2008 Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 14: Introducción a los métodos ágiles y Scrum Buenos Aires, 9 de Octubre de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento

Más detalles

Qué esperan aprender en esta clase?

Qué esperan aprender en esta clase? Diego Rubio Álvaro Ruiz de Mendarozqueta Natalia Andriano Juan Pablo Bruno Mauricio Silclir Cuál es su experiencia con las metodologías ágiles? Qué esperan aprender en esta clase? 1 Cómo que métricas?

Más detalles

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review) 1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum

Más detalles

SCRUM. Gestión ágil de proyectos

SCRUM. Gestión ágil de proyectos SCRUM Gestión ágil de proyectos 1 Qué es Scrum? SCRUM es una metodología ágil utilizada en el desarrollo de proyectos de software y que permite obtener el mejor resultado posible en la gestión de un proyecto

Más detalles

FORMULACION DE CRITERIOS PARA LA SELECCION DE METODOLOGIAS DE DESARROLLO DE SOFTWARE LEONARDO FLOREZ MARIN FELIPE GRISALES TOBON

FORMULACION DE CRITERIOS PARA LA SELECCION DE METODOLOGIAS DE DESARROLLO DE SOFTWARE LEONARDO FLOREZ MARIN FELIPE GRISALES TOBON FORMULACION DE CRITERIOS PARA LA SELECCION DE METODOLOGIAS DE DESARROLLO DE SOFTWARE LEONARDO FLOREZ MARIN FELIPE GRISALES TOBON UNIVERSIDAD TECNOLOGICA DE PEREIRA FACULTAD DE INGENIERIAS INGENIERIA EN

Más detalles

Febrero 2010. Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland

Febrero 2010. Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland Febrero 2010 Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland Agradecimientos General Scrum se basa en buenas prácticas aceptadas por la industria, usadas y probadas durante décadas.

Más detalles

MODELO DE CONSTRUCCIÓN DE PROTOTIPO

MODELO DE CONSTRUCCIÓN DE PROTOTIPO El modelo de proceso en la ingeniería de software incluye un conjunto de actividades estructurales, acciones y tareas de trabajo. Los modelos de procesos dan a conocer el flujo de proceso descriptivo y

Más detalles

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 DATOS IDENTIFICATIVOS: 1. Título del Proyecto Herramienta para el Desarrollo de Aplicaciones Software con Metodologías

Más detalles

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

Más detalles

Una Introducción a Scrum

Una Introducción a Scrum Una Introducción a Scrum Ernesto Grafeuille Noviembre 2008 Estamos perdiendo la carrera de relevos En enfoque de carrera de relevos en el desarrollo de productos... puede entrar en conflicto con los objetivos

Más detalles

DES. Fundamento Institucional. Objetivos. Alcance

DES. Fundamento Institucional. Objetivos. Alcance DES INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de DESARROLLO en el ciclo de vida del software en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Octubre de 2011 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 3 Visión general

Más detalles

XP- EXTREME PROGRAMMING

XP- EXTREME PROGRAMMING XP- EXTREME PROGRAMMING RUBBY CASALLAS DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN FACULTAD DE INGENIERÍA UNIVERSIDAD DE LOS ANDES Agenda Qué es XP? 12 Prácticas Actividades Principales: Planeación Diseño Codificación

Más detalles

Prototipado Ágil. Mateu Batle Sastre

Prototipado Ágil. Mateu Batle Sastre Prototipado Ágil Mateu Batle Sastre Uso informativo y confidencial Prototipado Ágil Prototipos Metodologías ágiles Metodología Scrum Definición de prototipo Ejemplar original o primer molde en que se fabrica

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Julio de 2013 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 4 Visión general

Más detalles

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM Por Jesus Demetrio Velázquez Camacho Dentro de las organizaciones de desarrollo de aplicaciones existen dos grandes corrientes para la metodología

Más detalles

Metodologías Ágiles: Scrum y técnicas de estimación ágil

Metodologías Ágiles: Scrum y técnicas de estimación ágil Metodologías Ágiles: Scrum y técnicas de estimación ágil PreparaTIC - Junio 2009 Jorge Manrubia Díez jorge.manrubia@giss.seg-social.es Por qué? Hacer un programa es cómo... Can you get a design that is

Más detalles

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047 UNIVERSIDAD NACIONAL EXPERIMENTAL DE LOS LLANOS OCCIDENTALES EZEQUIEL ZAMORA Ingeniería en Informática Subproyecto: Metodología de Desarrollo del Software Semestre VII Bachilleres: Bustamante Dayana C.I:

Más detalles

Checklist para Scrum Masters

Checklist para Scrum Masters Fuente original : Michael James (mj4scrum@gmail.com). http://www.colabpro.com 14 September 2007 (Revised 24 July 2012) Traducción : José Vázquez Sánchez. (a113779@gmail.com) http://www.gestiondeproyectosit.es

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

Miguel Torres Jaime Pavlich-Mariscal

Miguel Torres Jaime Pavlich-Mariscal Miguel Torres Jaime Pavlich-Mariscal Implementar algunos requerimientos feedback Implementar algunos requerimientos feedback Implementar algunos requerimientos Iteración de 2-6 semanas Entrega al cliente

Más detalles

Gestión de proyectos ágil: conceptos básicos

Gestión de proyectos ágil: conceptos básicos Gestión de proyectos ágil: conceptos básicos NST-0003 Rev. 0.1 http://www.navegapolis.net Juan Palacio, 2006 Gestión de proyectos clásica Introducción Los entornos de negocio de muchos sectores han experimentado

Más detalles

Gestión de Equipos de Desarrollo. Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress.

Gestión de Equipos de Desarrollo. Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress. Gestión de Equipos de Desarrollo Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress.com Contexto Metodologías agiles de desarrollo de Software y como las usamos

Más detalles

Certified Scrum Developer (CSD), Módulo 3 y Track Completo

Certified Scrum Developer (CSD), Módulo 3 y Track Completo Certified Scrum Developer (CSD), Módulo 3 y Track Completo Surgida en 2009, la certificación CSD es la última novedad en certificaciones oficiales de la Scrum Alliance a través de la cual los equipos de

Más detalles

Scrum Manager Gestión de proyectos

Scrum Manager Gestión de proyectos Scrum Manager Gestión de proyectos INTRODUCCIÓN Caos Procesos Agilidad cc-by **Maurice** LICENCIA DE USO Este es un recurso educativo abierto (OER) del proyecto Scrum Manager Los contenidos OER de ScrumManager

Más detalles

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Examen tipo EXIN Agile Scrum Foundation Edición Mayo 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Más detalles

El método Scrum. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. Ciclo diario Scrum. Ciclo mensual. Sprint

El método Scrum. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. Ciclo diario Scrum. Ciclo mensual. Sprint 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 54 (Management) El método Scrum crum es, actualmente, uno de los métodos S ágiles para desarrollo de software de mayor difusión en la industria, junto con

Más detalles

Guía Comparativa de Metodologías Ágiles

Guía Comparativa de Metodologías Ágiles Universidad de Valladolid E. U. de Informática (SEGOVIA) Grado en Ingeniería Informática de Servicios y Aplicaciones Guía Comparativa de Metodologías Ágiles Alumno: María José Pérez Pérez Tutor: Francisco

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum.

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum. La Guía Nexus La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum Desarrollado y mantenido por Ken Schwaber y Scrum.org Agosto 2015 Tabla de Contenido Información General de Nexus...

Más detalles

La incertidumbre y la ingeniería de software María Irma Díaz

La incertidumbre y la ingeniería de software María Irma Díaz d o s La incertidumbre y la ingeniería de software María Irma Díaz Una respuesta metodológica al desafío de modificar el pensamiento para enfrentar las condiciones del presente y el futuro. A comienzos

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013.

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. Aplicación de metodologías Ágiles en TI Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. 1 To Do En Proceso Done! Agile Scrum Intro Lean Kanban Aplicabilidad Cierre 2 To

Más detalles

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

Más detalles

Scrum Manager Curso de formación

Scrum Manager Curso de formación Scrum Manager Curso de formación SCRUM cc-by **Maurice** 1.0 LICENCIA DE USO Este es un recurso educativo abierto (OER) del proyecto Scrum Manager Los contenidos OER de ScrumManager se pueden emplear de

Más detalles

El modelo Scrum. NST-0010 Rev. 0.1

El modelo Scrum. NST-0010 Rev. 0.1 NST-0010 Rev. 0.1 http://www.navegapolis.net Juan Palacio, 2006 Scrum: La teoría El origen. Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados

Más detalles

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia

Más detalles

Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR

Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR Elaborado Por: Alejandro Arbeláez Acevedo Elaborado Para: Proyecto de Grado Versión: 1.0 Mayo, 2014 Confidencial Eafit UP. Versión

Más detalles

Scrum. Juan Palacio Bañeres

Scrum. Juan Palacio Bañeres Scrum Juan Palacio Bañeres La esencia de Scrum Al iniciar cada iteración, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará como un incremento de funcionalidad incorporado

Más detalles

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Proceso Unificado de Rational

Proceso Unificado de Rational RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original

Más detalles

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del

Más detalles

Trabajo Práctico Integrador

Trabajo Práctico Integrador Trabajo Práctico Integrador Objetivo: Relacionar los conceptos vistos durante la cursada bajo una actividad práctica en la que los alumnos puedan aplicar los conceptos a la luz de un contexto organizacional.

Más detalles

Introducción a las Metodologías Ágiles. Nicolás Brailovsky March 7, 2009

Introducción a las Metodologías Ágiles. Nicolás Brailovsky March 7, 2009 Universidad Tecnológica Nacional Facultad Regional Buenos Aires Diseño de Sistemas Introducción a las Metodologías Ágiles Nicolás Brailovsky March 7, 2009 1 Qué es una metodología? 2 Metodologías Ágiles

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Desarrollo Ágil Introducción a desarrollo ágil Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Agenda Continuación de Scrum Tarea Bibliografía SCRUM Master (Roles) Representa la administración

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Uso del Programa Gantt Project

Uso del Programa Gantt Project Uso del Programa Gantt Project 1 Presentación En esta práctica guiada aprenderás varias cosas relacionadas con el uso de Gantt Project, que es una aplicación de ayuda a la gestión de proyectos. En particular,

Más detalles

Scrum en breve. Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano

Scrum en breve. Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano Contenido Scrum en breve Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano El Equipo... 1 La Reserva de Pedidos... 3 El Lanzamiento, o Release... 4

Más detalles

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software.

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Rodolfo Meda (rodolfomeda@yahoo.com), Jorge Ierache (jierache@yahoo.com.ar).

Más detalles

SCRUM: Una revisión de la literatura

SCRUM: Una revisión de la literatura SCRUM: Una revisión de la literatura Gabriela Patricia Tomaselli; Cesar J. Acuña; Marcelo Estayno; Cintia Lenkovich Universidad Tecnológica Nacional, Facultad Regional Resistencia Abstract En la actualidad,

Más detalles

Programación Extrema

Programación Extrema Programación Extrema Índice 1. Qué es XP?...2 1.1. Metodología ágil... 2 1.2. Definición...2 1.3. Posturas a favor y en contra... 2 2. Historia...4 3. Principios básicos... 5 4. Proceso de desarrollo...

Más detalles

Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno. Dirección: María Consuelo Franky

Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno. Dirección: María Consuelo Franky Guía metodológica para la gestión de proyectos ágiles de software integrando herramientas de seguimiento de actividades, integración continua y repositorio distribuido de versiones. Autores: Mónica Fernanda

Más detalles

Adopción de la Gestión Lean Agile en Áreas de Sistemas en Organizaciones en México: Éxito o Fracaso

Adopción de la Gestión Lean Agile en Áreas de Sistemas en Organizaciones en México: Éxito o Fracaso Adopción de la Gestión Lean Agile en Áreas de Sistemas en Organizaciones en México: Éxito o Fracaso Derechos Reservados Esta presentación puede ser compartida siempre y cuando no se altere su contenido,

Más detalles

Introducción a Scrum

Introducción a Scrum Autentia & Agile Spain Introducción a Scrum Leo Antolí - lantoli@autentia.com Juan Gutierrez - juan.gutierrez@agilizar.es Agustín Yagüe - agustin.yague@upm.es Índice Metodologías ágiles Scrum Metodologías

Más detalles

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real.

Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Integración de Metodologías Ágiles en el Desarrollo de un Sistema de Monitoreo Inalámbrico para Medir la Contaminación del Aire en Tiempo Real. Walter Fuertes, Diego Carrera, César Villacís, Fernando Galárraga,

Más detalles

CRC y un Taller. Ing. Diego Vallespir.

CRC y un Taller. Ing. Diego Vallespir. CRC y un Taller Ing. Diego Vallespir. Presentado para llamado a Grado 1 del Instituto de Computación - Facultad de Ingeniería Universidad de la República. 26 de Junio de 2002, Montevideo Uruguay. Resumen

Más detalles

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Guillermo Watson Datalytics Stibenzon Cañas Sánchez Ceiba Software House Business Intelligence No es una tecnología ni un

Más detalles

Una meta un Equipo. www.cv-team.com es.group-sii.com @CVTeamSII #TalentoCVTeam #ExcelenciaTIC

Una meta un Equipo. www.cv-team.com es.group-sii.com @CVTeamSII #TalentoCVTeam #ExcelenciaTIC Una meta un Equipo Quiénes Somos Concatel Vanture Team - SII es una empresa especializada en servicios de Tecnologías de la Información y Comunicación (TIC) e Ingeniería para la gestión empresarial. Nuestra

Más detalles

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Universidad Rafael Landivar Campus Quetzaltenango Facultad de Ingeniería PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Linda Estrella Córdova Monterroso

Más detalles

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI MODELO Y HERRAMIENTA DE AUTOMATIZACIÓN PARA AGREGAR VALOR A LOS PRINCIPIOS ÁGILES DE DESARROLLO

Más detalles

Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil

Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil 05/04/2014 Ingeniería de Sistemas - PUJ Juan Darío Murcia

Más detalles

Desarrollo Ágil con SCRUM. Itzcoalt Alvarez M. Joiz.Net

Desarrollo Ágil con SCRUM. Itzcoalt Alvarez M. Joiz.Net Desarrollo Ágil con SCRUM Itzcoalt Alvarez M. Joiz.Net Objetivo Acercamiento a SCRUM, conocer sus ventajas y desventajas, así como su funcionamiento. 2 Agenda Antecedentes Como funciona SCRUM Roles y responsabilidades

Más detalles

MANUAL DEL SITIO WEB. Estamos facilitando aún más LA EXPERIENCIA ONLINE. de los clientes. Nuevas funcionalidades del sitio web y más opciones

MANUAL DEL SITIO WEB. Estamos facilitando aún más LA EXPERIENCIA ONLINE. de los clientes. Nuevas funcionalidades del sitio web y más opciones MANUAL DEL SITIO WEB 2014 Estamos facilitando aún más LA EXPERIENCIA ONLINE de los clientes Nuevas funcionalidades del sitio web y más opciones SOLO PARA USO INTERNO A Premier Farnell Company FY14_WEB_playbook

Más detalles

Tema 5. Gestión de Proyectos (ISG3)

Tema 5. Gestión de Proyectos (ISG3) Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 2.5 - España 1 Planificación 1ª Clase: Presentación y Conceptos Generales 2ª Clase:

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

3-2-8. Participantes

3-2-8. Participantes 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos: METODOLOGIAS AGILES Licenciatura en Informática 3-2-8 2.- HISTORIA DEL PROGRAMA

Más detalles

Bienvenido al tutorial de Campus Virtual para estudiantes.

Bienvenido al tutorial de Campus Virtual para estudiantes. Bienvenido al tutorial de Campus Virtual para estudiantes. Contenidos Cada uno de los siguientes temas, le introducirá un concepto diferente de la herramienta de aprendizaje Campus Virtual, y le permitirá

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

METODOLOGÍA TRADICIONAL.

METODOLOGÍA TRADICIONAL. COMPARACIÓN DE METODOLOGÍAS METODOLOGÍA TRADICIONAL. Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación

Más detalles

Sistemas de Programas Universidad Simón Bolívar

Sistemas de Programas Universidad Simón Bolívar Pruebas en sistemas orientados a objetos Sistemas de Programas Universidad Simón Bolívar Agenda 2 Introducción Qué es probar software? Por qué necesitamos probar el software? Terminología de Pruebas Black

Más detalles

Introducción a la asignatura MADS-1.0

Introducción a la asignatura MADS-1.0 Introducción a la asignatura MADS-1.0 Sesión 1 Datos de la asignatura Grado en Ingeniería Informática (4º curso) Especialidad: Ingeniería del Software Ficha de la asignatura Departamento de Ciencia de

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE. Mª Carmen Bartolomé. mcbartolome@qualityobjects.

DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE. Mª Carmen Bartolomé. mcbartolome@qualityobjects. DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE Mª Carmen Bartolomé mcbartolome@qualityobjects.com Índice Introducción a extreme Programming (XP) Herramientas OpenSource

Más detalles

ENERO NOTI LEITZ. soluciones a su alcance SCRUM. Feliz Año Nuevo. Tendencias Tecnología al Día

ENERO NOTI LEITZ. soluciones a su alcance SCRUM. Feliz Año Nuevo. Tendencias Tecnología al Día ENERO 2014 NOTI LEITZ soluciones a su alcance SCRUM Feliz Año Nuevo Tendencias Tecnología al Día 1 Grupo Leitz EMPLEADOS 25 Enero Feliz Día de la Mujer Hondureña LA ACTITUD POSITIVA SERA EL ARMA PARA INCIAR

Más detalles

Scrum. Marcos Bermejo PID_00177692

Scrum. Marcos Bermejo PID_00177692 Scrum Marcos Bermejo PID_00177692 CC-BY-NC-ND PID_00177692 Scrum Los textos e imágenes publicados en esta obra están sujetos excepto que se indique lo contrario a una licencia de Reconocimiento-NoComercial-SinObraDerivada

Más detalles

Proyecto de Desarrollo de una Base de Datos para un concesionario

Proyecto de Desarrollo de una Base de Datos para un concesionario Proyecto de Desarrollo de una Base de Datos para un concesionario Etienne Boshoff de Jong Enginyeria en Informàtica Juan Martinez Bolaños 14 enero 2013 Proyecto Final de Carrera: Base de Datos Page 1 1.

Más detalles

Construcción y Pruebas de Software

Construcción y Pruebas de Software UNIVERSIDAD DE CARABOBO Facultad Experimental de Ciencias y Tecnología Departamento de Computación Construcción y Pruebas de Software Elaborado por: Gustavo Bazán Francisco Rosas Bárbula, Junio de 2012

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Metodologías Iterativas de Desarrollo

Metodologías Iterativas de Desarrollo Metodologías Iterativas de Desarrollo Lic. Carlos Leone (MBA) Ing. Nicolás Passerini Ing. Gustavo A. Brey 2005 Agenda # Tema 1 Introducción a Metodologías de Desarrollo 2 Tipos de Metodología 3 Metodologías

Más detalles