Follow the Sun (FTS), un subcampo de la ingeniería de software distribuida globalmente (GDSE), es un tipo de flujo de trabajo de conocimiento global diseñado para reducir el tiempo de comercialización , en el que el producto de conocimiento pertenece y es avanzado por un sitio de producción. en una zona horaria y se trasladaron al final de su día de trabajo al siguiente sitio de producción que se encuentra en varias zonas horarias al oeste para continuar ese trabajo. [1] [2] Idealmente, los días de trabajo en estas zonas horarias se superponen de modo que cuando un sitio termina su día, comienza el siguiente.
FTS tiene el potencial de aumentar significativamente el tiempo total de desarrollo por día (visto desde la perspectiva de un solo huso horario): con dos sitios, el tiempo de desarrollo puede aumentar hasta 16 horas, o hasta 24 horas si hay tres sitios , reduciendo la duración del desarrollo hasta en un 67%.
No se practica comúnmente en la industria y hay pocos casos documentados en los que se aplique con éxito. [3] Esto probablemente se deba a sus requisitos poco comunes, lo que lleva a una falta de conocimiento sobre cómo aplicar con éxito FTS en la práctica.
Historia
Follow the Sun se remonta a mediados de la década de 1990, cuando IBM tenía el primer equipo de software global que se creó específicamente para aprovechar las ventajas de FTS. [4] El equipo se distribuyó en cinco sitios en todo el mundo. Desafortunadamente, en este caso FTS no tuvo éxito porque era poco común entregar los artefactos de software a diario.
Treinen y Miller-Frost han documentado otros dos casos de FTS en IBM. [3] El primer equipo se distribuyó por un sitio en los Estados Unidos y un sitio en Australia. FTS fue un éxito para este equipo. El segundo equipo se distribuyó por un sitio en los Estados Unidos y un sitio en la India. En este caso, FTS no tuvo éxito debido a problemas de comunicación, problemas de zona horaria y diferencias culturales.
Principios
FTS se basa en los siguientes cuatro principios:
- El objetivo principal es la reducción de la duración del desarrollo / tiempo de comercialización .
- Los sitios de producción están separados por muchas zonas horarias.
- Siempre hay un solo sitio que es propietario y trabaja en el proyecto.
- Las transferencias se realizan diariamente al final de cada turno. El siguiente sitio de producción se encuentra en varias zonas horarias al oeste.
Conceptos erróneos comunes
Un paso importante en la definición de FTS es eliminar la ambigüedad de otras configuraciones distribuidas globalmente para indicar claramente lo que no es FTS. Los siguientes cuatro tipos de configuraciones similares distribuidas globalmente no son FTS: [2]
- El trabajo del conocimiento global se define como trabajadores del conocimiento dispersos geográficamente que trabajan en colaboración desde múltiples ubicaciones. [5] Esto no es FTS porque no hay transferencias.
- Servicio 24/7 . En esta configuración, el trabajo se distribuye a los trabajadores que están disponibles en ese momento. Se enfoca en la disponibilidad y los trabajadores tienen poca dependencia, mientras que FTS se enfoca en reducciones de duración y requiere dependencias entre los diferentes sitios para realizar los traspasos diarios.
- Fabricación 24 horas. Esta configuración se enfoca en hacer que los turnos optimicen por completo los recursos costosos que no podrían producir más al aumentar la cantidad de empleados por turno. Sin embargo, este factor que impulsa la reducción del costo de los recursos no es el motor de FTS.
- Turnos múltiples colocados. A diferencia de FTS, esta configuración elige una ubicación donde la mano de obra es barata y ejecuta múltiples turnos de ocho horas al mismo tiempo.
Dificultades
La mayor fortaleza de FTS, que distribuye el desarrollo en múltiples zonas horarias, es simultáneamente su mayor debilidad. Su flujo de trabajo distribuido es más complejo de implementar debido a diferencias culturales y técnicas, así como a las diferencias de tiempo que dificultan la coordinación y la comunicación.
La principal razón por la que FTS es difícil de implementar es porque las transferencias son un elemento esencial que es difícil de hacer bien. El factor más importante que causa esta dificultad es la mala comunicación. [3]
Hay pocos casos documentados de empresas que hayan aplicado FTS con éxito. [3] Algunas empresas han afirmado haber implementado con éxito FTS, pero estas empresas no practicaron las transferencias diarias. [3] [6] Sin embargo, Cameron encontró una cantidad limitada de aplicaciones exitosas de FTS que incluían transferencias diarias de artefactos, utilizando un modelo concurrente distribuido [2] . [7]
Los estudios recientes sobre FTS se han trasladado al modelado matemático de FTS. [8] [9] [10] [11] [12] La investigación se centra en el tema de la velocidad y los problemas relacionados con las transferencias.
Métodos
Como FTS es un subcampo de GDSE, [4] las mismas metodologías ágiles de desarrollo de software que funcionan bien en GDSE funcionan bien con FTS. [2] En particular, Carmel et al. (2009) argumentan que las metodologías de desarrollo de software ágiles ayudan a los principios de FTS porque: [1]
- Apoyar las transferencias diarias. La integración continua y la integración automatizada del código fuente permite que cada sitio trabaje en sus propias bases de código durante su día de trabajo, mientras que la integración mantiene el código actualizado y comprobable para ser utilizado por el siguiente sitio.
- ocuparse de la comunicación. Las metodologías ágiles enfatizan la comunicación. Enfatizan específicamente la comunicación cara a cara, que se puede hacer dentro de un sitio. Dado que FTS tiene como objetivo reducir la comunicación entre sitios, el aspecto cara a cara no es un gran obstáculo para la aplicación general de metodologías de desarrollo ágiles.
- generar cooperación y colaboración. Como FTS requiere más colaboración y cooperación, este énfasis es especialmente útil.
Desafíos
Kroll y col. (2013) han investigado artículos publicados entre 1990 y 2012 y han encontrado 36 mejores prácticas y 17 desafíos para FTS. [13] Los desafíos se agruparon en tres categorías: coordinación, comunicación y cultura. Estos desafíos deben superarse para implementar FTS con éxito.
Coordinación
- Las diferencias de zona horaria reducen las oportunidades de colaboración en tiempo real. Los miembros del equipo deben ser flexibles para lograr la superposición con colegas remotos. La limitada superposición y la demora en las respuestas tienen un impacto negativo en la coordinación.
- Los ciclos de traspaso diarios o el traspaso del trabajo en curso son un requisito de FTS porque sin él no se puede reducir el tiempo de comercialización.
- Dispersión geográfica
- Estimación de costos
- Pérdida de equipo
- Numero de sitios
- Desglose de la coordinación
- Dificultades gerenciales
- Plataformas técnicas
Comunicación
- Pérdida de riqueza comunicativa / comunicación cara a cara
- Dificultades de diversidad sociocultural
- Comunicación sincrónica
- Diferencia de idioma
- Dificultades técnicas
- Gestionar festividades religiosas o nacionales.
Cultura
- Diferencias culturales
- Diferentes antecedentes técnicos
Mejores prácticas
Es de gran importancia seleccionar y adaptar una metodología para las transferencias diarias [1] [13], por ejemplo, utilizando el desarrollo de software ágil o el modelo en cascada .
Las mejores prácticas identificadas son el uso de métodos ágiles y el uso de tecnologías para desarrollar actividades de FTS. Agile admite transferencias diarias, lo cual es un desafío crítico en FTS. [1] Las herramientas de gestión se pueden utilizar para estimar y planificar programas, gestionar sprints y realizar un seguimiento del progreso. Además, las tecnologías como video de conferencias, correos electrónicos y llamadas telefónicas son fáciles de implementar y permiten a las empresas realizar comunicaciones sincrónicas y asincrónicas entre equipos y funcionan bien en un entorno ágil.
Desafortunadamente, no existe una buena práctica sólida que funcione mejor, ya que FTS se puede aplicar de muchas formas.
Sigue la luna
Un concepto relacionado es el seguimiento de la luna , que consiste en programar el trabajo para que se realice específicamente durante las horas nocturnas locales por razones como el ahorro en los costos del centro de datos mediante el uso de electricidad nocturna más barata [14] o potencia de procesamiento adicional.
Otros terminos
- Desarrollo de 24 horas
- desarrollo-las-24 horas
Ver también
notas y referencias
- ↑ a b c d Carmel, E., Dubinsky, Y. y Espinosa, A. (2009, enero). Desarrollo de software Follow the Sun: nuevas perspectivas, fundamento conceptual y estudio de campo exploratorio. En System Sciences, 2009. HICSS'09. 42ª Conferencia Internacional de Hawái sobre (págs. 1-9). IEEE.
- ↑ a b c d Carmel, E., Espinosa, JA y Dubinsky, Y. (2010). Flujo de trabajo "Follow the Sun" en el desarrollo global de software. Revista de sistemas de información de gestión, 27 (1), 17-38.
- ↑ a b c d e Treinen, JJ y Miller-Frost, SL (2006). Siguiendo el sol: estudios de caso en el desarrollo de software global. IBM Systems Journal, 45 (4), 773-783.
- ↑ a b Carmel, E. (1999). Equipos de software globales: colaborando a través de fronteras y husos horarios. PTR de Prentice Hall.
- ^ Espinosa, JA, Cummings, JN, Wilson, JM y Pearce, BM (2003). Problemas de límites de equipo en múltiples firmas globales. Revista de sistemas de información de gestión, 19 (4), 157-190.
- ^ Yap, M. (2005, julio). Follow the sun: desarrollo de programación extremo distribuido. En Agile Conference, 2005. Actas (págs. 218-224). IEEE.
- ^ Alexander Cameron (agosto de 2003). "Conferencia de usuarios racionales 2003. Reducción del tiempo de comercialización mediante técnicas de seguimiento del sol" .
- ^ Espinosa, JA y Carmel, E. (2003, mayo). Modelado de costos de coordinación debido a la separación de tiempo en equipos de software globales. En Taller de desarrollo de software global, Conferencia internacional sobre ingeniería de software (ICSE) (págs. 64-68).
- ^ Jalote, P. y Jain, G. (2006). Asignación de tareas en un modelo de desarrollo de software de 24 h. Revista de sistemas y software, 79 (7), 904-911.
- ^ Setamanit, SO, Wakeland, W. y Raffo, D. (2007). Uso de la simulación para evaluar estrategias de asignación de tareas de desarrollo de software global. Proceso de software: mejora y práctica, 12 (5), 491-503.
- ^ Sooraj, P. y Mohapatra, PK (2008). Modelado del proceso de desarrollo de software de 24 h. Subcontratación estratégica: una revista internacional, 1 (2), 122-141.
- ^ Taweel, A. y Brereton, P. (2006). Modelado del desarrollo de software en zonas horarias. Tecnología de la información y el software, 48 (1), 1-11.
- ↑ a b Kroll, J., Hashmi, SI, Richardson, I. y Audy, JL (2013, agosto). Una revisión sistemática de la literatura de las mejores prácticas y desafíos en el desarrollo de software de seguimiento del sol. En los Talleres Globales de Ingeniería de Software (ICGSEW), 2013 IEEE 8th International Conference on (pp. 18-23). IEEE.
- ^ Jeff Caruso (19 de agosto de 2009). "Sigue a la luna y salva a millones" .
- Godinez, Victor (2 de enero de 2007). "Sol 24 horas al día, 7 días a la semana: como el trabajo de EDS se detiene en una zona horaria, se recupera en otra" . Las noticias de la mañana de Dallas . Consultado el 31 de octubre de 2008 .
- "Siguiendo el sol: estudios de caso en el desarrollo de software global" . Revista de sistemas de IBM. 1 de octubre de 2006 . Consultado el 31 de octubre de 2008 .
- "La red global de centros de llamadas reduce los costos en Barclays" . Computer Weekly. 11 de octubre de 2001 . Consultado el 31 de octubre de 2008 .
enlaces externos
- Ejemplo de uso en la industria - Soporte de TI