54-58 Management - 36.

qxd

3/19/07

5:25 PM

Page 54

(Management)

El mtodo Scrum
crum es, actualmente, uno de los mtodos
giles para desarrollo de software de mayor
difusin en la industria, junto con Extreme
Programming (XP). Su nombre proviene del
rugby, deporte en el que un scrum es una jugada que permite reiniciar el juego luego de una falta accidental. La
eleccin del nombre busca rescatar el principio de trabajo en equipo que se observa en un scrum de rugby: varios jugadores se toman de los hombros y se esfuerzan
para lograr por s solos y rpidamente un objetivo comn, que consiste en aduearse de la pelota y llevarla
hacia delante.
El creador de Scrum es Jeff Sutherland, uno de los 17
gures agilistas que se reunieron en el ao 2001 para establecer los postulados del desarrollo de software
gil, y redactar y firmar el mtico Manifiesto gil. En
el texto de dicho manifiesto se establecen los objetivos de las metodologas giles, entre los cuales se destaca la preferencia de algunos valores por sobre otros,
por ejemplo:

> Individuos e interacciones, sobre procesos y herramientas.

> Software operativo, sobre documentacin extensiva.
> Colaboracin con el cliente, sobre negociacin de
contratos.

Backlog de
producto

> Respuesta a los cambios, sobre cumplimiento estricto de un plan.

En estos postulados se observa la intencin de los agilistas de rebelarse contra los vicios tpicos de los procesos tradicionales de desarrollo de software: planes que no se cumplen o que se extienden ms all
de los plazos, documentacin que exige demasiado trabajo de elaboracin y no refleja la realidad del producto final, contratos que terminan
perjudicando a una de las dos partes (desarrollador o cliente) o a ambas, entre otros males.
Scrum intenta atacar esos problemas endmicos del desarrollo de
software rescatando la filosofa de procesos que llev a las automotrices japonesas (con Toyota a la cabeza) a abrumar a sus pares estadounidenses, al superarlos en aspectos tales como productividad y
eficiencia. El secreto de Toyota era tan simple como dar a cada empleado la posibilidad de crear sus propias reglas, junto con la responsabilidad de maximizar la calidad en la parte del desarrollo que le tocaba llevar a cabo.

Caractersticas de un proceso Scrum

La metodologa Scrum asume que el proceso de desarrollo de software es impredecible, y lo trata como a una caja negra controlada, en vez de manejarlo como un proceso completamente definido.
sta es una de las principales diferencias entre Scrum y otras metodologas, como los modelos de espiral o de cascada, en los cuales el
proceso de desarrollo se define por completo desde el inicio. Por tratar de planificar el proceso en forma completa desde el principio, las

Ciclo
diario
Scrum

Backlog de
sprint

Ciclo
mensual

Ejecutable
incremental

Sprint
Reunin de
demostracin
post-sprint

Reunin de
planificacin de sprint

Estndares, tcnicas, procesos,

lineamientos, herramientas
de desarrollo

[Figura 1] En el ncleo del proceso Scrum se observa un ciclo de trabajo de 30 das (sprint) y otro ciclo diario (scrum)
delimitado por reuniones breves del equipo de desarrollo.

54

users.code

54-58 Management - 36.qxd

3/19/07

5:25 PM

Page 55

Desde los inicios del desarrollo de software,

se ha intentado, sin mucho xito, lidiar con
los problemas tpicos de esta disciplina.
Ahora veremos cmo se pueden resolver.

metodologas tradicionales fallan al toparse con algunos problemas habituales del desarrollo de software, como la falta de comprensin de los
requerimientos al empezar el proceso, el cambio en los requerimientos
durante el proceso, o la dificultad para prever los resultados del uso de
nuevas herramientas y tecnologas.
Otra diferencia de Scrum con las metodologas tradicionales es que
no trata el proceso de desarrollo de software como un proceso lineal,
en el que se sigue la secuencia de anlisis, diseo, codificacin y testing. En Scrum, el proyecto puede iniciarse con cualquier actividad, y
cambiar de una a otra en cualquier momento.
Un proyecto administrado mediante Scrum se organiza en iteraciones, llamadas sprints, que normalmente tienen entre dos y cuatro semanas de duracin. Al principio de cada sprint se establece una lista de requerimientos llamada backlog, que debe completarse cuando
ste finalice. A diario se realizan breves reuniones del equipo de desarrollo, en las que se exponen los avances y los problemas encontrados, y se sealan posibles caminos para resolverlos (la resolucin
detallada de estos problemas no debe determinarse durante la reunin, para mantener su brevedad).

