54 users.code

(Management)

El método Scrum

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

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áde los plazos, documentación que exige demasiado trabajo de elabora-ción y no refleja la realidad del producto final, contratos que terminanperjudicando a una de las dos partes (desarrollador o cliente) o a am-bas, entre otros males.

Scrum intenta atacar esos problemas endémicos del desarrollo desoftware rescatando la filosofía de procesos que llevó a las automo-trices japonesas (con Toyota a la cabeza) a abrumar a sus pares esta-dounidenses, al superarlos en aspectos tales como productividad yeficiencia. El secreto de Toyota era tan simple como dar a cada em-pleado la posibilidad de crear sus propias reglas, junto con la respon-sabilidad de maximizar la calidad en la parte del desarrollo que le to-caba llevar a cabo.

Características de un proceso ScrumLa metodología Scrum asume que el proceso de desarrollo de soft-

ware es impredecible, y lo trata como a una “caja negra” controla-da, en vez de manejarlo como un proceso completamente definido.Ésta es una de las principales diferencias entre Scrum y otras meto-dologías, como los modelos de espiral o de cascada, en los cuales elproceso de desarrollo se define por completo desde el inicio. Por tra-tar de planificar el proceso en forma completa desde el principio, las

crum es, actualmente, uno de los métodoságiles para desarrollo de software de mayordifusión en la industria, junto con ExtremeProgramming (XP). Su nombre proviene del

rugby, deporte en el que un scrum es una jugada que per-mite reiniciar el juego luego de una falta accidental. Laelección del nombre busca rescatar el principio de traba-jo en equipo que se observa en un scrum de rugby: va-rios jugadores se toman de los hombros y se esfuerzanpara lograr –por sí solos y rápidamente– un objetivo co-mún, que consiste en adueñarse de la pelota y llevarlahacia delante.

El creador de Scrum es Jeff Sutherland, uno de los 17“gurúes agilistas” que se reunieron en el año 2001 pa-ra establecer los postulados del desarrollo de softwareágil, y redactar y firmar el mítico Manifiesto Ágil. Enel texto de dicho manifiesto se establecen los objeti-vos de las metodologías ágiles, entre los cuales se des-taca la preferencia de algunos valores por sobre otros,por ejemplo:

> Individuos e interacciones, sobre procesos y herra-mientas.

> Software operativo, sobre documentación extensiva.> Colaboración con el cliente, sobre negociación de

contratos.

S

