Вы находитесь на странице: 1из 31
METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING.
METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING.
METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING.
METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING.
METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING.

METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM

METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM CURSO : INGENIERIA DE SOFTWARE I DOCENTE : ING. GARCIA

CURSO

:

INGENIERIA DE SOFTWARE I

DOCENTE

:

ING. GARCIA VILLEGAS, CRISTHIAN

INTEGRANTES

:

DELGADO POZO, MARLON MUÑOZ PISCO, ALEC ROSALES SILVA ORFILA SORIA ALFARO, IVAN

SEMESTRE

:

2010 - I

TINGO MARIA PERÚ

2010

A Dios por darnos la

vida y

la

oportunidad

de

poder

desarrollarnos

como

profesionales.

A nuestros amigos que siempre están a nuestro en los buenos y malos momentos.

DEDICATORIA

A nuestras familias por su apoyo incondicional en los momentos buenos y malos en el transcurrir de nuestros estudios.

OBJETIVOS

Brindar conocimiento sobre el tema: “METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM

Describir el funcionamiento de la metodología SCRUM

Especificar los temas principales que engloban en la metodología SCRUM

INTRODUCCION

En muchas ocasiones, los modelos de gestión tradicionales no nos sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces nos ha ocurrido: cuando el proyecto se encuentra bastante avanzado nos damos cuenta de que no vamos por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios nos obligan a tirar por la borda todo el trabajo realizado hasta entonces, y nos impiden acabar en el plazo previsto.

Dado que los cambios nunca van a dejar de existir, lo que necesitamos es ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses Takeuchi y Nonaka estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard. De ahí extrajeron la base de la metodología SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.

Scrum es una metodología ágil, que puede ser usada para manejar el desarrollo de productos complejos de software, en esta metodología se usan prácticas iterativas e incrementales. Scrum a sido usado desde proyectos simples hasta en proyectos de cambios estructurales completos en las empresas para sus negocios. Scrum incrementa significativamente la productividad y reduce el tiempo de espera para ver los beneficios así como facilitar la adaptación de los sistemas desarrollados. En este siguiente trabajo hablaremos sobre esta famosa metodología “Scrum”.

METODOLOGIA SCRUM

QUE ES UN SCRUM:

Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo.

Ideal para proyectos con un rápido cambio de requerimientos. Scrum es una metodología ágil, y como tal:

Es un modo de desarrollo de carácter adaptable más que predictivo.

Orientado a las personas más que a los procesos.

Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.

ágil: incremental basada en iteraciones y revisiones. Estructura del Scrum Se comienza con la visión general

Estructura del Scrum

Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tiene mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve.

Cada uno de estos periodos de desarrollo de una iteración que finaliza con la producción de un incremento operativo del producto.

Estas iteraciones son la base del desarrollo ágil y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente.

Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus raíces teóricas están en las teorías de la auto-organización.

MEJOR CON EQUIPOS PEQUEÑOS Y AUTO-ORGANIZADOS

Los equipos pequeños y formados por miembros de diferentes disciplinas consiguen mejores resultados. Es fundamental que el equipo pueda organizarse por sí mismo y la comunicación sea transparente. Esta es la manera de que todos los miembros se comprometan y se encuentren motivados. De hecho, la palabra SCRUM procede del vocabulario del rugby y significa melé; es decir, esa “figura” en la que los compañeros del equipo se amontonan, forman una piña y empujan todos en la misma dirección.

forman una piña y empujan todos en la misma dirección. HISTORIA: En 1986 Hirotaka Takeuchi e

HISTORIA:

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales. 1 Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, como en el rugby, donde el equipo entero «actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro. Los casos de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas fotográficas, computadoras e impresoras.

En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions (A problemas malvados, soluciones virtuosas),se refirieron a esta aproximación como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.

A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a

poner en práctica el scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation

y fue el primero en denominarla scrum.En 1995 Sutherland y Schwaber, durante el

