1. 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 54
(Management)
El método Scrum
crum es, actualmente, uno de los métodos > Respuesta a los cambios, sobre cumplimiento estricto de un plan.
S ágiles para desarrollo de software de mayor
difusión en la industria, junto con Extreme
Programming (XP). Su nombre proviene del
rugby, deporte en el que un scrum es una jugada que per-
En estos postulados se observa la intención de los agilistas de rebe-
larse contra los vicios típicos de los procesos tradicionales de desarro-
llo de software: planes que no se cumplen o que se extienden más allá
mite reiniciar el juego luego de una falta accidental. La de los plazos, documentación que exige demasiado trabajo de elabora-
elección del nombre busca rescatar el principio de traba- ción y no refleja la realidad del producto final, contratos que terminan
jo en equipo que se observa en un scrum de rugby: va- perjudicando a una de las dos partes (desarrollador o cliente) o a am-
rios jugadores se toman de los hombros y se esfuerzan bas, entre otros males.
para lograr –por sí solos y rápidamente– un objetivo co- Scrum intenta atacar esos problemas endémicos del desarrollo de
mún, que consiste en adueñarse de la pelota y llevarla software rescatando la filosofía de procesos que llevó a las automo-
hacia delante. trices japonesas (con Toyota a la cabeza) a abrumar a sus pares esta-
El creador de Scrum es Jeff Sutherland, uno de los 17 dounidenses, al superarlos en aspectos tales como productividad y
“gurúes agilistas” que se reunieron en el año 2001 pa- eficiencia. El secreto de Toyota era tan simple como dar a cada em-
ra establecer los postulados del desarrollo de software pleado la posibilidad de crear sus propias reglas, junto con la respon-
ágil, y redactar y firmar el mítico Manifiesto Ágil. En sabilidad de maximizar la calidad en la parte del desarrollo que le to-
el texto de dicho manifiesto se establecen los objeti- caba llevar a cabo.
vos de las metodologías ágiles, entre los cuales se des-
taca la preferencia de algunos valores por sobre otros, Características de un proceso Scrum
por ejemplo: La metodología Scrum asume que el proceso de desarrollo de soft-
ware es impredecible, y lo trata como a una “caja negra” controla-
> Individuos e interacciones, sobre procesos y herra- da, en vez de manejarlo como un proceso completamente definido.
mientas. Ésta es una de las principales diferencias entre Scrum y otras meto-
> Software operativo, sobre documentación extensiva. dologías, como los modelos de espiral o de cascada, en los cuales el
> Colaboración con el cliente, sobre negociación de proceso de desarrollo se define por completo desde el inicio. Por tra-
contratos. tar de planificar el proceso en forma completa desde el principio, las
Ciclo
Backlog de diario
producto Backlog de Scrum
sprint
Ejecutable
incremental
Ciclo
mensual
Sprint
Reunión de
demostración
post-sprint
Estándares, técnicas, procesos,
Reunión de lineamientos, herramientas
planificación de sprint de desarrollo
[Figura 1] En el núcleo del proceso Scrum se observa un ciclo de trabajo de 30 días (sprint) y otro ciclo diario (scrum)
delimitado por reuniones breves del equipo de desarrollo.
54 users.code

