Sigue el sol
Tipo de flujo de trabajo en ingeniería de software
Mapa del mundo que muestra parte del mismo durante el día y parte durante la noche; el flujo de trabajo siguiendo el sol permite un trabajo de software continuo.

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 es propiedad de un sitio de producción en una zona horaria y es avanzado por él y entregado al final de su día laboral al siguiente sitio de producción que está varias zonas horarias al oeste para continuar ese trabajo. [1] [2] Idealmente, los días laborales en estas zonas horarias se superponen de tal manera que cuando un sitio termina su día, el siguiente comienza.

FTS tiene el potencial de aumentar significativamente el tiempo total de desarrollo por día (visto desde la perspectiva de una sola zona horaria): 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 aplica con éxito. [3] Esto probablemente se debe a sus requisitos poco comunes, lo que genera una falta de conocimiento sobre cómo aplicar FTS con éxito en la práctica.

Historia

El origen de la técnica Follow-the-sun se remonta a mediados de los años 90, cuando IBM contaba con el primer equipo de software global creado específicamente para aprovechar las ventajas de FTS. [4] El equipo estaba distribuido en cinco sedes en todo el mundo. Lamentablemente, en este caso, FTS no tuvo éxito porque no era habitual transferir los artefactos de software a diario.

Treinen y Miller-Frost han documentado otros dos casos de FTS en IBM. [3] El primer equipo estaba distribuido en un sitio en los Estados Unidos y otro en Australia. El FTS tuvo éxito para este equipo. El segundo equipo estaba distribuido en un sitio en los Estados Unidos y otro en la India. En este caso, el FTS no tuvo éxito debido a problemas de comunicación, problemas de zona horaria y diferencias culturales.

Principios

FTS se basa en cuatro principios:

  1. El objetivo principal es la reducción del tiempo de desarrollo/ tiempo de comercialización .
  2. Los sitios de producción están separados por muchas zonas horarias.
  3. Siempre hay un solo sitio que posee y trabaja en el proyecto.
  4. Los traspasos se realizan diariamente al final de cada turno. El siguiente sitio de producción se encuentra a varias zonas horarias al oeste.

Conceptos erróneos comunes

Un paso importante para definir FTS es distinguirlo de otras configuraciones distribuidas globalmente para indicar claramente qué no es FTS. Estos tipos de configuraciones distribuidas globalmente similares no son FTS: [2]

  • El trabajo de 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 entre los trabajadores que están disponibles en ese momento. Se centra en la disponibilidad y los trabajadores tienen poca dependencia, mientras que FTS se centra en la reducción de la duración y requiere dependencias entre los diferentes sitios para realizar los handoffs diarios.
  • Fabricación las 24 horas. Esta configuración se centra en optimizar al máximo los turnos de trabajo de recursos costosos que no podrían producir más aumentando el número de empleados por turno. Sin embargo, este factor de reducción del coste de los recursos no es el factor de FTS.
  • Turnos múltiples ubicados en el mismo lugar. A diferencia de FTS, esta configuración elige una ubicación donde la mano de obra es barata y ejecuta varios turnos de ocho horas simultáneamente.

Dificultades

La mayor fortaleza de FTS, que reparte el desarrollo en múltiples zonas horarias, es al mismo tiempo su mayor debilidad. Su flujo de trabajo distribuido es más complejo de implementar debido a las diferencias culturales y técnicas, así como a las diferencias horarias, lo que dificulta la coordinación y la comunicación.

La principal razón por la que la implementación de FTS es difícil es porque las transferencias son un elemento esencial que es difícil de hacer correctamente. El factor más importante que causa esta dificultad es la mala comunicación. [3]

Hay pocos casos documentados de empresas que hayan aplicado con éxito el FTS. [3] Algunas empresas han afirmado haber implementado con éxito el FTS, pero no han practicado las entregas diarias. [3] [6] Sin embargo, Cameron encontró una cantidad limitada de aplicaciones exitosas del FTS que sí incluían entregas diarias de artefactos, utilizando un modelo distribuido-concurrente, [2] . [7]

Estudios recientes sobre FTS han pasado al modelado matemático de FTS. [8] [9] [10] [11] [12] La investigación se centra en la cuestión de la velocidad y los problemas relacionados con las transferencias.

Métodos

Como FTS es un subcampo de GDSE, [4] las mismas metodologías de desarrollo de software ágil que funcionan bien en GDSE funcionan bien con FTS. [2] En particular, Carmel et al. (2009) sostienen que las metodologías de desarrollo de software ágil ayudan a los principios de FTS porque: [1]

  1. Admite entregas 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 jornada laboral, mientras que la integración mantiene el código actualizado y comprobable para que lo use el siguiente sitio.
  2. Abordar la comunicación: las metodologías ágiles hacen hincapié en la comunicación, especialmente en la comunicación cara a cara, que puede realizarse dentro de un mismo 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 las metodologías de desarrollo ágiles.
  3. Fomentar la cooperación y la colaboración: como el FTS requiere más colaboración y cooperación, este énfasis es especialmente útil.

Desafíos

Kroll et al. (2013) investigaron artículos publicados entre 1990 y 2012 y encontraron 36 mejores prácticas y 17 desafíos para el FTS. [13] Los desafíos se agruparon en tres categorías: coordinación, comunicación y cultura. Estos desafíos deben superarse para implementar el FTS con éxito.