OOPSLA '95 desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo Scrum, siendo ésta la primera aparición pública de la metodología. Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo que ahora se le conoce como scrum. En

2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum.

CARACTERISTICAS:

Scrum por su proceso iterativo incremental produce un grupo de funcionalidades en cada fin de iteración. Sus características son:

Un proceso agile para el manejo y control del trabajo de desarrollo

Un contenedor de prácticas de ingeniería existentes

Equipos autodirigidos.

Utiliza reglas para crear un entorno ágil de administración de proyectos.

No prescribe prácticas específicas de ingeniería.

Los requerimientos se capturan como ítems de la lista Product Backlog

El producto se construye en una serie de Sprints de un mes de duración

Un enfoque basado en equipos, incrementa el desarrollo cuando los requerimientos cambian rápidamente

Proceso que controla el caos entre los conflictos de interés y las necesidades

Camino para mejorar las comunicaciones y maximiza r la cooperación

Camino para detectar la causa y solucionar cualquier problema en el desarrollo

Escalable desde proyectos simples a proyectos completos organizacionales.

Scrum ha controlado y organizado el desarrollo de productos y proyectos con miles de desarrolladores e implementadores

Es la ruta para sentirse bien en el trabajo

Naturalmente Scrum se enfoca en la construcción de proyectos exitosos en las organizaciones, sin mayores cambios dentro de los 30 días de cada carrera (ciclo) construyendo una funcionalidad completa y demostrada del producto al final de cada carrera, Scrum puede implementarse al principio o a la mitad de un proyecto de desarrollo

REQUISITOS PARA PODER UTILIZAR SCRUM:

Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continúa.

Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y disponibilidad para poder colaborar.

Compromiso de la Dirección de la organización para resolver problemas

autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes serviles.

endémicos

y

realizar

cambios

organizativos,

formando

Relación entre proveedor y cliente basada en ganar-ganar, colaboración y

transparencia.

Tamaño de cada equipo entre 5 y 9 personas (con técnicas de colaboración entre equipos que trabajan en el mismo proyecto).

Equipo trabajando en un mismo espacio común para maximizar la comunicación.

Dedicación del equipo a tiempo completo.

PROCESO DEL SCRUM:

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que

proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la replanificación de objetivos que realiza al inicio de cada iteración.

Las actividades que se llevan a cabo en Scrum son las siguientes:

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.

Estos son tiempos máximos en el caso de iteraciones mensuales. En iteraciones de tamaño menor el tiempo es proporcionalmente inferior, y se va reduciendo conforme el equipo va ganando experiencia en este tipo de reuniones.

Beneficios:

1. Productividad mediante comunicación y creación de sinergias: Todos los miembros del equipo tienen una misma visión del objetivo y se ha utilizado los conocimientos y las experiencias de todos para elaborar la mejor solución entregable en el mínimo tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.

2.

Potenciación del compromiso del equipo sobre el objetivo común de la iteración:

Es todo el equipo quien asume la responsabilidad de completar en la iteración los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algún impedimento que bloquea el progreso de la iteración, especialmente si cuando se está llegando al final de la iteración es necesaria la participación de todos para poder completar los objetivos comprometidos.

Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se autoasignó) en los tiempos que proporcionó. Si existe falta de compromiso con respecto al resto de miembros del equipo se hará muy evidente en las reuniones diarias de sincronización del equipo (Scrum daily meeting).

3. Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo.

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 susceptible de ser entregado con el mínimo esfuerzo cuando el cliente (Product Owner) lo solicite.

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.

Recomendaciones: Para poder completar el máximo de requisitos en la iteración, se debe minimizar el número de objetivos/requisitos en que el equipo trabaja simultáneamente (WIP, Work In Progress), completando primero los que den más

valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteración, permite tener más capacidad de reacción frente a cambios o situaciones inesperadas.

Restricciones:

No se puede cambiar los objetivos/requisitos de la iteración en curso.

