KOWLAN: Una experiencia Scrum en un entorno de innovación

Javier García-Algarra, Javier González-Ordás

Telefónica Investigación y Desarrollo, Madrid, Spain {algarra, javiord}@tid.es

Resumen: Esta comunicación describe el empleo de Scrum en un proyecto de diagnóstico de fallos en la red de datos MACROLAN de Telefónica España. El desarrollo presentaba un alto grado de incertidumbre por el carácter experimental de la solución tecnológica adoptada, la indefinición de los requisitos y la necesidad de implantarlo en un plazo muy breve. Se optó por Scrum porque parecía adaptarse a este entorno mejor que una solución waterfall. El equipo carecía de experiencia previa en esta metodología, y el usuario no la conocía. Pese a estas dificultades, el proyecto se completó según lo previsto, y Scrum ayudó en gran medida a cumplir el objetivo.

Palabras clave: Scrum, Agile, sistemas multiagente, redes bayesianas, diagnóstico distribuido,

1 Introducción

La operación de redes de telecomunicación es una actividad que tras décadas de estabilidad, vive un proceso de cambios profundos. La aplicación de modelos de referencia de aceptación general como ITU-T TMN [1] o, en fechas más recientes, TMF NGOSS [2], ha guiado el diseño de sistemas comerciales o propietarios de las operadoras. En entornos empresariales, la familia de normas en torno a SNMP [3] ha cumplido una función similar.

Estas arquitecturas clásicas emplean un principio implícito de diseño y es que el estado de todas las variables de la red se conoce en un instante dado. Una jerarquía de niveles permite distribuir de manera ordenada los componentes de las diferentes áreas funcionales. El enfoque determinista ha demostrado su utilidad cuando toda la red pertenece a un único dominio de gestión y el número de nodos está en un rango de hasta decenas de miles. Sin embargo, la realidad evoluciona hacia escenarios en los que en la prestación de los servicios intervienen varios actores. Aparece la incertidumbre como un dato más de partida; el estado de cada componente va asociado a una función de probabilidad. En lugar de manejar miles de elementos hay que controlar millones y eso convierte en inviables desde el punto de vista computacional las soluciones centralizadas. Un tercer efecto del crecimiento y sofisticación de las redes es la aparición de comportamientos emergentes, debido a su naturaleza compleja [4]-[7].

El diagnóstico es una de las facetas de la gestión de red más sensibles a la incertidumbre. La detección de la causa raíz de una avería requiere en un alto porcentaje de ocasiones la intervención de un experto. Las pruebas que hay que lanzar en cada caso dependen de la configuración del servicio, que puede involucrar decenas de equipos y tecnologías heterogéneas. Además, es común que, al fallar las comunicaciones, la información disponible para alcanzar una conclusión no sea completa ya que resulta imposible acceder a algunos elementos. Es el experto el que como un médico sabe interpretar el conjunto de síntomas que se presentan y decidir entre las posibles causas, basándose en su conocimiento previo. Dado que los expertos son recursos muy escasos y costosos, la investigación académica e industrial lleva años buscando modelos capaces de emular su comportamiento.

KOWLAN [8],[9] es un proyecto experimental que se desarrolló durante 2009 para diagnosticar de forma automática las averías que se producen en la red de datos MACROLAN de Telefónica España. Su concepción y diseño se plantearon como un ejercicio para atacar un problema conocido con estrategia, tecnología y modelo de desarrollo que rompieran con el enfoque tradicional.

1.1 Principios de diseño e implementación

Antes del comienzo del proyecto, el grupo de trabajo había establecido tres principios filosóficos a los que ceñirse para abordar la gestión de red desde una perspectiva nueva. El primero, la neutralidad de cualquier solución, que debe adaptarse al mapa de sistemas existente. Uno de los problemas más comunes en el mundo TIC es la convivencia de sistemas de generaciones distintas y la tentación de hacer tabla rasa del pasado para construir todo desde cero cada poco tiempo. El segundo, muy ligado al anterior, es reducir al mínimo las perturbaciones causadas por la implantación y para ello el nuevo sistema debe coexistir con el anterior sin obligar a transiciones traumáticas. El tercero es la inevitabilidad de la incertidumbre, así que el sistema debe funcionar con datos incompletos o incluso parcialmente erróneos.

