METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM

CURSO

INGENIERIA DE SOFTWARE I

DOCENTE

ING. GARCIA VILLEGAS, CRISTHIAN

INTEGRANTES

DELGADO POZO, MARLON MUOZ PISCO, ALEC ROSALES SILVA ORFILA SORIA ALFARO, IVAN

SEMESTRE

2010 - I

TINGO MARIA PER 2010 1

DEDICATORIA

A Dios por darnos la vida y la oportunidad desarrollarnos profesionales. de poder como

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

A nuestros amigos que siempre estn a nuestro en los buenos y malos momentos.

OBJETIVOS
Brindar conocimiento sobre el tema: METODOLOGIA DE DESARROLLO DE SOFTWARE: SCRUM Describir el funcionamiento de la metodologa SCRUM Especificar los temas principales que engloban en la metodologa SCRUM

INTRODUCCION
En muchas ocasiones, los modelos de gestin tradicionales no nos sirven para afrontar un reto que hoy en da 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 ms gil. Con ese objetivo, en los aos 80 los japoneses Takeuchi y Nonaka estudiaron las prcticas de empresas con buenos resultados de rapidez y flexibilidad en la produccin: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard. De ah extrajeron la base de la metodologa SCRUM que, aunque naci en el mbito tecnolgico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes. Scrum es una metodologa gil, que puede ser usada para manejar el desarrollo de productos complejos de software, en esta metodologa se usan prcticas 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 adaptacin de los sistemas desarrollados. En este siguiente trabajo hablaremos sobre esta famosa metodologa Scrum.

METODOLOGIA SCRUM
QUE ES UN SCRUM:
Scrum es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo. Ideal para proyectos con un rpido cambio de requerimientos. Scrum es una metodologa gil, y como tal: Es un modo de desarrollo de carcter adaptable ms que predictivo. Orientado a las personas ms que a los procesos. Emplea la estructura de desarrollo gil: incremental basada en iteraciones y revisiones.

Estructura del Scrum

Se comienza con la visin 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 iteracin que finaliza con la produccin de un incremento operativo del producto.

Estas iteraciones son la base del desarrollo gil y Scrum gestiona su evolucin a travs de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el da anterior y el previsto para el da siguiente. Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo ms productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus races tericas estn en las teoras de la auto-organizacin. MEJOR CON EQUIPOS PEQUEOS Y AUTO-ORGANIZADOS Los equipos pequeos y formados por miembros de diferentes disciplinas consiguen mejores resultados. Es fundamental que el equipo pueda organizarse por s mismo y la comunicacin 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 compaeros del equipo se amontonan, forman una pia y empujan todos en la misma direccin.

HISTORIA:
En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximacin holstica que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.1 Takeuchi y Nonaka comparan esta nueva aproximacin holstica, 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 acta como un solo hombre para intentar llegar al otro lado del campo, pasando el baln de uno a otro. Los casos de estudio provienen de las industrias automovilsticas, as como de fabricacin de mquinas fotogrficas, 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 aproximacin como scrum (mel en ingls), un trmino propio del rugby mencionado en el artculo por Takeuchi y Nonaka. A principios de los aos 1990 Ken Schwaber emple una aproximacin que lo llev a poner en prctica el scrum en su compaa, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarroll una aproximacin 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 artculos describiendo Scrum, siendo sta la primera aparicin pblica de la metodologa. Durante los aos siguientes, Schwaber y Sutherland, colaboraron para consolidar los artculos antes mencionados, as como sus experiencias y el conjunto de mejores prcticas de la industria que conforman a lo que ahora se le conoce como scrum. En 2001, Schwaber y Mike Beedle describieron la metodologa en el libro Agile Software Development with Scrum.

CARACTERISTICAS:
Scrum por su proceso iterativo incremental produce un grupo de funcionalidades en cada fin de iteracin. Sus caractersticas son: Un proceso agile para el manejo y control del trabajo de desarrollo Un contenedor de prcticas de ingeniera existentes Equipos autodirigidos. Utiliza reglas para crear un entorno gil de administracin de proyectos. No prescribe prcticas especficas de ingeniera. Los requerimientos se capturan como tems de la lista Product Backlog El producto se construye en una serie de Sprints de un mes de duracin Un enfoque basado en equipos, incrementa el desarrollo cuando los requerimientos cambian rpidamente Proceso que controla el caos entre los conflictos de inters y las necesidades Camino para mejorar las comunicaciones y maximiza r la cooperacin Camino para detectar la causa y solucionar cualquier problema en el desarrollo Escalable desde proyectos simples a proyectos completos