En la reunión de planificación de la iteración el equipo adquirió el compromiso de completar en la iteración unos requisitos concretos, basó su plan y organización en ellos. Cambiar los objetivos/requisitos de la iteración dificulta la concentración del equipo, baja su moral y su compromiso.

El hecho de no poder cambiar los objetivos/requisitos de la iteración una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qué es lo más prioritario a desarrollar, antes de iniciar la iteración.

Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se están desarrollando eran los más prioritarios justo antes de iniciar la iteración y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas) como para que la probabilidad de cambios una vez iniciada la iteración sea mínima.

Terminación anormal de la iteración: Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteración para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido. En ese caso, se dará por finalizada la iteración y se dará inicio a otra mediante una reunión de planificación de la iteración.

REUNIÓN DIARIA DE SINCRONIZACIÓN DEL EQUIPO (SCRUM DAILY MEETING)

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.

El objetivo de esta reunión es facilitar

la

transferencia de información

y

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.

Beneficios:

Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto:

o

Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o por que hay dependencias (especialmente si existe un retraso).

o

Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar los impedimentos que el equipo no puede solucionar por sí solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.

o

Las tareas no planeadas que está realizando que el equipo no conoce y puede que no estén alineadas con el compromiso del equipo, aunque él crea que lo que está haciendo es lo mejor que se puede hacer.

o

Cuales son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el máximo valor y no realizar tareas que no proporcionan ningún beneficio al resto del equipo.

o

Cual es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo está realizando tareas por debajo del rendimiento

esperado. Se evita que una persona señale con el dedo a otra, dado que la reunión de sincronización pone a todos los miembros del equipo en la misma situación de tener que explicar en qué tareas están trabajando.

o Cuales son los criterios que está utilizando para realizar sus tareas, de manera que estén alineados con los objetivos comunes del equipo.

Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan los otros según sus especialidades y experiencias.

Conocer el estado de la iteración, ver si es posible completar los requisitos a que se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.

Restricciones:

La reunión diaria de estado y sincronización del equipo no es para resolver problemas, los problemas se resuelven después de la reunión.

o

No a todos los miembros del equipo les interesan todos los detalles de cada tema.

o

En la reunión los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.

o

No puede haber una persona explicando su estado mientras otras "se han apartado" de la reunión para comentar un tema particular. Si apareciese alguna conversación de interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qué están trabajando los demás. Si la mini conversación no es del interés de todos, debe hacerse después de la reunión.

El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución de las de tareas

o El proceso de ejecución de las tareas debe estar consensuado para evitar que cada reunión sea una exposición de discrepancias entre los miembros del equipo.

Recomendaciones:

Realizar la reunión diaria de sincronización de pie, para que los miembros del equipo no se relajen ni se extiendan en más detalles de los necesarios. Realizar las reuniones de colaboración entre miembros del equipo justo después de la de sincronización.

DEMOSTRACIÓN DE REQUISITOS COMPLETADOS (SPRINT DEMONSTRATION)

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.

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

Beneficios:

El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos que proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que necesita y tomar mejores decisiones respecto al proyecto.

El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.

El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va obteniendo. No está meses trabajando sin poder exhibir su obra.

Restricciones: Sólo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedará como un requisito más a replanificar.

RETROSPECTIVA (SPRINT RETROSPECTIVE)

Con el objetivo de mejorar de manera continua su productividad, el equipo analiza cómo ha sido su manera de trabajar durante la iteración:

Qué cosas han funcionado bien.ha sido su manera de trabajar durante la iteración : Cuales hay que mejorar. Qué cosas

Cuales hay que mejorar.durante la iteración : Qué cosas han funcionado bien. Qué cosas quiere probar hacer en la

Qué cosas quiere probar hacer en la siguiente iteración.manera de trabajar durante la iteración : Qué cosas han funcionado bien. Cuales hay que mejorar.

Qué ha aprendido.: Qué cosas han funcionado bien. Cuales hay que mejorar. Qué cosas quiere probar hacer en

Cuales 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 Facilitador se encargará de ir eliminando los obstáculos identificados que el propio equipo no pueda resolver por sí mismo.

