Universidad Nacional de Trujillo

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA DE INFORMATICA

“AÑO DE LA INVERSION PARA EL DESARROLLO RURAL Y LA SEGURIDAD

ALIMENTARIA”

“Metodología Scrum”

CURSO : Metodología e Ingeniería de Software II

DOCENTE : Arturo Díaz Pulido

ALUMNOS :

Becerra Gil, Jordy Cabrera Silva, Ebert Cotrina Mendoza, Edwin Gómez Gutiérrez, Mario

Guadalupe – Perú

2013

pág. 1

INDICE

DEDICATORIA 3

INTRODUCCION 4

1. METODOLOGIA AGIL

1.1 FASES DEL DESARROLLO AGIL

5

5

2. METODOLOGIA AGIL VS METODOLOGIA TRADICIONAL

3. METODOLOGIA SCRUM

3.1 CICLO DE VIDA DEL SCRUM3.2 EVENTOS SCRUM3.3 COMPONENTES SCRUM

3.4 ELEMENTOS DE SCRUM

4. VENTAJAS5. DESVENTAJAS

CONCLUSIONES

BIBLIOGRAFIA

6

7

77810

1112

13

13

pág. 2

DEDICATORIA

En primer lugar a Dios por habernos permitido llegar hasta este punto de nuestra carrera, habernos dado salud y darnos lo necesario para seguir adelante día a día para lograr nuestros objetivos, además de su infinita bondad y amor.

A nuestro profesor por su gran apoyo y motivación para la culminación de nuestro curso METODOLOGÍA E INGENIERÍA DE SOFTWARE II, por su apoyo ofrecido en este trabajo, por habernos transmitido los conocimientos obtenidos y habernos llevado pasó a paso en el aprendizaje.

pág. 3

INTRODUCCIÓN

La gestión ágil de proyectos nace como respuesta a los mercados actuales, ya que tiene como objetivo dar garantías a las cuatro demandas principales: valor; reducción del tiempo; agilidad y fiabilidad, adaptando el curso del proyecto a la evolución de los requisitos y a las circunstancias cambiantes del entorno.

Scrum está especialmente indicado para proyectos en entornos complejos donde se necesita obtener resultados pronto y los requisitos son cambiantes o poco definidos, y la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. Con resultados probados en miles de proyectos, se utiliza tanto en empresas muy pequeñas y en multinacionales como Amazon, Google, MySpace, Yahoo, etc.

1. Metodología Ágil

pág. 4

Consisten en desarrollar una pequeña parte del software que se desea construir. De esta forma, el cliente nos indica si vamos por el buen camino, estableciendo aquellas partes que le son más relevantes y así juntos, nos aseguramos de que construiremos una aplicación que añadirá valor a su negocio. Las metodologías agiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos o cambiantes.

Fases del desarrollo Ágil:

Concepto

Se define de forma general las características del producto y se asigna el equipo que se encargará de su desarrollo.

a. EspeculaciónEn esta fase se hacen disposiciones con la información obtenida y se establecen los límites que marcarán el desarrollo del producto, tales como costes y agendas.Se construirá el producto a partir de las ideas principales y se comprueban las partes realizadas y su impacto en el entorno.Esta fase se repite en cada iteración y consiste, en rasgos generales, en:

Desarrollar y revisar los requisitos generales. Mantener la lista de las funcionalidades que se esperan. Plan de entrega. Se establecen las fechas de las versiones, hitos e

iteraciones. Medirá el esfuerzo realizado en el proyecto.

b. ExploraciónSe incrementa el producto en el que se añaden las funcionalidades de la fase de especulación.

c. RevisiónEl equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado.

d. CierreSe entregará en la fecha acordada una versión, el cierre no indica que se ha finalizado el proyecto, sin que seguirá habiendo cambios, denominados “mantenimiento”, que hará que el producto final se acerque el producto final deseado.

pág. 5

2. Metodología Agile vs Metodología Tradicional

Metodologías Agiles Metodologías TradicionalesBasadas en Heurísticas provenientes de prácticas de producción de código.

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo.

Especialmente preparadas para cambios durante el proyecto.

Cierta resistencia a los cambios.

Impuestas internamente (por el equipo).

Impuestas externamente.

Proceso menos controlado, con pocos principios.

Proceso mucho más controlado, con numerosas políticas/normas.

No existe contrato tradicional o al menos es bastante flexible.

Existe un contrato prefijado.

El cliente es parte del equipo de desarrollo.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio.

Grupos grandes y posiblemente distribuidos.

Pocos artefactos. Más artefactos.Pocos roles. Más roles.

Menos énfasis en la arquitectura del software.

La arquitectura del software es esencial y se expresa mediante modelos.

3. Metodología Scrum

pág. 6

Scrum es un proceso en el que se aplican de manera regular prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. 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.

I. Ciclo de vida de Scrum

a. Pre-Juego: PlanteamientoEl propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción.

b. Pre-Juego: MontajeEl propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.

c. Juego o DesarrolloEl propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum.

d. Post-juego: LiberaciónEl propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta.

II. Eventos de ScrumEn Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.

a. Sprint

pág. 7

El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.

