Qu es SCRUMScrum es un proceso en el que se aplican de manera regularun conjunto debuenas prcticasparatrabajar colaborativamente, en equipo, y obtenerel mejor resultado posiblede un proyecto.Estas prcticas se apoyan unas a otras y su seleccin tiene origen en unestudio de la manera de trabajar de equipos altamente productivos.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 paraproyectos enentornos complejos, donde se necesitaobtener resultados pronto, donde losrequisitos son cambiantes o poco definidos, donde lainnovacin, lacompetitividad, laflexibilidady laproductividadson fundamentales.Scrum tambin se utiliza para resolver situaciones en queno se est entregando al cliente lo que necesita, cuandolas entregas se alargan demasiado,los costes se disparanola calidad no es aceptable, cuando se necesitacapacidad de reaccin ante la competencia, cuandola moral de los equipos es baja y la rotacin alta, cuando es necesarioidentificar y solucionar ineficiencias sistemticamenteo cuando se quiere trabajar utilizando unproceso especializado en el desarrollo de producto.Ver en detalle cuales son losbeneficios de Scrum, susfundamentosy susrequisitos.El procesoEn Scrum un proyecto se ejecuta en bloques temporales cortos y fijos(iteracionesde un mes naturaly hasta dedos semanas, si as se necesita). Cada iteracin tiene que 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 lalista de objetivos/requisitos priorizadadel producto, que acta como plan del proyecto. En esta listaelclienteprioriza los objetivos balanceando el valor que le aportan respecto a su costeyquedan repartidos en iteraciones y entregas. De manera regular el cliente puedemaximizar la utilidad de lo que se desarrollay elretorno de inversinmediante lareplanificacin de objetivosdel producto, que realiza durante la iteracin con vista a las siguientes iteraciones.Las actividades que se llevan a cabo en Scrum son las siguientes:Planificacin de la iteracinEl primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes:1. Seleccin de requisitos(4 horas mximo). El cliente presenta alequipola lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.2. Planificacin de la iteracin(4 horas mximo). El equipo elabora lalista de tareas de la iteracinnecesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.Ejecucin de la iteracinCada da el equipo realiza unareunin de sincronizacin(15 minutos mximo). 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 poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo responde a tres preguntas: Qu he hecho desde la ltima reunin de sincronizacin? Qu voy a hacer a partir de este momento? Qu impedimentos tengo o voy a tener?Durante la iteracin elFacilitador (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 externasque puedan afectar su compromiso o su productividad.Inspeccin y adaptacinEl ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:1. Demostracin(4 horas mximo). 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. 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.2. Retrospectiva(4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados.Cmo funciona Scrum

ScrumVase tambin:medio scrum

Ciclos de desarrollo.

Ficha sinptica

Marco de Trabajo SCRUMScrum es el nombre con el que se denomina a los marcos de desarrollo giles caracterizados por: Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y ejecucin completa del producto. Basar la calidad del resultado ms en el conocimiento tcito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada.ndice[ocultar] 1Historia 2Caractersticas de Scrum 3Roles en Scrum 3.1Roles Principales 3.2Roles Auxiliares 4Reuniones en Scrum 4.1Daily Scrum o Stand-up meeting 4.2Scrum de Scrum 4.3Reunin de Planificacin del Sprint (Sprint Planning Meeting) 4.4Reunin de Revisin del Sprint (Sprint Review Meeting) 4.5Retrospectiva del Sprint (Sprint Retrospective) 5Sprint 6Beneficios de Scrum 7Documentos 7.1Product backlog 7.2Sprint backlog 7.3Burn down chart 8Notas 9Referencias 10Vase tambin 11Enlaces externosHistoria[editar]Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cmo desarrollaban los nuevos productos las principales empresas de manufactura tecnolgica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formacin de mel (scrum en ingls) de los jugadores de Rugby, a raz de lo cual qued acuado el trmino scrum para referirse a ella.Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es apropiada para proyectos con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.En 1995 Ken Schwaber present Scrum Development Process en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference)(SCRUM Development Process), un marco de reglas para desarrollo de software, basado en los principios de scrum, y que l haba empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compaa que en los macrojuegos de compras y fusiones, se integrara en VMARK, y luego en Informix y finalmente en Ascential Software Corporation)