2. 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 típicos de esta disciplina. Gustavo du Mortier
Gerente de desarrollo en
Ahora veremos cómo se pueden resolver. la empresa MasterSoft
gustavo.dumortier@
mastersoft.com.ar
metodologías tradicionales fallan al toparse con algunos problemas ha-
bituales del desarrollo de software, como la falta de comprensión de los
Revisión de planes de versión (release).
requerimientos al empezar el proceso, el cambio en los requerimientos
[desarrolladores]
durante el proceso, o la dificultad para prever los resultados del uso de
nuevas herramientas y tecnologías.
Otra diferencia de Scrum con las metodologías tradicionales es que
no trata el proceso de desarrollo de software como un proceso lineal, Distribución, revisión y ajuste
en el que se sigue la secuencia de análisis, diseño, codificación y tes- de estándares de producto.
ting. En Scrum, el proyecto puede iniciarse con cualquier actividad, y [desarrolladores]
cambiar de una a otra en cualquier momento.
Un proyecto administrado mediante Scrum se organiza en iteracio-
nes, llamadas sprints, que normalmente tienen entre dos y cuatro se-
manas de duración. Al principio de cada sprint se establece una lis-
ta de requerimientos llamada backlog, que debe completarse cuando Sprint
éste finalice. A diario se realizan breves reuniones del equipo de de- Desarrollo
sarrollo, en las que se exponen los avances y los problemas encon- Empaquetado
trados, y se señalan posibles caminos para resolverlos (la resolución Revisión
detallada de estos problemas no debe determinarse durante la reu- Ajuste
nión, para mantener su brevedad).
[desarrolladores]
Su majestad el backlog
Un proceso Scrum reconoce tres tipos de backlog: el backlog de pro-
ducto, el backlog de versión y el backlog de sprint.
El backlog de producto es un repositorio de requerimientos enuncia- Revisión de Sprint
dos por los interesados en el éxito del proyecto (los llamados stakehol- Revisión del software.
ders, que pueden ser usuarios, administradores, técnicos de soporte, Comparación del backlog con el
etc.). Por lo general, los requerimientos incluidos en este backlog son software desarrollado.
de alto nivel, evitan detallar cuestiones técnicas o de implementación, Edición del backlog.
y tienen asociadas estimaciones de tiempos también de alto nivel, rea- Agregado de nuevos puntos al backlog.
lizadas por los stakeholders. Asignar puntos del backlog a los
El backlog de versión (release backlog) consiste en una lista de reque- equipos de desarrollo.
rimientos extraída del backlog de producto, priorizada para la próxima Planificar próxima versión.
versión (release) del producto. Los elementos de este backlog tienen un [stakeholders]
mayor nivel de detalle en cuanto a los requerimientos y tienen asocia-
das estimaciones más precisas, realizadas por los miembros del equipo
de Scrum.
El backlog de sprint se arma al principio de cada sprint, y reúne
aquellos requerimientos que el equipo se compromete a completar pa-
ra cuando finalice dicho sprint. Completar un requerimiento implica
codificarlo, testearlo y documentarlo. El backlog de sprint se arma di- Análisis de variables:
vidiendo los requerimientos del backlog de release en tareas que co- tiempo, requerimientos, costo,
múnmente pueden completarse en períodos de 8 a 16 horas. calidad. ¿Concuerdan con
los objetivos de
El equipo de trabajo la versión?
En Scrum, los equipos de desarrollo deben estar formados por una
cantidad aproximada de siete miembros. El líder del equipo es el deno- Sí
minado Scrum Master, y su trabajo consiste en implementar y admi-
nistrar el proceso Scrum en el proyecto. Al inicio del proyecto, el equi-
po debe ponerse de acuerdo en cuanto a las prácticas que se van a im- Cierre.
plementar, la frecuencia de las reuniones, los artefactos por utilizar, etc. [stakeholders]
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 [Figura 2] Fases detalladas del proceso Scrum.
55

