{"id":2629,"date":"2012-10-22T20:41:33","date_gmt":"2012-10-22T18:41:33","guid":{"rendered":"http:\/\/www.palentino.es\/blog\/?p=2629"},"modified":"2014-11-07T23:47:50","modified_gmt":"2014-11-07T22:47:50","slug":"resumen-de-la-metodologia-scrum-para-el-desarrollo-del-software-historia-caracteristicas-roles","status":"publish","type":"post","link":"https:\/\/www.palentino.es\/blog\/resumen-de-la-metodologia-scrum-para-el-desarrollo-del-software-historia-caracteristicas-roles\/","title":{"rendered":"Resumen de la metodolog\u00eda Scrum para el desarrollo del software – Historia – Caracter\u00edsticas – Roles"},"content":{"rendered":"

Scrum\u00a0<\/strong>es una\u00a0metodolog\u00eda\u00a0\u00e1gil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas pr\u00e1cticas de producci\u00f3n por Hirotaka Takeuchi e Ikujijo Nonaka.<\/p>\n

Sepamos algo m\u00e1s …<\/p>\n

<\/p>\n

En\u00a01986\u00a0Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximaci\u00f3n hol\u00edstica que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales. Takeuchi y Nonaka comparan esta nueva aproximaci\u00f3n hol\u00edstica (El holismo supone que todas las propiedades de un\u00a0sistema<\/strong>\u00a0no pueden ser determinadas o explicadas como la suma de sus componentes. En otras palabras, el holismo considera que\u00a0el sistema completo se comporta de un modo distinto que la suma de sus partes<\/strong>.)\u00a0en la cual las fases son realizadas por un equipo con funciones transversales, como en el rugby<\/strong>, donde el equipo entero \u00abact\u00faa como un s\u00f3lo hombre para intentar llegar al otro lado del campo, pasando el bal\u00f3n de uno a otro\u00bb<\/strong>.<\/p>\n

Los casos de estudio provienen de las industrias automovil\u00edsticas, as\u00ed como de fabricaci\u00f3n de m\u00e1quinas fotogr\u00e1ficas, computadoras e impresoras.<\/p>\n

En\u00a01991\u00a0Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions<\/strong> (A problemas malvados, soluciones virtuosas), se refirieron a esta aproximaci\u00f3n como scrum (mel\u00e9 en ingl\u00e9s<\/strong>), un t\u00e9rmino propio del rugby mencionado en el art\u00edculo por Takeuchi y Nonaka.<\/p>\n

A principios de los a\u00f1os\u00a01990\u00a0Ken Schwaber emple\u00f3 una aproximaci\u00f3n que lo llev\u00f3 a poner en pr\u00e1ctica el scrum en su compa\u00f1\u00eda, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarroll\u00f3 una aproximaci\u00f3n similar en Easel Corporation y fue el primero en denominarla scrum. En\u00a01995\u00a0Schwaber y Sutherland, durante el OOPSLA ’95 desarrollado en\u00a0Austin, presentaron en paralelo una serie de art\u00edculos describiendo scrum, siendo \u00e9sta la primera aparici\u00f3n p\u00fablica de la metodolog\u00eda.<\/p>\n

Durante los a\u00f1os siguientes, Schwaber y Sutherland, colaboraron para consolidar los art\u00edculos antes mencionados, as\u00ed como sus experiencias y el conjunto de mejores pr\u00e1cticas de la industria que conforman a lo que ahora se le conoce como scrum.<\/p>\n

En\u00a02001, Schwaber y Mike Beedle describieron la metodolog\u00eda en el libro Agile Software Development with Scrum<\/strong>.<\/p>\n

Caracter\u00edsticas de Scrum<\/h2>\n

Scrum es un modelo de referencia que define un conjunto de pr\u00e1cticas y roles<\/strong>, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar\u00e1 durante un proyecto.<\/p>\n

Los roles principales en Scrum son el ScrumMaster<\/strong>, que mantiene los procesos y trabaja de forma similar al director de proyecto<\/strong>, el ProductOwner<\/strong>, que representa a los stakeholders (clientes externos o internos), y el Team<\/strong> que incluye a los desarrolladores.<\/p>\n

Durante cada sprint<\/strong>, un periodo entre 15 y 30 d\u00edas<\/strong> (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable).<\/p>\n

El conjunto de caracter\u00edsticas que forma parte de cada sprint viene del Product Backlog<\/strong>, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.<\/p>\n

Los elementos del Product Backlog que forman parte del sprint se determinan durante la reuni\u00f3n de Sprint Planning<\/strong>.<\/p>\n

Durante esta reuni\u00f3n, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse<\/strong> a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog<\/strong>, lo que significa que los requisitos est\u00e1n congelados durante el sprint.<\/p>\n

Scrum permite la creaci\u00f3n de equipos autoorganizados impulsando la co-localizaci\u00f3n<\/strong> de todos los miembros del equipo, y la comunicaci\u00f3n verbal entre todos los miembro<\/strong>s y disciplinas involucrados en el proyecto.<\/p>\n

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<\/strong> (a menudo llamado requirements churn<\/strong>), y que los desaf\u00edos impredecibles no pueden ser f\u00e1cilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximaci\u00f3n pragm\u00e1tica, aceptando que el problema no puede ser completamente entendido o definido<\/strong>, y centr\u00e1ndose en maximizar la capacidad del equipo de entregar r\u00e1pidamente y responder a requisitos emergentes.<\/p>\n

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas “post-it”<\/strong> y pizarras<\/strong> hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy f\u00e1cil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.<\/p>\n

Roles en Scrum<\/h2>\n

En Scrum se definen varios roles, estos est\u00e1n divididos en dos grupos: cerdos y gallinas.<\/strong> El nombre de los grupos est\u00e1n inspirados en el chiste sobre un cerdo y una gallina que se relata a continuaci\u00f3n.<\/p>\n

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: “Hey, \u00bfpor qu\u00e9 no abrimos un restaurante?” El cerdo mira a la gallina y le dice: “Buena idea, \u00bfc\u00f3mo se llamar\u00eda el restaurante?” La gallina piensa un poco y contesta: “\u00bfPor qu\u00e9 no lo llamamos “Huevos con jam\u00f3n?” “Lo siento pero no”, dice el cerdo, “T\u00fa s\u00f3lo estar\u00edas involucrada mientras que yo estar\u00eda comprometido”.<\/strong><\/p>\n

 <\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

De esta forma, los ‘cerdos’ est\u00e1n comprometidos a trav\u00e9s de sus aportes ‘directos’ en la construcci\u00f3n de software, mientras que las ‘gallinas’ est\u00e1n involucradas a trav\u00e9s de sus aportes ‘indirectos’.<\/p>\n

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.<\/p>\n

Roles “Cerdo”<\/h3>\n

Los Cerdos son los que est\u00e1n comprometidos con el proyecto y el proceso Scrum; ellos son los que “ponen el jam\u00f3n en el plato”.<\/p>\n

Product Owner<\/h3>\n

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.<\/p>\n

ScrumMaster (o Facilitador)<\/h3>\n

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obst\u00e1culos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el l\u00edder del equipo (porque ellos se auto-organizan), sino que act\u00faa como una protecci\u00f3n 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.<\/p>\n

Equipo<\/h3>\n

El equipo tiene la responsabilidad de entregar el producto. Un peque\u00f1o equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (dise\u00f1ador, desarrollador, etc).<\/p>\n

Roles “Gallina”<\/h3>\n

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximaci\u00f3n \u00e1gil es la pr\u00e1ctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders).<\/p>\n

Es importante que esa gente participe y entregue retroalimentaci\u00f3n con respecto a la salida del proceso a fin de revisar y planear cada sprint.<\/p>\n

An\u00e1lisis de la frase “Rol gallina”:
\nLa gallina alimenta al proyecto “poniendo huevos”, no se ve comprometida como el cerdo que va al matadero.<\/strong><\/p>\n

Usuarios<\/h3>\n

Es el destinatario final del producto. Como bien lo dice la paradoja, El \u00e1rbol cae en el bosque cuando no hay nadie \u00bfHace ruido? Aqu\u00ed la definici\u00f3n ser\u00eda Si el software no es usado \u00bffue alguna vez escrito?.<\/p>\n

Stakeholders (Clientes, Proveedores, Inversores)<\/p>\n

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir\u00e1 el beneficio acordado que lo justifica. S\u00f3lo participan directamente durante las revisiones del sprint.<\/p>\n

Managers<\/h3>\n

Es la gente que establece el ambiente para el desarrollo del producto.<\/p>\n

 <\/p>\n

Reuniones en Scrum<\/h2>\n

Daily Scrum<\/h3>\n

Cada d\u00eda de un sprint, se realiza la reuni\u00f3n sobre el estado de un proyecto.<\/p>\n

Esto se llama “daily standup<\/strong>“. El Scrum tiene unas pautas espec\u00edficas:<\/p>\n

\u00b7 La reuni\u00f3n comienza puntualmente a su hora. A menudo hay castigos<\/strong> -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de pl\u00e1stico del cuello, etc).
\n\u00b7 Todos son bienvenidos, pero s\u00f3lo los “cerdos” pueden hablar<\/strong>.
\n\u00b7 La reuni\u00f3n tiene una duraci\u00f3n fija de 15 minutos<\/strong>, de forma independiente del tama\u00f1o del equipo.
\n\u00b7 Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reuni\u00f3n corta)
\n\u00b7 La reuni\u00f3n debe ocurrir en la misma ubicaci\u00f3n y a la misma hora todos los d\u00edas<\/strong>.<\/p>\n

