Metodologia Scrum



Comments



Description

InstitutoTecnológico Nacional de México Instituto Tecnológico Nacional de México INSTITUTO TECNOLÓGICO SUPERIOR DE EL MANTE. Nombre de la Materia: GESTION DE PROYECTOS DE SOFTWARE Nombre del Alumno: Milka Isaura Sierra Reynoso. N°Control: 1201F0091 Semestre °7 Nombre del Docente: Ing. ADRIANA AVALOS ROBLES PORMETODOLOGIA SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente. Proceso y Roles de Scrum El proceso El desarrollo se realiza de forma iterativa e incremental. Cada iteración. En Scrum se realizan entregas parciales y regulares del producto final. en equipo. y obtener el mejor resultado posible de un proyecto. la competitividad. denominada Sprint. obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. Scrum también se utiliza para resolver situaciones como las siguientes:       No se está entregando al cliente lo que necesita. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Cuando las entregas se alargan demasiado. Por ello. Cuando la moral de los equipos es baja y la rotación alta. Scrum está especialmente indicado para proyectos en entornos complejos. se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio. donde se necesita obtener resultados pronto. Los costes se disparan o la calidad no es aceptable. . donde la innovación. Cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. donde los requisitos son cambiantes o poco definidos. la flexibilidad y la productividad son fundamentales. tiene una duración preestablecida de entre 2 y 4 semanas. Cuando se necesita capacidad de reacción ante la competencia. priorizadas por el beneficio que aportan al receptor del proyecto. En cada nuevo Sprint. Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint. en la retrospectiva. para  en una segunda parte de la reunión. Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint. en la que el equipo se sincroniza para trabajar de  forma coordinada. Product owner (PO): Representante de lso accionistas y clientes que usan el software. Traslada la visión del proyecto al equipo. Posteriormente. La gestión de un proyecto Scrum se centra en definir cuáles son las características que debe tener el producto a construir (qué construir. Roles En Scrum. Daily sprint meeting: Reunión diaria de cómo máximo 15 min. el equipo se focaliza en construir software de calidad. Herramientas Scrum . Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product   Backlog a las que se ha comprometido. Cada miembro comenta que hizo el día anterior. formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint. decidir y organizar cómo lo va a conseguir. en una nueva versión del software totalmente operativo. el equipo analiza qué se hizo bien. Sprint Planning: Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. que hará hoy y si hay impedimentos. Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI. o lo que es lo mismo. Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio. qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares. por retorno de inversión considerando su beneficio y  coste. qué no y en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. El equipo Scrum está formado por los siguientes roles: Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología. Permite gestionar las listas de tareas e historias de usuario. Permite añadir historias de usuario a la pila de producto. Kunagi: Herramienta Web que proporciona un sistema de gestión de proyectos basado en Scrum. Es una metodología que difiere del resto. Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son   importantes. Posee  gráficos de avance burndown en 3D. Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e   interferencias. Facilita en gran medida la planificación de Sprints y las reuniones. Ofrece las opciones de operación. es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Ventajas    Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes. Se trabaja en iteraciones cortas. obtener gráficos de avance “burndown” y  también dar soporte a la estimación con Planning Poker. incluso permite fallar si es necesario. IceScrum: Herramienta Scrum y Kanban. Ofrece herramientas colaborativas y otras facilidades. Posee la técnica de Planning Poker para la estimación y  paneles virtuales. y esto causa cierta resistencia en su aplicación para algunas personas. estimar y priorizar la pila de producto. . propuesto originalmente por BOEHM en 1976. consulta y estimación de historias de usuario. como un cuadro de mando del proyecto. Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado. dividir el tiempo en Sprints y mover estas historias de la pila de producto a cada uno de los Sprint. Pango Scrum: Otra de las herramientas Scrum online. Para simplificar el intercambio de datos permite exportar gráficos e informes a Excel. un panel interactivo para  el Sprint o soporte a la estimación con Planning Poker. con una interfaz sencilla y amigable que permite escribir. evitando el estancamiento Desventajas   Requiere delegar responsabilidades al equipo. Permite producir software de una forma consistente. de alto enfoque y total transparencia. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. SprintoMeter: Herramienta para la gestión. ScrumDo: Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso. Metodología Espiral MODELO en espiral. sostenida y competitiva. crear y gestionar iteraciones. medición y seguimiento de proyectos Scrum y eXtreme Programming. Las reuniones se dedican a inconvenientes recientes. EL modelo en espiral se divide en un número de actividades de marco de trabajo. Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección. el tiempo y otras informaciones relacionadas con el proyecto. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo. . el software se desarrolla en una serie de versiones incrementales.  Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.  Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado. Son todos los requerimientos.En el modelo espiral. Herramientas para desarrollar cada etapa tareas  que componen este modelo son: Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.  Planificación: las tareas requeridas para definir recursos. también llamadas REGIONES DE TAREAS . el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. Construcción y adaptación: las tareas requeridas para construir. probar.  El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. .  Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. En la utilización de grandes sistemas doblado la productividad.  Como el software evoluciona a medida que progresa el proceso. Ventajas  El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.  El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. instalar y proporcionar soporte al usuario. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas. Producto de esta etapa es el código en cualquier nivel. él diseño. .) Metodología Cascada También conocido como modelo clásico.Software para gestión de la actividad de negocio de una empresa (nóminas.  Genera mucho tiempo en el desarrollo del sistema  Modelo costoso  Requiere experiencia en la identificación de riesgos A qué tipo de desarrollo se dirige A diferencia de otros modelos el modelo espiral se usa también una vez entregado el software (para su mantenimiento). la integración y las pruebas. la implementación. incluido el producido por sistemas de generación automática. Herramientas para desarrollar cada etapa  El análisis de requerimientos consiste en reunir las necesidades del producto y casi siempre su salida es texto.  Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. El modelo en espiral es realista para el desarrollo de software a gran escala. Está es una secuencia de actividades(o etapas) que consisten en el análisis de requerimientos.Software para gestión de las subvenciones agrarias de un país . etc. modelo tradicional o modelo lineal secuencial.  La implementación significa programación.Desventajas  Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. facturación. se puede decir que es un método puro que implica un desarrollo rígido.  El diseño describe la estructura interna del producto y suele representarse con diagramas y texto.  La integración es el proceso de integración es el proceso de ensamblar las partes para completar el producto. En el modelo espiral no hay un número de iteraciones ni costes cerrados. ya que esto se revisa en cada paso por la actividad de planeamiento. Ejemplos: . 4. 6. 5. El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo. de poca innovación y proyectos definitivos y detallados. Permite la departamentalización y control de gestión. Metodología pueden confundir al equipo profesional en las etapas tempranas del proyecto. Diseño del Programa –Todo el hardware y el software que se usara para el desarrollo Del sistema Codificación –De igual manera el hardware y el software para desarrollar el programa Pruebas –Personal capacitado para realizar las acciones del sistema. 3. Permite tener bajo control el proyecto. Se tarda mucho tiempo en pasar por todo el ciclo La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto plazo. Ya que la mayoría de los que desarrollan proyectos no cumple con este lineamiento. A qué tipo de desarrollo se dirige Análisis de requisitos -Personal administrativo des el jefe hasta la persona de menor rango. Es sencilla y facilita la gestión de proyectos. Limita la cantidad de interacción entre equipos que se produce durante el desarrollo. Este proceso conduce a entregar el proyecto a tiempo.Ventajas 1. . No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos. 2. Diseño del Sistema –Arquitectura pura de donde se va trabaja teniendo dependencia a su vez del hardware. Desventajas No refleja realmente el proceso de desarrollo del software. este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones.  Construir y revisar la maqueta (prototipo). Mantenimiento – Desarrolladores para la actualización y estabilidad del sistema. Metodología Prototipo El modelo de prototipos permite que todo el sistema. sistema operativo o de la interface hombre-máquina. Recolección de requisitos. Este modelo es útil cuando:  El cliente no identifica los requisitos detallados. o algunos de sus partes.Verificación –Personal capacitado para verificar que todo esté en orden. de la adaptabilidad del sistema o de la forma en que interactúa el hombre y la máquina. se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. Herramientas para desarrollar cada etapa Paradigma de construcción de prototipos tiene tres pasos:  Escuchar al cliente. es ideal para medir el alcance del producto. pero no se asegura su uso real. Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida. el usuario. es decir cuando el responsable no está seguro de la eficacia de un algoritmo. Etapas para la elaboración del Modelo de Prototipo.  El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo. Se encuentran y definen los objetivos globales.  El responsable del desarrollo no está seguro de la eficiencia de un algoritmo. se identifican los requisitos conocidos y las áreas donde es obligatorio más definición. . no muy amigable en su uso. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo. A qué tipo de desarrollo se dirige Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación. Realiza. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente. pero. procesamiento o salida. puesto que el software está constantemente variando. estática. porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. para contrastarlo con el usuario. . sólo muestra las pantallas por las que irá pasando la futura aplicación. no procesa datos. muy grande. a la larga. por tanto. Desventajas Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final. El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con "plastilina y alambres". en cuanto a la satisfacción de las necesidades del cliente. pero dicha interfaz está fija. un un proceso real de datos. pero no identifica los requisitos detallados de entrada. según las apreciaciones del cliente. Se va modificando y desarrollando sobre la marcha. o incluso. y puede desilusionarse al decirle que el sistema aún no ha sido construido. su cara externa. Es posible que el prototipo sea muy lento. que esté escrito en un lenguaje de programación inadecuado. se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional.Ventajas Este modelo es útil cuando el cliente conoce los objetivos generales para el software. Por su parte. genera un producto más seguro. de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. El prototipo no tiene desarrollada una lógica interna. el prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. diseño rápido -Construcción del Prototipo -Desarrollo. luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Metodología XP También conocido como desarrollo con prototipación o modelo de desarrollo evolutivo.Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor las necesidades del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación del sistema final se habla de un prototipo desechable. Además el prototipo debe ser construido en poco tiempo. Pero eso si al construir el prototipo nos asegura que nuestro software sea de mejor calidad. Un prototipo podrá ser construido solo si con el software es posible experimentar. Herramientas para desarrollar cada etapa -Recolección y refinamiento de requisitos -Modelado. Este modelo se utiliza para dar al usuario una vista preliminar de parte del software. además de que su interfaz sea de agrado para el usuario. Este modelo es básicamente prueba y error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho. Para que la construcción de prototipos sea posible se debe contar con la participación activa del cliente. usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software. evaluación del prototipo por el cliente -Refinamiento del prototipo -Producto de Ingeniería Ventajas No modifica el flujo del ciclo de vida Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios Reduce costo y aumenta la probabilidad de éxito Exige disponer de las herramientas adecuadas . se inicia con la definición de los objetivos globales para el software. Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Modelo de Prototipos reutilizable: También conocido como "Evolutionary Prototyping". . se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa. si bien determinados productos de hardware pueden hacer uso del prototipo como la base del diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles. impresiones. pero no su uso real. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo. El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente. interacción y tiempo. procesamiento o salida. pero no identifica los requisitos detallados de entrada. Resulta muy útil para realizar tests baratos.Este modelo es útil cuando el cliente conoce los objetivos generales para el software. Mayormente es utilizado en el desarrollo de software. Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto. los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo. Modelo de Prototipos Modular: También conocido como Prototipo Incremental (Incremental prototyping). Resulta muy útil para evaluar el alcance del producto. emulando la función del producto real sin mostrar el aspecto real del mismo. Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas. de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina Desventajas Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software. no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real. A qué tipo de desarrollo se dirige Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto. Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz. Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final. se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador. Es sencilla y facilita la gestión de proyectos. que esté escrito en un lenguaje de programación inadecuado. pero no identifica los requisitos detallados de entrada. muy grande. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. 3. propuesto originalmente por BOEHM en 1976. Metodología pueden confundir al equipo profesional en las etapas tempranas del proyecto. Este modelo es útil cuando el cliente conoce los objetivos generales para el software. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente. porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. o algunos de sus partes. El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con "plastilina y alambres". se puede decir que es un método puro que implica un desarrollo rígido. no muy amigable en su uso. es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. 5. y puede desilusionarse al decirle que el sistema aún no ha sido construido. No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos. 6. Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. de poca innovación y proyectos definitivos y detallados. Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificación de riesgos Cascada También conocido como modelo clásico. Permite tener bajo control el proyecto. el usuario. -Como el software evoluciona a medida que progresa el proceso. adaptación. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Este proceso conduce a entregar el proyecto a tiempo. -El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto. Ya que la mayoría de los que desarrollan proyectos no cumple con este lineamiento. No refleja realmente el proceso de desarrollo del software. la integración y las pruebas. Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua. Es posible que el prototipo sea muy lento. 2. Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. Está es una secuencia de actividades(o etapas) que consisten en el análisis de requerimientos. auto-gestión e innovación. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo. XP También conocido como desarrollo No modifica el flujo del ciclo de Debido a que el usuario ve que el . 4. procesamiento o salida. El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo. Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto. modelo tradicional o modelo lineal secuencial. cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se tarda mucho tiempo en pasar por todo el ciclo La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto plazo. pero no se asegura su uso real. Limita la cantidad de interacción entre equipos que se produce durante el desarrollo. Permite la departamentalización y control de gestión.Metodologías Definición Ventajas Desventajas Scrum Es una metodología ágil y flexible para gestionar el desarrollo de software. la implementación. Espiral MODELO en espiral. Prototipo Permite que todo el sistema. este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones. el equipo los estima y con esta información el Product Owner establece su prioridad. -El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional. el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo. él diseño. permite despejar riesgos eficazmente de manera anticipada. es ideal para medir el alcance del producto. o incluso. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas. 2011) . 2013) (INGENIERÍA DE SOFTWARE. 2010) (BRAUDE. desconocido) (rodrygo.(Desconocido.
Copyright © 2024 DOKUMEN.SITE Inc.