3. 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 56
[management]
Jeff Sutherland creó una metodología de procesos de desarrollo
que demostró su efectividad para elevar la productividad.
mayor parte, indirecta. Su trabajo consiste en “atajar” las interferen- Fases de un proceso Scrum
cias externas para que el equipo de desarrollo optimice su producti- El proceso de desarrollo Scrum se compone de cinco ac-
vidad, resolviendo los impedimentos que no pueden ser resueltos tividades principales: revisión de los planes de release;
por los miembros del equipo. Su responsabilidad también incluye el distribución, revisión y ajuste de los estándares de pro-
hecho de asegurar la transparencia del proceso de desarrollo, man- ducto; sprint; revisión de sprint, y cierre (ver [Figura 2]).
teniendo los artefactos definidos para el proceso (ver el recuadro La fase de sprint es en la que se realiza el desarrollo de
“Los roles de un Scrum”). software propiamente dicho. Dentro de un sprint se efec-
túan varias sub-actividades: desarrollo, empaquetado,
Las reuniones de Scrum revisión y ajuste. No existe secuencia dentro de esta fa-
Las reuniones de Scrum deben llevarse a cabo diariamente, aun- se. Algunas veces, un ítem del backlog debe ser desarro-
que el equipo puede ponerse de acuerdo al inicio para realizarlas con llado, empaquetado y revisado, y otras veces, el ítem só-
una periodicidad diferente; por ejemplo, día por medio. Es importan- lo debe ser revisado y ajustado; todo depende de las ca-
te que se efectúen siempre en el mismo lugar y a la misma hora, y racterísticas del ítem en cuestión.
que su duración no exceda los 30 minutos. Cada sprint es seguido por un proceso de revisión. Du-
Durante la reunión, el Scrum Master hace a cada miembro del rante esta etapa, se revisa el software desarrollado en el
equipo tres preguntas: qué hizo desde la última reunión de Scrum, sprint que acaba de finalizar y, de ser necesario, se agre-
qué obstaculizó su trabajo y qué planea hacer desde ese momento gan nuevos ítem en el backlog. El grupo de revisores de-
hasta la próxima reunión. La conversación debe limitarse a las res- be incluir a los stakeholders, los administradores del
puestas de los miembros del equipo a las tres preguntas anteriores. proyecto, los desarrolladores y los usuarios.
Sobre la base de las respuestas obtenidas y de los problemas que és- Las actividades de sprint y revisión de sprint tienen
tas reflejen, pueden agendarse reuniones para llevar a cabo en for- que repetirse hasta que el producto está en condiciones
ma inmediata luego de la reunión de Scrum, entre un subgrupo del de ser distribuido por los accionistas. Luego, el proyecto
equipo, para dar solución a los inconvenientes detectados. entra en la fase de cierre, tras la cual el producto queda
El Scrum Master señala los caminos de solución a los problemas y en condiciones para el cierre de versión (release) y dis-
es responsable de identificar impedimentos externos que puedan tribución.
frenar el proceso. En la fase de cierre, se realizan las últimas tareas de
Controles
Compuesto por Afecta
Backlog Versión
Formado por Cuestión
Paquete
Punto del backlog
Produce
Componente / objeto Solución
del producto
Resuelve
Cambio
Implementa
Problema Riesgo
[Figura 3] Controles que se aplican durante el proceso Scrum.
56 users.code

