31
Instituto Universitario De Tecnología “Antonio José De Sucre” Extensión Guayana Puerto Ordaz – Estado Bolívar METODOLOGIA ESPIRAL Bachilleres: Espinoza Jesús Romero Aurimar Leonardo Vazquez

Metodo espiral

Embed Size (px)

Citation preview

Instituto Universitario De Tecnología

“Antonio José De Sucre”

Extensión Guayana

Puerto Ordaz – Estado Bolívar

METODOLOGIA ESPIRAL

Bachilleres:

Espinoza Jesús

Romero Aurimar

Leonardo Vazquez

Ciudad Guayana, 29 de Noviembre de 2014

INDICE

INTRODUCCION.............................................................................................3

METODOLOGIA ESPIRAL.............................................................................4

COMO TRABAJA ESPIRAL...........................................................................5

ROLES Y RESPONSABILIDADES...............................................................11

FLUJO DE EJECUCION DE ESPIRAL.........................................................13

ESQUEMA DE COMUNICACIÓN.................................................................15

COMO IMPLEMENTARLO...........................................................................16

VENTAJAS....................................................................................................20

DESVENTAJAS............................................................................................21

CONCLUSION...............................................................................................22

BIBLIOGRAFIA.............................................................................................23

INTRODUCCION

El software es el cerebro, el que permite la almacenar de datos, por lo

que es un componente muy importante, sobre todo en la sociedad actual,

que es altamente dependiente de la tecnología, y con el pasar del tiempo

cada vez más, pero las personas ajenas al tema de la informática no están

conscientes del trabajo que supone realizar este tipo de programas.

Para esto están los programadores, que se encargan de la labor, pero

no solo se trata sobre programadores, ya que estos al igual que cualquier

otro ser humano, son propenso a cometer errores, para disminuir este riesgo,

existe un tema interesante llamado “desarrollo ágil de software” que son

métodos de ingeniería del software basado en el “desarrollo iterativo e

incremental”, donde los requerimientos y soluciones evolucionan mediante la

colaboración de grupos auto organizado.

Se podría decir que estos son como una serie de pasos o consejos

que se siguen para la óptima realización de algún software, un método, pero

este tiene algunas particularidades, las cuales veremos a continuación.

3

METODOLOGIA ESPIRAL

Scrum es una metodología ágil y flexible para gestionar el desarrollo

de software, cuyo principal objetivo es maximizar el retorno de la inversión

para su empresa .Se basa en construir primero la funcionalidad de mayor

valor para el cliente y en los principios de inspección continua, adaptación,

auto-gestión e innovación.

En Scrum se realizan entregas parciales y regulares del producto final,

priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,

Scrum está especialmente indicado para proyectos en entornos complejos,

donde se necesita obtener resultados pronto, donde los requisitos son

cambiantes o poco definidos, donde la innovación, la competitividad, la

flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está

entregando al cliente lo que necesita, cuando las entregas se alargan

demasiado, los costes se disparan o la calidad no es aceptable, cuando se

necesita capacidad de reacción ante la competencia, cuando la moral de los

equipos es baja y la rotación alta, cuando es necesario identificar y

solucionar ineficiencias sistemáticamente o cuando se quiere trabajar

utilizando un proceso especializado en el desarrollo de producto.

Scrum es un modelo de desarrollo ágil caracterizado por:

• Adoptar una estrategia de desarrollo incremental, en lugar de la

planificación y ejecución completa del producto.

• Basar la calidad del resultado más en el conocimiento tácito de las

personas en equipos auto organizados, que en la calidad de los procesos

empleados.

4

• Solapamiento de las diferentes fases del desarrollo, en lugar de

realizar una tras otra en un ciclo secuencial o de cascada.

COMO TRABAJA SCRUM

Esta metódica de trabajo promueve la innovación, motivación y

compromiso del equipo que forma parte del proyecto, por lo que los

profesionales encuentran un ámbito propicio para desarrollar sus

capacidades. Desde el punto de vista de la entidad que maneja los datos,

existen amenazas de origen externo como por ejemplo las agresiones

técnicas, naturales o humanos, sino también amenazas de origen interno,

como la negligencia del propio personal o las condiciones técnicas, procesos

operativos internos. Desde un punto de vista general, dividiríamos los riesgos

entre tres grupos:

5

Planificación de la iteración (Sprint Planning)

La planificación de las tareas a realizar en la iteración se divide en dos

partes:

• Primera parte de la reunión. Se realiza en un timebox de cómo

máximo 4 horas :

El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteración (de manera que

ayude a tomar decisiones durante su ejecución) y propone los requisitos más

prioritarios a desarrollar en ella .El equipo examina la lista, pregunta al cliente

las dudas que le surgen, añade más condiciones de satisfacción y selecciona