Para evitar los problemas de escalado, se decidió construir las nuevas aplicaciones de forma distribuida, para que puedan crecer orgánicamente con la red. En cuanto a la representación del conocimiento, se optó desde el comienzo por emplear tecnología semántica, como forma de dar más valor a la información y potenciar su reutilización (por ejemplo, para aprendizaje). Para resolver el núcleo fundamental del problema, el diagnóstico en entornos con incertidumbre, nos inclinamos por las redes bayesianas (BN). Éstas fueron descritas por primera vez por Judea Pearl [10] y se formalizan mediante un grafo en el que los nodos representan las variables y los arcos sus relaciones de probabilidad. Las redes bayesianas son muy eficaces para realizar un razonamiento “hacia atrás”, esto es, en función de los síntomas observados calculan la probabilidad de las distintas causas que los han podido originar. Se utilizan con éxito en distintos campos de aplicación y en fechas recientes van ganando terreno como una alternativa a otros algoritmos para el diagnóstico en telecomunicaciones [11]-[14].

Una última restricción, que no afecta al diseño pero sí a la realización, fue la de

utilizar en exclusiva software open source y hardware económico, para minimizar los costes de despliegue y mantenimiento.

2 Elección de la metodología

Antes de la implementación de KOWLAN, se realizó una prueba de concepto denominada KOWGAR para detectar problemas de navegación en la Intranet de Telefónica I+D [15]. Este ejercicio permitió al equipo familiarizarse con los componentes tecnológicos y comprobar la viabilidad técnica de la solución. Debido a su carácter de prototipo de laboratorio los aspectos metodológicos del desarrollo no se consideraron de máxima prioridad.

A finales de 2008 se solicitó la realización de un sistema basado en la tecnología KOWGAR para ayudar en el diagnóstico de averías MACROLAN. Este es el nombre con el que Telefónica España comercializa su servicio de redes privadas virtuales de banda ancha, sobre accesos basados en Ethernet, con velocidades de 2Mbit/s a 1Gbit/s. Emplea tecnologías estándar de Red Privada Virtual de niveles 2 y nivel 3 para conectar sedes de cliente situadas en distintas ubicaciones geográficas con prestaciones equivalentes a las que se obtendrían si perteneciesen a una misma red de área local. Para su construcción se combinan diversas tecnologías de acceso y de transporte, dando lugar a seis posibles escenarios según se utilicen o no enlaces de fibra, accesos de cobre, conversores de medios, circuitos dedicados o tramos JDS (Jerarquía Digital Síncrona). Cubre todo el territorio español y cuenta en la actualidad con unos 40.000 circuitos.

Las necesidades del negocio imponían un plazo de realización y despliegue de seis meses, con la primera versión operativa en la red en tan solo dos, coste cero de adaptación en cualquier sistema del que hubiera que obtener datos y coste cero de licencias. Con esta planificación se buscaba demostrar la capacidad tanto de la plataforma KOWGAR como de Scrum para aportar valor a Telefónica. Estos condicionantes, junto con la indefinición de los requisitos funcionales, hicieron pensar en Scrum como opción para gestionar el desarrollo [17],[18].

Pese a que el equipo no tenía experiencia previa en un desarrollo Agile de envergadura, podía contar con el apoyo y la formación del grupo de metodología software de Telefónica I+D que en esos momentos estaba promocionando su uso [16].

3 Scrum en KOWLAN

En el proyecto se adoptó el Agile TI+D Framework desarrollado por el citado equipo y basado en Scrum. A continuación se describe el esquema de trabajo que se siguió.

