CARRERA PROFESIONAL : CARRERA PROFESIONAL : COMPUTACION E INFORMATICA CURSO: CURSO:ANALIS Y DISEÑO DE SISTEMAS PROFESOR: PROFESOR:ING. MOISES ALVARES HUAMAN.

Slides:



Advertisements
Presentaciones similares
Ciclo de vida de desarrollo de software
Advertisements

Scrum Juan Palacio Bañeres.
Administrado y desarrollado utilizando Scrum
Proyecto Call Center Taller de desarrollo de proyectos II
Metodologías ágiles.
75.47 PRESENTACIÓN INICIAL Taller de Desarrollo de Proyectos II
UNIVERSIDAD "ALONSO DE OJEDA"
Desarrollo de software innovador con métodos ágiles
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles.
Materia: Tecnología de la Información
Metodología de Trabajo Aperio: SCRUM Aperio Inducción
METODOLOGIAS AGILES DE CONSTRUCCION DE SOFWARE
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles.
“8 Principios de la Gestión Administrativa”
COSTOS ESTANDAR DEFINCIÓN
Alexis Masson Nicolás Fetter
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
DEFINICION DE LOS PROCESOS DE LAS EMPRESAS FAMILIARES.
Modelo de Desarrollo XP
Trabajo Práctico Taller de Desarrollo de Proyectos 2 Septiembre 2009.
PROCESO O REUNIONES EN SCRUM BENEFICIOS DE UTILIZAR SCRUM
Planeación de una Demostración
Facultad: Administración y Negocios
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
Ciclos de vida ágiles.  Es una metodología ágil que plantea: ◦ Iteraciones cortas ◦ Entregables periódicos ◦ Colaboración con el cliente full time ◦
Metodologías Ágiles - Scrum
Por: Niels Amador Cerda
Fase Inicial Grupo 6 – PIS – 2013.
Scrum Images goes here …y prácticas ágiles para desarrollo de software.
Gestión de Proyectos Informáticos Sesión N° 5 Ciclo de Vida de un Proyecto Roberto Jijena I.
Entornos de Desarrollo
Aplicación de metodología ágil SCRUM software de consultas de resultados de la “Carrera Nacional de Carros”
EDUAR 2.0 Sistema de Explotación de Información Educativa 10/05/2011.
Análisis de Requerimientos
Planificación Temporal y Seguimiento del Proyecto
Plan de Sistemas de Información (PSI)
¿Cómo nos ayuda GeneXus a mejorar la calidad en el proceso de desarrollo de Software? Ing. Rosario Estévez Ing. Rafael Mon
INGENIERÍA DE SOFTWARE
Ximena Romano – Doris Correa
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de metodologías ágiles Tatiana Alejandra.
Alexander Aristizabal Ángelo flores herrera
Ingeniería de Software
Diseño E Implementación En Delphi Del Caso De Posicionamiento 2D
Ciclo de vida de un sistema
METODOLOGÍAS DE DESARROLLO DE SOFTWARE MODERNAS
UNIVERSITARIO: DAVID MAMANI EL ALTO – LA PAZ – BOLIVIA 2009 CARRERA: ING. DE SISTEMAS MATERIA: INGENIERIA DE SOFTWARE.
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de metodologías ágiles Tatiana Alejandra.
Gestión Ágil de Proyectos Colaborador: Anónimo
Scrum Una Alternativa Ágil para el desarrollo de Software
Introducción al proceso de verificación y validación.
GESTIÓN DEL EQUIPO HUMANO DEL PROYECTO
Republica Bolivariana De Venezuela Ministerio Del Poder Popular Para La Educación Universidad Gran Mariscal De Ayacucho Cátedra: Dirección De Operaciones.
Estructurar tus ideas para hacerlas realidad
Ciclo de Vida del Software
AceSchool Daniel Labra Fernando Figueroa ¿Qué Hicimos? -Refinar Causa-Efecto -Elección Metodología -Esquema de la Solución -Resultado Encuesta -Refinar.
Ingeniería en Informática F UNDAMENTOS DE C OMPUTACIÓN B ACHILLERATO EN I NGENIERÍA I NFORMÁTICA L IC. C ARLOS H. G UTIÉRREZ L EÓN.
Taller de desarrollo de proyectos II Presentación Inicial.
Scrum Ciclo Profesor: Ing. José Díaz
INGENIERIA DE SOFTWARE
¿Qué ES? Es una herramienta de administración por medio de la cual una empresa delega la ejecución de ciertas actividades a empresas altamente especializadas,
CONCEPTO DE CICLO DE VIDA 1 En los departamentos de Sistemas se debe definir un marco de referencia común que debe ser:  Pueda ser empleado por todos.
Fundamentos de Computación
Metodologías de Programación II UNAJ - Instituto de Ingeniería y Agronomía - Ingeniería en Informática 1 3 Clase Clase 6 Scrum (Parte 2)
Ingeniería de Software Facultad de Ingeniería Septiembre 2010 Fernando Alsuyet Ariel Illio Matias Baldini.
Procesos de Planeación
 La gestión de proyectos una disciplina que ha tomado fuerza en la medida en que buena parte de lo que se hace tanto a nivel personal como profesional.