organizacionales. 7

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 construccin de proyectos exitosos en las organizaciones, sin mayores cambios dentro de los 30 das 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 implantacin de una gestin gil de proyectos como Scrum: Cultura de empresa basada en trabajo en equipo, delegacin, creatividad y mejora contina. Compromiso del cliente en la direccin de los resultados del proyecto, gestin del ROI y disponibilidad para poder colaborar. Compromiso de la Direccin de la organizacin para resolver problemas endmicos y realizar cambios organizativos, formando equipos

autogestionados y multidisciplinares y fomentando una cultura de gestin basada en la colaboracin y en la facilitacin llevada a cabo por lderes serviles. Compromiso conjunto y colaboracin de los miembros del equipo. Relacin entre proveedor y cliente basada en ganar-ganar, colaboracin y transparencia. Facilidad para realizar cambios en el proyecto. Tamao de cada equipo entre 5 y 9 personas (con tcnicas de colaboracin entre equipos que trabajan en el mismo proyecto). Equipo trabajando en un mismo espacio comn para maximizar la comunicacin. Dedicacin del equipo a tiempo completo. Estabilidad de los miembros del equipo

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 iteracin tiene que 8

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

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta 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 inversin mediante la replanificacin de objetivos que realiza al inicio de cada iteracin. Las actividades que se llevan a cabo en Scrum son las siguientes: Planificacin de la iteracin (Sprint Planning) Ejecucin de la iteracin (Sprint) Reunin diaria de sincronizacin del equipo (Scrum Daily Meeting) Demostracin de los requisitos completados (Sprint Demostration) Retrospectiva (Sprint Retrospective) Replanificacin del proyecto

PLANIFICACIN DE LA ITERACIN (SPRINT PLANNING) La planificacin de las tareas a realizar en la iteracin se divide en dos partes: Primera parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas: El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteracin (de manera que ayude a tomar decisiones durante su ejecucin) y propone los requisitos ms prioritarios a desarrollar en ella. El equipo examina la lista, pregunta al cliente las dudas que le surgen, aade ms condiciones de satisfaccin y selecciona los objetivos/requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.

Segunda parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas* . El equipo planifica la iteracin, elabora la tctica que le permitir conseguir el mejor resultado posible con el mnimo 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 cmo realizarlo. Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteracin (Sprint Backlog) basndose en la definicin de completado. Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea. Cada miembro del equipo se autoasigna a las tareas que puede realizar.

Estos son tiempos mximos en el caso de iteraciones mensuales. En iteraciones de tamao 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 comunicacin y creacin de sinergias: Todos los miembros del equipo tienen una misma visin del objetivo y se ha utilizado los conocimientos y las experiencias de todos para elaborar la mejor solucin entregable en el mnimo tiempo y con el mnimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.

10

2. Potenciacin del compromiso del equipo sobre el objetivo comn de la iteracin:

Es todo el equipo quien asume la responsabilidad de completar en la iteracin los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algn impedimento que bloquea el progreso de la iteracin, especialmente si cuando se est llegando al final de la iteracin es necesaria la participacin 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 sincronizacin del equipo (Scrum daily meeting).

3. Una estimacin conjunta es ms fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo. EJECUCIN DE LA ITERACIN (SPRINT) En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un mes natural y hasta de dos semanas). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto que sea susceptible de ser entregado con el mnimo esfuerzo cuando el cliente (Product Owner) lo solicite.

Cada da el equipo realiza una reunin de sincronizacin, 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 iteracin (Sprint Backlog) y los grficos 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 obstculos 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 mximo de requisitos en la iteracin, se debe minimizar el nmero de objetivos/requisitos en que el equipo trabaja simultneamente (WIP, Work In Progress), completando primero los que den ms 11

valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteracin, permite tener ms capacidad de reaccin frente a cambios o situaciones inesperadas. Restricciones: No se puede cambiar los objetivos/requisitos de la iteracin en curso. En la reunin de planificacin de la iteracin el equipo adquiri el compromiso de completar en la iteracin unos requisitos concretos, bas su plan y organizacin en ellos. Cambiar los objetivos/requisitos de la iteracin dificulta la concentracin del equipo, baja su moral y su compromiso. El hecho de no poder cambiar los objetivos/requisitos de la iteracin una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qu es lo ms prioritario a desarrollar, antes de iniciar la iteracin. Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se estn desarrollando eran los ms prioritarios justo antes de iniciar la iteracin 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 iteracin sea mnima. Terminacin anormal de la iteracin: Slo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminacin anormal de la iteracin. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteracin para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido. En ese caso, se dar por finalizada la iteracin y se dar inicio a otra mediante una reunin de planificacin de la iteracin. REUNIN DIARIA DE SINCRONIZACIN DEL EQUIPO (SCRUM DAILY MEETING) El objetivo de esta reunin es facilitar la transferencia de informacin y la colaboracin entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros. Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para al finalizar la reunin poder hacer las adaptaciones

12

necesarias que permitan cumplir con el compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de planificacin de la iteracin). Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cmo mximo 15 minutos: Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena planeado? Cul 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 iteracin y en el proyecto? Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, asi como con el grfico de horas pendientes en la iteracin. 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 realizacin 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 estn 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 mximo valor y no realizar tareas que no proporcionan ningn 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 13

esperado. Se evita que una persona seale con el dedo a otra, dado que la reunin de sincronizacin pone a todos los miembros del equipo en la misma situacin de tener que explicar en qu tareas estn trabajando. o Cuales son los criterios que est utilizando para realizar sus tareas, de manera que estn alineados con los objetivos comunes del equipo. Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cmo trabajan los otros segn sus especialidades y experiencias. Conocer el estado de la iteracin, 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 reunin diaria de estado y sincronizacin del equipo no es para resolver problemas, los problemas se resuelven despus de la reunin. o o o No a todos los miembros del equipo les interesan todos los detalles de cada tema. En la reunin los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc. No puede haber una persona explicando su estado mientras otras "se han apartado" de la reunin para comentar un tema particular. Si apareciese alguna conversacin de inters comn (que debe ser rpida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qu estn trabajando los dems. Si la mini conversacin no es del inters de todos, debe hacerse despus de la reunin. El equipo debe contar con unos criterios consensuados sobre el proceso de ejecucin de las de tareas o El proceso de ejecucin de las tareas debe estar consensuado para evitar que cada reunin sea una exposicin de discrepancias entre los miembros del equipo. Recomendaciones: Realizar la reunin diaria de sincronizacin de pie, para que los miembros del equipo no se relajen ni se extiendan en ms detalles de los necesarios. Realizar las reuniones de colaboracin entre miembros del equipo justo despus de la de sincronizacin.

14

DEMOSTRACIN DE REQUISITOS COMPLETADOS (SPRINT DEMONSTRATION) Reunin informal donde el equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo, haciendo un recorrido por ellos lo ms real y cercano posible al objetivo que se pretende cubrir. En funcin 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 iteracin, replanificando el proyecto. Se realiza en un timebox de cmo mximo 4 horas. Beneficios: El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos que proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que necesita y tomar mejores decisiones respecto al proyecto. El equipo puede ver si realmente entendi cules eran los requisitos que solicit el cliente y ver en qu puntos hay que mejorar la comunicacin entre ambos. El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va obteniendo. No est meses trabajando sin poder exhibir su obra. Restricciones: Slo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en funcin de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedar como un requisito ms a replanificar. RETROSPECTIVA (SPRINT RETROSPECTIVE) Con el objetivo de mejorar de manera continua su productividad, el equipo analiza cmo ha sido su manera de trabajar durante la iteracin: Qu cosas han funcionado bien. Cuales hay que mejorar. Qu cosas quiere probar hacer en la siguiente iteracin. Qu ha aprendido.

15

Cuales son los problemas que podran impedirle progresar adecuadamente. El Facilitador se encargar de ir eliminando los obstculos identificados que el propio equipo no pueda resolver por s mismo. Esta reunin se realiza despus de la reunin de demostracin al cliente de los objetivos conseguidos en la iteracin, para poder incorporar su feedback y cumplimiento de expectativas como parte de los temas a tratar en la reunin de retrospectiva. Se realiza en un timebox de cmo mximo 3 horas. Beneficios: Incrementa la productividad en el proyecto y el aprendizaje del equipo de manera sistemtica, iteracin a iteracin, con resultados a corto plazo. Aumenta la motivacin del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y ms sostenibles) para ir eliminando lo que le molesta y le impide que sea ms 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 sistemticamente los mismos obstculos y no poder solucionarlos. REPLANIFICACIN DEL PROYECTO En las reuniones de planificacin de entregas y/o durante el transcurso de una iteracin, el cliente va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, aadiendo requisitos, modificndolos, eliminndolos,