[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.

Backlog desprint

Reunión deplanificación de sprint

CiclodiarioScrum

Ejecutableincremental

Ciclomensual

Estándares, técnicas, procesos,lineamientos, herramientas

de desarrollo

Sprint

Reunión de demostración

post-sprint

Backlog deproducto

54-58 Management - 36.qxd 3/19/07 5:25 PM Page 54

metodologías tradicionales fallan al toparse con algunos problemas ha-bituales del desarrollo de software, como la falta de comprensión de losrequerimientos al empezar el proceso, el cambio en los requerimientosdurante el proceso, o la dificultad para prever los resultados del uso denuevas herramientas y tecnologías.

Otra diferencia de Scrum con las metodologías tradicionales es queno trata el proceso de desarrollo de software como un proceso lineal,en el que se sigue la secuencia de análisis, diseño, codificación y tes-ting. En Scrum, el proyecto puede iniciarse con cualquier actividad, ycambiar 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éste finalice. A diario se realizan breves reuniones del equipo de de-sarrollo, en las que se exponen los avances y los problemas encon-trados, y se señalan posibles caminos para resolverlos (la resolucióndetallada de estos problemas no debe determinarse durante la reu-nión, para mantener su brevedad).

Su majestad el backlogUn 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-

dos por los interesados en el éxito del proyecto (los llamados stakehol-ders, que pueden ser usuarios, administradores, técnicos de soporte,etc.). Por lo general, los requerimientos incluidos en este backlog sonde alto nivel, evitan detallar cuestiones técnicas o de implementación,y tienen asociadas estimaciones de tiempos también de alto nivel, rea-lizadas por los stakeholders.

El backlog de versión (release backlog) consiste en una lista de reque-rimientos extraída del backlog de producto, priorizada para la próximaversión (release) del producto. Los elementos de este backlog tienen unmayor nivel de detalle en cuanto a los requerimientos y tienen asocia-das estimaciones más precisas, realizadas por los miembros del equipode Scrum.

El backlog de sprint se arma al principio de cada sprint, y reúneaquellos requerimientos que el equipo se compromete a completar pa-ra cuando finalice dicho sprint. Completar un requerimiento implicacodificarlo, testearlo y documentarlo. El backlog de sprint se arma di-vidiendo los requerimientos del backlog de release en tareas que co-múnmente pueden completarse en períodos de 8 a 16 horas.

El equipo de trabajoEn Scrum, los equipos de desarrollo deben estar formados por una

cantidad aproximada de siete miembros. El líder del equipo es el deno-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-plementar, la frecuencia de las reuniones, los artefactos por utilizar, etc.A partir de allí, es responsabilidad del Scrum Master asegurar que elequipo se atenga a las normas establecidas.

El Scrum Master asume el rol de facilitador, y su autoridad es, en su

55

Desde los inicios del desarrollo de software,se ha intentado, sin mucho éxito, lidiar conlos problemas típicos de esta disciplina.Ahora veremos cómo se pueden resolver.

Gustavo du MortierGerente de desarrollo en

la empresa MasterSoftgustavo.dumortier@

mastersoft.com.ar

[Figura 2] Fases detalladas del proceso Scrum.

Revisión de planes de versión (release).[desarrolladores]

Distribución, revisión y ajustede estándares de producto.

[desarrolladores]

Sprint

DesarrolloEmpaquetado

RevisiónAjuste

[desarrolladores]

Revisión de Sprint

Revisión del software.Comparación del backlog con el

software desarrollado.Edición del backlog.

Agregado de nuevos puntos al backlog.Asignar puntos del backlog a los

equipos de desarrollo.Planificar próxima versión.

[stakeholders]

Cierre.[stakeholders]

Análisis de variables:tiempo, requerimientos, costo,

calidad. ¿Concuerdan conlos objetivos de

la versión?

Sí

54-58 Management - 36.qxd 3/19/07 5:25 PM Page 55

56 users.code

mayor parte, indirecta. Su trabajo consiste en “atajar” las interferen-cias externas para que el equipo de desarrollo optimice su producti-vidad, resolviendo los impedimentos que no pueden ser resueltospor los miembros del equipo. Su responsabilidad también incluye elhecho de asegurar la transparencia del proceso de desarrollo, man-teniendo los artefactos definidos para el proceso (ver el recuadro“Los roles de un Scrum”).

Las reuniones de ScrumLas reuniones de Scrum deben llevarse a cabo diariamente, aun-

que el equipo puede ponerse de acuerdo al inicio para realizarlas conuna periodicidad diferente; por ejemplo, día por medio. Es importan-te que se efectúen siempre en el mismo lugar y a la misma hora, yque su duración no exceda los 30 minutos.

Durante la reunión, el Scrum Master hace a cada miembro delequipo tres preguntas: qué hizo desde la última reunión de Scrum,qué obstaculizó su trabajo y qué planea hacer desde ese momentohasta la próxima reunión. La conversación debe limitarse a las res-puestas de los miembros del equipo a las tres preguntas anteriores.Sobre la base de las respuestas obtenidas y de los problemas que és-tas reflejen, pueden agendarse reuniones para llevar a cabo en for-ma inmediata luego de la reunión de Scrum, entre un subgrupo delequipo, para dar solución a los inconvenientes detectados.

El Scrum Master señala los caminos de solución a los problemas yes responsable de identificar impedimentos externos que puedanfrenar el proceso.

Fases de un proceso ScrumEl proceso de desarrollo Scrum se compone de cinco ac-

tividades principales: revisión de los planes de release;distribución, revisión y ajuste de los estándares de pro-ducto; sprint; revisión de sprint, y cierre (ver [Figura 2]).

La fase de sprint es en la que se realiza el desarrollo desoftware propiamente dicho. Dentro de un sprint se efec-túan varias sub-actividades: desarrollo, empaquetado,revisión y ajuste. No existe secuencia dentro de esta fa-se. Algunas veces, un ítem del backlog debe ser desarro-llado, empaquetado y revisado, y otras veces, el ítem só-lo debe ser revisado y ajustado; todo depende de las ca-racterísticas del ítem en cuestión.

Cada sprint es seguido por un proceso de revisión. Du-rante esta etapa, se revisa el software desarrollado en elsprint que acaba de finalizar y, de ser necesario, se agre-gan nuevos ítem en el backlog. El grupo de revisores de-be incluir a los stakeholders, los administradores delproyecto, los desarrolladores y los usuarios.

Las actividades de sprint y revisión de sprint tienenque repetirse hasta que el producto está en condicionesde ser distribuido por los accionistas. Luego, el proyectoentra en la fase de cierre, tras la cual el producto quedaen condiciones para el cierre de versión (release) y dis-tribución.

En la fase de cierre, se realizan las últimas tareas de

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

Controles

Backlog

Punto del backlog

Versión

Paquete

Cuestión

Solución

RiesgoProblema

Componente / objetodel producto

Formado por

Produce

Resuelve

Implementa

Compuesto por Afecta

Cambio

[management]

Jeff Sutherland creó una metodología de procesos de desarrolloque demostró su efectividad para elevar la productividad.

54-58 Management - 36.qxd 3/19/07 5:25 PM Page 56

57

depuración (debugging), luego de lo cual se construyen los entre-gables y el proyecto se da por finalizado. Debido a lo imprevisi-ble de los procesos de desarrollo de software, no es posible defi-nir exactamente cuándo ocurrirá la fase de cierre, de modo quelos proyectos pueden demorarse más o menos de lo planeado. Pe-ro mediante el uso de los controles que provee Scrum, se puedenhacer estimaciones sobre su duración.

Cómo evitar que se descontrole el proyectoHasta aquí hemos explicado cómo se estructura un proceso

Scrum y cómo es la dinámica de trabajo, pero aún no vimos lasclaves para asegurar que concluya exitosamente en tiempo y enforma, y que, a la vez, sea flexible y adaptable a los cambios.

En general, en los proyectos de desarrollo que involucran métodoságiles se fijan los plazos y los costos, pero se permite que los alcan-ces varíen de una forma controlada. Los controles son, entonces, laherramienta imprescindible para que el proyecto arribe a buen puer-to. En Scrum se define una serie de aspectos del proceso, que se con-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,son los siguientes:> Puntos del backlog: Requerimientos funcionales del producto

que no son cumplidos adecuadamente por la actual versión.Bugs, defectos, mejoras pedidas por el usuario, funcionalidadcompetitiva y actualizaciones tecnológicas son otros posiblespuntos del backlog.

> Versión (release): Un conjunto de puntos del backlog que, enun determinado momento, representan una nueva versión via-ble del producto, sobre la base de las variables de requerimien-tos, tiempo, calidad y competencia.

> Paquetes: Componentes del producto u objetos que debencambiarse para implementar un punto del backlog en unanueva versión del producto.

> Cambios: Cambios que deben ocurrir en un paquete para im-plementar un punto del backlog.

> Problemas: Problemas técnicos que suceden y deben resolver-se para implementar un cambio.

> Riesgos: Los riesgos que afectan el éxito del proyecto son con-tinuamente evaluados y se planean respuestas. Otros controlesse ven afectados como consecuencia del análisis de riesgo.

> Soluciones: Soluciones a los problemas y riesgos, que habi-tualmente derivan en cambios.

> Cuestiones (issues): Cualquier otra cuestión que afecte al pro-yecto, y que no se defina en términos de paquetes, cambios oproblemas.

En la [Figura 3] se observa cómo los controles se conectan en-tre sí y qué influencia tienen unos sobre otros.

Los controles se usan en varias fases de Scrum. La gerenciadel proyecto los emplea para administrar el backlog. Los equi-pos de desarrollo los utilizan para administrar cambios y pro-blemas. En conjunto, la gerencia y los equipos de desarrollo ad-ministran las cuestiones, riesgos y soluciones. Los controlesson revisados, modificados y conciliados en cada reunión derevisión de un sprint.

La revisión de los controles permite al administrador del

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 incluyendefinir las características del producto, determinar lafecha de lanzamiento y el contenido, asegurar la renta-bilidad del producto, priorizar las características segúnel valor de mercado, ajustar las características y lasprioridades cada treinta días (según sea necesario), yaceptar o rechazar resultados del trabajo. El Dueño delproducto es responsable por la primera de las tres “ce-remonias” de Scrum: la planificación.

El Scrum Master es un facilitador y líder de equipo, quetrabaja en contacto estrecho con el Dueño del producto.Sus responsabilidades abarcan asegurar que el equipose mantenga plenamente funcional y productivo; permi-tir la cooperación estrecha entre todos los roles y funcio-nes; eliminar las barreras que obstaculicen el desarrollodel proyecto; proteger al equipo de las interferencias ex-ternas, y asegurar que el proceso se lleve a cabo correc-tamente, asegurando la concurrencia de los involucra-dos a las reuniones diarias de Scrum, a las revisiones desprint y a las planificaciones de sprint.

Durante las reuniones diarias de Scrum, el ScrumMaster debe saber qué tareas han sido completadas,cuáles se han iniciado, qué nuevas tareas se han des-cubierto y qué estimaciones cambiaron. Esto hace po-sible mantener actualizado el diagrama de burndown,que muestra, día tras día, el trabajo que queda pen-diente. El Scrum Master debe observar cuidadosa-mente el número de tareas abiertas en progreso, paraasegurarse de mantener este número en valores ópti-mos. Debe sacar a la luz las dependencias y los blo-queos que actúen como impedimentos para el Scrum,determinando sus prioridades y realizando su segui-miento. Es preciso implementar un plan de soluciónpara estos impedimentos en orden de prioridad. Algu-nos podrán resolverse con el equipo; otro podrán re-solverse entre equipos, y otros requerirán la partici-pación de la gerencia, ya que pueden ser cuestionesde la compañía que estén impidiendo a todos los equi-pos lograr su óptima capacidad de producción.

Por último, el Scrum Master debe detectar problemaspersonales o conflictos dentro del Scrum que necesi-ten solución. Estos conflictos deben ser clarificadospor él y resueltos mediante el diálogo dentro del equi-po, o bien el Scrum Master puede solicitar ayuda a lagerencia o a la oficina de recursos humanos.

El Equipo debe ser polifuncional, compuesto por sietemiembros (más/menos dos). Su labor consiste en se-leccionar el objetivo final de cada sprint, especificar losresultados del trabajo y llevarlo a cabo. Posee el dere-cho de realizar lo que sea –dentro de los límites queimpongan los lineamientos del proyecto– para alcan-zar el objetivo final de un sprint. Debido a que operacomo una “caja negra”, debe organizarse a sí mismo ya su trabajo, y debe preparar una demo de los resulta-dos para exhibir ante el Dueño del producto.

54-58 Management - 36.qxd 3/19/07 5:25 PM Page 57

58 users.code

[management]

proyecto obtener métricas sobre él. Por ejemplo: el nú-mero de puntos del backlog define el tamaño del pro-yecto, mientras que la cantidad de puntos finalizadosexitosamente indica el progreso logrado. A su vez, lacantidad de riesgos define la complejidad del proyecto.

No hay balas de plataLos métodos ágiles son comúnmente considerados

“balas de plata”, en especial, por directivos de ingenie-ría de software que han visto uno o más proyectos ries-gosos concluir con éxito luego de aplicar metodologíastales como Scrum o XP. El problema es que el éxito deunos pocos casos es difícil de replicar en la mayoría.

La idea detrás de las balas de plata es que, al utilizar-las, se puede poner a cualquier persona a desarrollarsoftware. Los procesos ágiles traen un lema diferente: el

desarrollo de software es una tarea complicada, por lo que ofrece unmarco de trabajo y un conjunto de prácticas con los cuales se faci-litará comprometer y administrar equipos en este dificultoso traba-jo. No se hace el intento por hacer creer que el trabajo es fácil o quepuede ser realizado por personas sin experiencia, indiferentes o in-competentes. En cambio, los procesos ágiles, simplemente, logranque el impacto del trabajo de profesionales sin la necesaria capaci-dad se haga visible y evidente en forma temprana, y pueda ser tra-tado como corresponda.

Otras metodologías cometen el error de ocultar los malos resulta-dos hasta el final del proyecto, y en algunos casos, los malos resul-tados afloran después de terminarlo, cuando alguien intenta efec-tuar 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 magnitudcapaz de poner en riesgo al proyecto en su totalidad. ●

Sugerencias de su creador

En exclusiva, gracias a la gente deBaufest (www.baufest.com), tuvimosla posibilidad de reunirnos con el Dr.Jeff Sutherland, creador de la meto-dología Scrum y coautor del Mani-fiesto Ágil. Él mismo nos cuenta cuá-les son los beneficios de esta meto-dología que, día a día, las empresastoman como referente.Scrum es una forma de gestionarproyectos de software. No es unametodología de análisis, ni de dise-ño, como podría ser RUP, sino unametodología de gestión del trabajo.Una de las características más im-portantes es que es muy fácil de ex-plicar y de entender, lo que contribu-ye mucho a su implantación.¿Cómo ayuda Scrum en la evolución deldesarrollo de software?Scrum puede ser aplicada a distintosmodelos de calidad (como podría serCMMI), puesto que éstos dicen quétendríamos que hacer o qué debería-mos gestionar en el proyecto, perono nos dicen cómo hacerlo. Ahí esdonde entra Scrum como modelo degestión del proyecto. Los siguientesson los elementos básicos de estametodología:> Una lista, llamada Product Backlog,

con las funcionalidades de la apli-

cación ordenadas de mayor a me-nor importancia. No hace faltaque contenga todas las funciona-lidades inicialmente.

> De la lista anterior, se toman lasprimeras funcionalidades, se des-componen en tareas y se las anotaen otra lista, que se llama SprintBacklog. Estas tareas serán reali-zadas en el siguiente mes.

Además de estos elementos, existenunas cuantas reglas básicas y senci-llas que deberemos cumplir:> Una vez que se pasan las tareasprioritarias del Product Backlog alSprint Backlog, no se las puede cam-biar; esto quiere decir que el trabajode un mes queda fijado. Ésta es la

regla más importante de todas.> Al final del mes –período que se

denomina sprint–, hay que tenerun ejecutable con las funcionali-dades del Sprint Backlog.

> Todos pueden añadir funcionali-dades al Product Backlog, perosólo una persona puede ordenar-lo. A esta persona se la denominaProduct Owner, y es el responsa-ble del producto final.

> Cada día se hace una reunión demenos de 15 minutos, en la quese reúne todo el equipo –ingenie-ros y gestor (llamado Scrum Mas-ter)–, y cada miembro expone só-lo los siguientes temas: ¿Qué se hizo el día anterior? ¿Qué se va a hacer hoy? ¿Qué impedimentos tengo pararealizar mi trabajo? Sólo se tratan estos temas paraque la reunión sea rápida y no semalgaste el tiempo de los demás.Si es necesario tratar otro tema,se hace otra reunión sólo con laspersonas implicadas.

> Al final del mes (es decir, al finaldel sprint), se presenta el produc-to y se toman del Product Backlogordenado las funcionalidades pa-ra cubrir en el siguiente mes.

Dr. Jeff SutherlandCTO de PatientKeeper

54-58 Management - 36.qxd 3/19/07 5:26 PM Page 58