3.1 Equipo de trabajo

El grupo de trabajo de KOWLAN estuvo compuesto de forma estable por seis personas. El núcleo del equipo lo formaron tres ingenieros senior, dos de los cuales habían construido previamente la plataforma KOWGAR. La interfaz de usuario quedó a cargo de un desarrollador Web con dedicación no completa. Participaron también dos estudiantes del programa internacional de becas de Telefónica I+D, uno de la Universidad de Stuttgart durante la primera mitad del proyecto, y otro de la Universidad de Nantes que le sustituyó a partir del tercer sprint. El Scrum Master del proyecto colaboró en tareas de especificación y modelado.

El equipo estaba separado geográficamente. Cuatro de los miembros trabajaban en Madrid y dos en Boecillo (Valladolid). Pese a ello, la colaboración y comunicación no se resintió, gracias al uso de medios de comunicación electrónicos y a la realización de reuniones presenciales periódicas. El Product Owner del proyecto fue el Coordinador del Centro Técnico MACROLAN de Telefónica España en Barcelona.

Una Agile Coach del Grupo de Metodologías Software dio soporte y formación al proyecto durante todo el ciclo de vida. El grupo de desarrollo, incluido el estudiante de Stuttgart, había recibido un curso de metodología Scrum antes de iniciar el proyecto. El estudiante de Nantes, que se incorporó mediado el proyecto, recibió la formación en Scrum del resto del equipo. También se organizó una sesión de una hora con el Product Owner y algunos de los futuros usuarios. La Agile Coach explicó la forma de trabajar, qué podían esperar al final de cada sprint y la importancia de su contribución para el éxito de KOWLAN. A medio plazo se comprobó la importancia de esta sesión, pues los usuarios interiorizaron el lenguaje de Scrum y se involucraron de una forma activa en el proceso.

3.2 Toma de decisiones

En este proyecto se decidió una separación completa de la toma de decisiones técnicas de las de gestión, para comprobar el efecto de Scrum. La composición del equipo, financiación y objetivos globales se fijaron de antemano. Una vez establecidos, la organización interna, selección de herramientas y dirección del desarrollo quedó en manos del equipo, que adoptó todas las decisiones de manera consensuada. Se evitó de forma consciente asimilar la figura del Scrum Master a la del jefe de proyecto tradicional, ciñendo sus funciones a las que indica la metodología. Como parte del experimento, el responsable de gestión de la unidad que desarrolló KOWLAN fue uno de los programadores para evaluar cómo funciona la separación de funciones.

3.3 Herramientas de trabajo

En un proyecto ágil es muy importante compartir el conocimiento en el equipo, y establecer una comunicación fluida con el Product Owner. Para facilitar la colaboración, en KOWLAN se usaron las siguientes herramientas:

• Wiki del proyecto, como herramienta ligera de compartición de información y documentación informal.

• Servidor documental, donde se depositaban todos los ficheros relativos al proyecto. Todos los documentos de trabajo se generaron en inglés.

• Repositorio Subversion para el control de versiones del código. • Blog del proyecto, para facilitar la comunicación dentro del proyecto y,

sobre todo, con otros empleados dentro de Telefónica I+D. • Hoja Excel facilitada por la Agile Coach, para la gestión del Product

Backlog, los Sprint Backlog y la lista de impedimentos. Todos los miembros del equipo tenían acceso y podían actualizarla.

• Bugzilla, para el seguimiento y resolución de reparos. • Microsoft Office para la documentación formal (especificaciones,

presentaciones, guía de uso, etc.) • Correo electrónico, videoconferencia, mensajería instantánea, Skype y

teléfono para la comunicación entre miembros del equipo. La relación del equipo con el Product Owner y los usuarios de KOWLAN la

canalizó el Scrum Master y se realizó por teléfono y correo electrónico. Además se llevaron a cabo los correspondientes Sprint Review en Barcelona.

3.4 Daily Meeting

