Scrum, ¿Un Paradigma de Administración de Proyectos que Cumple lo que Promete?

Omar Otoniel Soto Romero1 y Germán Harvey Alférez Salinas2

Universidad de Montemorelos, MéxicoFacultad de Ingeniería y Tecnología

1.osoto@um.edu.mx 2.harveyalferez@um.edu.mx

Abstract 

En este paper se demuestra que el  Scrum  es uno de los mejores procesos empíricos de las metodologías ágiles en la actualidad. Se presenta un caso de estudio donde se describe cómo el equipo de desarrollo de software de una institución educativa al norte de México ha llegado al punto de desarrollar software de manera rápida, de alta calidad, que genera un gran valor al negocio, en un ambiente de trabajo propicio y agradable para los programadores y además, con clientes altamente satisfechos. Todo esto sin una inversión inicial monetaria, tan solo con dedicación de tiempo y la motivación por generar productos que satisfagan las necesidades reales de los usuarios.

Introducción

Desde los inicios del desarrollo de software, se ha intentado encontrar la llave maestra que abra la puerta del paraíso: una metodología que permita crear software de manera acelerada, de alta calidad y que solucione de la mejor manera posible los requerimientos solicitados por los usuarios finales. Se han visto desfilar una tras otra metodologías que intentan hacer más placentero el viaje a través del proceso de desarrollo: Metodología en Cascada, Metodología en Espiral, Metodología All­at­once, entre otras. 

En 1993, Jeff Sutherland, siendo el jefe de ingenieros en Easel Corporation, se dio cuenta que requería  un proceso de desarrollo  acelerado,  donde  la  visualización del  diseño pudiera  de manera   inmediata   resultar   en   un   código   funcional.  Después   de  un   cuidadoso   análisis   de proyectos exitosos y metodologías de desarrollo,  se decidió  aplicar el modelo de negocios creado  por  Hirotaka  Takeuchi  e   Ikujiro  Nonaka quienes  dieron  a  conocer  el  concepto  de Scrum.   Fue   entonces,   que   nació  Scrum  como  una   metodología   aplicada   al   desarrollo   de software, siendo el primer proyecto una herramienta en Smaltalk que incorporaba "round­trip engineering"  (1).   En   1995,   Ken   Schwaber   formaliza  Scrum  como   una   metodología   en OOPSLA '95 (2).

A partir de ese momento, empresas de todos los tamaños se han convencido de las bondades que ofrece Scrum, entre ellas Yahoo!, Google, Microsoft, Cisco, GE Medical, entre otros (3).

En este artículo se presenta un caso de estudio en donde se aprecia cómo un equipo pequeño de desarrollo de software se ha visto beneficiado desde el primer día que apostó por  Scrum como su metodología de trabajo, generando soluciones de manera rápida y dejando un buen sabor de boca a sus clientes. 

En el primer capítulo se presenta  Scrum  como proceso empírico diseñado para mantener el orden en medio del caos; se explica además la mecánica y engranaje del mismo. En el segundo capítulo se describen los esfuerzos de un pequeño grupo de desarrolladores por encontrar la mejor forma de trabajo para lograr un producto de software de alta calidad en el menor tiempo posible. En tercer capítulo, se muestra cómo se ha implementado Scrum a través de un caso de estudio. Se han incluido algunas gráficas y datos cuantitativos que permiten, visualizar de una manera más objetiva, la influencia que ha tenido la implementación de Scrum.

1. ¿Qué es Scrum?

El   término  Scrum  fue  utilizado  por   primera  vez  por  Takeuchi   y  Nonaka   en  1986.  Ellos revisaron las mejores prácticas de negocios para construir nuevos productos, particularmente en las industrias automotrices y de consumo. Además notaron que los equipos pequeños y multifuncionales producían los mejores resultados. En 1993, Jeff Sutherland, entonces jefe de ingenieros en Easel Corporation, se le ocurrió implementar estos conceptos de negocios a la ingeniería   del   software,   logrando   resultados   sorprendentes   con   la   generación   de   nuevos productos   de   software   de   alta   calidad,   listos   para   entregarse   al   cliente   en   los   tiempos estipulados (1). Todo producto de software, durante su creación, enfrenta un proceso complejo de desarrollo debido al ambiente dinámico. A mayor grado de complejidad mayor grado de flexibilidad se requerirá para lograr el éxito. Es entonces donde embona a la perfección  Scrum, ya que es como una caja negra donde seguir un proceso lineal no es la regla. Por el contrario, se está listo para atacar cualquier eventualidad de manera inmediata durante el proceso adaptándose a la nueva realidad. Es ahí donde se encuentra el núcleo y fortaleza de Scrum. En palabras de Ken Schwaber:  "Mientras más cercano al borde del caos opere un equipo, manteniendo el orden, más competitivo y útil será el producto final” (2).