Durante la reuni\u00f3n, cada miembro del equipo contesta a tres preguntas:<\/p>\n

\u00b7 \u00bfQu\u00e9 has hecho desde ayer?
\n\u00b7 \u00bfQu\u00e9 es lo que est\u00e1s planeando hacer hoy?
\n\u00b7 \u00bfHas tenido alg\u00fan problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).<\/p>\n

Scrum de Scrum<\/h3>\n

Cada d\u00eda normalmente despu\u00e9s del \u201cDaily Scrum\u201d<\/p>\n

\u00b7 Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfoc\u00e1ndose especialmente en \u00e1reas de solapamiento e integraci\u00f3n.
\n\u00b7 Asiste una persona asignada por cada equipo.<\/p>\n

La agenda ser\u00e1 la misma como del Daily Scrum, adem\u00e1s de las siguientes cuatro preguntas:<\/p>\n

\u00b7 \u00bfQu\u00e9 ha hecho tu equipo desde nuestra \u00faltima reuni\u00f3n?
\n\u00b7 \u00bfQu\u00e9 har\u00e1 tu equipo antes que nos volvamos a reunir?
\n\u00b7 \u00bfHay algo que demora o estorba a tu equipo?
\n\u00b7 \u00bfEst\u00e1s a punto de poner algo en el camino del otro equipo?<\/p>\n