Se mantuvo a diario por audioconferencia durante todo el proyecto, incluso durante los denominados Improvement Periods (periodos de mejora) entre sprints. En los Daily Meeting participaban todos los miembros del equipo, incluido el Scrum Master y, ocasionalmente, el Agile Coach. El Product Owner nunca estuvo presente.

En los Daily Meeting se informaba sobre las actividades realizadas, las que se iban a iniciar, se señalaban los obstáculos detectados, se discutían brevemente aspectos técnicos y se identificaban áreas de trabajo que requerían reuniones en mayor profundidad. La duración habitual de las reuniones fue de 15 minutos, alcanzando ocasionalmente la media hora.

3.5 Sprint Planning

Scrum distingue dos partes en un Sprint Planning (reunión de planificación de sprint). En la primera el Product Owner, en colaboración con el equipo, propone la funcionalidad que formará parte del siguiente sprint. En la segunda parte, el equipo realiza un desglose detallado en tareas del sprint (reflejado en el Sprint Backlog), estima su duración y determina qué funcionalidad tendrá finalmente cabida.

En KOWLAN, debido a la lejanía geográfica entre el equipo y el Product Owner, la primera parte del Sprint Planning se hizo conjuntamente con el Sprint Review del ciclo anterior, en reuniones celebradas en el Centro Técnico MACROLAN en Barcelona. Para cada uno de los sprints, el Product Owner proponía nueva funcionalidad, identificaba la más prioritaria y proporcionaba información detallada sobre ella.

La segunda parte del Sprint Planning la realizaba el equipo, de forma presencial, o por videoconferencia. En algunas ocasiones se añadió al sprint nueva funcionalidad

de mejoras de la plataforma no solicitada por el cliente. En líneas generales, todas las peticiones del cliente se implementaron en el sprint acordado.

3.6 Sprint Review

Los Sprint Review (revisiones del sprint) consistieron en reuniones de demostración en Barcelona. Todas se hicieron sobre el sistema real. Por este motivo, los usuarios ya habían tenido ocasión de probar brevemente la nueva versión antes de la demo.

Como resultado de cada revisión se aprobaba, por parte del Product Owner, la funcionalidad desarrollada, se sugerían posibles mejoras y, en su caso, se identificaban carencias. Los Sprint Review sirvieron también para evaluar la experiencia de los usuarios con el sistema en producción desde el anterior sprint y obtener realimentación muy útil para la evolución del sistema.

3.7 Planificación

KOWLAN fue un proyecto de 6 meses y 4 sprints de duración, cada uno de los cuales con una duración de 4-5 semanas, y separados por un periodo de mejora.

3.7.1 Sprint 0

El Sprint 0 corresponde a la fase de definición del producto. En KOWLAN se sustanció con una visita de tres días al Centro Técnico MACROLAN del Scrum Master y de un colaborador experto para la captura de requisitos, para conocer los procesos de trabajo del Centro Técnico y las herramientas que utilizaban, y para modelar las casuísticas de fallos del servicio y los flujos de diagnóstico.

La información proporcionada se tradujo en los siguientes elementos: • Product Backlog de KOWLAN, aprobado y priorizado por el Product

Owner • Arquitectura de alto nivel de KOWLAN. • Red bayesiana genérica para el diagnóstico de fallos en MACROLAN.

El equipo evaluó la complejidad de KOWLAN durante el Estimation Meeting (reunión de estimación) del proyecto. Para ello, se utilizó la técnica del Planning Poker. Sólo se asignó un esfuerzo previsto a aquella funcionalidad con un grado de definición razonable. El resto, la menos prioritaria, se marcó con un esfuerzo 100, equivalente a indefinido.

3.7.2 Sprint 1

El primer sprint tenía como objetivo permitir el diagnóstico básico de cortes francos de servicio, por petición desde la interfaz de usuario. De esta forma, se cumplía con la premisa de aportar valor a los técnicos de MACROLAN antes de dos meses. Para fomentar su uso, se decidió mostrar en la interfaz de usuario el resultado de las