4. 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 57
Los roles de un Scrum
El método Scrum reconoce tres roles: Dueño del pro-
ducto, Scrum Master y Equipo.
Las responsabilidades del Dueño del producto incluyen
definir las características del producto, determinar la
fecha de lanzamiento y el contenido, asegurar la renta-
bilidad del producto, priorizar las características según
el valor de mercado, ajustar las características y las
prioridades cada treinta días (según sea necesario), y
aceptar o rechazar resultados del trabajo. El Dueño del
depuración (debugging), luego de lo cual se construyen los entre- producto es responsable por la primera de las tres “ce-
gables y el proyecto se da por finalizado. Debido a lo imprevisi- remonias” de Scrum: la planificación.
ble de los procesos de desarrollo de software, no es posible defi-
nir exactamente cuándo ocurrirá la fase de cierre, de modo que El Scrum Master es un facilitador y líder de equipo, que
los proyectos pueden demorarse más o menos de lo planeado. Pe- trabaja en contacto estrecho con el Dueño del producto.
ro mediante el uso de los controles que provee Scrum, se pueden Sus responsabilidades abarcan asegurar que el equipo
hacer estimaciones sobre su duración. se mantenga plenamente funcional y productivo; permi-
tir la cooperación estrecha entre todos los roles y funcio-
Cómo evitar que se descontrole el proyecto nes; eliminar las barreras que obstaculicen el desarrollo
Hasta aquí hemos explicado cómo se estructura un proceso del proyecto; proteger al equipo de las interferencias ex-
Scrum y cómo es la dinámica de trabajo, pero aún no vimos las
ternas, y asegurar que el proceso se lleve a cabo correc-
claves para asegurar que concluya exitosamente en tiempo y en
forma, y que, a la vez, sea flexible y adaptable a los cambios. tamente, asegurando la concurrencia de los involucra-
En general, en los proyectos de desarrollo que involucran métodos dos a las reuniones diarias de Scrum, a las revisiones de
ágiles se fijan los plazos y los costos, pero se permite que los alcan- sprint y a las planificaciones de sprint.
ces varíen de una forma controlada. Los controles son, entonces, la Durante las reuniones diarias de Scrum, el Scrum
herramienta imprescindible para que el proyecto arribe a buen puer- Master debe saber qué tareas han sido completadas,
to. En Scrum se define una serie de aspectos del proceso, que se con-
cuáles se han iniciado, qué nuevas tareas se han des-
trolan y miden de forma tal de no anular la cualidad de “caja negra”
que caracteriza a las etapas de desarrollo. Estos aspectos, o controles, cubierto y qué estimaciones cambiaron. Esto hace po-
son los siguientes: sible mantener actualizado el diagrama de burndown,
> Puntos del backlog: Requerimientos funcionales del producto que muestra, día tras día, el trabajo que queda pen-
que no son cumplidos adecuadamente por la actual versión. diente. El Scrum Master debe observar cuidadosa-
Bugs, defectos, mejoras pedidas por el usuario, funcionalidad mente el número de tareas abiertas en progreso, para
competitiva y actualizaciones tecnológicas son otros posibles asegurarse de mantener este número en valores ópti-
puntos del backlog. mos. Debe sacar a la luz las dependencias y los blo-
> Versión (release): Un conjunto de puntos del backlog que, en
queos que actúen como impedimentos para el Scrum,
un determinado momento, representan una nueva versión via-
ble del producto, sobre la base de las variables de requerimien- determinando sus prioridades y realizando su segui-
tos, tiempo, calidad y competencia. miento. Es preciso implementar un plan de solución
> Paquetes: Componentes del producto u objetos que deben para estos impedimentos en orden de prioridad. Algu-
cambiarse para implementar un punto del backlog en una nos podrán resolverse con el equipo; otro podrán re-
nueva versión del producto. solverse entre equipos, y otros requerirán la partici-
> Cambios: Cambios que deben ocurrir en un paquete para im- pación de la gerencia, ya que pueden ser cuestiones
plementar un punto del backlog. de la compañía que estén impidiendo a todos los equi-
> Problemas: Problemas técnicos que suceden y deben resolver-
pos lograr su óptima capacidad de producción.
se para implementar un cambio.
> Riesgos: Los riesgos que afectan el éxito del proyecto son con- Por último, el Scrum Master debe detectar problemas
tinuamente evaluados y se planean respuestas. Otros controles personales o conflictos dentro del Scrum que necesi-
se ven afectados como consecuencia del análisis de riesgo. ten solución. Estos conflictos deben ser clarificados
> Soluciones: Soluciones a los problemas y riesgos, que habi- por él y resueltos mediante el diálogo dentro del equi-
tualmente derivan en cambios. po, o bien el Scrum Master puede solicitar ayuda a la
> Cuestiones (issues): Cualquier otra cuestión que afecte al pro-
gerencia o a la oficina de recursos humanos.
yecto, y que no se defina en términos de paquetes, cambios o
problemas. El Equipo debe ser polifuncional, compuesto por siete
miembros (más/menos dos). Su labor consiste en se-
En la [Figura 3] se observa cómo los controles se conectan en- leccionar el objetivo final de cada sprint, especificar los
tre sí y qué influencia tienen unos sobre otros. resultados del trabajo y llevarlo a cabo. Posee el dere-
Los controles se usan en varias fases de Scrum. La gerencia cho de realizar lo que sea –dentro de los límites que
del proyecto los emplea para administrar el backlog. Los equi-
impongan los lineamientos del proyecto– para alcan-
pos de desarrollo los utilizan para administrar cambios y pro-
blemas. En conjunto, la gerencia y los equipos de desarrollo ad- zar el objetivo final de un sprint. Debido a que opera
ministran las cuestiones, riesgos y soluciones. Los controles como una “caja negra”, debe organizarse a sí mismo y
son revisados, modificados y conciliados en cada reunión de a su trabajo, y debe preparar una demo de los resulta-
revisión de un sprint. dos para exhibir ante el Dueño del producto.
La revisión de los controles permite al administrador del
57

