INSTITUTO POLITCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERA Y DE CIENCIAS SOCIALES Y ADMINISTRATIVAS

SCRUM Equipo 6 Canseco Gutirrez Ana Silvia Castaeda Ibez Hugo Erik German Bez Gabriela Rangel Ibarra Andrea Vellve Montoya Michel

German Bez Gabriela

Mxico, D.F., 10 de Septiembre de 2013

ndice

Introduccin.1

Capitulado...2

Conclusiones13

Introduccin Durante dcadas los desarrolladores de software han intentado emplear mtodos denidos de trabajo y administracin de proyectos. Los mtodos denidos son apropiados

cuando las variables que ingresan al sistema se encuentran bien denidas y el mtodo por el cual se las transforma en resultados es predecible. El desarrollo de software y otras formas de trabajo complejos no encajan con esa clase de mtodos. Las metodologas de trabajo tradicionales se basan en documentos para plasmar y comunicar conocimiento de un especialista al siguiente. Los ciclos de retroalimentacin son demasiado largos o incluso no existen. De acuerdo a State of Agile Survey el 60% de los proyectos en empresas son giles, ya que los marcos giles ayudan a las empresas a acelerar el tiempo de comercializacin, aumentar la productividad y responder a los cambios en las prioridades. De los marcos ms adoptados encontramos a SCRUM (Scrum Alianza,N.d.) El desarrollo gil de software son mtodos de ingeniera del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto organizados y multidisciplinarios ( Desarrollo gil de software ,N.d.)

(What is Scrum? ,N.d) Capitulado Historia Gracias a la publicacin del artculo The New Product Development Game por Takeuchi y Nonaka en 1986 se di a conocer una forma de gestionar proyectos llamada SCRUM, en la que la agilidad, flexibilidad y la incertidumbre son los elementos principales.

Nonaka y Takeuchi tomaron como base empresas tecnolgicas que realizaban productos en menos tiempo, de buena calidad y menos costes, que otras del mismo mbito laboral; as notaron que el producto no segua unas fases en las que haba un equipo especializado en cada una de ellas, sino que se parta de unos requisitos muy generales y el producto lo realizaba un equipo multidisciplinario que trabajaba desde el comienzo del proyecto hasta el final. Scrum aparece como una prctica destinada a los productos tecnolgicos, pero es en el ao de 1993 que Jeff Sutherland presenta la metodologa para desarrollar un software en su empresa Easel Corporation y en 1995 Ken Schwaber presenta en OOPSLA (ObjectOriented Programming Systems & Applications Conference) , la implementacin de Scrum para el desarrollo de un software llamado Delphi.

Es hasta el ao de 1996, Jeff Sutherland y Ken Schwaber presentaron las prcticas que se usaban como proceso formal para el desarrollo de software y que pasaran a incluirse en la lista de Agile Alliance

Qu es SCRUM? Es un marco de trabajo basado en los mtodos giles, que tiene como objetivo el control continuo sobre el estado actual del software, en el cual el cliente establece las prioridades y el equipo SCRUM se auto-organiza para determinar la mejor forma de entregar resultados (Abrahamsson, Salo, Ronkainen y Warsta, 2002).

Caractersticas Cuenta con equipos auto-organizados y de esto depende gran parte el xito del proyecto, cuando un miembro del equipo obtiene un triunfo, el triunfo es para todo el equipo y de igual manera todos colaboran entre s. El desarrollo del software se lleva a cabo por medio de una series Sprints que duran de un mes a dos semanas. Los requisitos no solo son recolectados sino que estos tambin son capturados en una lista. Utiliza normas generativas para crear un entorno gil para la entrega de proyectos. Promueve la colaboracin con el cliente en lugar de rgida negociacin de contratos. Cmo funciona SCRUM? Si bien la metodologa gil se puede utilizar para la gestin de cualquier proyecto, el proceso gil Scrum es ideal para proyectos con cambios rpidos o requisitos altamente emergentes.(Alonso Dorado C ,Nd) Nos ayuda al manejo de proyectos que tienen como n el desarrollo de productos complejos y se basa en la adaptacin continua a las circunstancias de la evolucin del proyecto. Es un modo de desarrollo adaptable, antes que predictivo. Orientado a las personas, ms que a los procesos. Emplea el modelo de construccin incremental basado en iteraciones y revisiones. La esencia de Scrum es: El equipo recibe objetivos claros El equipo se organiza en funcin del trabajo a realizar El equipo entrega con regularidad las funcionalidades ms valiosas El equipo recibe retroalimentacin de individuos que se encuentran fuera del equipo El equipo reexiona sobre su manera de trabajar, con el objetivo de mejorar La organizacin completa posee visibilidad sobre el progreso del equipo El equipo y la gerencia se comunican entre s de manera honesta, transparentando progreso y riesgos. Esta metodologa es adecuada para empresas en las que el desarrollo de sus productos se encuentra en un entorno de incertidumbres, auto-organizacin y transmisin del conocimiento. Los roles en SCRUM (INFOMANIAUPT,N.d.)