Gustavo du Mortier
Gerente de desarrollo en
la empresa MasterSoft
gustavo.dumortier@
mastersoft.com.ar

Revisin de planes de versin (release).

[desarrolladores]

Distribucin, revisin y ajuste

de estndares de producto.
[desarrolladores]

Sprint
Desarrollo
Empaquetado
Revisin
Ajuste
[desarrolladores]

Su majestad el backlog
Un proceso Scrum reconoce tres tipos de backlog: el backlog de producto, el backlog de versin y el backlog de sprint.
El backlog de producto es un repositorio de requerimientos enunciados por los interesados en el xito del proyecto (los llamados stakeholders, que pueden ser usuarios, administradores, tcnicos de soporte,
etc.). Por lo general, los requerimientos incluidos en este backlog son
de alto nivel, evitan detallar cuestiones tcnicas o de implementacin,
y tienen asociadas estimaciones de tiempos tambin de alto nivel, realizadas por los stakeholders.
El backlog de versin (release backlog) consiste en una lista de requerimientos extrada del backlog de producto, priorizada para la prxima
versin (release) del producto. Los elementos de este backlog tienen un
mayor nivel de detalle en cuanto a los requerimientos y tienen asociadas estimaciones ms precisas, realizadas por los miembros del equipo
de Scrum.
El backlog de sprint se arma al principio de cada sprint, y rene
aquellos requerimientos que el equipo se compromete a completar para cuando finalice dicho sprint. Completar un requerimiento implica
codificarlo, testearlo y documentarlo. El backlog de sprint se arma dividiendo los requerimientos del backlog de release en tareas que comnmente pueden completarse en perodos de 8 a 16 horas.

El equipo de trabajo
En Scrum, los equipos de desarrollo deben estar formados por una
cantidad aproximada de siete miembros. El lder del equipo es el denominado Scrum Master, y su trabajo consiste en implementar y administrar el proceso Scrum en el proyecto. Al inicio del proyecto, el equipo debe ponerse de acuerdo en cuanto a las prcticas que se van a implementar, la frecuencia de las reuniones, los artefactos por utilizar, etc.
A partir de all, es responsabilidad del Scrum Master asegurar que el
equipo se atenga a las normas establecidas.
El Scrum Master asume el rol de facilitador, y su autoridad es, en su

Revisin de Sprint
Revisin del software.
Comparacin del backlog con el
software desarrollado.
Edicin del backlog.
Agregado de nuevos puntos al backlog.
Asignar puntos del backlog a los
equipos de desarrollo.
Planificar prxima versin.
[stakeholders]

Anlisis de variables:
tiempo, requerimientos, costo,
calidad. Concuerdan con
los objetivos de
la versin?
S
Cierre.
[stakeholders]

[Figura 2] Fases detalladas del proceso Scrum.

55

54-58 Management - 36.qxd

3/19/07

5:25 PM

Page 56

[management]
Jeff Sutherland cre una metodologa de procesos de desarrollo
que demostr su efectividad para elevar la productividad.

mayor parte, indirecta. Su trabajo consiste en atajar las interferencias externas para que el equipo de desarrollo optimice su productividad, resolviendo los impedimentos que no pueden ser resueltos
por los miembros del equipo. Su responsabilidad tambin incluye el
hecho de asegurar la transparencia del proceso de desarrollo, manteniendo los artefactos definidos para el proceso (ver el recuadro
Los roles de un Scrum).

Las reuniones de Scrum