5. 54-58 Management - 36.qxd 3/19/07 5:26 PM Page 58
[management]
proyecto obtener métricas sobre él. Por ejemplo: el nú- desarrollo de software es una tarea complicada, por lo que ofrece un
mero de puntos del backlog define el tamaño del pro- marco de trabajo y un conjunto de prácticas con los cuales se faci-
yecto, mientras que la cantidad de puntos finalizados litará comprometer y administrar equipos en este dificultoso traba-
exitosamente indica el progreso logrado. A su vez, la jo. No se hace el intento por hacer creer que el trabajo es fácil o que
cantidad de riesgos define la complejidad del proyecto. puede ser realizado por personas sin experiencia, indiferentes o in-
competentes. En cambio, los procesos ágiles, simplemente, logran
No hay balas de plata que el impacto del trabajo de profesionales sin la necesaria capaci-
Los métodos ágiles son comúnmente considerados dad se haga visible y evidente en forma temprana, y pueda ser tra-
“balas de plata”, en especial, por directivos de ingenie- tado como corresponda.
ría de software que han visto uno o más proyectos ries- Otras metodologías cometen el error de ocultar los malos resulta-
gosos concluir con éxito luego de aplicar metodologías dos hasta el final del proyecto, y en algunos casos, los malos resul-
tales como Scrum o XP. El problema es que el éxito de tados afloran después de terminarlo, cuando alguien intenta efec-
unos pocos casos es difícil de replicar en la mayoría. tuar mantenimiento o cambios en el software. Los procesos ágiles,
La idea detrás de las balas de plata es que, al utilizar- en cambio, comunican las malas noticias apenas éstas se producen,
las, se puede poner a cualquier persona a desarrollar para que puedan ser atacadas antes de que alcancen una magnitud
software. Los procesos ágiles traen un lema diferente: el capaz de poner en riesgo al proyecto en su totalidad. ●
Sugerencias de su creador
En exclusiva, gracias a la gente de regla más importante de todas.
Baufest (www.baufest.com), tuvimos > Al final del mes –período que se
la posibilidad de reunirnos con el Dr. denomina sprint–, hay que tener
Jeff Sutherland, creador de la meto- un ejecutable con las funcionali-
dología Scrum y coautor del Mani- dades del Sprint Backlog.
fiesto Ágil. Él mismo nos cuenta cuá- > Todos pueden añadir funcionali-
les son los beneficios de esta meto- dades al Product Backlog, pero
dología que, día a día, las empresas sólo una persona puede ordenar-
toman como referente. lo. A esta persona se la denomina
Scrum es una forma de gestionar Product Owner, y es el responsa-
proyectos de software. No es una ble del producto final.
metodología de análisis, ni de dise- Dr. Jeff Sutherland > Cada día se hace una reunión de
ño, como podría ser RUP, sino una CTO de PatientKeeper menos de 15 minutos, en la que
metodología de gestión del trabajo. se reúne todo el equipo –ingenie-
Una de las características más im- cación ordenadas de mayor a me- ros y gestor (llamado Scrum Mas-
portantes es que es muy fácil de ex- nor importancia. No hace falta ter)–, y cada miembro expone só-
plicar y de entender, lo que contribu- que contenga todas las funciona- lo los siguientes temas:
ye mucho a su implantación. lidades inicialmente. ¿Qué se hizo el día anterior?
¿Cómo ayuda Scrum en la evolución del > De la lista anterior, se toman las ¿Qué se va a hacer hoy?
desarrollo de software? primeras funcionalidades, se des- ¿Qué impedimentos tengo para
Scrum puede ser aplicada a distintos componen en tareas y se las anota realizar mi trabajo?
modelos de calidad (como podría ser en otra lista, que se llama Sprint Sólo se tratan estos temas para
CMMI), puesto que éstos dicen qué Backlog. Estas tareas serán reali- que la reunión sea rápida y no se
tendríamos que hacer o qué debería- zadas en el siguiente mes. malgaste el tiempo de los demás.
mos gestionar en el proyecto, pero Además de estos elementos, existen Si es necesario tratar otro tema,
no nos dicen cómo hacerlo. Ahí es unas cuantas reglas básicas y senci- se hace otra reunión sólo con las
donde entra Scrum como modelo de llas que deberemos cumplir: personas implicadas.
gestión del proyecto. Los siguientes > Una vez que se pasan las tareas > Al final del mes (es decir, al final
son los elementos básicos de esta prioritarias del Product Backlog al del sprint), se presenta el produc-
metodología: Sprint Backlog, no se las puede cam- to y se toman del Product Backlog
> Una lista, llamada Product Backlog, biar; esto quiere decir que el trabajo ordenado las funcionalidades pa-
con las funcionalidades de la apli- de un mes queda fijado. Ésta es la ra cubrir en el siguiente mes.
58 users.code