1.1 Fundamentos de Scrum

El proceso de  Scrum  consta de unos pocos pasos sencillos pero bien definidos. Primero se definen los roles básicos, a saber:  Product Owner (Propietario del Producto),  Scrum Master  (Líder   del   Equipo)   y  Team  (el   Equipo).   Algunos   autores   agregan   otros   roles   como Stakeholders (Inversionistas) y Managers (Administradores).

• Product  Owner (PO).  Es  quien  tiene  la  visión del  producto final.  Está  en contacto continuo con los clientes, conoce la tendencia de los mercados y de la competencia. Así mismo, tiene bien en claro las prioridades y el valor que agregará al negocio el producto final. 

• Scrum Master (SM). Es el protector del equipo. A diferencia del clásico rol de líder de proyectos, este rol está para servir al equipo y garantizar que se cumplan las prácticas dictadas por Scrum.   Además, su función es como la de un paraguas, protegiendo del ambiente agresivo al equipo a la vez que ayuda a remover los obstáculos que se puedan presentar.

• Team (Equipo). Es un conjunto multifuncional y autónomo de desarrolladores. 

El proceso se inicia con el Scrum Planing Meeting (SPM). En la primera parte de esta reunión el PO presenta ante el Scrum Master y el Equipo el Product Backlog (lista de requerimientos ordenados por importancia para el negocio). El PO comparte con el  Equipo  la visión que se pretende  lograr  con el  producto de software.  Enlista  cada  una  de  las   funcionalidades  que formarán el nuevo producto y permite al Equipo seleccionar los elementos con los que desean trabajar. Al estar debidamente ordenado el Product Backlog por prioridades, se garantiza que el  Equipo  seleccionará de la lista aquellas funcionalidades más urgentes. Entonces inicia la segunda   parte   de   la   reunión,   donde   el  Equipo  y   el   SM   toman   cada   uno   los   elementos seleccionados   previamente   del  Product   Backlog,   detallándolos   lo   más   posible   a   fin   de conseguir unidades individuales de trabajo de aproximadamente un día de duración. Las tareas individuales obtenidas forman lo que se conoce como Sprint Backlog.

Un Sprint, es un ciclo de trabajo, el cual puede durar entre dos y cuatro semanas. El objetivo es finalizar cada una de las tareas listadas en el Sprint Backlog durante el período de tiempo correspondiente. El Sprint ha de finalizar en la fecha estipulada aún cuando no se haya logrado el objetivo. Es de lo más común, que los equipos que inician a implementar Scrum, durante los primeros Sprints les falta tiempo para finalizar las tareas o bien les sobra tiempo. Sin embargo, esta habilidad se desarrollará con el tiempo.

1.2 Mecánica de un Sprint

Se debe recordar que el equipo es una entidad autónoma, a la cual no se le indica cómo ha de trabajar.  De este modo el equipo se organiza a sí mismo. Cada miembro del Equipo elije de las tareas disponibles, en cuáles desea trabajar. 

Cada día, al iniciar la jornada laboral, se lleva a cabo el Daily Scrum. En esta reunión de 15 minutos, cada miembro del equipo responde a tres preguntas: ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué  obstáculos me impiden avanzar? El objetivo es informarse unos a otros los avances, retrasos y obstáculos a fin de poder colaborar, adaptarse y solucionar cualquier eventualidad. En esta  breve pero fundamental   reunión,  puede haber   invitados  como el  PO,  Managers  y Stakeholders;  no obstante ellos  estarán solo para escuchar   lo que se  informan entre  sí   los integrantes del equipo. Cualquier discusión deberá tratarse con el SM después de la reunión.

Una vez transcurrido el  Sprint, se lleva a cabo el  Sprint Review. El PO, el SM y el  Equipo revisan las  funcionalidades  creadas  o mejoradas.  El  PO puede entonces presentar  ante   los usuarios   finales,  Managers  y  Stakeholders  aquellas   aplicaciones   que   él   decidió   ya   han completado su funcionalidad y están listas para ser liberadas como un producto final.