repriorizndolos, 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 demostracin que el equipo realiza al final de cada iteracin 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).

16

Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.etc. Para realizar esta tarea, el cliente colabora con el equipo: Para cada nuevo objetivo/requisito conjuntamente se hace una identificacin inicial de sus condiciones de satisfaccin (que se detallarn en la reunin de planificacin de la iteracin). El cliente obtiene del equipo la re-estimacin de costes de desarrollo para completar los objetivos/requisitos siguientes, segn la definicin de completado. El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su velocidad de desarrollo en funcin de la experiencia adquirida hasta ese momento en el proyecto. El cliente re-prioriza la lista de objetivos/requisitos en funcin de estas nuevas estimaciones. Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la iteracin en curso, (que de hecho eran los ms prioritarios al iniciar la iteracin). No es posible cambiar los requisitos que se desarrollan durante la iteracin. En la reunin de planificacin de la iteracin el cliente presentar la nueva lista de requisitos para que sea desarrollada. Beneficios De manera sistemtica, iteracin a iteracin, 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.

17

ESTRCUTURA GENERAL DEL SCRUM:

ROLES EN SCRUM (RESPONSABILIDADES)

En Scrum se definen varios roles, estos estn 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 continuacin. 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, cmo se llamara el restaurante?" La gallina piensa un poco y contesta: "Por qu no lo llamamos "Huevos con jamn?" "Lo siento pero no", dice el cerdo, "Yo estara comprometido pero t solamente estaras involucrada". De esta forma, los cerdos estn 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.

18

Roles "Cerdo" Los Cerdos son los que estn comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamn en el plato", lo desempean: Product Owner (Dueo del producto): 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 obstculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino que acta como una proteccin 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 pequeo equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseador, 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 aproximacin gil es la prctica de involucrar en 19

el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentacin con respecto a la salida del proceso a fin de revisar y planear cada sprint. Anlisis 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 en el bosque cuando no hay nadie Hace ruido? Aqu la definicin sera 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 producir el beneficio acordado que lo justifica. Slo participan directamente durante las revisiones del sprint. Managers: 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 slo una estimacin inicial de los requisitos. Es un documento dinmico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.).

20

Sprint Backlog (Lista de tareas de la iteracin) Especifica la serie de tareas que se van a desarrollar segn los requisitos sealados. Estas tareas tienen una duracin de entre 4 y 16 hrs. de trabajo. Las de mayor duracin intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo. Al final del sprint se busca un incremento en la funcionalidad.

21

Burndown charts (Grficos de trabajo pendiente) Un grfico 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 grfico permite realizar diversas simulaciones: ver cmo se aplazan las fechas de entrega si se le aaden requisitos, ver cmo se avanzan si se le quitan requisitos o se aade otro equipo, etc.

22

REUNIONES EN SCRUM Daily Scrum Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guas especficas:

La reunin comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo- para quin llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plstico del cuello, etc)

Todos son bienvenidos, pero solo los "cerdos" pueden hablar. La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo.

Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunin corta)

La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:6

Qu has hecho desde ayer? Qu es lo que ests planeando hacer hoy? Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

23

Scrum de Scrum Cada da normalmente despus del Daily Scrum

Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose especialmente en reas de solapamiento e integracin.

Asiste una persona asignada por cada equipo.

La agenda ser la misma como del Daily Scrum, adems de las siguientes cuatro preguntas:

Qu ha hecho tu equipo desde nuestra ltima reunin? Qu har tu equipo antes que nos volvamos a reunir? Hay algo que demora o estorba a tu equipo? Ests a punto de poner algo en el camino del otro equipo?

Reunin de Planificacin del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin 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 cunto del trabajo es probable que se realice durante el actual Sprint Ocho horas como lmite

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la Reunin de Revisin del Sprint y la Retrospectiva del Sprint Reunin de Revisin 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 lmite

24