Caractersticas de Scrum[editar]SCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son elScrumMaster, que procura facilitar la aplicacin de scrum y gestionar cambios, elProductOwner, que representa a losstakeholders(interesados externos o internos), y elTeamque ejecuta el desarrollo y dems elementos relacionados con el. Durante cadasprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo mas corta posible), el equipo crea un incremento de softwarepotencialmente entregable(utilizable). El conjunto de caractersticas que forma parte de cada sprint viene delProduct Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos delProduct Backlogque forman parte del sprint se determinan durante la reunin deSprint Planning. Durante esta reunin, elProduct Owneridentifica los elementos delProduct Backlogque quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.1Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que losrequisitosestn congelados durante el sprint.Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamadorequirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes.Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptacin, retorno de inversin, mitigacin de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por ltimo equipo motivado. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prcticas para el trabajo en equipo y de esa manera obtener resultados posibles.Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.Roles en Scrum[editar]Roles Principales[editar]Product OwnerElProduct Ownerrepresenta la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribehistorias de usuario, las prioriza, y las coloca en elProduct Backlog.ScrumMaster (o Facilitador)ElScrumes facilitado por unScrumMaster, cuyo trabajo primario es eliminar los obstculos que impiden que el equipo alcance el objetivo del sprint. ElScrumMasterno 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 de desarrolloEl equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (anlisis, diseo, desarrollo, pruebas, documentacin, etc).Roles Auxiliares[editar]Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximacin gil es la prctica de involucrar en 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.Stakeholders (Clientes, Proveedores, Vendedores, etc)Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el beneficio acordado que justifica su produccin. Slo participan directamente durante las revisiones del sprint.Administradores (Managers)Es la gente que establece el ambiente para el desarrollo del producto.Reuniones en Scrum[editar]Daily Scrum o Stand-up meeting[editar]Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llamadaily standupoStand-up meeting. El scrum tiene unas guas especficas: La reunin comienza puntualmente a su hora. Todos son bienvenidos, pero slo los involucrados en el proyecto pueden hablar. La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo. 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:2 Qu has hecho desde ayer? Qu es lo que hars para maana? Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).Scrum de Scrum[editar]Estas reuniones por lo general se realizan cuando en la organizacin existan varios equipos Scrum, y les permiten discutir su trabajo, enfocndose especialmente en reas de solapamiento e integracin. Se hace normalmente cada da normalmente despus del Daily Scrum o mximo cada dos das. Asiste una persona asignada por cada equipo Scrum.La agenda ser la misma que la del Daily Scrum, aadiendo adems 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)[editar]Al inicio de cada ciclo de Sprint (cada 15 o 30 das), se lleva a cabo unareunin de planificacin del Sprint. Se pretende: Seleccionar qu trabajo se har. Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que llevar hacer el trabajo. Identificar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint. Realizarse esta planificacin en ocho horas como tiempo lmite.Al final del ciclo Sprint se hacen dos reuniones ms: lareunin de revisin del Sprinty laretrospectiva del Sprint.Reunin de Revisin del Sprint (Sprint Review Meeting)[editar] 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 lmiteRetrospectiva del Sprint (Sprint Retrospective)[editar]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.Sprint[editar]El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la duracin de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duracin de sprint en particular (2 o 3 semanas) e ir ajustndolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deber presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se recomienda no agregar objetivos al sprint osprint backloga menos que la falta de estos objetivos amenace al xito del proyecto. La constancia permite la concentracin y mejora la productividad del equipo de trabajo.Beneficios de Scrum[editar] Flexibilidad a cambios.Gran capacidad de reaccin ante los cambiantes requerimientos generados por las necesidades del cliente o la evolucin del mercado. El marco de trabajo est diseado para adecuarse a las nuevas exigencias que implican proyectos complejos. Reduccin del Time to Market.El cliente puede empezar a utilizar las caractersticas ms importantes del proyecto antes de que est completamente terminado. Mayor calidad del software.El trabajo metdico y la necesidad de obtener una versin de trabajo funcional despus de cada iteracin, ayuda a la obtencin de un software de alta calidad. Mayor productividad.Se logra, entre otras razones, debido a la eliminacin de la burocracia y la motivacin del equipo proporcionado por el hecho de que pueden estructurarse de manera autnoma. Maximiza el retorno de la inversin (ROI).Creacin de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorizacin por retorno de inversin. Predicciones de tiempos.A travs de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fcil cuando se podr hacer uso de una determinada funcionalidad que todava est en el Backlog. Reduccin de riesgosEl hecho de llevar a cabo las funcionalidades de mayor valor en primer lugar y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera anticipada.3Documentos[editar]Product backlog[editar]Elproduct backlogse trata como un documento de alto nivel para todo el proyecto. Es el conjunto de todos los requisitos de proyecto, el cual contiene descripciones genricas de funcionalidades deseables, priorizadas segn su retorno sobre la inversin (ROI) . Representa elquva a ser construido en su totalidad. Es abierto y solo puede ser modificado por elproduct owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimacin ayuda alproduct ownera ajustar la lnea temporal (KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos caractersticas tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendr probablemente ms prioridad, debido a que suROIser ms alto.Sprint backlog[editar]Elsprint backloges el subconjunto de requisitos que sern desarrollados durante el siguiente sprint. Al definir el sprint backlog, se describe elcmoel equipo va a implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen en tareas, a las cuales se asignan ciertashoras de trabajopero ninguna tarea con una duracin superior a 16 horas. Si una tarea es mayor de 16 horas, deber ser dividida en otras menores. Las tareas en elsprint backlognunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca adecuado.Burn down chart[editar]Laburn down chartes una grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variar o incluso valdr cero en algunos tramos.