En el  Sprint  Retrospective,  el  Equipo  y el  SM se reúnen al  finalizar  el  Sprint  Review.  El objetivo es revisar lo que se hizo bien o lo que se hizo mal durante el Sprint que ha finalizado. Se toman acuerdos, se definen o mejoran procedimientos y estándares de trabajo que genere un mayor apego al proceso de Scrum y elimine cualquier práctica que afectó el desempeño del Equipo  durante  el  ciclo  que finalizó.  Mientras   tanto,  el  PO se reúne con  los  Managers  y Stakeholders para actualizar el nuevo Product Backlog (4) (5).

Como se puede apreciar, el proceso es muy sencillo, evita cualquier práctica burocrática que estorbe al proceso de desarrollo de software y promueve el trabajo en equipo en un ambiente laboral propicio para la productividad.  Es por ello que en la última década,  Scrum  ha ido 

creciendo desde sus humildes inicios hasta convertirse en un movimiento que agrupa a miles de proyectos  en los  cientos  de compañías   líderes  alrededor  del  mundo  (1).  Scrum  se  está convirtiendo rápidamente en una metodología de desarrollo de software reconocida por sus resultados palpables.

2. En busca del Santo Grial

El desarrollo de sistemas en la UM, en el  estado de Nuevo León, México comenzó  en la primera mitad de los 90's. El objetivo era desarrollar de manera interna software que resolviera de manera apropiada las necesidades de la institución.

Durante años, la búsqueda de la fórmula mágica para un desarrollo de software armonioso fue infructuosa. Se intentó con el clásico modelo de cascada, espiral, "Synergy Process" de Paul R.   Reed   Jr.,   el   cual   se   basa   en   desarrollo   de   software   de   manera   iterativa   mediante   el modelado y la aplicación de UML[7]; finalmente, cada uno de los líderes de proyecto eligió su forma de  trabajo  personal.  Este  panorama,  no es más  que el   reflejo  del  arduo camino de aprendizaje necesario para lograr la madurez suficiente en el ámbito empresarial del desarrollo de software.

Los sistemas de la UM han evolucionado a través del tiempo, desde Cobol y Pascal en sus inicios, pasando por Gupta, JSP's y finalmente aterrizando en Appfuse  (6). Sin embargo, ha habido  una  constante,   la  urgencia  con  la  que  cada   requerimiento  debe  ser  desarrollado  y entregado. En otras palabras, desde sus inicios se formó una bola de nieve que a través de los años ha ido creciendo y creciendo haciendo imposible detenerla, creando un círculo vicioso donde solo se sobrevive al día, generando código al vuelo sin un correcto análisis y diseño, y ni pensar en planificación o pruebas. 

Como es  lógico pensar,  este  modo de  trabajo ha ocasionado un software de baja  calidad, soluciones a medias de los requerimientos y un crecimiento descontrolado de los sistemas. Ni hablar de la frustración de los usuarios al percibir que la solución a los requerimientos no es la adecuada, está incompleta o bien tarda más tiempo del necesario en llegar. Los desarrolladores también   se   frustran   al   ver   que   a   pesar   de   todos   sus   esfuerzos   no   logran   avanzar   en   el cumplimiento de los requerimientos como quisieran. 

3. Aplicación de Scrum en un Proyecto de Software de la UM

La Dirección de Sistemas de la UM desarrolla principalmente dos sistemas para la institución: el   sistema  financiero  y  el   sistema  académico.  Ambos  proyectos,   son  construidos  por  dos equipos   independientes.  El  equipo de  desarrollo  del  sistema financiero  fue  el  que decidió probar suerte con  Scrum. A continuación se relatan las crónicas de su éxodo desde la tierra árida   donde   no   existe   metodología   alguna   hacia   la   tierra   donde   las   metodologías   dan excelentes resultados. 

3.1 Inicio, El Primer    Sprint   En la manera tradicional de desarrollar software, cada uno de los requerimientos debía pasar, de   manera   secuencial,   a   través   de   las   distintas   etapas   de   análisis,   diseño,   programación, pruebas e implementación. Según la experiencia del equipo financiero, las primeras dos etapas absorbían   la  mayor   parte   del   tiempo,   dejando   al   equipo   en   una   situación  de   éxito  poco probable, ya que se debía programar a marchas forzadas intentando cumplir con las fechas de entrega.   Es fácil de imaginar que para la fase de pruebas ya no se contaba con el tiempo suficiente,  haciendo poco probable que se detectaran  la  mayoría de los errores de manera previa a la liberación del software.