pruebas realizadas en el mismo formato que el de los scripts de test que manejaban hasta entonces los operadores.

El esfuerzo en el primer sprint se dedicó a las siguientes actividades: • Arquitectura detallada del sistema. • Ampliación de la plataforma KOWGAR para cubrir ciertas necesidades

adicionales impuestas por el escenario MACROLAN. • Construcción de redes bayesianas completas para todas las posibles

causas de corte franco y en todos los escenarios de red. • Definición del modelo de datos. • Especificación e implementación del modelo semántico que describe la

información intercambiada entre agentes. • Definición e implementación de la interfaz de usuario base. • Implementación de los agentes KOWLAN (de diagnóstico, de

observación, de base de datos, etc.). La complejidad total estimada de la funcionalidad incluida en el Sprint 1 fue de 62

puntos de historia. A priori, esta cifra es adimensional, no tiene una traducción directa en jornadas. Tras crear la descripción detallada de tareas, y estimar su duración, el total resultante fue de 92 jornadas ideales. Empleando un factor de dedicación del 60%, esto corresponde a 131 jornadas reales, o a 26 días laborables para un equipo de 5 miembros. En la práctica, se añadió una semana más, debido a la incertidumbre del proyecto, y a las vacaciones de Navidad.. Teniendo en cuenta estos factores, la duración definitiva del primer sprint fue de poco más de 7 semanas de calendario (30 días laborables). Fue el más largo de todos.

La dificultad del primer sprint estribaba no sólo en la funcionalidad acordada, bastante avanzada para un desarrollo tan corto, sino sobre todo en los siguientes factores:

• Incluía tareas de definición de la arquitectura, de mejora de la plataforma y de creación de herramientas de apoyo.

• La novedad del planteamiento y plan de puesta en producción de KOWLAN no encajaba bien con la cultura existente en la organización (procesos de despliegue y aprobación, comunicación, etc.).

• Dependencia con terceros sistemas y departamentos no implicados directamente en el proyecto, y que no conocían nada sobre él.

• Inexperiencia del equipo de trabajo y del cliente en Scrum. • Información incompleta sobre la red y las pruebas. • Necesidad de desplegar y configurar la infraestructura necesaria

(máquinas, red, permisos de acceso) en tan corto espacio de tiempo. A pesar de los riesgos identificados, el primer sprint de KOWLAN cumplió con el

objetivo marcado. Sólo el inicio automático de diagnósticos hubo de posponerse para el siguiente sprint. La velocidad final del Sprint 1 fue de 60 unidades de esfuerzo en 30 días laborables.

Fig. 1. Burndown Chart del Sprint 1 de KOWLAN. El eje Y representa las jornadas ideales pendientes de realizar, en X se muestran las fechas.

En la figura 1 se observa cómo las estimaciones se ajustaron bien a la evolución real del proyecto. Durante el periodo navideño la línea aparece plana ya que no se actualizó la hoja Excel, pero aún así se aprecia que el avance fue menor. Los últimos días se dedicaron a la integración de componentes, a la realización de pruebas, y a la instalación del sistema en el servidor de producción. Estas tareas dieron menos problemas de los esperados para una primera versión del sistema, lo que explica el rápido avance los últimos días. Las jornadas que quedan pendientes corresponden a la tarea pospuesta para el siguiente ciclo.

El Sprint Review sirvió para validar la funcionalidad desarrollada y dar a conocer el sistema a sus futuros usuarios, que empezaron a experimentar con KOWLAN a partir de entonces.

3.7.3 Sprint 2

El objetivo del segundo sprint fue conectar KOWLAN con los sistemas externos, en concreto con los de gestión de boletines de avería, de provisión de servicios, de gestión de la red de transporte y de inventariado de Equipos de Cliente (EDC), además de comunicarse con los propios EDC de MACROLAN. Se amplió la capacidad de diagnóstico a nuevas hipótesis (además del corte franco), se incluyeron nuevas pruebas y se abordaron mejoras de la interfaz de usuario y de la plataforma.