Coordinación

  • Las diferencias horarias 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 superposición limitada y la demora en las respuestas tienen un impacto negativo en la coordinación.
  • Los ciclos de entrega diaria o la entrega del trabajo en progreso son un requisito de FTS porque sin ello no se puede reducir el tiempo de comercialización.
  • Dispersión geográfica
  • Estimación de costos
  • Pérdida de espíritu de equipo
  • Número de sitios
  • Ruptura de coordinación
  • Dificultades de gestión
  • Plataformas técnicas

Comunicación

  • Pérdida de riqueza comunicativa / comunicación cara a cara
  • Dificultades de la diversidad sociocultural
  • Comunicación sincrónica
  • Diferencia de idioma
  • Dificultades técnicas
  • Gestionar días festivos religiosos o nacionales.

Cultura

  • Diferencias culturales
  • Diferentes antecedentes técnicos

Mejores prácticas

Es de gran importancia seleccionar y adaptar una metodología para las entregas 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 las entregas diarias, lo que constituye un desafío crítico en FTS. [1] Las herramientas de gestión se pueden utilizar para estimar y planificar cronogramas, administrar sprints y realizar un seguimiento del progreso. Además, las tecnologías como videoconferencias, 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.

Sigue la luna

Un concepto relacionado es el de seguir la luna , que consiste en programar trabajos que se realizarán específicamente durante las horas nocturnas locales por razones tales como ahorrar en costos del centro de datos mediante el uso de electricidad nocturna más barata [14] o potencia de procesamiento adicional.

Otros términos

  • Desarrollo 24 horas
  • desarrollo las 24 horas

Véase también

Notas y referencias

  1. ^ abcd Carmel, E., Dubinsky, Y., y Espinosa, A. (enero de 2009). Desarrollo de software siguiendo el sol: nuevas perspectivas, fundamentos conceptuales y estudio de campo exploratorio. En Ciencias de sistemas, 2009. HICSS'09. 42.ª Conferencia internacional de Hawái sobre (págs. 1-9). IEEE.
  2. ^ abcd Carmel, E., Espinosa, JA, & Dubinsky, Y. (2010). Flujo de trabajo "Seguir al sol" en el desarrollo de software global. Journal of Management Information Systems, 27(1), 17-38.
  3. ^ abcde Treinen, JJ y Miller-Frost, SL (2006). Siguiendo el sol: estudios de casos en el desarrollo global de software. IBM Systems Journal, 45(4), 773-783.
  4. ^ ab Carmel, E. (1999). Equipos de software globales: colaboración a través de fronteras y zonas horarias. Prentice Hall PTR.
  5. ^ Espinosa, JA, Cummings, JN, Wilson, JM y Pearce, BM (2003). Problemas de límites entre equipos en múltiples empresas globales. Journal of Management Information Systems, 19(4), 157-190.
  6. ^ Yap, M. (2005, julio). Follow the sun: distributed extreme programming development. En Agile Conference, 2005. Actas (pp. 218-224). IEEE.
  7. ^ Alexander Cameron (agosto de 2003). "Conferencia de usuarios racionales 2003. Reducción del tiempo de comercialización mediante técnicas de seguimiento del sol".
  8. ^ Espinosa, JA, y Carmel, E. (mayo de 2003). Modelado de los costos de coordinación debido a la separación temporal en equipos de software globales. En Global Software Development Workshop, International Conference on Software Engineering (ICSE) (pp. 64-68).
  9. ^ Jalote, P., y Jain, G. (2006). Asignación de tareas en un modelo de desarrollo de software de 24 horas. Journal of Systems and Software, 79(7), 904-911.
  10. ^ Setamanit, SO, Wakeland, W., y Raffo, D. (2007). Uso de simulación para evaluar estrategias globales de asignación de tareas de desarrollo de software. Software Process: Improvement and Practice, 12(5), 491-503.
  11. ^ Sooraj, P., y Mohapatra, PK (2008). Modelado del proceso de desarrollo de software de 24 horas. Subcontratación estratégica: una revista internacional, 1(2), 122-141.
  12. ^ Taweel, A., y Brereton, P. (2006). Modelado del desarrollo de software en distintas zonas horarias. Tecnología de la información y el software, 48(1), 1-11.
  13. ^ ab Kroll, J., Hashmi, SI, Richardson, I., y Audy, JL (agosto de 2013). Una revisión sistemática de la literatura sobre las mejores prácticas y los desafíos en el desarrollo de software "follow-the-sun". En Global Software Engineering Workshops (ICGSEW), 2013 IEEE 8th International Conference on (pp. 18-23). ​​IEEE.
  14. ^ Jeff Caruso (19 de agosto de 2009). "Sigue la luna y ahorra millones".
  • Godinez, Victor (2 de enero de 2007). "Sunshine 24/7: mientras el trabajo de EDS se detiene en una zona horaria, se reanuda en otra". The Dallas Morning News . Consultado el 31 de octubre de 2008 .
  • "Siguiendo el sol: casos prácticos de desarrollo de software global". IBM Systems Journal. 1 de octubre de 2006. Consultado el 31 de octubre de 2008 .
  • "La red global de centros de llamadas reduce los costes en Barclays". Computer Weekly. 11 de octubre de 2001. Consultado el 31 de octubre de 2008 .
  • Ejemplo de uso en la industria - Soporte TI
Obtenido de "https://es.wikipedia.org/w/index.php?title=Sigue-al-sol&oldid=1214733879"