Reuni\u00f3n de Planificaci\u00f3n del Sprint (Sprint Planning Meeting<\/strong>)<\/p>\n

Al inicio del ciclo Sprint (cada 15 o 30 d\u00edas), una \u201cReuni\u00f3n de Planificaci\u00f3n del Sprint\u201d se lleva a cabo.<\/p>\n

\u00b7 Seleccionar que trabajo se har\u00e1.
\n\u00b7 Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomar\u00e1 hacer el trabajo.
\n\u00b7 Identificar y comunicar cu\u00e1nto del trabajo es probable que se realice durante el actual Sprint
\n\u00b7 Ocho horas como l\u00edmite.<\/p>\n

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la \u201cReuni\u00f3n de Revisi\u00f3n del Sprint\u201d y la \u201cRetrospectiva del Sprint\u201d.<\/p>\n

Reuni\u00f3n de Revisi\u00f3n del Sprint (Sprint Review Meeting)<\/h3>\n

\u00b7 Revisar el trabajo que fue completado y no completado.
\n\u00b7 Presentar el trabajo completado a los interesados (alias \u201cdemo\u201d).
\n\u00b7 El trabajo incompleto no puede ser demostrado.
\n\u00b7 Cuatro horas como l\u00edmite.<\/p>\n

Retrospectiva del Sprint (Sprint Retrospective)<\/h3>\n