En   muchas   de   las   ocasiones,   el   usuario   modificaba   las   especificaciones   iníciales   de   la funcionalidad,   obligando   al   equipo   a   encontrar   la   manera   de   continuar   desarrollando   las soluciones  a   los   requerimientos  en espera,  además  de modificar  diagramas,  documentos  y código   para   satisfacer   los   cambios   solicitados.   Este   círculo   vicioso   pudo   finalmente   ser desquebrajado desde sus raíces  gracias a  la  flexibilidad  y respuesta ágil  de  Scrum  ante  el entorno complejo y dinámico.

Fue en  el  verano  del  año 2008,  en  una  charla   impartida  en   la  ciudad  de  Monterrey,  por "Entrenamiento Servicios Educacionales" de Sun Microsystems, México, que se presentaron algunos fundamentos del desarrollo de software ágil en la ciudad de Monterrey, Nuevo León, México, donde el interés por Scrum nació en el líder de proyectos del sistema financiero. En el transcurso de los siguientes días se investigó  un poco más acerca de los fundamentos y la mecánica de Scrum. Sin esperar más se decidió iniciar el primer Sprint, con una duración de tres semanas, utilizando el conjunto de requerimientos en los cuales se estaba trabajando en ese momento para alimentar el Product Backlog.

El primer cambio que provocó esta decisión fue eliminar al "Líder de Proyectos". Es decir, eliminar todo ese concepto de "el jefe con el látigo en la mano", cuyo único interés es cumplir a fuego y sangre con las fechas estipuladas en las gráficas de Gantt, sin detenerse a pensar por un momento siquiera en el bienestar del equipo. Fue un cambio radical de mentalidad, “el ogro se  transformó  en benefactor”.  Dejó  de existir  el   jefe que mira a sus subalternos  desde su pedestal para convertirse ahora en un miembro efectivo del equipo, que trabaja hombro con hombro  con   los  demás   integrantes  para   construir   el  proyecto,   ayudando  a   eliminar   a   los obstáculos que limitan el avance y promoviendo un ambiente armonioso de trabajo. Ahora, cada miembro del  equipo podía expresar de manera abierta  y confiada los obstáculos  que limitaban sus avances, sin temor a reprimendas.  Por el contrario, ahora recibía ayuda del SM para buscar la mejor solución al problema.

En el Daily Scrum se informaban entre sí los miembros del equipo en qué habían trabajado el día  anterior,  en  qué   trabajarían  el  día  actual  y   si   tenían  algún  problema que  les   impedía avanzar en la tarea.  En caso de existir un problema el SM ayudaba a encontrar la solución.

En una temporada, se descuidó esta práctica hasta que eventualmente se dejó de realizar por completo el Daily Scrum, bajo pretexto de adelantar trabajo.  Fue gracias a un integrante del equipo, el cual externó  su sentir acerca de la necesidad de realizar el  Daily Scrum, que se renovó el compromiso de apegarse a las prácticas de Scrum.

En el Sprint Review, al finalizar el primer  Scrum, se hizo evidente que los resultados fueron positivos.  Se   lograron   finalizar   todas   las   tareas   listadas   en   el  Sprint  Backlog  en   las   tres semanas de duración del Sprint. Los miembros de equipo se sintieron motivados y expresaron durante  el  Sprint  Retrospective  que  deseaban  continuar   trabajando  de  este  modo.  En este punto,   algunas   de   las   cualidades   del  Scrum  se   hicieron   evidentes.   En   palabras   de   Jeff Sutherland, "Scrum está diseñado para agregar energía, concentración, claridad y transparencia a la planeación e implementación del proyecto”  (7). Tan solo en el primer  Sprint  el equipo había empezado a experimentar las bondades de la comunicación consistente y estable, al ver su creatividad estimulada y su calidad de vida incrementada.

3.2 Siguientes Sprints

Antes  de  comenzar   el   segundo  Sprint,   se  presentaron   los  principios  básicos  de  Scrum  al Director Financiero y al Director de Contabilidad de la institución. Cuando se les mencionó que bajo esta nueva forma de trabajo ellos serían parte activa del equipo, les nació un interés genuino y les renació la esperanza de ver sus requerimientos solucionados de manera más ágil. Al conocer las ventajas que promete  Scrum  decidieron aventurarse a jugar bajo las nuevas reglas, siendo nombrado al Director de Contabilidad como Product Owner.