Esta reunión se realiza después de la reunión de demostración al cliente de

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.

en

la

para poder

incorporar

su

feedback

Beneficios:

Incrementa la productividad en el proyecto y el aprendizaje del equipo de manera sistemática, iteración a iteración, con resultados a corto plazo. Aumenta la motivación del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir eliminando lo que le molesta y le impide que sea más productivo.

Restricciones: En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es frustrante encontrar sistemáticamente los mismos obstáculos y no poder solucionarlos.

REPLANIFICACIÓN DEL PROYECTO

En las reuniones de planificación de entregas y/o durante el transcurso de una iteración, 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 [1].

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 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).al final de cada iteración sobre los resultados obtenidos, ahora que el cliente entiende mejor el

Nuevosrequisitos proyecto.etc. o tareas como resultado de nuevos riesgos en el Para realizar esta tarea,

requisitos

proyecto.etc.

o

tareas

como

resultado

de

nuevos

riesgos

en

el

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

El cliente re-prioriza la lista de objetivos /requisitos en función de estas nuevas estimaciones. 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.

Beneficios

De manera sistemática, iteración a iteración, se obtienen los siguientes beneficios:

El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y posibles desviaciones:

a. Replanificar el proyecto para obtener un nuevo calendario de entregas que cumpla con sus necesidades actuales.

b. Incorporar nuevos recursos.

c. Cancelar el proyecto con los requisitos completados hasta el momento

plenamente operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo.

El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de última hora.

ESTRCUTURA GENERAL DEL SCRUM:

ESTRCUTURA GENERAL DEL SCRUM: ROLES EN SCRUM (RESPONSABILIDADES) En Scrum se definen varios roles, estos están

ROLES EN SCRUM (RESPONSABILIDADES)

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos estan inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación.

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada".

De esta forma, los cerdos están comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque, si éste falla, no son un cerdo, es decir, no son los que de manera comprometida ponen su propio pellejo (y carne) para sacar el proyecto adelante. Las necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.

Roles "Cerdo" Los Cerdos son los que están comprometidos con el proyecto y el proceso

Roles "Cerdo"

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato", lo desempeñan:

Product Owner (Dueño del producto): El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum 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.

ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster , cuyo trabajo primario es eliminar los obstáculos 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 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).

Roles "Gallina"

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse 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.

Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero.

Usuarios: Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?.

Stakeholders (Clientes, Proveedores, Inversores): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.

Managers: Es la gente que establece el ambiente para el desarrollo del producto. Es la gente que establece el ambiente para el desarrollo del producto.

HERRAMIENTAS SCRUM:

Product Backlog (Lista de requisito priorizada)

Crea un listado con los requisitos de los usuarios o propietarios del sistema para planificar el proyecto.

No es una lista completa y definitiva. Es sólo una estimación inicial de los requisitos.

Es un documento dinámico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.).

Sprint Backlog (Lista de tareas de la iteración)  Especifica la serie de tareas que
Sprint Backlog (Lista de tareas de la iteración)  Especifica la serie de tareas que

Sprint Backlog (Lista de tareas de la iteración)

Especifica la serie de tareas que se van a desarrollar según los requisitos señalados.

Estas tareas tienen una duración de entre 4 y 16 hrs. de trabajo.

Las de mayor duración intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo.

Al final del sprint se busca un incremento en la funcionalidad.

Burndown charts (Gráficos de trabajo pendiente) Un gráfico de trabajo pendiente a lo largo del

Burndown charts (Gráficos de trabajo pendiente)

Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá completar el trabajo en el tiempo estimado.

Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se aplazan las fechas de entrega si se le añaden requisitos, ver cómo se avanzan si se le quitan requisitos o se añade otro equipo, etc.

de entrega si se le añaden requisitos, ver cómo se avanzan si se le quitan requisitos
REUNIONES EN SCRUM Daily Scrum Cada día de un sprint, se realiza la reunión sobre