Integrantes: Mejía Zúñiga Yoselin Taco Apaza Pamela Ychuta Torres John.
GESTIÓN DE PROYECTOS.
Gestión del Alcance del Proyecto
Transcripción de la presentación:

CARRERA PROFESIONAL : CARRERA PROFESIONAL : COMPUTACION E INFORMATICA CURSO: CURSO:ANALIS Y DISEÑO DE SISTEMAS PROFESOR: PROFESOR:ING. MOISES ALVARES HUAMAN MNAS: ALUMNAS: ACUÑA QUISPE LIZBETH LUCERO ACUÑA QUISPE MÓNICA FIGUEROA PALOMINO KELLY PAITAN IPARRAGUIRE MARIA TAIPE MACHUCA BETTY ZAIDA TAIPE VILA JHON SEMESTRE: SEMESTRE: IV TURNO TURNO: DIA

SCRUM Es un marco de trabajo para la gestión y desarrollo de software basada en un proceso interativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.desarrollo de softwareinterativo e incrementaldesarrollo ágil de software

Roles Principales representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El ProductOwner escribe historias de usuario, las prioriza, y las coloca en el ProductBacklog.historias de usuarioProductBacklog ScrumMaster (o Facilitador) El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc). Roles Auxiliares Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc) Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint. Administradores (Managers) Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum DailyScrum Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "dailystandup". El scrum tiene unas guías específicas: La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc) Todos son bienvenidos, pero sólo los responsables pueden hablar. La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

Scrum de Scrum Cada día normalmente después del “DailyScrum”: Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. Asiste una persona asignada por cada equipo. Reunión de Planificación del Sprint (Sprint Planning Meeting) Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint Ocho horas como límite Reunión de Revisión del Sprint (Sprint Review Meeting) Revisar el trabajo que fue completado y no completado Presentar el trabajo completado a los interesados (alias “demo”) El trabajo incompleto no puede ser demostrado Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retrospective) Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas. Sprint El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se recomienda no cambiar los objetivos del sprint o sprintbacklog a menos que la falta de estos cambios amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

Productbacklog Es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI)ROI Sprintbacklog Es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Burndown Es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.

Scrum aplicado al desarrollo de software Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.

Beneficios:  Cumplimento de expectativas  Flexibilidad a cambios  Reducción del Time toMarket  Mayor calidad del software  Maximiza el retorno de la inversión (ROI)  Predicciones de tiempos  Reducción de riesgos  Mayor productividad

Ventajas - Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes. - Se trabaja en iteraciones cortas, de alto enfoque y total transparencia. - Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes. - Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado. - Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias. - Permite producir software de una forma consistente, sostenida y competitiva. - Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

Desventajas - Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario. - Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas Conclucion Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes. Se puede decir que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.