A partir de este momento, se hizo necesario crear dos documentos compartidos. El  Product  Backlog, donde el PO alimentaría todas las funcionalidades requeridas; y el  Sprint Backlog, donde el SM y el Equipo ingresarían aquellas tareas en las cuales trabajarían durante el Sprint. Estos  documentos  se  compartieron  además  con otros  roles,  como los  Managers,  haciendo transparente   el   proceso   de   desarrollo.   Gracias   a  GoogleDocs  (8),   es   por   demás   sencillo mantener el Product Backlog al día.

Conforme se ha avanzado a través de los  Sprints, se ha visto la necesidad de catalogar las tareas del  Sprint Backlog  en: tareas pendientes, tareas en las que se está trabajando y tareas finalizadas. Se decidió sombrear aquellas tareas en las cuales se está trabajando con el color amarillo, en color verde aquellas tareas ya finalizadas al 100%, en color rojo aquellas tareas no completadas durante el Sprint y de color azul aquellas tareas en las cuales no se pudo trabajar, como por ejemplo por falta de documentación suficiente. Este código de colores ha facilitado el seguimiento del Sprint por parte del PO y los Managers.

Cuando el proceso cíclico del Sprint llega a su fin, se organiza el Sprint Review, convocando el SM al PO y los Managers. Esta reunión ha servido para revisar de manera rápida el avance de cada una de las funcionalidades que el Equipo se comprometió a realizar durante el Sprint. El PO verifica que los requerimientos especificados han sido correctamente solucionados en las aplicaciones demostradas.

En la experiencia del equipo financiero,  durante los  Sprint Review,  el PO y los  Managers rectifican las prioridades de los elementos del Product Backlog, llegando incluso a agregar nuevos requerimientos a la lista. En ocasiones, no ha sido posible que el PO y los Managers tengan un espacio disponible en sus agendas para poder llevar a cabo el  Sprint Review  en cuanto finaliza el Sprint. Para optimizar el uso del tiempo, el equipo financiero ha decidido organizar el Sprint Retrospective antes que el Sprint Review.

El  Sprint  Retrospective,   ha   sido  una   instrumento  de  gran  utilidad  al   equipo   financiero. Durante   estas   reuniones   se   han   identificado   prácticas   intrínsecas   al   equipo   que   sin   un período de retrospección no serían fáciles de reconocer. El resultado natural de los  Sprint  Retrospective,   es   la   creación   de   estándares   que   por   necesidad   del   mismo  Equipo  son definidos con el objetivo de agilizar el proceso de desarrollo de software.  A continuación se listan algunos de los estándares que el equipo ha acordado:

1. Crear prueba web sin parámetros para simular la ejecución de la funcionalidad desde el menú principal

2. Definir de manera detallada cada una de las tareas3. Antes de dar por finalizada cualquier tarea, esta debe ser cotejada de manera cuidadosa 

contra las pruebas  por el SM y el integrante del equipo que la finalizó

4. Incluir JavaDocs en todos los métodos, indicando propósito y cualquier situación especial a considerar para utilizar el método

5. Incluir comentarios en aquellas líneas de código que así lo ameriten

Una vez que se ha finalizado una iteración del proceso, este comienza de nuevo con el Sprint  Planning Meeting donde nuevamente el SM convoca al PO y Managers. Debido a las agendas ocupadas  del  PO y   los  Managers,   durante   el   tiempo  que  el   equipo   financiero  ha  estado implementando Scrum, esta reunión se ha ido adaptando de tal modo que el Sprint Review y el Sprint Planning Meeting se llevan a cabo como una sola reunión.

3.3 Resultados Cuantitativos

Como se mencionó anteriormente, es el equipo de desarrollo del sistema financiero de la UM el que decidió aventurarse en los territorios de Scrum, generando en el camino algunos datos dignos de analizar. Es necesario mencionar que este equipo decidió  implementar  Sprints  de tres semanas cada uno, y que en el periodo de tiempo que a este caso de estudio atañe, este contaba   con   solo   dos   programadores   que   hacían   las   veces   de   analistas,   diseñadores   e ingenieros  de calidad.  A continuación,  se analizarán y explicarán de manera  detallada   los resultados obtenidos.