REUNIONES EN 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: 6

¿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).

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

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.

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.

Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los

promulgadores

está

considerado como modelo ágil por la Agile Alliance. La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:

Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.

Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.

del

En

el

desarrollo

de

software

scrum

Reuniones:

Planificación del sprint, Revisión diaria, Revisión del sprint. Sprint

BENEFICIOS DEL SCRUM:

Los principales beneficios que proporciona Scrum son:

Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:

o

Gestión regular de las expectativas del cliente y basada en resultados tangibles.

o

 

o

y

respecto

a

las

necesidades

del

cliente,

cambios en el mercado, etc.

 

o

 

o

Se enfoca en equipos de trabajo

Hay una comunicación diaria

Ofrece una dirección basada en experiencia y de bajo nivel

Hace los obstáculos visibles

Se toman decisiones y se resuelven problemas en tiempo real

EMPRESAS QUE APLICAN EL SCRUM:

En 1986 se utilizaría por primera vez esta famosa metodología en productos exitosos en Japón y los Estados Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos partían de requisitos muy generales, así como novedosos, y debían salir al mercado en mucho menos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español).

En 1993 se realizó el primer Scrum para desarrollo de software y en 1995 el proceso fue formalizado.

En 2001 un grupo de personas muy relevantes en lo que empezaba a ser el desarrollo ágil escribieron los valores fundamentales de los procesos ágiles.

Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 5 personas desarrollando un producto, como en multinacionales, entre las que se encuentran las siguientes:

SECTORES

EJEMPLOS DE EMPRESAS QUE UTILIZAN LA METODOLOGIA SCRUM

Media y Telcos

BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia, Palm, Qualcomm, Schibsted, Sony/Ericsson, Telefonica I+D, TeleAtlas, Verizon

Software,

Hardware

Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén, IBM, Intel, Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts, Primavera, Proyectalis, Softhouse, Valtech, VersionOne.

Internet

Amazon, Google, mySpace, Yahoo

ERP

SAP

Banca e

Inversión

Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch

Sanidad y

Salud

Patientkeeper, Philips Medical

Defensa y

Aeroespacial

Boeing, General Dynamics, Lockheed Martin

Juegos

Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts

Otros

3M, Bose, GE, UOC

En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software. La Scrum Alliance es la organización sin ánimo de lucro que se encarga de difundir Scrum en este ámbito.

CONLUSIONES

Para contar con un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización del desarrollo, es necesaria la aplicación de una metodología, con la cual se puede mantener una fácil administración de este proceso; como por ejemplo la metodología SCRUM.

Al implementar un Metodología Scrum, es importante la utilización de Patrones, los cuales ya tienen una funcionalidad general y han sido predefinidos, y así contar con una base consistente y previamente elaborada para la implementación del Software.

La elaboración de distintos diagramas y herramientas siguiendo la metodología SCRUM proveen una fácil ejecución del proceso de elaboración de un Sistema de Software.

La metodología SCRUM permite la creación de equipos motivados, capaces de organizarse por sí mismos, donde la comunicación y la transparencia son totales.

Además, el usuario gana protagonismo y el cliente se convierte en parte del equipo de desarrollo.

Esta metodología ayuda mucho en un compromiso de cambiar la filosofía de la empresa, alcanzando la capacidad de poder organizar su trabajo e influenciar.

ANEXOS

ANEXOS 30

DEDICATORIA

OBJETIVOS

INTRODUCCIÓN

INDICE

METODOLOGÍA DE SCRUM

Que es SCRUM

6

Historia

7

Características

8

Requisitos para poder utilizar SCRUM

9

Proceso del SCRUM

10

Estructura general del SCRUM

19

Roles en SCRUM (Responsabilidades)

19

Herramientas SCRUM

21

Reuniones en SCRUM

25

SCRUM aplicado al desarrollo de software

27

Beneficios del SCRUM

27

Empresas que aplican el SCRUM

26

CONCLUSIONES

BIBLIOGRAFÍA

ANEXOS