Aprenda Scrum como si estuviera en primero (I)

En este artículo pretendo mostrar las características básicas de esta metodología de desarrollo software creada en 1990 por Ken Schwaber y Jeff Sutherland, en el marco de lo que posteriormente se denominó como metodologías ágiles de desarrollo de software. La redacción de este artículo es totalmente propia, si bien cuenta con numerosa documentación al final.

Ideas fundamentales

¿Qué diferencia a Scrum (el nombre viene de una técnica de rugby) de otras metodologías? Fundamentalmente una cosa: Scrum entiende el desarrollo de software como algo empírico, y no determinista. Esto significa que Scrum comprende que crear software es algo muy complejo, sujeto a multitud de variaciones e incertidumbres, sobre todo al comienzo. Además cada problema es diferente y no existe una solución mágica o bala de plata que se pueda aplicar a cualquier proyecto (Peopleware, deMarco y Lister). Por ello trata de acometer esta incertidumbre y estos riesgos desde el propio modelo de desarrollo.

Otra caracterísitica fundamental de Scrum es la visibilidad. Scrum trata de que todo el mundo involucrado en el proyecto conozca perfectamente en qué punto del desarrollo se encuentra el proyecto y qué falta por hacer. Esto se consigue a través de las numerosas reuniones de control, que no tratan de informar al jefe de proyecto o los stakeholders, sino más bien a TODAS las personas involucradas en el proyecto. El objetivo no es sólo el control del proyecto, sino la involucración y el conocimiento por parte de todos. Además, es importante que el equipo esté cohesionado y colaboren unos miembros con otros, se solapen y se apoyen mutuamente.

Scrum no es una metodología “mágica” (Peopleware, deMarco y Lister), sino un marco de posibles estrategias, respetando unas reglas prefijadas. Una plantilla a la que después se puede acoplar distintas técnicas de planificación, gestión, control, estimación, análisis, diseño, implementación y pruebas. En esta simplicidad radica su potencial. Las reglas del juego se aprenden más rápido que aprender a jugar al parchís, realmente.

Otra idea fundamental de Scrum es que trata todo el desarrollo del software desde el punto de vista del sentido común. A medida que profundicemos en la metodología en las siguientes secciones (y opcionalmente consultando la bibliografía adjunta) conoceremos cómo se utiliza el sentido común para desarrollar software. También veremos que es una metodología flexible.

Desde el punto de vista de desarrollo, se trata de un proceso fundamentalmente iterativo. Más adelante se detallan las fases y cómo se estructuran las iteraciones.

Aplicabilidad de la metodología

Por lo expuesto anteriormente, se entiende que Scrum es aplicable a cualquier tipo y tamaño de proyectos, si bien es especialmente útil en proyectos medios y grandes en cuanto a complejidad o a tamaño, o bien en aquellos proyectos donde la incertidumbre es grande, bien por el campo en el cual se desarrolla, o bien porque los requisitos no están bien definidos desde el principio y son muy susceptibles de cambiar durante el desarrollo.

Conceptos

La metodología utiliza una serie de tecnicismos para referirse a determinados artefactos, roles y actividades (desde el punto de vista de la terminología RUP), stakeholders y demás:

Backlog: documento en el cual se detallan, de forma priorizada, los requisitos del sistema.
Sprint: cada una de las iteraciones de que se compone el desarrollo con Scrum. Si existe razón de suficiente peso, puede abortarse el sprint y comenzar uno nuevo.
Backlog sprint: “trozo” de backlog que nos comprometemos a implementar de forma satisfactoria en el sprint (iteración) actual.
ProductOwner: Cliente fundamental del sistema. El que desea o propone el software. El propietario del producto. El ‘input’ principal para poner en marcha el nuevo proyecto. Es fundamental que la persona que desempeña este rol se implique al máximo en el proyecto, para que éste tenga garantías de éxito.
ScrumMaster: Gestor del proyecto un poco especial: motiva al equipo. Crea un clima en el cual el equipo trabaje a gusto y sin interrupciones: protege a su equipo. Sin embargo, le deja trabajar libremente. No debe fallar al equipo. No debe faltar a ninguna reunión. Siempre estará ahí, para atender las necesidades del equipo. Es más un “líder” que un “gestor” al uso. Ken Schawber dice que es como el perro pastor de un rebaño de ovejas. Vigila y protege a las ovejas, pero sin molestarlas, sin intervenir prácticamente en sus cometidos.
Team: Equipo de desarrollo. Cada equipo estará compuesto por 7 +-2 personas (es decir: entre 5 y 9 personas, preferiblemente 7). El ScrumMaster jamás intervendrá aquí. El equipo debe estar cohesionado y debe promoverse la filosofía de “todos ayudan a todos”. El equipo se autogestiona a sí mismo. Los miembros del equipo no tienen roles: colaboran entre ellos y “todos hacen de todo”: análisis, diseño, implementación, pruebas y documentación. De este modo no se rompe la continua colaboración y desarrollo de las funcionalidades del proyecto.