Las reuniones de Scrum deben llevarse a cabo diariamente, aunque el equipo puede ponerse de acuerdo al inicio para realizarlas con
una periodicidad diferente; por ejemplo, da por medio. Es importante que se efecten siempre en el mismo lugar y a la misma hora, y
que su duracin no exceda los 30 minutos.
Durante la reunin, el Scrum Master hace a cada miembro del
equipo tres preguntas: qu hizo desde la ltima reunin de Scrum,
qu obstaculiz su trabajo y qu planea hacer desde ese momento
hasta la prxima reunin. La conversacin debe limitarse a las respuestas de los miembros del equipo a las tres preguntas anteriores.
Sobre la base de las respuestas obtenidas y de los problemas que stas reflejen, pueden agendarse reuniones para llevar a cabo en forma inmediata luego de la reunin de Scrum, entre un subgrupo del
equipo, para dar solucin a los inconvenientes detectados.
El Scrum Master seala los caminos de solucin a los problemas y
es responsable de identificar impedimentos externos que puedan
frenar el proceso.

Fases de un proceso Scrum

El proceso de desarrollo Scrum se compone de cinco actividades principales: revisin de los planes de release;
distribucin, revisin y ajuste de los estndares de producto; sprint; revisin de sprint, y cierre (ver [Figura 2]).
La fase de sprint es en la que se realiza el desarrollo de
software propiamente dicho. Dentro de un sprint se efectan varias sub-actividades: desarrollo, empaquetado,
revisin y ajuste. No existe secuencia dentro de esta fase. Algunas veces, un tem del backlog debe ser desarrollado, empaquetado y revisado, y otras veces, el tem slo debe ser revisado y ajustado; todo depende de las caractersticas del tem en cuestin.
Cada sprint es seguido por un proceso de revisin. Durante esta etapa, se revisa el software desarrollado en el
sprint que acaba de finalizar y, de ser necesario, se agregan nuevos tem en el backlog. El grupo de revisores debe incluir a los stakeholders, los administradores del
proyecto, los desarrolladores y los usuarios.
Las actividades de sprint y revisin de sprint tienen
que repetirse hasta que el producto est en condiciones
de ser distribuido por los accionistas. Luego, el proyecto
entra en la fase de cierre, tras la cual el producto queda
en condiciones para el cierre de versin (release) y distribucin.
En la fase de cierre, se realizan las ltimas tareas de

Controles
Compuesto por

Backlog

Afecta

Versin
Cuestin

Formado por

Punto del backlog

Paquete

Produce

Componente / objeto
del producto

Solucin
Resuelve

Cambio
Implementa
Problema

Riesgo

[Figura 3] Controles que se aplican durante el proceso Scrum.

56

users.code

54-58 Management - 36.qxd

3/19/07

5:25 PM

Page 57

Los roles de un Scrum

El mtodo Scrum reconoce tres roles: Dueo del producto, Scrum Master y Equipo.

depuracin (debugging), luego de lo cual se construyen los entregables y el proyecto se da por finalizado. Debido a lo imprevisible de los procesos de desarrollo de software, no es posible definir exactamente cundo ocurrir la fase de cierre, de modo que
los proyectos pueden demorarse ms o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se pueden
hacer estimaciones sobre su duracin.

Cmo evitar que se descontrole el proyecto

Hasta aqu hemos explicado cmo se estructura un proceso
Scrum y cmo es la dinmica de trabajo, pero an no vimos las
claves para asegurar que concluya exitosamente en tiempo y en
forma, y que, a la vez, sea flexible y adaptable a los cambios.
En general, en los proyectos de desarrollo que involucran mtodos
giles se fijan los plazos y los costos, pero se permite que los alcances varen de una forma controlada. Los controles son, entonces, la
herramienta imprescindible para que el proyecto arribe a buen puerto. En Scrum se define una serie de aspectos del proceso, que se controlan y miden de forma tal de no anular la cualidad de caja negra
que caracteriza a las etapas de desarrollo. Estos aspectos, o controles,
son los siguientes:
> Puntos del backlog: Requerimientos funcionales del producto
que no son cumplidos adecuadamente por la actual versin.
Bugs, defectos, mejoras pedidas por el usuario, funcionalidad
competitiva y actualizaciones tecnolgicas son otros posibles
puntos del backlog.
> Versin (release): Un conjunto de puntos del backlog que, en
un determinado momento, representan una nueva versin viable del producto, sobre la base de las variables de requerimientos, tiempo, calidad y competencia.
> Paquetes: Componentes del producto u objetos que deben
cambiarse para implementar un punto del backlog en una
nueva versin del producto.
> Cambios: Cambios que deben ocurrir en un paquete para implementar un punto del backlog.
> Problemas: Problemas tcnicos que suceden y deben resolverse para implementar un cambio.
> Riesgos: Los riesgos que afectan el xito del proyecto son continuamente evaluados y se planean respuestas. Otros controles
se ven afectados como consecuencia del anlisis de riesgo.
> Soluciones: Soluciones a los problemas y riesgos, que habitualmente derivan en cambios.
> Cuestiones (issues): Cualquier otra cuestin que afecte al proyecto, y que no se defina en trminos de paquetes, cambios o
problemas.
En la [Figura 3] se observa cmo los controles se conectan entre s y qu influencia tienen unos sobre otros.
Los controles se usan en varias fases de Scrum. La gerencia
del proyecto los emplea para administrar el backlog. Los equipos de desarrollo los utilizan para administrar cambios y problemas. En conjunto, la gerencia y los equipos de desarrollo administran las cuestiones, riesgos y soluciones. Los controles
son revisados, modificados y conciliados en cada reunin de
revisin de un sprint.
La revisin de los controles permite al administrador del