Retrospectiva del Sprint (Sprint Retrospective) Despus 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 recin superado. El propsito de la retrospectiva es realizar una mejora continua del proceso. Esta reunin tiene un tiempo fijo de cuatro horas. SCRUM APLICADO AL DESARROLLO DE SOFTWARE Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin 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 integrara en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo present junto con Ken Schwaber como proceso formal, tambin para gestin del desarrollo de software en OOPSLA 96. Ms tarde, en 2001 seran dos de los promulgadores del Manifiesto gil. En el desarrollo de software scrum est considerado como modelo gil por la Agile Alliance. La ficha adjunta incluye una descripcin sinptica 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.

Reuniones:

Planificacin del sprint, Revisin diaria, Revisin del sprint.

Sprint

BENEFICIOS DEL SCRUM: Los principales beneficios que proporciona Scrum son: Entrega mensual (o quincenal) de resultados (los requisitos ms prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:

25

o o o o o

Gestin regular de las expectativas del cliente y basada en resultados tangibles. Resultados anticipados (time to market). Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el mercado, etc. Gestin sistemtica del Retorno de Inversin (ROI). Mitigacin sistemtica de los riesgos del proyecto.

Productividad y calidad. Alineamiento entre el cliente y el equipo de desarrollo. Equipo motivado Se enfoca en equipos de trabajo Hay una comunicacin diaria Ofrece una direccin basada en experiencia y de bajo nivel Hace los obstculos visibles Se toman decisiones y se resuelven problemas en tiempo real EMPRESAS QUE APLICAN EL SCRUM: En 1986 se utilizara por primera vez esta famosa metodologa en productos exitosos en Japn y los Estados Unidos (cmaras de fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos partan de requisitos muy generales, as como novedosos, y deban salir al mercado en mucho menos del tiempo del que se tard en lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de proyecto muy

similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby y su formacin de Scrum (mel en espaol). 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 pequeas, startups con tan slo 5 personas desarrollando un producto, como en multinacionales, entre las que se encuentran las siguientes: 26

SECTORES

EJEMPLOS DE EMPRESAS QUE UTILIZAN LA METODOLOGIA SCRUM BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia,

Media y Telcos

Palm, Qualcomm, Schibsted, Sony/Ericsson, Telefonica I+D, TeleAtlas, Verizon

Software, Hardware Internet ERP Banca e Inversin Sanidad y Salud Defensa y Aeroespacial Juegos Otros

Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailn, IBM, Intel, Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts, Primavera, Proyectalis, Softhouse, Valtech, VersionOne. Amazon, Google, mySpace, Yahoo SAP Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch

Patientkeeper, Philips Medical

Boeing, General Dynamics, Lockheed Martin Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts 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 organizacin sin nimo de lucro que se encarga de difundir Scrum en este mbito.

27

CONLUSIONES
Para contar con un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin del desarrollo, es necesaria la aplicacin de una metodologa, con la cual se puede mantener una fcil administracin de este proceso; como por ejemplo la metodologa SCRUM.

Al implementar un Metodologa Scrum, es importante la utilizacin 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 implementacin del Software.

La elaboracin de distintos

diagramas y herramientas siguiendo la

metodologa SCRUM proveen una fcil ejecucin del proceso de elaboracin de un Sistema de Software.

La metodologa SCRUM permite la creacin de equipos motivados, capaces de organizarse por s mismos, donde la comunicacin y la transparencia son totales.

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

Esta metodologa ayuda mucho en un compromiso de cambiar la filosofa de la empresa, alcanzando la capacidad de poder organizar su trabajo e influenciar.

28

BIBLIOGRAFIA
http://www.proyectosagiles.org/ http://es.wikipedia.org/wiki/Scrum http://www.navegapolis.net/files/s/NST-010_01.pdf http://www.chuidiang.com/ood/metodologia/scrum.php http://srinclan.wordpress.com/2009/04/ http://www.scribd.com/doc/13359717/Metodologia-Scrum-Proyecto-Final-OAD http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html

29

ANEXOS

30

INDICE

DEDICATORIA OBJETIVOS INTRODUCCIN METODOLOGA DE SCRUM Que es SCRUM Historia Caractersticas Requisitos para poder utilizar SCRUM Proceso del SCRUM Estructura general del SCRUM Roles en SCRUM (Responsabilidades) Herramientas SCRUM Reuniones en SCRUM SCRUM aplicado al desarrollo de software Beneficios del SCRUM Empresas que aplican el SCRUM CONCLUSIONES BIBLIOGRAFA ANEXOS 6 7 8 9 10 19 19 21 25 27 27 26

31