En esta metodología existen dos roles bastante graciosos y que dan forma a Scrum: cerdos (pigs) y gallinas (chicken). La denominación viene de un popular chiste: 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, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta: “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”.

En Scrum, los cerdos (aquellos que están comprometidos de forma seria con el proyecto) son desempeñados por los subroles Team, ScrumMaster y ProductOwner. El rol gallina está constituído por otros clientes y stakeholders (ejecutivos, etc.). Al final, todos los roles “cerdo” son gestores (managers), desde el momento en el que se dice que están comprometidos con el proyecto.

NOTA: A pesar de mi marcado desprecio del uso de anglicismos y del ‘spanglish’, mantendré el nombre de los roles en inglés, por correspondencia con la idea original.

(Continuará)

5 pensamientos en “Aprenda Scrum como si estuviera en primero (I)

  1. Excelente resumen, aunque desgraciadamente soy demasiado escéptico con todas las metodologías ágiles. La mayoría de ellas parten de la base en la que “el cliente” sabe lo que quiere, y esto en mi corta experiencia (5 años) es una utopía.

    A parte tenemos el problema que la infórmatica ha pasado a ser un corre corre, con proyectos que deberían estar para ayer, antes de empezar y donde es imposible sentarse a hacer reuniones de control, o simplemente establecer unas guias de como hacer las cosas, para intentar que el código sea los más homogeneo posible.

    De todas formas, te vuelvo a felicitar por el artículo, y espero la siguiente parte.

  2. No Indigo, las metodologías ágiles no parten de que el cliente sabe lo que quiere.

    Metodologías como Scrum planean sprints que pueden ir de 2 a 6 semanas y al final de cada Sprint congelan una versión que muestran al cliente, el cliente cada poco tiempo ve lo que le ofrecen y ve si concuerda o no con su visión. Así si el cliente no tiene ni la más remota idea después de trabajar las primeras semanas verá que no es lo que quería y el equipo podrá cambiar sólo habiendo “perdido” (es también muy complicado que todo sea tiempo perdido) unas semanas.

    Existe otro mecanismo en las metodlogías ágiles para minimizar el riesgo de que el cliente no sepa lo que quiere y es el hecho de integrar al cliente totalmente en el proyecto, como dice el artículo de Luis, el cliente está comprometido. En esas reuniones de final y comienzo de Sprint es todo el equipo es que participa en la reunión y acribilla a preguntas al Product Owner para minimizar los malentendidos.

    En metodlogías clásicas como el CMMI si el cliente no sabe lo que quiere o el encargado de la toma de requisitos no lo comprende se pueden perder meses de desarrollo, ya que el cliente no ve lo que se está trabajando.

    Lo que me parece una utopía es que una a dos personas cojan los requisitos, sin que el cliente o la persona que se encarga de esa tarea se equivoque y que a lo largo de meses el equipo no pierda el foco o el cliente no cambie de opinión. Cuanto más tiempo pase sin tener feedback del cliente final más se separará el proyecto de la línea que el cliente tenía en mente.

    Todo esto estaría genial en el un hilo en debug_mode=ON😀 Creo que luego abriré un hilo con mi reflexión y parte de tu comentario, te animo a participar ahí.

    Un saludo,

  3. Muy interesante lo que comentáis. Simplemente un apunte que no sé si digo en el artículo o en la segunda parte que aún no he publicado: existe un mecanismo para estudiar el avance en el proyecto, que se llama diagrama “burn-down”. No voy a explicar aquí de qué va, pero si se detecta que no se avanza en el proyecto porque el cliente está continuamente cambiando requisitos puede decidirse abortar el Sprint y no seguir más. Ocasionalmente apretarle las tuercas al ProductOwner y hacerle ver la situación.

    Por otra parte, como diré en la segunda parte del artículo, inicialmente no se conocen cuántos Sprints serán necesarios para culminar el proyecto. Esto refleja perfectamente la cualidad empírica de la metodología.

    Muchas gracias por vuestras aportaciones.

  4. Un comentario Luis,

    En teoría el usuario no puede cambiar requisitos en mitad de un Sprint, para ello el equipo de desarrollo selecciona las tareas que se van a realizar durante el Sprint, para que el usuario no pueda añadir o quitar cosas. Digo en teoría porque no es fácil, para ello se necesita que el Scrum Master sea una persona fuerta y pueda decirle NO al Product Owner.

    Un saludo,

  5. Exacto. El Sprint Backlog es tan inamovible que si el ProductOwner se pone pesado con que le urge tal o cual cosa el ScrumManager le propondrá abortar el Sprint actual y redefinir el Sprint Backlog para reflejar esas nuevas peticiones, comenzando así un nuevo Sprint.

    Lo más natural es que el ProductOwner se replantee en ese momento si realmente le corre tanta prisa esas nuevas funcionalidades como para detener el proceso… XDD

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s