Despu\u00e9s 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\u00e9n superado. El prop\u00f3sito de la retrospectiva es realizar una mejora continua del proceso. Esta reuni\u00f3n tiene un tiempo fijo de cuatro horas.<\/p>\n

<\/h2>\n

Documentos<\/h2>\n

Product backlog<\/h3>\n

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones gen\u00e9ricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas seg\u00fan su retorno sobre la inversi\u00f3n (ROI<\/strong>) . Es el qu\u00e9 va a ser construido.<\/p>\n

Es abierto y cualquiera puede modificarlo<\/strong>. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimaci\u00f3n ayuda al product owner a ajustar la l\u00ednea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos caracter\u00edsticas tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendr\u00e1 probablemente m\u00e1s prioridad, debido a que su ROI ser\u00e1 m\u00e1s alto.<\/p>\n

Sprint backlog<\/h3>\n

El sprint backlog es un documento detallado donde se describe el c\u00f3mo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duraci\u00f3n superior a 16 horas. Si una tarea es mayor de 16 horas, deber\u00e1 ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.<\/p>\n

Burn down<\/h3>\n

La burn down chart<\/strong> es una gr\u00e1fica mostrada p\u00fablicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una l\u00ednea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta l\u00ednea sea descendente (en casos en que todo va bien en el sentido de que los requisitos est\u00e1n bien definidos desde el principio y no var\u00edan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay m\u00e1s requisitos pendientes de ser completados en el Backlog). Si durante el proceso se a\u00f1aden nuevos requisitos la recta tendr\u00e1 pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variar\u00e1 o incluso valdr\u00e1 cero en algunos tramos.<\/p>\n

 <\/p>\n

\"\"<\/a>

Escenario Scrum<\/p><\/div>\n

 <\/p>\n

Scrum aplicado al desarrollo de software<\/h2>\n

Aunque surgi\u00f3 como modelo para el desarrollo de productos tecnol\u00f3gicos, tambi\u00e9n 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.<\/p>\n

Jeff Sutherland<\/strong><\/a> aplic\u00f3 el modelo Scrum al desarrollo de software en 1993<\/strong> en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integrar\u00eda en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo present\u00f3 junto con Ken Schwaber como proceso formal, tambi\u00e9n para gesti\u00f3n del desarrollo de software en OOPSLA 96. M\u00e1s tarde, en 2001 ser\u00edan dos de los promulgadores del Manifiesto \u00e1gil<\/a>.<\/strong> En el desarrollo de software scrum est\u00e1 considerado como modelo \u00e1gil por la Agile Alliance<\/a>.<\/p>\n

La imagen inferior incluye una descripci\u00f3n sin\u00f3ptica<\/strong> del proceso y sus elementos que son:<\/p>\n

\u00b7 Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
\n\u00b7 Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
\n\u00b7 Reuniones:\u00a0Planificaci\u00f3n del sprint, Revisi\u00f3n diaria, Revisi\u00f3n del sprint.
\n\u00b7 Sprint.<\/p>\n

 <\/p>\n

 <\/p>\n

\"\"<\/a>

Proceso Scrum<\/p><\/div>\n

Nota: Por favor, recuerda si te ha gustado, puedes contribuir con aportaciones publicitarias, \u00a0para caf\u00e9s al menos \";-)\"<\/p>\n

Eso es todo. Saludos.<\/p>\n","protected":false},"excerpt":{"rendered":"

Scrum\u00a0es una\u00a0metodolog\u00eda\u00a0\u00e1gil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas pr\u00e1cticas de producci\u00f3n por Hirotaka Takeuchi e Ikujijo Nonaka. Sepamos algo m\u00e1s …<\/p>\n","protected":false},"author":1,"featured_media":2632,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32,116,41,7],"tags":[86,293,82],"class_list":["post-2629","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-formacion","category-historia","category-ingenieria-del-software","category-software","tag-agilismo","tag-metodologia","tag-scrum"],"_links":{"self":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/2629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/comments?post=2629"}],"version-history":[{"count":15,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/2629\/revisions"}],"predecessor-version":[{"id":7373,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/2629\/revisions\/7373"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media\/2632"}],"wp:attachment":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media?parent=2629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/categories?post=2629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/tags?post=2629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}