III. Componentes de ScrumPara entender todo el proceso de desarrollo de desarrollo del scrum, se describirá de forma general las fases y los roles. Estas fases y roles se detallaran de forma más concisa más adelante.Scrum se puede dividir de forma general en 3 fases, que podemos entender como reuniones. Las reuniones forman parte de los artefactos de esta metodología junto con los roles y los elementos que lo forman.

a. Reuniones

Planificación BacklogSe definirá un documento en el que se reflejarán los requisitos del sistema por prioridades. En esta fase se definirá también la planificación de Sprint 0, además se obtendrá un Sprint Backlog, que es la lista de tareas que es el objetivo más importante del Sprint.- Planificación Sprint:

Jornada de trabajo previa al inicio de cada sprint en la que se determina cual va ser el trabajo y los objetivos que se deben conseguir en la iteración.

Seguimiento BacklogBreve revisión diaria, de no más de 15 minutos, en la que cada miembro dice las tareas en las que está trabajando:- El trabajo que realizo el día anterior.- El que tiene previsto realizar.- Cosas que puede necesitar o impedimentos que debe

suprimirse para realizar el trabajo.

Revisión de Sprint- Análisis y revisión del incremento generado.- Retrospectiva de lecciones aprendidas para mejorar la

implementación de scrum en la organización.

pág. 8

b. RolesHay solo tres roles en Scrum: el Product Owner (dueño del producto), the Team (el equipo), y el ScrumMaster (Maestro Scrum). Todas las responsabilidades de manejo de un proyecto se dividen entre estos tres papeles:

Product Owner (Dueño del Producto)El Product Owner es el responsable de cuidar los intereses de cada uno de los participantes, recalcándolos con una “estaca”, lo cual se transformara en el producto final. El Product Owner estima el financiamiento inicial y el requerido en el curso del proyecto mediante la creación de los requisitos totales e iniciales del proyecto, preocupándose de retornar los objetivos de inversión (ROL), y los planes de revisión.

The Team (El Equipo)Los equipos auto-suficientes, auto-organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionabilidad del producto y planificar su propio trabajo para lograrlo. Los miembros del equipo son responsables en conjunto del éxito de cada iteración y del proyecto en su totalidad.

El ScrumMaster (Líder del Proyecto)El ScrumMaster es responsable del proceso Scrum, debe enseñar la metodología Scrum a cada integrante implicado en el proyecto, preocupándose de poner la metodología en práctica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno sigua las Reglas y prácticas de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum.

La gente que sigue estos roles son la personas que confían en el éxito del proyecto. Otros pudieron estar interesados en el proyecto, pero no están comprometidos. Scrum hace una distinción clara entre estos dos grupos y asegura de que los que son responsables del proyecto tengan la autoridad suficiente para hacer lo que consideren necesario para el éxito del proyecto y de que los que no sean responsables no interfieran innecesariamente.

pág. 9

Esto se ejemplifica a continuación, refiero a esta gente como “cerdos” y “pollos,” respectivamente. Estos nombres vienen de una vieja historia: El pollo y el cerdo.Están caminando en un sendero. El pollo dice al cerdo, “¿Deseas abrir un restaurante conmigo?” El cerdo considera la pregunta y responde, “Está bien, ¿Cómo quieres tu que se llame el restaurante?” La gallina responde, “El jamón de Cerdo y los huevos de pollo!” El cerdo se detiene repentinamente y dice, “pensándolo bien, creo que no voy a abrir un restaurante contigo. Porque yo estaría realmente comprometido, pero tú solamente estarías implicado.”

Comprometido en el Proyecto Implicados en el Proyecto

Dueño del Producto Equipo ScrumMaster

Marketing Comercial Etc.

IV. Elementos de Scrum

a. Producto Backlog (Lista de Producto)La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.

- Una Lista de Producto nunca está completa. - La Lista de Producto es dinámica; cambia

constantemente para identificar lo que el producto

pág. 10

necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Lista de Producto también existe.

- La Lista de Producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras.

b. Sprint Backlog (Lista de Pendientes de Sprint)La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.La Lista de Pendientes del Sprint hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.

c. IncrementoEl Incremento es la suma de todos los elementos de la Lista de Producto completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no.

4. Ventajas:

pág. 11

Obtención de Software con requerimientos exigidos de forma rápida. Trabajo con iteraciones rápidas. Gran adaptación al cambio. Ventaja competitiva. Creatividad y efectividad del equipo auto administrado y entorno libre de

interrupciones. Reuniones dedicadas a problemas recientes.

5. Desventajas

Aunque Scrum es una metodología ampliamente extendida y aceptada pueden darse situaciones en las que no se muestren sus ventajas, algunas causas de estas son:

Falta de competencia Falta de confianza Falta de compromiso

Conclusiones

pág. 12

La principal desventaja de Scrum es que las reuniones y la asignación de tareas deben estar controladas por un líder que conozca y comparta este sistema de trabajo.Scrum es sin lugar a dudas la metodología de desarrollo ágil más sencillo de comprender y de implantar en las empresas, ya que tiene los suficientes puntos en común con las metodologías de desarrollo tradicionales para superar la resistencia de la cultura empresarial pero a la vez es lo bastante flexible como para resultar efectiva.

Bibliografía

http://es.wikipedia.org/wiki/Scrumhttp://www.proyectosagiles.org/que-es-scrumhttp://carlospesquera.com/metodologia-scrum-funcionamiento/

pág. 13