La complejidad total asignada a este sprint fue de 46 unidades de esfuerzo, que en la estimación de tareas se convirtieron en 57 jornadas, distribuidas en 19 días laborables. Con esta estimación se esperaba una mejora de velocidad respecto al

sprint 1 integraciósprint, elrealizar lesfuerzo

El seglas notas

Fig. 2. Esdel segund

3.7.4 S

La meta implicabagestión dreparacióy se realnovedad su tiempograves sin

La velque en l

que finalmenón con el sistel optimismo las tareas del en 19 días labundo sprint sudel Sprint Rev

tadística de diado sprint.

Sprint 3

del tercer sa documentar de boletines, yón. Se incluyó izaron diversfue que, debido a dar soportn esperar a la locidad estimalos dos sprin

te no se prodema de gestiódel equipo lesegundo. En

borables, la miupuso una noview..

agnósticos diari

sprint era aulos resultado

y redirigir dicnueva casuíst

as mejoras endo al mayor ue al sistema efinalización d

ada fue de 48 nts anteriores.

dujo, ya que nón de la red dee llevó a sub

n la práctica, isma que en dtable mejora

ios de KOWLA

utomatizar elos del diagnóschos boletinestica de fallos, n la interfaz dso del sisteman producción,

del sprint. unidades en 2. En esta oc

no fue posible transporte. Tbestimar el ela velocidad

durante el primfuncional en e

AN. Nótese el

l tratamientostico de KOWs a las unidadse soportaron

de usuario y a, el equipo tu, incluyendo l

24 días laboraasión no que

le finalizar a Tras el éxito dsfuerzo necesfue de 38 un

mer ciclo. el sistema de

cambio tras la

de incidencWLAN en el s

des responsabn nuevos equipen la platafo

uvo que dedicala corrección d

ables, es decir,edó pendiente

tiempo la del primer sario para nidades de

acuerdo a

instalación

cias. Esto sistema de bles de su pos de red

orma. Otra ar parte de de reparos

, la misma e ninguna

funcionalidad. En cuanto a la estimación de jornadas ideales, fue de 59. Debe tenerse en cuenta que la dedicación del equipo fue menor, al invertir parte del tiempo en el soporte en producción, y a que dos de los componentes tuvieron dedicación parcial.

3.7.5 Sprint 4

El último sprint tuvo como objetivo el perfeccionamiento del diagnóstico.

Consistió en mejoras de tipo evolutivo como el reajuste de las probabilidades en las redes bayesianas, la incorporación de alguna casuística adicional y la corrección de errores detectados en el ciclo anterior.

En esta ocasión no se hizo una estimación de esfuerzo, sino que directamente se tomó la funcionalidad prioritaria indicada por el Product Owner, y se realizó la planificación en jornadas tras el desglose en tareas. El resultante fue de 51 jornadas ideales en 17 días laborables (el cuarto fue un sprint corto). Finalmente se descartó una de las mejoras debido a la ausencia de interfaces viables con un tercer sistema, con lo que se implementó el equivalente a 39 jornadas ideales, lo que indica una velocidad semejante a la de los sprints anteriores.

El resultado final fue un sistema de gran valor para el Centro Técnico, que realiza más de 100 diagnósticos automáticos Y 300 manuales al día con KOWLAN.

3.8 Retrospectivas

Al final de cada sprint se realizó una reunión de retrospectiva con todos los miembros del equipo. Las principales conclusiones fueron, en la parte positiva:

• Buena percepción de Scrum, las reuniones diarias resultan muy útiles. Se obtiene una buena imagen de situación, se identificación rápidamente los problemas, se comparten conocimientos y sentimientos.