los objetivos/requisitos más prioritarios que se compromete a completar en la

iteración, de manera que puedan ser entregados si el cliente lo solicita.

• Segunda parte de la reunión. Se realiza en un timebox de cómo

máximo 4 horas.

El equipo planifica la iteración, elabora la táctica que le permitirá

conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad

la realiza el equipo dado que ha adquirido un compromiso, es el responsable

de organizar su trabajo y es quien mejor conoce cómo realizarlo.

• Define las tareas necesarias para poder completar cada

objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog)

basándose en la definición de completado.

• Realiza una estimación conjunta del esfuerzo necesario para realizar

cada tarea.

• Cada miembro del equipo se autoasigna a las tareas que puede

realizar.

6

Ejecución de la iteración (Sprint)

En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas

(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene

que proporcionar un resultado completo, un incremento de producto que sea

potencialmente entregable, de manera que cuando el cliente (Product

Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el

producto esté disponible para ser utilizado. Para ello, durante la iteración el

equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:

• Cada día el equipo realiza una reunión de sincronización, donde

cada miembro inspecciona el trabajo de los otros para poder hacer las

adaptaciones necesarias, comunica cuales son los impedimentos con que se

encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint

Backlog) y los gráficos de trabajo pendiente (Burndown charts).

• El Facilitador (Scrum Master) se encarga de que el equipo pueda

cumplir con su compromiso y de que no se merme su productividad.

• Elimina los obstáculos que el equipo no puede resolver por sí mismo.

• Protege al equipo de interrupciones externas que puedan afectar su

compromiso o su productividad.

Reunión diaria de sincronización del equipo (Scrum daily

meeting)

El objetivo de esta reunión es facilitar la transferencia de información y

la colaboración entre los miembros del equipo para aumentar su

productividad, al poner de manifiesto puntos en que se pueden ayudar unos

a otros.

7

Cada miembro del equipo inspecciona el trabajo que el resto está

realizando (dependencias entre tareas, progreso hacia el objetivo de la

iteración, obstáculos que pueden impedir este objetivo) para al finalizar la

reunión poder hacer las adaptaciones necesarias que permitan cumplir con el

compromiso conjunto que el equipo adquirió para la iteración (en la reunión

de planificación de la iteración).

Cada miembro del equipo debe responder las siguientes preguntas en

un timebox de cómo máximo 15 minutos:

• ¿Qué he hecho desde la última reunión de sincronización? ¿Pude

hacer todo lo que tenía planeado? ¿Cuál fue el problema?

• ¿Qué voy a hacer a partir de este momento?

• ¿Qué impedimentos tengo o voy a tener para cumplir mis

compromisos en esta iteración y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la

iteración, donde se actualiza el estado y el esfuerzo pendiente para cada

tarea, asi como con el gráfico de horas pendientes en la iteración.

Demostración de requisitos completados (Sprint Review)

Reunión informal donde el equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto preparado

para ser entregado con el mínimo esfuerzo, haciendo un recorrido por ellos lo

más real y cercano posible al objetivo que se pretende cubrir.

En función de los resultados mostrados y de los cambios que haya

habido en el contexto del proyecto, el cliente realiza las adaptaciones

necesarias de manera objetiva, ya desde la primera iteración, replanificando

el proyecto.

8

Se realiza en un timebox de cómo máximo 4 horas.

Retrospectiva (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la

calidad del producto que está desarrollando, el equipo analiza cómo ha sido

su manera de trabajar durante la iteración, por qué está consiguiendo o no

los objetivos a que se comprometió al inicio de la iteración y por qué el

incremento de producto que acaba de demostrar al cliente era lo que él

esperaba o no:

• Qué cosas han funcionado bien.

• Cuales hay que mejorar.

• Qué cosas quiere probar hacer en la siguiente iteración.

• Qué ha aprendido.

• Cuáles son los problemas que podrían impedirle progresar

adecuadamente. El Facilitador se encargará de ir eliminando los obstáculos

identificados que el propio equipo no pueda resolver por sí mismo.

Notar que esta reunión se realiza después de la reunión de

demostración al cliente de los objetivos conseguidos en la iteración, para

poder incorporar su feedback y cumplimiento de expectativas como parte de

los temas a tratar en la reunión de retrospectiva

Se realiza en un timebox de cómo máximo 3 horas (si la iteración es

mensual).

9

Replanificación del proyecto - Product Backlog Refinement

En las reuniones de planificación de entregas y durante el transcurso

de una iteración (en el Product Backlog Refinement o Grooming), el cliente

va trabajando en la lista de objetivos/requisitos priorizada del producto o

proyecto, añadiendo requisitos, modificándolos, eliminándolos,

repriorizándolos, cambiando el contenido de iteraciones y definiendo un

calendario de entregas que se ajuste mejor a sus nuevas necesidades.

Los cambios en la lista de requisitos pueden ser debidos a:

• Modificaciones que el cliente solicita tras la demostración que el

equipo realiza al final de cada iteración sobre los resultados obtenidos, ahora

que el cliente entiende mejor el producto o proyecto.

• Cambios en el contexto del proyecto (sacar al mercado un producto

antes que su competidor, hacer frente a urgencias o nuevas peticiones de

clientes, etc).

• Nuevos requisitos o tareas como resultado de nuevos riesgos en el

proyecto.

• Para realizar esta tarea, el cliente colabora con el equipo.

• Para cada nuevo objetivo/requisito, conjuntamente se hace una

identificación inicial de sus condiciones de satisfacción (que se detallarán en

la reunión de planificación de la iteración).

• El cliente obtiene del equipo la re-estimación de costes de desarrollo

para completar los objetivos/requisitos siguientes, según la definición de

completado. El equipo ajusta el factor de complejidad, el coste para

completar los requisitos y su velocidad de desarrollo en función de la

experiencia adquirida hasta ese momento en el proyecto.

10

• El cliente re-prioriza la lista de objetivos/requisitos en función de

estas nuevas estimaciones.

Hay que notar que el equipo sigue trabajando con los

objetivos/requisitos de la iteración en curso, (que de hecho eran los más

prioritarios al iniciar la iteración). No es posible cambiar los requisitos que se

desarrollan durante la iteración. En la reunión de planificación de la iteración

el cliente presentará la nueva lista de requisitos para que sea desarrollada.

ROLES Y RESPONSABILIDADES

En Scrum, el equipo se focaliza en construir software de calidad. 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, qué no y

en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la

tarea del equipo de desarrollo.

El equipo Scrum está formado por los siguientes roles:

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el

equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.

El Product Owner escribe historias de usuario, las prioriza, y las coloca en el

Product Backlog.

Sus responsabilidades son variadas:

• Se sitúa como representante de todos los interesados (clientes,

usuarios finales) en el proyecto, tiene capacidad para tomar decisiones

concernientes al mismo y actúa como interlocutor único ante el equipo

11

• Define objetivos del proyecto, así como dirige sus resultados y se

preocupa por la priorización de los requisitos del cliente (ROI –Return Of

Investment-) para formar el Product Backlog . Además, colabora con el

equipo de manera activa, para llevar a cabo la planificación, revisión, etc…

de cada iteración o Sprint.

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

El equipo tiene la responsabilidad de entregar el producto. Un

pequeño equipo de 5 a 9 personas con las habilidades transversales

necesarias para realizar el trabajo (diseñador, desarrollador, etc).

12

FLUJO DE EJECUCION DE SCRUM

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un

proyecto. Esto se llama “daily standup”. 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 quién llega tarde (por ejemplo:

dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)

• Todos son bienvenidos, pero solo los “cerdos” pueden hablar.

• La reunión tiene una duración fija de 15 minutos, de forma

independiente del tamaño del equipo.

• Todos los asistentes deben mantenerse de pie (esto ayuda a

mantener la reunión corta)

• La reunión debe ocurrir en la misma ubicación y a la misma hora

todos los días.

Durante la reunión, cada miembro del equipo contesta a tres

preguntas:

• ¿Qué has hecho desde ayer?

• ¿Qué es lo que estás planeando hacer hoy?

• ¿Has tenido algún problema que te haya impedido alcanzar tu

objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

13

Scrum de Scrum

Cada día normalmente después del “Daily Scrum”

• 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.

La agenda será la misma como del Daily Scrum, además de las

siguientes cuatro preguntas:

• ¿Qué ha hecho tu equipo desde nuestra última reunión?

• ¿Qué hará tu equipo antes que nos volvamos a reunir?

• ¿Hay algo que demora o estorba a tu equipo?

• ¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de

Planificación del Sprint” se lleva a cabo.

• Seleccionar que trabajo se hará

• 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

14

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión

de Revisión del Sprint” y la “Retrospectiva del Sprint”

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.

ESQUEMA DE COMUNICACIÓN

La forma más eficiente y efectiva de comunicar información de ida y

vuelta dentro de un equipo de desarrollo es mediante la comunicación cara a

cara.

Sprint Planning

• Se priorizan las actividades contenidas en el Product BackLog.

• Se define la meta.

15

Sprint Planning

• Reunión previa al Sprint en rint en donde el Product Owner muestra

las actividades contenidas en el Product Backlog, ya priorizadas, el Scrum

• Team en conjunto con el Scrum Master determinan las actividades

que contendrá el siguiente Sprint Backlo rint Backlog.

COMO IMPLEMENTARLO

Revisión del Sprint

Al final del Sprint haz una reunión para revisar el Sprint (Sprint

Review) . Invita a todo el equipo. Invita a todos los tomadores de decisiones

16

del negocio. Invita a tomadores de decisiones importantes incluyendo

ejecutivos cuando sea apropiado.

Revisa lo que fue entregado con el Sprint. Haz una demostración del

software. Si es completo, software funcional antes de la entrega final o si es

un trabajo en progreso dentro de un proyecto de varios Sprints, haz la

demostración de lo que se ha completado dentro del Sprint. Deja que los

miembros del equipo demuestren las áreas en las que han trabajado.

El propósito de la revisión del Sprint es triple:

• Permite a los miembros del equipo mostrar lo que han logrado y

demostrar su contribución al producto.

• Permite a todos los tomadores de decisión ver lo que se ha hecho y

proveer valiosa retroalimentación en una base regular, mientras aun hay

tiempo de tomarla en consideración.

• Ayuda al equipo a permanecer enfocado en el tiempo del Sprint. -

nadie quiere aparecerse en la revisión del Sprint con nada útil que demostrar.

Retrospectiva del Sprint.

Siguiendo la revisión del Sprint, haz una reunión de retrospectiva.

Invita a todo el equipo. Invita al propietario del producto. Pero esta reunión no

es para todos los tomadores de decisión. Típicamente puede seguir

inmediatamente después de la revisión del Sprint.

El propósito de la retrospectiva del Sprint es reflexionar sobre como

fueron las cosas durante el Sprint. Es una oportunidad para que el equipo

discuta el Sprint y consideren como se pueden mejorar las cosas.

Juntos el equipo debería:

17

• Revisar el gráfico de seguimiento: ¿Cómo fue? ¿Entregó el equipo lo

que se había comprometido en entregar al inicio del Sprint? Anotar las horas

empleadas en una hoja de cálculo para que la tasa de éxito del equipo pueda

ser graficada sobre el tiempo, para ver si está mejorando o empeorando.

Esta es una herramienta para que el equipo mida su progreso. No es una

medida para gestión.

• Revisa la "velocidad" del equipo: La velocidad es el número de

puntos estimados en la pila del producto original, para los items completados

en el Sprint. Solamente los items 100% completos y entregados, firmados, en

el software cuentan para la velocidad del equipo.

De nuevo, grafica esto para que la velocidad del equipo pueda ser

monitoreada sobre el tiempo, así el equipo puede ver si está entregando más

o menos en el transcurso del tiempo. La velocidad gradualmente se

establecerá cerda de una norma y entonces puede ser usada en la

planificación del Sprint como una medida de cuanto puede realmente un

equipo lograr, basado en la trayectoria.

• Discute lo que fue bien: (intenta asegurarte que se repita la siguiente

vez).

• Discute que podría haber ido mejor: (intenta entender por qué) .

• Decide lo que el equipo hará diferente en el siguiente Sprint: (Intenta

tomar un par de puntos de acción que en realidad puedan ser hechos de

forma diferente en el siguiente Sprint).

18

Repetir

El equipo está ahora armado con valiosa información - sobre el

producto, sobre el rendimiento y sobre algunos impedimentos en su entorno,

ejemplo:

• Cómo se ve el software después del último Sprint.

• Retroalimentación sobre el producto desarrollado hasta entonces.

• Hasta qué punto el equipo capaz de entregar lo que se había

comprometido en la planificación del Sprint.

• La velocidad del equipo y lo que es alcanzable en una iteración

típica.

• Lo que fue bien.

• Lo que no fue tan bien.

• Lo que será hecho distinto para avanzar.

19

Todo lo que le queda al equipo, es repetir el proceso, con el mayor

conocimiento ganado desde lo anterior.

De modo realista toma 3 o 4 Sprints para que el equipo entre en ritmo.

Para aplicar las mejoras y que sean usadas en el proceso. Para que la

velocidad se estabilice.

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.

20

• 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.

21

CONCLUSIÓN

Después de una visión general de esta metodología, queda claro que

Scrum es muy útil para el desarrollo de proyectos ágiles software, en

particular para aquellos en constante cambio y con una necesidad de

feedback por parte del cliente constante.

Por otra parte, se trata de una metodología considerada como un

marco de trabajo, por lo que resulta en muchos casos imprescindible

utilizarla en conjunto con otras metodologías software, sobre todo con XP

(eXtreme Programming).

22

BIBLIOGRAFÍA

http://es.wikipedia.org/wiki/Archivo:Agile_Software

http://es.wikipedia.org/wiki/Scrum

http://www.monografias.com/trabajos91/metodologias-desarrollo-agil-

mele-scrum/metodologias-desarrollo-agil-mele-

scrum.shtml#ixzz3KTHnFf9y

23