Estos se dividen en 2 grupos: Los que estn comprometidos con el proyecto y el proceso de Scrum. 1. Product Owner (Dueo del Producto): Ser quien lidere el desarrollo y el encargado de tratar con el cliente. Es el responsable del proyecto y de una etapa fundamental en SCRUM: la planificacin. 2. Scrum Master: Es quien hace de nexo entre el Product Owner y el Equipo. Es bsicamente un moderador, encargado de asegurar la cooperacin y el cumplimiento de la planificacin funcional realizada por el Product Owner. Es el encargado de prevenir conflictos y de sacar el mejor provecho de cada integrante del equipo en las reuniones diarias. 3. El Equipo: Debe tener entre 5 y 9 miembros (7 es lo tericamente ideal) es el conjunto de personas, los encargados de efectivizar la resolucin de cada sprint y especificar los resultados del trabajo. Estn autorizados a llevar a cabo casi cualquier actividad a fin de llevar a cabo el objetivo final de cada sprint. El equipo posee reuniones diarias de no ms de 15 minutos donde se ponen en comn las tareas realizadas en el ltimo da y las a realizar durante el presente; en el desarrollo de las mismas es de vital importancia el Scrum Master para preguntar a cada miembro del equipo que hizo desde la ltima reunin, qu problemas tuvo y con qu tareas continuar. Los que aunque no son parte del proceso, son necesarios para la retroalimentacin del proyecto (Stakeholders, usuarios y Managers)

(Dan Rawsthorne y Douglas E. Shimp ,2010)

Reuniones durante esta metodologa (Grafeuille, 2008) Esta metodologa se puede dividir en 3 fases o reuniones generales. 1. Planificacin del Sprint Se escoger la prioridad de los requisitos del sistema y se definir el Sprint 0 decidiendo el objetivo y el trabajo a realizar en dicha iteracin. Lo ms relevante de esta reunin es que se especificar la lista de tareas (Sprint Backlog) y el objetivo con ms prioridad.

(Scrum Formacin de Sprint Backlog,n.d)

2. . Daily Scrum La reunin comienza puntualmente a su hora. A menudo hay castigos para quien llegue tarde, stas tienen una duracin fija de 15 minutos y debe ocurrir siempre en la misma ubicacin y la misma hora. Todos son bienvenidos, pero slo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar. Durante la reunin, cada miembro del equipo contesta a tres preguntas: 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). (Metodologa Scrum,n.d)

3. Revisin del Sprint Es una reunin informal con duracin aproximada de 2 horas, todo el equipo participa. En ella se realizar el o los incrementos que se generan, presentando los resultados finales, ayudando as el feedback con el cliente

(Blog Mazzive, 2009). 4. Retrospectiva del Sprint Es una revisin peridica de lo que funciona y de lo que no ,tiene una duracinn de 15 a 30 minutos y en ella participan todos y cada uno de los miembros del equipo Scrum.

(Maxxor, n.d.)

Artefactos utilizados en la metodologa (Artefactos de Scrum ,s.f.) Se refiere a los diferentes modelos de informacin que se generan en el proceso de desarrollo del software, SCRUM produce los siguientes tres artefactos: 1. Product Backlog (Pila del producto) Es el corazn de SCRUM, es la llista donde se registra la relacin de requisitos del producto, en la cual no es necesario excesivo detalle pero s deben estar priorizados. sta lista o pila del producto est en constante evolucin; ya que maneja constantemente los cambios para idenficar que necesita el producto para ser: apropiado,competitivo y util.Se encuentra abierta a todos los roles, pero es el propietario del producto el responsable y quien decide sobre esta. El Product Backlog nunca se acaba, se desarrolla paralelamente a medida que el producto y el ambiente en el cual se trabaja evoluciona. Mientras exista un producto, el Product Backlog tambin existe.

(Artefactos de Scrum ,s.f.) 2. Spring Backlog (Pila del SPRINT) Es un subconjunto de Product Backlog y son los requisitos comprometidos por el equipo para el Sprint, estos definen el trabajo, o las tareas que el equipo desarrollar para poder convertir el Product Backlog en un incremento potencial funcional del producto. Las tareas deben ser divididas de modo que cada una dure entre 4 a 16 horas finalizarlas. Las tareas de mayor duracin (16 horas )se consideran secundarias, ya que todava no se han definido apropiadamente. Solamente el equipo puede cambiar el Sprint Backlog. El Sprint Backlog es un cuadro altamente visible, es lo que debe conseguir durante una iteracin del Sprint.