• El feedback temprano de los usuarios ayudó a centrar mucho el proyecto. El diseño de la interfaz web, es el ejemplo más notable, pero hubo otros de carácter muy técnico en los procedimientos de prueba o en la interconexión con otros sistemas.

• La documentación y herramientas asociadas a Scrum permitieron compartir el conocimiento de una forma muy eficaz.

• Se pasó de forma muy suave del prototipo de los sprints 1 y 2 a un sistema en plena producción a partir del 3.

• La participación de todos los miembros del equipo en la toma de decisiones favorece su implicación con el proyecto y potencia el espíritu colaborativo.

Y en la negativa:

• El Product Backlog no permitió detectar algunas dependencias entre tareas, por lo que puede resultar necesaria alguna herramienta de planificación adicional en proyectos más complejos.

• Aunque lo fundamental en producir software que funcione hay que prestar también cuidado a la documentación, por lo que resulta aconsejable incluirla como una tarea más de los backlog.

• Se echa en falta una gestión de riesgos explícita, si bien las revisiones frecuentes propias de Scrum contribuyen a reducirlos.

• Los desarrolladores pasaron por etapas de gran ansiedad en las fechas previas a cada demo y apenas hubo lugar para rebajar esa tensión.

4. Conclusiones

Scrum demostró ser una metodología de desarrollo útil en un entorno con gran incertidumbre como es el de innovación. Partiendo de un equipo sin experiencia previa en su uso, la curva de aprendizaje fue muy rápida, aunque hay que tener en cuenta que se trataba de un grupo formado por personal experto

Es fundamental dar formación, aunque sea muy somera, al Product Owner y a sus colaboradores técnicos más próximos para que entiendan la forma de trabajar. En particular, es crítico que cada uno de los sprints pueda resumirse en un objetivo principal para que los usuarios concentren sus peticiones y sugerencias en ese campo.

Desde nuestro punto de vista, resulta crucial hablar con los usuarios finales de la aplicación, por muchos niveles intermedios de gestión y especificación que puedan presentarse en las grandes organizaciones. Sólo con su colaboración se puede asegurar un despliegue exitoso en un plazo razonable.

Scrum fortalece los lazos dentro del equipo de trabajo de una forma extraordinaria. Favorece la toma de decisiones de forma democrática, lo que hace que todos se sientan partícipes de ellas y evita la aparición de competencia intragrupal.

La implantación de metodologías ágiles debe vencer escepticismos y resistencias al cambio propias de toda organización. Es importante contar con el respaldo de una decisión de los policy makers al más alto nivel que apoye su implantación. La imagen tópica del Scrum Master rodeado de un grupo de estética geek frente a un tablón lleno de post-it puede resultar simpática entre los iniciados pero poco tranquilizadora para quienes no conocen la metodología. Hay que explotar otras posibilidades para su promoción interna como la gran cantidad de medidas objetivas de productividad que genera. A la vista de los resultados, sugerimos dos mecanismos que resultan útiles en la transmisión de sus ventajas. El primero es que en los equipos haya parte de los componentes que ya hayan tenido una experiencia Scrum, que sepan a lo que se enfrentan y puedan ayudar a sus compañeros a aprovechar esta metodología. El segundo es proporcionar formación a los cuadros intermedios y de gerencia para que, mediante talleres de un día de duración, tengan una experiencia de primera mano de cómo se trabaja en equipo con Scrum y entiendan el significado de los términos. Uno de los problemas que puede aparecer es la tendencia a disfrazar con terminología Agile los procedimientos waterfall más burocráticos.

Hay que desterrar el mito de que Scrum es una metodología de nicho, solo útil para proyectos muy particulares, de tamaño reducido y con un equipo concentrado. La experiencia de KOWLAN demuestra Scrum resulta también beneficioso en un entorno de innovación, geográficamente disperso y en un campo de aplicación

(gestión de la red) en el que no había ninguna referencia previa en la compañía. Creemos que con los ajustes necesarios, Scrum puede resultar también útil en otros escenarios, por su versatilidad y carácter no normativo. No es una fe que se acepta o se rechaza sino una herramienta de gran flexibilidad que se hace buena con su uso.

