Scrum & Scrum de Scrums (I)

enero 06, 2014

Después de un tiempo sin poder escribir por causas de fuerza mayor, por fin tengo tiempo para volver a dedicarle tiempo a este pequeño espacio que tanto quiero.

Mi compañera Gema Gutiérrez y yo hemos elaborado un informe sobre que dice la teoría del manejo de múltiples equipos Scrums. Hemos investigado diversas fuentes, como páginas "agilistas" de renombre, foros y blogs de expertos así como libros de culto. Es bastante interesante ver como en el mundo este de lo "ágil" se lleva escribiendo tanto tiempo y lo poco que hay escrito sobre lo que pasa en la realidad. De todas formas ha sido interesante explorar un poco este tipo de soluciones porque tarde o temprano estaremos involucrados en uno y siempre viene bien tener empollada la teoría a tope.

Como aún no he explicado Scrum en este blog, y aunque hay miles de post, libros, artículos, revistas que hablan sobre ello (porque explicarlo está chupado, lo difícil es aplicarlo), pues voy a explicarlo por encima, para que sepamos de que hablamos. Una vez finalizada la explicación de Scrum, le daremos caña a Scrum de Scrums en un articulo posterior, por lo tanto esto es un bipost:

Scrum & Scrum de Scrums (I)
Scrum & Scrum de Scrums (II)

Haré un pequeño resumen de Scrum de manera que es muy posible que haya cosas que me deje en el tintero, por lo que os recomiendo que os leáis cuando podáis el siguiente libro:

Agile Project Management with Scrum - Ken Schwaber

Ken es uno de los padres de Scrum, así que es la mejor manera de aprender.

¡Comencemos!

Introducción

Scrum se ha convertido en uno de los frameworks más famosos para gestionar equipos y ha ido creciendo el número de empresas que lo utilizan en los últimos años. Los productos desarrollados utilizando Scrum son cada vez más complejos y exige tener a varios equipos trabajando de forma sincronizada, por lo que surge la necesidad de encontrar alguna solución que nos permita seguir utilizando esta metodología ágil eficientemente.

En el presente documento daremos unas pinceladas a Scrum y veremos como podemos resolver la gestión de varios equipos que estén construyendo un mismo producto proponiendo unas buenas prácticas y estableciendo una serie de pautas recomendadas, apoyándonos en distintas fuentes expertas.

Para finalizar y una vez estudiadas las soluciones, ofreceremos unas conclusiones aportando nuestra visión personal a Scrum de Scrums.

Scrum

La construcción de software ha ido evolucionando y con el paso del tiempo hemos intentado encontrar aproximaciones más eficientes para la gestión de equipos de desarrollo software. Para la resolución satisfactoria de los proyectos se aplican metodologías de gestión de equipos basadas en los distintos modelos de ciclo de vida del desarrollo software. Durante un tiempo la gestión de equipos en el mundo de la informática estaba gobernada por las metodologías clásicas/pesadas/llave en mano, que basaban su ciclo de vida en modelos cascada donde lo importante era:

· Documentación: delimitaba las etapas del desarrollo, las etapas y los roles de cada etapa.

· Etapas: cada etapa estaba diferenciada de la otra y típicamente se pueden resumir en Análisis, Diseño, Implementación, Pruebas y Mantenimiento.

· Roles: cada etapa tenía unos roles muy definidos y los equipos estaban formados por especialistas, donde había trabajadores especializados en cada etapa y no tenían conocimientos de cómo desarrollar aquellas que no pertenecieran a la suya.

Esto conlleva una serie de problemas intrínsecos a la manera en la que actúa esta metodología y que además se suma al echo de que construir software no es lo mismo que construir edificios. En respuesta a esa realidad surgieron varias metodologías que se escudaron bajo el manifiesto ágil. Una de estas metodologías ágiles era Scrum que encajaba directamente con el manifiesto ágil y resolvía los problemas típicos de las metodologías clásicas.