(Artefactos de Scrum ,s.f.) 3. Burndown charts (Carta Burndown) Una carta del burndown demuestra la cantidad de trabajo restante a travs del tiempo,es una manera excelente de visualizar la correlacin entre la cantidad de trabajo restante en cualquier punto y el progreso de los equipos de proyecto en la reduccin de este trabajo. Esto me permite ver el Que pasa si al proyecto le voy agregando o quitando funcionalidad de manera de manejar el tiempo y si es necesario aplazar en un funcin de ganar funcionalidad y vice -versa.

(Artefactos de Scrum ,s.f.)

El proceso SCRUM (Oiver Andrs Prez A,2011) Debido a que la metodologa SCRUM es ms enfocada a la organizacin del equipo de trabajo, as como tambin lo es en gran parte XP, en SCRUM a diferencia de XP que tambin est basado en los mtodos giles, se divide el proyecto en periodos con duracion de 15 das o de 4 semanas aproximadamente, cada periodo se denomina Sprint y cada equipo SCRUM recibe una lista de pedidos a ejecutar en un sprint determinado. Para comenzar en cada SPRINT se define una lista de requerimientos o BackLog, los cuales deben estar satisfechos al fin de la iteracin. Hay ocasiones en las que se puede optar por Sprints ms largos al comienzo (mes y medio o dos meses) ya que al principio cuesta ms obtener un ejecutable y al final Sprints ms cortos (una semana o dos) cuando se est en la fase final de refinamiento. Pero bsicamente el proceso es el mismo de principio a fin.

(Manuel Trigas Gallego,n.d.)

El proceso SCRUM se compone de 5 fases las cuales contienen las actividades a desarrollar durante un periodo, comprendidas de la siguiente manera: 1. Revisin de planes de Release. sta fase se ejecuta una vez establecida Product Backlog y es llevada a cabo por el equipo a fin de evaluar las diferentes factibilidades de los requerimientos y estimaciones, basndose en la funcionalidad y las prioridades de Product Backlog. 2. Distribucin, revisin y ajustes de estndares de producto. En sta fase los desarrolladores realizan los ajustes de los estndares y requerimientos mnimos, dejando todo listo para comenzar con la fase de Sprint. 3. Sprint. sta fase de aproximadamente 30 das es donde se efecta el desarrollo del software y se llevan a cabo las reuniones, consta de las siguientes subfases: elaborar, integrar, revisar y ajustar. Estas subfases no son estrictas, pero claramente obedecena prcticas ya mencionadas en las metodologas 4. Revisin del Sprint. Corresponde al incremento,en sta fase se revisa el Sprint y si es necesario se aaden nuevos tems a la pila de producto.ste proceso se repite hasta que el producto est listo para la fase de cierre. 5. Cierre. En sta fase se da lugar a la depuracin y correcciones de errores (debugging), ste procedimiento se repite hasta alcanzar la calidad en el producto. Posterior a las correcciones y pruebas se realiza el Marketing y promocin del producto y al terminar sta fase el proyecto queda cerrado.

(Oiver Andrs Prez A. ,2011)

Ventajas / Beneficios de Scrum (Beneficios de Scrum ,n.d.) 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: 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.

Desventajas de Scrum (Muos, J. F,s.f.) Si no existe una fecha definitiva de finalizacin del proyecto es posible que se siga solicitando, y aadiendo, nueva funcionalidad. Si una tarea no est bien definida, los costes de tiempo y dinero estimados del proyecto no sern demasiado exactos. En ese caso, la tarea se puede extender sobre varios sprints. Si los miembros del equipo no estn centrados y convencidos, el proyecto nunca se completar o incluso fallar. Est bien para proyectos pequeos, de rpido movimiento ya que trabaja bien solo con equipos pequeos. Esta metodologa necesita solo miembros de equipo experimentados. Si el equipo consiste en gente que son junior, el proyecto no puede ser completado a tiempo. Adems de los recursos sin suficiente experiencia , la falta de direccin firme pueden llevar a los proyectos a no completarse o incluso fallar.

 La metodologa Scrum funciona bien cuando el scrum master confa en el equipo que lleva. Si se practican controles muy estrictos sobre los miembros del equipo, puede ser extremadamente frustrante para ellos, llevando a la desmoralizacin y el fallo del proyecto. Si algunos de los miembros del equipo se marcha durante el desarrollo puede tener un efecto negativo enorme en el desarrollo del proyecto. El control de la calidad del proyecto es difcil de implementar y cuantificar a menos que el equipo de test pueda llevar a cabo testeo de regresin despus de cada sprint.