Las responsabilidades del Dueo del producto incluyen

definir las caractersticas del producto, determinar la
fecha de lanzamiento y el contenido, asegurar la rentabilidad del producto, priorizar las caractersticas segn
el valor de mercado, ajustar las caractersticas y las
prioridades cada treinta das (segn sea necesario), y
aceptar o rechazar resultados del trabajo. El Dueo del
producto es responsable por la primera de las tres ceremonias de Scrum: la planificacin.
El Scrum Master es un facilitador y lder de equipo, que
trabaja en contacto estrecho con el Dueo del producto.
Sus responsabilidades abarcan asegurar que el equipo
se mantenga plenamente funcional y productivo; permitir la cooperacin estrecha entre todos los roles y funciones; eliminar las barreras que obstaculicen el desarrollo
del proyecto; proteger al equipo de las interferencias externas, y asegurar que el proceso se lleve a cabo correctamente, asegurando la concurrencia de los involucrados a las reuniones diarias de Scrum, a las revisiones de
sprint y a las planificaciones de sprint.
Durante las reuniones diarias de Scrum, el Scrum
Master debe saber qu tareas han sido completadas,
cules se han iniciado, qu nuevas tareas se han descubierto y qu estimaciones cambiaron. Esto hace posible mantener actualizado el diagrama de burndown,
que muestra, da tras da, el trabajo que queda pendiente. El Scrum Master debe observar cuidadosamente el nmero de tareas abiertas en progreso, para
asegurarse de mantener este nmero en valores ptimos. Debe sacar a la luz las dependencias y los bloqueos que acten como impedimentos para el Scrum,
determinando sus prioridades y realizando su seguimiento. Es preciso implementar un plan de solucin
para estos impedimentos en orden de prioridad. Algunos podrn resolverse con el equipo; otro podrn resolverse entre equipos, y otros requerirn la participacin de la gerencia, ya que pueden ser cuestiones
de la compaa que estn impidiendo a todos los equipos lograr su ptima capacidad de produccin.
Por ltimo, el Scrum Master debe detectar problemas
personales o conflictos dentro del Scrum que necesiten solucin. Estos conflictos deben ser clarificados
por l y resueltos mediante el dilogo dentro del equipo, o bien el Scrum Master puede solicitar ayuda a la
gerencia o a la oficina de recursos humanos.
El Equipo debe ser polifuncional, compuesto por siete
miembros (ms/menos dos). Su labor consiste en seleccionar el objetivo final de cada sprint, especificar los
resultados del trabajo y llevarlo a cabo. Posee el derecho de realizar lo que sea dentro de los lmites que
impongan los lineamientos del proyecto para alcanzar el objetivo final de un sprint. Debido a que opera
como una caja negra, debe organizarse a s mismo y
a su trabajo, y debe preparar una demo de los resultados para exhibir ante el Dueo del producto.

57

54-58 Management - 36.qxd

3/19/07

5:26 PM

Page 58

[management]

proyecto obtener mtricas sobre l. Por ejemplo: el nmero de puntos del backlog define el tamao del proyecto, mientras que la cantidad de puntos finalizados
exitosamente indica el progreso logrado. A su vez, la
cantidad de riesgos define la complejidad del proyecto.

No hay balas de plata