Como se aprecia en la figura 1, durante los primeros tres Sprints el nivel de productividad se fue incrementando de manera progresiva. Es evidente que conforme el equipo fue asimilando el proceso de  Scrum, un mayor porcentaje de las tareas se logró  completar.  Es importante hacer notar que el éxito de cada Sprint se fundamenta en el análisis cuidadoso de cada una de las funcionalidades seleccionadas del  Product Backlog. Si se descuida este factor de éxito, sería   muy   fácil   sobrepasar   la   capacidad   de   trabajo   del   equipo   dando   como   resultado   la incapacidad de cumplir con el compromiso de finalizar el 100% de las tareas.  Cómo en todo proceso de aprendizaje, es a través de la prueba y el error, que el equipo adquiere la maestría necesaria para lograr un equilibrio entre la capacidad del equipo y la carga de trabajo.

Se puede notar que a partir del cuarto Sprint hay una caída drástica de 35.71% en el nivel de productividad.  Las causas se analizarán a detalle más adelante en la figura 3.

Bajo la forma particular de trabajo de Scrum, se espera que debido a la continua interacción entre   el   PO   y   el  Equipo,   cada   funcionalidad   liberada   cumpla   de   manera   fiel   todos   los requisitos que se solicitaron, elevando así la calidad del software (7). 

Tomando como base este punto, se considera de relevancia el analizar de qué tipo de tareas está compuesto cada  Sprint. Es decir, tareas que agregan nueva funcionalidad, tareas que corrigen funcionalidad o tareas que modifican la funcionalidad.

Figura 2: Composición de las tareas

En la  figura 2 se puede observar que durante  los  Sprint  uno,  dos,  cinco y seis,  el  Sprint  Backlog  se compuso exclusivamente de tareas orientadas a generar nueva funcionalidad. Es decir, en estos ciclos no se trabajó en resolver bugs, ni en agregar o modificar funcionalidad a aplicaciones  ya existentes.  En el   tercer  Sprint,  14.29% de las  tareas  en que se  trabajaron, estuvieron orientadas a modificar funcionalidades de aplicaciones ya liberadas anteriormente. Esto puede interpretarse de dos maneras:

1. Hizo falta un análisis  más cuidadoso en compañía del  PO  a la hora de detallar  las funcionalidades   para   comprender   perfectamente   el   requerimiento   antes   de   iniciar alguno de los Sprints anteriores. 

2. El usuario final, una vez que tuvo la funcionalidad requerida, se da cuenta que esta no satisface plenamente sus necesidades. 

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

0%

20%

40%

60%

80%

100%

100% 100%86%

57%

100% 100%

0% 0%0%

29%

0% 0%0% 0%14% 14%

0% 0%

Modificación Funcionalidad

Corrección de Funcionalidad

Nueva Funcionalidad

En la figura 3, se aprecia que a partir del  Sprint cuatro, el  Equipo se vio en la necesidad de aceptar tareas que originalmente no habían formado parte del Sprint Backlog. Se hace evidente en   la   figura   1,   que   fue   imposible   finalizar   las   tareas   en   las   cuales   el  Equipo  se   había comprometido a entregar.

Figura 3: Tareas Imprevistas

¿Qué  ocasionó  este  escenario?  El  sistema financiero   tiene una antigüedad de siete  años y cuenta con ocho módulos principales, haciendo de la labor de mantenimiento de código una necesidad  primaria   que  demanda   recursos,   como   se  puede   observar   en   la   figura   2.   Esta situación abre  la  puerta  para que el  PO solicite  ciertas  modificaciones  y correcciones  con carácter de urgencia.

Algunos de estos requerimientos extraordinarios, están en relación directa con determinadas fechas o acontecimientos bien identificados como parte de la vida institucional. Por ejemplo, inicio y término del ciclo escolar,  inicio y fin de año contable.  En la figura 3, los tres últimos Sprints  se corresponden con períodos de cierre de año contable e inicio del siguiente ciclo contable.

Aunque se considera como una opción viable que el SM acepte nuevas tareas para un Sprint que ya inició, se considera una mejor práctica el finalizar el Sprint para reorganizar de nuevo las prioridades de los requerimientos (3).