Conclusiones Scrum en pocas palabras (Kniberg, H ,n.d.) Divide tu organizacin en equipos pequeos, interdisciplinarios y auto-organizados. Divide el trabajo en una lista de entregables pequeos y concretos. Ordena la lista por orden de prioridad y estima el esfuerzo relativo de cada elemento. Divide el tiempo en iteraciones cortas de longitud fija (generalmente de 1 a 4 semanas), con cdigo potencialmente entregable y demostrado despus de cada iteracin.

 Optimiza el plan de entregas y actualiza las prioridades en colaboracin con el cliente, basada en los conocimientos adquiridos mediante la inspeccin del entregable despus de cada iteracin. Optimiza el proceso teniendo una retrospectiva despus de cada iteracin.

Bibliografa Juan Palacio, C. R. (Enero de 2011). Scrum Manager. Obtenido de Gestion de proyecto: http://www.scrummanager.net/files/sm_proyecto.pdf Scrum Alianza: Transformando el Mundo del Trabajo - Alianza Scrum .(Nd). Obtenido de http://www.scrumalliance.org SCRUM by Alonso Dorado C on Prezi. (n.d.). Tomado de http://prezi.com/dudbm_j8g21/scrum/ Hundermark, P. (Noviembre de 2009). Un Mejor Scrum . Obtenido de http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf Kniberg, H. (n.d.). Scrum y XP desde las trincheras. Tomado de http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-lastrincheras.pdf Beneficios de Scrum | Proyectos giles . (Nd). Obtenido de http://www.proyectosagiles.org/beneficios-de-scrum Muos, J. F. (s.f.). Proyectos Integradores UCM. Obtenido de Desarrollo de Software para dispositivos moviles : http://integradores.wikispot.org/Proceso_para_el_desarrollo_de_software_para_dispositiv os_m%C3%B3viles. Desarrollo gil de software - Wikipedia, la enciclopedia libre . (Nd).Consultado el 08 de septiembre 2013, a partir de http://es.wikipedia.org/wiki/Metodolog% C3% ada_% C3% A1gil INFOMANIAUPT: Metologas . (Nd). Obtenido de http://infomaniaupt.blogspot.mx/p/metologias.html Facultad de Ingeniera y Arquitectura USMP (2012, March 29).CONFERENCIA SOBRE METODOLOGA SCRUM Y ASEGURAMIENTO DE LA CALIDAD. Obtenido de http://www.usmp.edu.pe/publicaciones/boletin/fia/info83/notifia/novedades177.html?TB_ifr ame=true&height=550&width=500

Manuel Trigas Gallego (n.d.). Metodologia SCRUM. Obtenido de http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memori a.pdf SCRUM Development Process -- po Ken Schwaber. (n.d.). Obtenido de http://geekswithblogs.net/emanish/archive/2008/10/24/126087.aspx Software Development Process | Maxxor. (n.d.). Tomado de http://www.maxxor.com/software-development-process Blog Mazzive (2009, February 3). El poder de la retroalimentacin en Scrum. Obtenido de http://mazzive.com/blog/?p=12 Dan Rawsthorne y Douglas E. Shimp (2010, March). How to Scrum. Retrieved from http://www.executivebrief.com/agile/how-to-scrum/ What is Agile? | What is Scrum? | cPrime. (n.d.). Retrieved from https://www.cprime.com/resources/what-is-agile-what-is-scrum/ http://www.ecured.cu/index.php/Metodolog%C3%ADa_Scrum Jeff Sutherland, Ph.D. Ken Schwaber (2007, October 14). The Scrum Papers. Tomado de http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052 The State of Scrum: Benchmarks and Guidelines. (2013, June). Obtenido de http://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/St ate%20of%20Scrum/2013-State-of-Scrum-Report_062713_final.pdf Artefactos de Scrum . (s.f.). Obtenido de https://sites.google.com/site/oeguzman/8artefactosdescrum Grafeuille, E. (Noviembre de 2008). Obtenido de Una introduccion a SCRUM: http://www.mountaingoatsoftware.com/presentations/an-introduction-to-scrum/ Oiver Andrs Prez A. (2011). Cuatro enfoques metodologicos para el desarrollo de software RUP-MSF-XP-SCRUM. En O. A. A., Cuatro enfoques metodologicos para el desarrollo de software RUP-MSF-XP-SCRUM (pgs. 73-76). Facultad de Ingeniera UNIMINUTO. Software, M. G. (s.f.). Scrum Formacin de Sprint Backlog. Obtenido de http://www.mountaingoatsoftware.com/scrum/sprint-backlog