Los mtodos giles son comnmente considerados
balas de plata, en especial, por directivos de ingeniera de software que han visto uno o ms proyectos riesgosos concluir con xito luego de aplicar metodologas
tales como Scrum o XP. El problema es que el xito de
unos pocos casos es difcil de replicar en la mayora.
La idea detrs de las balas de plata es que, al utilizarlas, se puede poner a cualquier persona a desarrollar
software. Los procesos giles traen un lema diferente: el

desarrollo de software es una tarea complicada, por lo que ofrece un

marco de trabajo y un conjunto de prcticas con los cuales se facilitar comprometer y administrar equipos en este dificultoso trabajo. No se hace el intento por hacer creer que el trabajo es fcil o que
puede ser realizado por personas sin experiencia, indiferentes o incompetentes. En cambio, los procesos giles, simplemente, logran
que el impacto del trabajo de profesionales sin la necesaria capacidad se haga visible y evidente en forma temprana, y pueda ser tratado como corresponda.
Otras metodologas cometen el error de ocultar los malos resultados hasta el final del proyecto, y en algunos casos, los malos resultados afloran despus de terminarlo, cuando alguien intenta efectuar mantenimiento o cambios en el software. Los procesos giles,
en cambio, comunican las malas noticias apenas stas se producen,
para que puedan ser atacadas antes de que alcancen una magnitud
capaz de poner en riesgo al proyecto en su totalidad.

Sugerencias de su creador
En exclusiva, gracias a la gente de
Baufest (www.baufest.com), tuvimos
la posibilidad de reunirnos con el Dr.
Jeff Sutherland, creador de la metodologa Scrum y coautor del Manifiesto gil. l mismo nos cuenta cules son los beneficios de esta metodologa que, da a da, las empresas
toman como referente.
Scrum es una forma de gestionar
proyectos de software. No es una
metodologa de anlisis, ni de diseo, como podra ser RUP, sino una
metodologa de gestin del trabajo.
Una de las caractersticas ms importantes es que es muy fcil de explicar y de entender, lo que contribuye mucho a su implantacin.
Cmo ayuda Scrum en la evolucin del
desarrollo de software?
Scrum puede ser aplicada a distintos
modelos de calidad (como podra ser
CMMI), puesto que stos dicen qu
tendramos que hacer o qu deberamos gestionar en el proyecto, pero
no nos dicen cmo hacerlo. Ah es
donde entra Scrum como modelo de
gestin del proyecto. Los siguientes
son los elementos bsicos de esta
metodologa:
> Una lista, llamada Product Backlog,
con las funcionalidades de la apli-

58

Dr. Jeff Sutherland

CTO de PatientKeeper
cacin ordenadas de mayor a menor importancia. No hace falta
que contenga todas las funcionalidades inicialmente.
> De la lista anterior, se toman las
primeras funcionalidades, se descomponen en tareas y se las anota
en otra lista, que se llama Sprint
Backlog. Estas tareas sern realizadas en el siguiente mes.
Adems de estos elementos, existen
unas cuantas reglas bsicas y sencillas que deberemos cumplir:
> Una vez que se pasan las tareas
prioritarias del Product Backlog al
Sprint Backlog, no se las puede cambiar; esto quiere decir que el trabajo
de un mes queda fijado. sta es la

regla ms importante de todas.

> Al final del mes perodo que se
denomina sprint, hay que tener
un ejecutable con las funcionalidades del Sprint Backlog.
> Todos pueden aadir funcionalidades al Product Backlog, pero
slo una persona puede ordenarlo. A esta persona se la denomina
Product Owner, y es el responsable del producto final.
> Cada da se hace una reunin de
menos de 15 minutos, en la que
se rene todo el equipo ingenieros y gestor (llamado Scrum Master), y cada miembro expone slo los siguientes temas:
Qu se hizo el da anterior?
Qu se va a hacer hoy?
Qu impedimentos tengo para
realizar mi trabajo?
Slo se tratan estos temas para
que la reunin sea rpida y no se
malgaste el tiempo de los dems.
Si es necesario tratar otro tema,
se hace otra reunin slo con las
personas implicadas.
> Al final del mes (es decir, al final
del sprint), se presenta el producto y se toman del Product Backlog
ordenado las funcionalidades para cubrir en el siguiente mes.
users.code