SciELO - Scientific Electronic Library Online

 
 issue7Biblioteca en la nubeOffice 365 De Microsoft Se Une a Cloud Computing author indexsubject indexarticles search
Home Pagealphabetic serial listing  

Services on Demand

Article

Indicators

    Related links

    • Have no cited articlesCited by SciELO
    • Have no similar articlesSimilars in SciELO

    Bookmark

    Revista de Información, Tecnología y Sociedad

    Print version ISSN 1997-4044

    RITS  no.7 La Paz Nov. 2012

     

    Artículo

     

    Scrum Distribuido Una Metodologia De Desarrollo En La Nube

     

     

    Edy Huiza Yampasi
    Universidad Mayor de San Andrés
    Facultad de Ciencias Puras y Naturales
    Carrera de Informática
    Simulación de Sistemas
    Kbyte@live.com.ar

     

     


    RESUMEN

    En el presente artículo se intenta dar una visión general a cerca de la metodología scrum para trabajar con equipos de desarrollo de software distribuidos en todo el mundo con base en la computación en la nube y las posibles problemáticas al trabajar con ella.

    Palabras Clave

    Scrum, metodología de desarrollo, Software a medida, Modelado, Flexibilidad scrum, agilidad, ambiente de trabajo, computación en la nube, scrum manager, internet.


     

     

    1.INTRODUCCION

    El avance de la tecnología y el uso masivo de internet ha revolucionado el mundo entero y con ella también se ha desarrollado el método de trabajo, ahora las personas podemos trabajar a través de internet sin necesidad de salir de casa. En los últimos años esta forma de trabajo se ha incrementado, y ahora con el desarrollo de la computación en la nube pues esta tendencia se incrementara aún más, puesto que los beneficios son mayores tanto como para la empresa contratante como para el empleado. Por todo lo anterior descrito se hace presenta la necesidad de una metodología de desarrollo de sistemas que pueda trabajar con este medio de trabajo y es justamente ahí donde se hace presente SCRUM DISTRIBUIDO, que gracias a su flexibilidad puede trabajar con equipos de trabajo distribuido en todo el mundo.

     

    2.PRINCIPIOS DE AGILIDAD

    En el contexto actual del desarrollo de productos y servicios nos enfrentamos a escenarios de creciente dinamismo e incertidumbre, tanto por la exigencia de innovación que demandan los mercados, como por la inestabilidad de los requisitos, sea por la propia falta de una visión clara del cliente como por las mismas exigencias de cambio de las circunstancias que rodean a los proyectos.

    Esto hace necesario incorporar enfoques de desarrollo que sean flexibles y adaptables a los cambios, puntos frente a los que las metodologías tradicionales (predictivas y basadas en procesos) se han revelado insuficientes, causando la pérdida del rumbo, el retraso crónico o simplemente el fracaso de los proyectos [1].

    Es por esta razón que para las metodologías agiles se ha llegado a valorar. [1]

    A los individuos y su interacción por encimadelos procesosylas herramientas.

    El software que funciona por encima de la documentación exhaustiva.

    La colaboración con el cliente por encima de la negociación contractual.

    La respuesta al cambio, por encima del seguimiento de un plan.

     

    3.¿QUE ES SCRUM?

    Scrum es una Metodología Ágil de Gestión de Proyectos que se basa en la adaptación continua a las circunstancias evolutivas del Proyecto apoyándose en iteraciones cortas conocidas como Sprint a través del siguiente ciclo:


    Fig. 1. Ciclo de desarrollo de scrum
    4.SCRUM DISTRIBUIDO

    Definiremos Scrum Distribuido como la variante de Scrum adaptada a los ambientes distribuidos, donde los diferentes participantes del Proyecto no comparten una misma ubicación física y/o temporal.

    Usar Scrum en equipos distribuidos plantea una serie de retos a superar y que provienen de la distancia física, las diferencias culturales e idiomáticas, el salto empresarial y los horarios particulares de cada equipo y persona del equipo. Diferencias que impactan, sobre todo, en la comunicación entre los miembros del equipo y, por ende, en la generación de un flujo de trabajo ágil, uno de los fundamentos de Scrum, pudiéndose dar situaciones con falta de sincronismo, pérdidas de afecciones personales, desmotivación o incomprensión.

    4.1 El equipo y el ambiente en el que se desarrolla

    La condición de equipo distribuido está relacionada con la imposibilidad de realizar un trabajo regular y conjunto en un mismo lugar y en una misma franja horaria. Por lo tanto, podemos encontrar distintas combinaciones de situaciones en las que encuadrar un equipo distribuido.

    Por un lado, atendiendo a la separación espacial de los integrantes, podemos identificar dos grandes categorías de situaciones[2] :

    •      Equipo particionado, aquél en que el grupo se encuentra dividido, pero algunos integrantes comparten el espacio de trabajo diariamente. Dentro de este caso podrían darse distintas situaciones como por ejemplo: el equipo de desarrollo colocado y el PO y/o SM en una ubicación distinta; o parte del equipo colocado con el PO y/o SM, otra parte del equipo colocada en una ubicación diferente. [2]

    •      Equipo virtual, aquél en el que todos los integrantes se encuentran distribuidos, es decir, no hay posibilidad de contacto cara-a-cara regular por parte de ninguno de los componentes del equipo.[2]

    Por otro lado, si consideramos la dimensión temporal, podemos tener distintos escenarios según las mayores a menores posibilidades de coincidencia entre los integrantes si:

    •      Comparten el mismo uso horario, por lo que existe posibilidad de comunicación sincrónica videoconferencia, teleconferencia o chat).

    •      Se encuentran en distinto uso horario con franja horaria común, lo que posibilita la comunicación sincrónica a determinadas horas que son comunes.

    •      Se encuentran en distinto huso horario sin franja horaria común, lo que impide u obstaculiza significativamente la comunicación sincrónica regular, y la comunicación es casi completamente asincrónica (foros, e-mails, wikis, etc.).

    •      Cuentan con disponibilidad de tiempo irregular, por lo que la coordinación y comunicación sólo es posible en forma asincrónica.

    4.2 Ubicación Geográfica y Horarios.

    Como hemos comentado, los equipos distribuidos se enfrentan, además, con otros dos grandes grupos de impedimentos o barreras con origen en:

    •      La ubicación geográfica
    •      La diferencia horaria.

    Desde hace décadas existen diferentes estudios (Allen, 1977; Kraut, 1988) que apoyan la teoría de que la proximidad está directamente relacionada con la colaboración efectiva. Teniendo en cuenta esta información, parece obvio pensar que los dos primeros tipos de equipos distribuidos (los co-localizados) encontrarán menos problemas a la hora de aplicar Scrum que los equipos remotos, sobre todo si tenemos en cuenta uno de los doce principios del Manifiesto Ágil dice: "El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara" el cual, en el caso de los equipos remotos, no podrá cumplirse literalmente, aunque con las herramientas adecuadas podrá tratar de simularse.

    Además, los equipos remotos gozan de mayores dificultades debido a que, a mayores distancias, mayor será la probabilidad de que varíen los días festivos o de vacaciones habituales. Un claro ejemplo lo tenemos cuando colaboran un equipo ubicado en el hemisferio norte y otro en el hemisferio sur, donde el verano marca las vacaciones entre julio y agosto en el primer caso, y entre enero y febrero en el segundo.

    4.3 Flexibilidad Scrum

    Cada proyecto tiene sus propias circunstancias: estabilidad del entorno, componente de innovación, grado de criticidad del producto que debe construir, cultura de la organización que lo desarrolla, etc. No hay dos proyectos iguales, ni dos empresas iguales; ni por tanto, una "talla única" de gestión de proyectos. La cuestión no es determinar si el modelo "bueno" para el software es PMI o Scrum, CMMI o Extreme Programming. La Flexibilidad se consigue al conocer ambos y emplear la forma más adecuada a las circunstancias de cada proyecto o de cada empresa.

    Se consigue al combinar y emplear modelos y prácticas desde el conocimiento de su "fondo" además del de su forma, para lograr la mejor "talla" para la empresa.

    [4] Un "gestor flexible", un "ScrumManager" tiene experiencia de trabajo en su industria, y además una visión sintética de la tesis y la antítesis; y cuanto mayores sean ambos mejor gestor será.

    4.4 Comunicación del Equipo

    Los equipos distribuidos deben registrar y etiquetar todas las comunicaciones que ocurran entre cualquiera de los miembros, lo cual comprende escribir la fecha, el contexto, los participantes, etc., siempre y cuando estén relacionadas con el objetivo del proyecto en curso.

    El hecho de registrar la comunicación y distribuirse a todos los interesados, así como su posterior lectura, asimilación y respuesta, tiene el riesgo de poder absorber un excesivo tiempo de trabajo. Por ello, es aconsejable que el espacio dedicado, número de caracteres, tiempo de audio, etc., que se puedan registrar sea negociado y acordado al inicio del proyecto por el equipo, por tanto, se trata de establecer un protocolo de comunicación ágil, de tal forma que se mantenga el principio:

    [1|] "El software que funciona por encima de la comunicación exhaustiva". (Beck et al., 2001).

    El concepto de comunicación en equipos distribuidos tiene dos características principales para el caso más extremo de distribución física de sus miembros:

    •      Comunicación asíncrona
    •      Imposibilidad de comunicación no verbal.

    4.5 El reto de la computación en la nube

    El desarrollo de la computación en la nube está generando un avance tecnológico muy grande y cada vez es mayor la demanda de creación de software en la web, y es justamente con ese enfoque con el que trabaja la computación en la nube, entonces satisfacer esta necesidad es un reto al paradigma informático, ya que somos nosotros los que debemos justamente satisfacer dicha necesidad. Pero el poder trabajar con equipos distribuidos en todo el mundo lejos de dificultar el desarrollo del sistema debe ser una ventaja o así debemos entenderlo.

    [6] No obstante, disponemos de herramientas que pueden ayudarnos, si no a derribar por completo esas barreras, sí a conseguir establecer una comunicación con garantía de éxito y conseguir que las personas funcionen como un verdadero equipo:

    •      Email, comunicación asíncrona
    •      Mailing List, comunicación de broadcasting asíncrona.
    •      Mensajería instantánea (instant messaging), comunicación en tiempo real basada en texto.
    •      Conference Calls, conferencias telefónicas entre diversos miembros.
    •      Skype, una alternativa a las conference calls, con distintas opciones gratuitas.
    •      Videoconferencias, conferencias audio/video entre diferentes sedes donde se ubican los equipos.
    •      Webcams, alternativa de bajo coste a las videoconferencias, más enfocada al dialogo uno a uno.
    •      Escritorios compartidos, interacción persona - máquina distribuida.

     

    5. CONCLUSION

    El desarrollo de tecnología y su impacto en la sociedad está generando necesidades de trabajo y con ella metodologías de trabajo que intentan dar una solución viable a esta problemática, no hay duda que dichas necesidades se irán incrementando, como también se seguirá planteando posibles soluciones a estas. Las metodologías de desarrollo de sistemas están evolucionando para poder trabajar con distintos ambientes de trabajo.

     

    6.REFERENCIAS

    Beck, K. et al. (2001). Manifiesto por el Desarrollo Ágil del Software. Extraído de http://agilemanifesto.org/iso/es/        [ Links ]

    Fainstein, Héctor N. (2005). ¿Qué son los equipos de trabajo?.Gestiopolis [Blog post]. Extraído de http://www.gestiopolis.com/canales5/rrhh/hfainstein/h42.htm        [ Links ]

    Kniberg, H. (2007). Scrum y XP desde las trincheras. Traducción al español por Angel Medinilla. Extraído de: http://www.proyectalis.com/wpcontent/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf        [ Links ]

    Palacio, J. (2007). Flexibilidad con Scrum. Extraído de: http://www.scrummanager.net/files/flexibilidad_con_scrum.pdf        [ Links ]

    Trabajo de investigación - Scrum distribuido Extraído de http://www.scrummanager.net/files/scrum_distribuido.pdf        [ Links ]