Una táctica que el equipo financiero ha adoptado, es identificar en conjunto con el PO y los Managers,   cualquier   probabilidad   de   la   existencia   de   solicitudes   de   requerimientos inesperados durante el Sprint, disminuyendo entonces de manera inversa la cantidad de tareas aceptadas por el equipo.

Conclusiones

La implementación correcta de Scrum no sucede de la noche a la mañana. Este es un proceso paulatino, en donde cada uno de los distintos roles debe aprender sus responsabilidades y a través de la práctica continua lograr jugar correctamente su papel.

Algunas  partes  de  Scrum  se han adaptado en la  Dirección de Sistemas de la  UM, con el objetivo de hacer la transición de una manera menos drástica, especialmente para el PO y los 

Managers. Afortunadamente  Scrum es lo suficientemente flexible como para adaptarse y así facilitar la asimilación del proceso. Sin embargo, se debe estar atento de no degradar el Scrum, eliminando así cualquier valor que este pudiera agregar a la organización.

En cada  Sprint Planning Meeting  fue necesario analizar  detenidamente las funcionalidades que se aceptaron en cada Sprint. Es muy fácil aceptar diez elementos del Product Backlog y al final   del  Sprint  darse   cuenta   que   se   sobrepasó   la   capacidad   productiva   del   equipo.   El determinar de manera real la cantidad de recursos que una funcionalidad demandará  es un punto clave para el éxito de Scrum

La comunicación constante entre el PO, el SM y el  Equipo garantizó que en cada  Sprint  se trabajara solo en aquellas funcionalidades que realmente  le  interesaban al  PO, resolviendo necesidades reales y evitando así la generación de código ocioso.

Anticiparse   a   las   fecha   críticas   que   demarcan   la   vida   de   la   institución,   evitando   así   la sobrecarga del Equipo por un incremento espontáneo de elementos en el Sprint Backlog.

Realizar el  Daily Scrum  de manera religiosa, ya que es muy fácil que esta práctica se vea ahogada entre las múltiples ocupaciones diarias. Sin embargo, no se debe caer en la tentación de alargar la duración de esta reunión más allá de 15 a 20 minutos.

Trabajo Futuro

El proceso de cambio del equipo de desarrollo del sistema financiero apenas comienza. Hay un largo camino por delante hasta que se logre dominar completamente el proceso de Scrum. Sin embargo, en un proceso de desarrollo de software no es suficiente con lograr desarrollar la capacidad de ser flexible y adaptarse rápidamente a la realidad cambiante. Es necesario a la vez, asegurar que los procesos relevantes sean implementados de manera eficiente, alcanzando así un nivel superior de desempeño (9).

El caso de estudio se continuará documentando mientras finaliza su transición hacia Scrum e inicia el camino hacia el CMMI.

BIBLIOGRAFÍA

1. Sutherland, Jeff. Agile development: Lessons learned from the first scrum. [aut. libro] Jeff Sutherland y Ken Schwaber and Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile Process. 2004, págs. 50­54.

2. Schwaber, Ken. Scrum development process. [aut. libro] Jeff Sutherland y Ken Schwaber and Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile Process.  1995, págs. 58­76.

3. Deemer, Pete y Benefield, Gabriell. Scrum primer. [aut. libro] Jeff Sutherland y Ken Schwaber and Co­Creators Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile  Process. 2006, págs. 20­32.

4. Sutherland, Jeff. A brief introduction to scrum. [aut. libro] Jeff Sutherland, Ken Schwaber y Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile  Process. 2006, págs. 14­19.

5. Reed R., Paul Jr. Developing Applications with Visual Basic and UML. s.l. : Addison­Wesley, 2000.

6. Raible, Matt. AppFuse. [En línea] http://appfuse.org.

7. Sutherland, Jeff. Type­c all­at­once scrum for paralell pipelining of sprints in complex projects. [aut. libro] Jeff Sutherland, Ken Schwaber y Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile Process. págs. 140­167.

8. Google. DocsGoogle. [En línea] http://docs.google.com.

9. Sutherland, Jeff, Ruseng Jackobsen, Cartsen y Johnson, Kent. Scrum and ccmi level 5: The magic potion for code warriors. [aut. libro] Jeff Sutherland, Ken Schwaber y Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile Process. págs. 106­120.

10. Sutherland, Jeff, Ken, Schwaber y Scrum, and Co­Creators of Scrum. Scrum Papers: Nuts, Bolts and Origins of an Agile Process. Newton : s.n., 2007.

[