A continuación veremos en que consiste Scrum y por qué se ha hecho tan famoso en los últimos años.

Un vistazo al Framework

Scrum es un framework que permite desarrollar software prototipando a través del desarrollo de distintas piezas del producto mediante iteraciones y favoreciendo la robustez y solidez del desarrollo mediante la aplicación de incrementos en cada iteración. En Scrum lo principal son las personas y las interacciones que existan entre ellas. Tanto es así que los roles y las herramientas que ofrece Scrum están orientados a favorecer la comunicación entre las distintas partes implicadas en el desarrollo de un producto software.

Dado que el objetivo de este trabajo es explicar como organizar, mantener y elaborar un proyecto de Scrum de Scrums, sólo vamos a explicar por encima las principales piezas o elementos que forman Scrum.

El regalo consiste en el primero que:

1. Comente en este Post.
2. Me esté siguiendo o me siga en Twitter.
3. Retwitee y haga fav a este post(de mi tweet original)

Se llevará una copia para origin de Dead Space 3 que me han dado los Reyes Magos para uno de mis lectores.

Roles

En Scrum podemos encontrar tres roles principales:

· Product Owner: es el propietario o el representante del propietario del producto software que se vaya a presentar. Es uno de los papeles más importantes dentro del equipo Scrum, puesto que creará y priorizará las Historias de Usuario y evaluará el producto entregable en cada iteración.

· Equipo: son todas las personas involucradas en el desarrollo del producto. Los equipos son auto-organizados y multidisciplinares.

· Scrum Máster: es el facilitador. Se encarga de tener una visión global del producto y de ayudar al Equipo y al Scrum Máster para finalizar con éxito el desarrollo completo del producto software.

Componentes

La siguiente ilustración muestra una visión global de Scrum:

Scrum está compuesto por los siguientes artefactos:

· Product Backlog: es un repositorio en el que se encuentran las historias de usuario priorizadas por el Product Owner.

· Sprint Backlog: es un repositorio para el equipo, en el que hay unas pocas Historias de Usuario correspondientes a ese Sprint que serán dividas en tareas a desarrollar. Los Sprint suelen durar de dos a cuatro semanas.

· Gráfico Burndown: es una herramienta que nos permite obtener métricas de velocidad del equipo y resolver futuros impedimentos, así como solucionar problemas de comunicación en tiempo real.

Por otra parte, en Scrum están definidas las reuniones que se deben aplicar:

· Sprint Planning: reunión al comienzo del Sprint en la que se planificará y establecerá un objetivo claro para finalizar con éxito el Sprint.

· Daily Meeting: reunión diaria de sincronización del Equipo, que no debe sobrepasar los quince minutos de duración.

· Sprint Review: es el momento en el que el Equipo y el Product Owner observarán el Sprint conjuntamente para ofrecer una mayor eficiencia en sucesivas iteraciones y evaluar el producto entregado.

· Sprint Retrospective: se verán los impedimentos que surgieron durante el Sprint y se evaluará como se puede ser más productivo en siguientes Sprints.

Y hasta aquí la primera parte del post, nos vemos en la siguiente.

Recordad que también seguiremos con las series:

· Modelos de Ciclo de Vida del Software

· Paradigmas BigData

Javi

Working with Data since 2012.

2 comentarios

JadakiPro31 de mayo de 2017, 13:50
Hola! Curiosamente nadie ha omentado y reclamado Dead Space?¿ :P

Me ha parecido abstante interesante, acabo de terminar recientemente un Master en Big Data y, curiosamente mi tutor fue Ignacio Bustillo... Lo has mencionado en algún otro post...

Sea como fuere, espero no abandones el blog y si pudieras hablar de metodologías ágiles en el mundo Big Data BI, podría ser curioso.

Un saludo.
ResponderEliminar
Respuestas

Añadir comentario

Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.

Scrum & Scrum de Scrums (I)

Introducción

Scrum