Referencias

1. ITU-T, “Principles for a Telecommunications Management Network”, Recommendation M.3010, (1996).

2. Creaner, M., Reilly, J.: “NGOSS Distilled – The Essential Guide to Next Generation Telecoms Management”, The Lean Corporation, (2005).

3. IETF Network Working Group: A Simple Network Management Protocol (SNMP). RFC 1157, http://www.ietf.org/rfc/rfc1157.txt

4. Chih-Chun Chen, Sylvia B. Nagi and Christopher D. Clack: Complexity and Emergence in Engineering Systems. Complex Systems in Knowledge based Environments: Theory, Models and Applications. Tolk, Andreas; Jain, Lakhmi C. (editors). Springer: New York, NY, USA, ch. 5, pp 99-128, (2009)

5. M. Faloutsos, P. Faloutsos, C. Faloutsos: On power-law relationships of the Internet topology, Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication, pp 251-262, ACM,( 1999).

6. J. Spencer, D. Johnson, A. Hastie, L. Sacks: Emergent properties of the BT SDH network”, BT Technology Journal, vol. 21, no. 2, pp. 28-36, April (2003)

7. Santiago A., Cárdenas J. P., Mouronte M. L., Feliu V. and Benito R, M: Modeling the topology of SDH networks, International Journal of Modern Physics C, vol. 19, no. 12, pp. 1809-1820, (2008)

8. S. García-Gómez, J. González-Ordás, J. García-Algarra, R. Toribio-Sardón, A. Sedano-Frade, F. Buisan-García: A Multi Agent System for Bayesian Diagnosis in Telecommunication Networks. Proceedings of the 2009 IEEE/WIC/ACM International Joint Conference on Web Intelligence and Intelligent Agent Technology, pp. 195-198 (2009)

9. J. Garcia-Algarra, P. Arozarena-Llopis, S. Garcia-Gomez, A. Carrera-Barroso: A Lightweight Approach to Distributed Network Diagnosis under Uncertainty, Proceedings of the International Conference on Intelligent Networking and Collaborative Systems, INCOS '09, pp. 74-80, (2009).

10. J. Pearl: Bayesian networks: A model of self-activated memory for evidential reasoning, UCLA Report CSD-850017, (1985)

11. J. Ding, N. Jiang, X. Li, B. Krämer, F. Davoli and Yingcai Bai: Construction of Simulation or Probabilistic Inference in Uncertain and Dynamic Networks Based on Bayesian Networks, Proceedings of the Intermational Coference on ITS Telecommunications Proceedings, pp. 983-986, (2006)

12. J. Ding: Probablistic Fault Management in Distributed Systems”, Ph. D. dissertation, FernUniversität in Hagen, Germany, (2008)

13. R. Barco-Moreno: Bayesian modeling of fault diagnosis in mobile communication networks, Ph. D. dissertation, Universidad de Málaga, Spain, (2007).

14. George J. Lee: CAPRI. A Common Architecture for Distributed Probabilistic Internet Fault Diagnosis, Ph. D. dissertation, CSAIL-MIT, Cambridge, MA, USA, (2007)

15. R. Toribio-Sardón, S. García-Gómez, J. González-Ordás and A. Sedano-Frade: Diagnóstico automático en red mediante técnicas probabilísticas. Proceedings of the Telecom I+D Conference, (2009).

16. G. Hornos, M. Izquierdo: Agile at Telefonica I+D, Catalyst for innovative culture. Scrum Alliance, 2009 Munich meeting. http://www.scrumalliance.org (2009)

17. K. Schwaber: Agile Project Management with Scrum. Microsoft Press, ISBN 978-0-735-61993-7 (2004)

18. H. Kniberg: Scrum and XP from the Trenches. Enterprise Software Development, ISBN: 978-1-4303-2264-1 (2007)