Desarrollo de software ágil distribuido

Métodos de desarrollo de software

El desarrollo de software ágil distribuido es un área de investigación que considera los efectos de aplicar los principios del desarrollo de software ágil a un entorno de desarrollo distribuido globalmente , con el objetivo de superar los desafíos en proyectos distribuidos geográficamente.

Los principios del desarrollo ágil de software proporcionan estructuras para promover una mejor comunicación, lo cual es un factor importante para trabajar con éxito en un entorno distribuido. Sin embargo, no tener interacción cara a cara elimina uno de los principios ágiles básicos. Esto hace que el desarrollo ágil de software distribuido sea más desafiante que el desarrollo ágil de software en general.

Historia / Investigación

La creciente globalización, con la ayuda de las nuevas capacidades que ofrece la eficacia tecnológica de Internet, ha llevado a las empresas de desarrollo de software a deslocalizar sus esfuerzos de desarrollo a áreas económicamente más atractivas. Este fenómeno comenzó en los años 90, mientras que su importancia estratégica se hizo evidente en los años 2000. [1] La mayoría de los estudios iniciales relacionados también datan de esta época. [2]

Durante este tiempo, se publicó el Manifiesto Ágil [3] , que representa una evolución de los enfoques de peso pesado predominantes para el desarrollo de software. Esto naturalmente llevó a la pregunta: "¿puede el desarrollo de software distribuido ser ágil?". Una de las primeras revisiones exhaustivas que intentaron responder a esta pregunta se realizó en 2006. [4] Al estudiar tres organizaciones, descubrieron que "la incorporación cuidadosa de la agilidad en entornos de desarrollo de software distribuido es esencial para abordar varios desafíos de comunicación, control y confianza entre equipos distribuidos". Más tarde, en 2014, se realizó una revisión sistemática de la literatura (SLR) para identificar los principales problemas para lograr que Agile funcione de manera distribuida. [5] En 2019, se realizó una SLR similar. [6] Además, se realizó una revisión general sobre el tema en. [7] Sin embargo, una revisión sistemática de 2023 encontró "que Distributed Scrum no tiene impacto, positivo o negativo, en el éxito general del proyecto" en el desarrollo de software distribuido. [8]

Los resultados de algunas de estas investigaciones se discutirán en la sección Desafíos y Riesgos.

En general, el desarrollo de software ágil distribuido sigue siendo un campo muy dinámico. Se siguen realizando investigaciones sobre todas sus facetas, lo que indica que ofrece oportunidades y ventajas únicas en comparación con los métodos más tradicionales, pero no sin imponer sus propios desafíos y riesgos.

Oportunidades

En un entorno distribuido, es posible que haya dificultades para realizar un seguimiento de la carga de trabajo de todos y de su contribución al resultado final. Mediante la adopción de principios y prácticas ágiles, la visibilidad se hace más clara, ya que hay múltiples iteraciones en las que se pueden visualizar los problemas o las criticidades en las etapas iniciales del proyecto. La integración continua del código de programación, que es una de las piezas centrales del desarrollo de software ágil, también sirve para reducir la configuración de los problemas ejecutivos. La adopción de principios ágiles parece afectar positivamente a la comunicación entre equipos, ya que el avance en los ciclos hace que sea más sencillo para los miembros ver los objetivos a corto plazo. Las revisiones de sprint pueden considerarse un método eficaz para mejorar la comunicación externa, ya que ayudan a compartir datos sobre las características y las condiciones previas entre los socios o las partes interesadas. Las prácticas ágiles también ayudan a generar confianza entre los distintos equipos asociados al proceso al estimular la comunicación constante y la transmisión de los resultados del software. Según un estudio realizado por Passivara, Durasiewicz y Lassenius, la calidad y la comunicación del software mejoran y la comunicación y el esfuerzo coordinado son más regulares en comparación como resultado del enfoque Scrum utilizado en el proyecto. Además, se ha constatado que la inspiración de los colegas se ha expandido. [9] En este sentido, la adopción de prácticas ágiles en un entorno distribuido ha demostrado ser valiosa para la calidad del proyecto y su ejecución. Así, estas pueden considerarse algunas de las ventajas que se consiguen al combinar la agilidad en el desarrollo distribuido, [10] sin embargo, la lista es exhaustiva. Los principales beneficios se pueden enumerar de la siguiente manera:

Mayor diversidad intercultural e intracultural

El entorno distribuido genera una sensación de mentalidad global en lugar de mentalidad local, donde el equipo puede intercambiar y aceptar las ideas, percepciones, cultura, estética, etc. de los demás. Los miembros de una amplia gama de culturas tienen la oportunidad de adquirir y compartir conocimientos de sus asociados, desde un punto de vista alternativo. De esta manera, pueden llevar a cabo nuevos planes para la tarea pensando en nuevas ideas.

Planes de trabajo flexibles

Los miembros del equipo pueden beneficiarse de una gran libertad y oportunidades en su forma de trabajar, con el único objetivo de completar las tareas y entregar los resultados a tiempo. Esto también abre paso a un mayor compromiso con la organización. De esa manera, los empleados pueden equilibrar tanto su vida profesional como personal y, por lo tanto, también se puede lograr el equilibrio entre la vida laboral y personal.

Atravesando zonas horarias

Los equipos pueden abarcar múltiples zonas horarias, de modo que se pueda acceder a ellos siempre que se cumpla el límite de 24 horas. Esto aumenta la productividad, ya que se contrata a personas de todo el mundo. El trabajo a realizar nunca se detiene, ya que siempre hay alguien disponible para ocuparse del problema. Esto también garantiza que el trabajo se lleve a cabo las 24 horas del día, los 7 días de la semana, y que casi no haya tiempo de inactividad. Como un entorno distribuido se centra más en la productividad y el rendimiento, la transferencia del trabajo ayuda a realizar la tarea.

Personas con discapacidades y limitaciones de movilidad.

Como se mencionó, el entorno ágil distribuido otorga más importancia a la productividad y el rendimiento que a la presencialidad. Esto beneficia a las personas con discapacidad, ya que tienen la libertad de trabajar desde un entorno que les resulte cómodo y contribuir al resultado final. Este escenario también es aplicable cuando el empleado no puede estar presente en la oficina y fichar las horas, puede trabajar desde casa para completar las tareas, sin afectar así el resultado final.

Aumento de los niveles de prosperidad

Trabajar en un entorno ágil y distribuido garantiza un mayor nivel de prosperidad y bienestar, tanto para las personas como para la empresa. Esto se debe a que no hay mucho estrés en una sola persona para completar el trabajo, ya que el trabajo se distribuye entre varias personas en todo el mundo. Por lo tanto, esto garantiza el bienestar físico y mental. Además, como varias personas contribuyen con su parte y el trabajo pasa por varias iteraciones, la calidad final del trabajo mejora, lo que es beneficioso para la empresa. Por lo tanto, es una situación en la que todos ganan, tanto la empresa como sus empleados.

Costes de viaje reducidos

Trabajar en un entorno distribuido suele generar la necesidad de mantener debates y reuniones sobre objetivos, plazos, trabajo, etc. Sin embargo, esta adopción de principios y prácticas ágiles en un entorno distribuido ayuda a reducir los costes de viaje, ya que abre la plataforma para comunicarse mediante videoconferencias y otras opciones viables. Esto elimina la necesidad de presencia física y mejora la idea de la interacción cara a cara, de modo que las reuniones se pueden llevar a cabo desde cualquier parte del mundo y sean accesibles para el resto del equipo.

Idea iterativa de ágil

Como el progreso del trabajo se realiza de manera iterativa, se puede realizar una verificación periódica para realizar un seguimiento del estado del producto final y comprobar si todos los miembros están de acuerdo en cuanto al nivel de comprensión. Además, de esta manera es más fácil identificar errores y fallos y se pueden corregir en las primeras etapas a medida que el proceso pasa por varias iteraciones. El aumento de la participación en cada etapa del trabajo da como resultado una mejor calidad del producto final.

Amplio grupo de RRHH

Como el mismo trabajo se lleva a cabo en diferentes partes del mundo, aumenta el rango de capacidades del grupo al llegar a un grupo más amplio de Recursos Humanos en todo el mundo. Esto introduce la necesidad de que todos los RR.HH. actúen como una sola mente para hacer cumplir las colaboraciones y la toma de decisiones en diferentes verticales y horizontales dentro de una organización, así como para comunicarse con las partes interesadas y priorizar los resultados.

Reduce el espacio de oficina

El entorno ágil distribuido mejora la idea del trabajo remoto, por lo que ya no es necesario ampliar los espacios de oficina para dar cabida a más empleados. Además, las diferentes cuestiones relacionadas con el trabajo, como la electricidad, las computadoras, los estacionamientos, etc., no son una preocupación importante, ya que los empleados tienen la libertad de trabajar desde el entorno que deseen. Esto, en cierto modo, es beneficioso, ya que ayuda a ahorrar una gran cantidad de dinero que de otro modo se gastaría en estos gastos generales. La mejora iterativa con entrega continua al cliente es una práctica central en la mejora ágil del software y una que identifica legítimamente una de las dificultades significativas de un giro de los acontecimientos en el extranjero: la disminución de la perceptibilidad del estado del proyecto. Las reuniones físicas periódicas permiten a los líderes de equipo, gerentes de proyectos, clientes y consumidores realizar un seguimiento del progreso del proyecto mediante la medida de la programación de trabajo que han obtenido.

Desafíos y riesgos

El desarrollo de software distribuido tiene sus propios desafíos inherentes debido a las diferencias espaciales, temporales y socioculturales entre los equipos distribuidos. Combinarlo con los principios y prácticas ágiles, a su vez, aumenta la gravedad de los riesgos involucrados, ya que ambos métodos están en contraste directo entre sí. El desarrollo de software ágil fue diseñado originalmente para ser utilizado por equipos ubicados en el mismo lugar, ya que se basa en la comunicación informal y la colaboración cercana. Sin embargo, el desarrollo distribuido requiere comunicación formal, estándares claros, pautas establecidas y una estructura rígida. [11] Esta sección describe los riesgos y desafíos involucrados en el desarrollo de software ágil distribuido como resultado de los problemas de compatibilidad mencionados anteriormente.

Desafíos

Como resultado de la incompatibilidad a la que uno se enfrenta al combinar principios y prácticas ágiles en un entorno distribuido, algunos de los desafíos que pueden surgir son los siguientes: [12]

Documentación

Las organizaciones offshore prefieren el diseño basado en planes, en el que los requisitos detallados se envían al exterior para su construcción. [13] Esto entra en conflicto con la práctica común de los equipos ágiles, que dan menor prioridad a la documentación. El resultado de esta situación es que es mucho más probable que surjan malentendidos.

Programación en pareja

La programación en parejas, en la que dos programadores trabajan codo con codo para resolver un problema concreto, es una práctica ágil habitual. Se ha demostrado que produce mejores productos en menos tiempo y mantiene a los programadores satisfechos con el proceso. [14] Debido a la distancia entre los equipos, esto es mucho más difícil de lograr.

Diferentes zonas horarias

Dependiendo de la zona horaria de cada equipo distribuido, resulta más complicado organizar reuniones en horarios en los que ambos equipos estén disponibles. Puede darse fácilmente la situación en la que un miembro del equipo esté disponible y el otro no para las reuniones. Esto es especialmente problemático si una tarea inmediata tiene componentes del programa que están estrechamente relacionados, en cuyo caso un equipo no podría continuar sin la retroalimentación del otro.

Enseñanza

En un entorno distribuido, la desventaja de no poder practicar una comunicación cercana se siente más con los desarrolladores inexpertos que necesitan pasar por una fase de capacitación. Capacitar a los empleados que no están ubicados en el mismo lugar es un desafío; piense en las diferencias de antecedentes y culturales que dificultan que estos miembros inexpertos del equipo se pongan al día. Debido a esto, se deben considerar formas alternativas de enseñanza.

Distribución del trabajo

En cuanto a la distribución del trabajo, queremos evitar que la arquitectura refleje la distribución geográfica del equipo distribuyendo el trabajo en función de la ubicación. Es mejor distribuir las tareas relacionadas con una única historia de usuario entre todo el equipo, pensando en términos de historias, no de componentes. La especialización excesiva por ubicación geográfica o componente es una señal de que su equipo está lidiando mal con los desafíos de comunicación que se plantean a los equipos distribuidos. Esta especialización excesiva tiene la consecuencia no deseada de cambiar el producto para que se adapte al desarrollo, no a los requisitos del cliente. [15]

Riesgos

Un estudio realizado en 2013 ha intentado consolidar la literatura sobre la gestión de riesgos en el desarrollo ágil distribuido. [11] Un estudio más exhaustivo ha intentado categorizar los factores de riesgo para proyectos ágiles distribuidos en [16] , esto se hizo utilizando tanto la literatura de investigación como la experiencia del mundo real de trece organizaciones de TI. En aras de la brevedad, se omite la lista completa de 45 factores de riesgo, con las técnicas de gestión correspondientes. En su lugar, se ofrece un breve resumen de las categorías principales y las técnicas de gestión generales.

Ciclo de vida del desarrollo de software

Esta categoría comprende los factores de riesgo relacionados con diversas actividades de desarrollo de software, como la especificación de requisitos por parte del cliente y la planificación, modelado, construcción e implementación de aplicaciones de software. [17] Muchos de los factores de riesgo de esta categoría se derivan de un intercambio de conocimientos ineficaz. Objetivos y requisitos poco claros, diferencias en las prácticas de los procesos estándar o inconsistencias entre los diseños, por nombrar algunos. Muchos de estos riesgos se pueden gestionar asegurándose de que el conocimiento se comparta de manera eficaz. Más específicamente, asegúrese de que el objetivo del proyecto esté perfectamente claro entre los equipos, así como los requisitos. Automatice y estandarice la mayor parte posible del ciclo de desarrollo, de modo que cada equipo trabaje con la misma pila de tecnología e infraestructura. En resumen, asegúrese de que todos estén en la misma página.

Gestión de proyectos

La gestión de proyectos se relaciona con tareas como la planificación, la organización, la dotación de personal, la dirección y el control de proyectos. Esta categoría implica riesgos debido a las interacciones entre las actividades de desarrollo y las actividades de gestión. La adopción del desarrollo ágil distribuido transformará la forma en que se debe gestionar el proyecto. Si esto no se hace con cuidado, los riesgos pueden incluir una menor velocidad inicial, equipos que se reorganizan en cada sprint o una falta de uniformidad en las capacidades de los equipos multisitio.

Conciencia grupal

Los factores de riesgo relacionados con la falta de conciencia de grupo se agrupan en esta categoría. La conciencia de grupo requiere una intensa comunicación, coordinación, colaboración y confianza entre los miembros del grupo. Los equipos ubicados en un mismo lugar logran esta conciencia con mayor facilidad, ya que surge de manera más natural al estar en el mismo lugar físico. Para gestionar los riesgos que implica la falta de conciencia de grupo, los equipos dispersos espacialmente tendrán que utilizar un enfoque más disciplinado en la comunicación utilizando las últimas herramientas tecnológicas. Prácticas como la ubicación conjunta inicialmente, para establecer el rumbo del proyecto, han demostrado ser eficaces para gestionar el riesgo.

Colaboración de partes interesadas externas

Estos factores están relacionados con la colaboración con clientes, proveedores y desarrolladores externos. La gestión de los riesgos se reduce a garantizar que la coordinación y la comunicación con estos actores externos se realicen de manera eficiente y clara.

Configuración de la tecnología

En esta categoría se agrupan los factores de riesgo que surgen debido al uso inadecuado de las herramientas. Por ejemplo, la falta de estructura de comunicación se puede solucionar proporcionando a los equipos los medios para realizar videoconferencias. Además de eso, es importante elegir las herramientas adecuadas para utilizar durante un proyecto. Esto puede variar según los proyectos, los equipos y los casos de uso, por lo que se recomienda un análisis previo de las herramientas que se utilizarán.

Herramientas y mejores prácticas

Comunicación

Uno de los factores más importantes para superar los desafíos que enfrenta el desarrollo de software ágil distribuido es mejorar la comunicación. [12] Esto significa minimizar el tiempo que lleva configurar y desmantelar una sesión de comunicación y favorecer la videoconferencia sobre la conferencia de voz si está disponible.

Se deben fomentar las oportunidades de contacto cara a cara con todo el equipo para ayudar a crear una buena relación. Es beneficioso hacerlo al principio para establecer un plan al que el equipo pueda adherirse durante todo el proyecto. Además, también es beneficioso en las últimas iteraciones antes de la publicación del resultado final. [15]

Diferencias horarias

Una opción para solucionar el problema de la disponibilidad para las reuniones debido a las zonas horarias es designar un representante para el equipo que sirva como intermediario entre los dos equipos y que haya establecido una buena relación entre ambos. Otra opción es utilizar Scrum anidado con informes multinivel y múltiples reuniones diarias de Scrum. [18]

Una solución para tener reuniones Scrum en equipos que se enfrentan a diferencias horarias es hacer una distinción entre reuniones de equipo locales y reuniones Scrum globales. [19] Cada equipo tiene una reunión local al comienzo de su día y una reunión global en otro momento del día. Esto solo es posible si sus días laborales se superponen.

Mantenerse al día con las prácticas ágiles

Debido a la naturaleza distribuida, un equipo puede desviarse de las prácticas ágiles sólidas y establecidas. Por lo tanto, debe haber alguien con el rol de entrenador que mantenga al equipo en el buen camino. También debe encargarse de pensar en alternativas para el entorno de trabajo distribuido que utilicen prácticas ágiles.

Para mantener a todos los miembros del equipo informados sobre el enfoque ágil adoptado, es importante mantener la documentación del proyecto. Esto mejora la colaboración del grupo en el uso de los principios y prácticas ágiles en un entorno de desarrollo de software distribuido [18] [20] [21] . [22] Para ello, se pueden utilizar varias herramientas que ayudan al equipo a mantener la documentación. [20]

Uso de herramientas

Se pueden utilizar diversas herramientas y plataformas para mejorar la comunicación en un entorno distribuido. Estas son incluso más esenciales que en un entorno no distribuido para minimizar la distancia virtual entre los equipos distribuidos.

Comunicación

Existen varias herramientas disponibles para respaldar la comunicación en el desarrollo de software distribuido . Las herramientas asincrónicas como el correo electrónico, las herramientas sincrónicas como el software de conferencias de audio y video y las herramientas híbridas como la mensajería instantánea brindan a los miembros del equipo los medios para tener las reuniones y comunicaciones necesarias. Otro ejemplo son las herramientas que respaldan las redes sociales para crear una experiencia compartida entre los miembros del equipo en diferentes ubicaciones.

Gestión de proyectos

Para guiar el proyecto y asegurarse de que todos los equipos y miembros del equipo tengan una visión clara de qué trabajo debe realizarse, se deben utilizar plataformas de gestión de proyectos como herramientas de gestión de problemas.

Herramientas de desarrollo

Para brindar una experiencia compartida para todos los miembros del equipo, cada uno de ellos debe tener acceso a las mismas herramientas para su desarrollo. [23] Tener las mismas herramientas de gestión de configuración de software vinculadas a las herramientas de gestión de proyectos permite a los desarrolladores trabajar al mismo ritmo y comunicarse sobre el desarrollo de una manera similar.

Gestión del conocimiento

Para que todos los miembros del equipo tengan acceso al mismo conocimiento sobre el producto y el desarrollo, se pueden utilizar herramientas como el software Wiki o bases de conocimiento.

Compatibilidad con el Manifiesto Ágil

Se han analizado los valores y principios del Manifiesto Ágil en su aplicabilidad en un entorno de trabajo distribuido en 12 casos de estudio. [24] Los estudios han seguido a empresas de software que aplicaron el desarrollo de software ágil distribuido en sus proyectos. Entre los 12 casos, 10 empresas locales estaban ubicadas en los EE. UU. y siete empresas extranjeras estaban ubicadas en la India. Los hallazgos se resumen en la siguiente tabla:

Características que promueve el Manifiesto ÁgilCaso 1Caso 2Caso 3Caso 4Caso 5Caso 6Caso 7Caso 8Caso 9Caso 10Caso 11Caso 12
Valores
Individuos e interacciones por encima de procesos y
herramientas
Software funcional con
documentación completa
Colaboración con el cliente en la negociación del contrato
Responder al cambio en lugar de seguir un planincógnitaincógnitaincógnita
Principios
Entrega temprana y continua de software valiosoincógnitaincógnitaincógnita
Bienvenidos a cambiar los requisitos incluso en una etapa avanzada del
desarrollo
Entregar software funcional con frecuencia
Los empresarios y los desarrolladores trabajan juntos
durante todo el proyecto.
Construir proyectos en torno a individuos motivados y
apoyarlos y confiar en ellos.
Conversación cara a cara dentro del
equipo de desarrollo
El software funcional es la medida principal del
progreso
Promover el desarrollo sostenible para mantener
un ritmo constante indefinidamente
Atención continua a la excelencia técnica y
al buen diseño.
La sencillez es esencial
Equipos autoorganizados
El equipo ajusta periódicamente el comportamiento para mejorar
la eficacia.

De esto aprendemos que todos los estudios de caso enfatizaron el primer valor del Manifiesto Ágil, que establece que las personas y las interacciones deben ser valoradas por encima de los procesos y las herramientas. El Manifiesto Ágil prefiere el software funcional por encima de la documentación completa sin negar necesariamente la documentación por completo. Este valor también se refleja en la mayoría de los casos. Solo se han identificado cuatro casos que enfatizan la importancia de la colaboración con el cliente por encima de la negociación del contrato. Como se puede ver claramente en la tabla, el cuarto valor ha sido el menos adoptado de todos por las empresas de software: "en lugar de seguir estrictamente las prácticas de desarrollo ágil como se definen comúnmente, las empresas las ajustan continuamente para que se ajusten a las necesidades cambiantes de sus proyectos". [25] Con respecto a los principios ágiles, no es una sorpresa que la conversación cara a cara con el equipo de desarrollo haya sido valorada por todos los estudios. Esto se simuló electrónicamente entre los equipos onshore y offshore. Sobre si estar abierto a cambiar los requisitos incluso en una etapa avanzada del desarrollo, ninguna de las empresas de software en el estudio proporcionó detalles. Por esto podemos asumir que no se consideró tan importante como algunos de los otros principios.

Referencias

  1. ^ Jiménez, M., Piattini, M., & Vizcaíno, A. (2009). Retos y mejoras en el desarrollo de software distribuido: una revisión sistemática. *Avances en Ingeniería de Software*, *2009*.
  2. ^ Prikladnicki, R., Damian, D., y Audy, JLN (junio de 2008). Patrones de evolución en la práctica del desarrollo de software distribuido: resultados cuantitativos de una revisión sistemática. En la 12.ª Conferencia internacional sobre evaluación y valoración en ingeniería de software (EASE) 12 (pp. 1-10)
  3. ^ Fowler, M., y Highsmith, J. (2001). El manifiesto ágil. Desarrollo de software, 9(8), 28-35.
  4. ^ Ramesh, B., Cao, L., Mohan, K. y Xu, P. (2006). ¿Puede el desarrollo de software distribuido ser ágil?. Communications of the ACM, 49(10), 41-46.
  5. ^ Razavi, AM y Ahmad, R. (septiembre de 2014). Desarrollo ágil en entornos grandes y distribuidos: una revisión sistemática de la literatura sobre aspectos organizativos, gerenciales y culturales. En 2014, 8.ª Conferencia de Ingeniería de Software de Malasia (MySEC) (pp. 216-221). IEEE.
  6. ^ Ghani, I., Lim, A., Hasnain, M., Ghani, I. y Babar, MI (2019). Desafíos en el entorno de desarrollo de software ágil distribuido: una revisión sistemática de la literatura. KSII Transactions on Internet & Information Systems, 13(9).
  7. ^ [6] Shrivastava, SV (2010). Desarrollo de software ágil distribuido: una revisión. *arXiv preprint arXiv:1006.1955*.
  8. ^ Santos, Ronnie de Souza; Ralph, Pablo; Arshad, Arham; Stol, Klaas-Jan (5 de octubre de 2023). "Scrum distribuido: un metaanálisis de casos". Encuestas de Computación ACM . doi : 10.1145/3626519 .
  9. ^ M. Paasivaara, S. Durasiewicz, C. Lassenius, Uso de Scrum en el desarrollo ágil distribuido: un estudio de casos múltiples, Conferencia internacional IEEE sobre ingeniería de software global, págs. 195-204, 2009
  10. ^ Shrivastava, S. V. y Date, H. (2010). Desarrollo de software ágil distribuido: una revisión. Seo-chogu: Revista de ciencias de la computación e ingeniería. 10-17
  11. ^ ab Shrivastava, SV y Rathod, U., 2014. Riesgos en el desarrollo ágil distribuido: una revisión. Procedia - Ciencias sociales y del comportamiento, 133, págs. 417-424.
  12. ^ ab Shrivastava, SV, 2010. Desarrollo de software ágil distribuido: una revisión. Preimpresión arXiv arXiv:1006.1955.
  13. ^ M. Fowler, “Uso de un proceso de software ágil con desarrollo offshore”, http://martinfowler.com/articles/agileOffshore.html, julio de 2006 (consultado el 11 de mayo de 2020)
  14. ^ Williams, L., Kessler, RR, Cunningham, W. y Jeffries, R., 2000. Fortaleciendo la defensa de la programación en pares. IEEE software, 17(4), pp.19-25
  15. ^ ab Ade Miller, “Distributed Agile Development at Microsoft patterns and practices”, Microsoft patterns and practices, http://www.pnpguidance.net/Post/DistributedAgile 16 DevelopmentMicrosoftPatternsPractices, octubre de 2008. (consultado el 11 de mayo de 2020)
  16. ^ Shrivastava, SV, y Rathod, U. (2015). Categorización de factores de riesgo para proyectos ágiles distribuidos. *Tecnología de la información y el software*, *58*, 373-387.
  17. ^ Pressman, RS (2005). *Ingeniería de software: un enfoque práctico*. Palgrave Macmillan.
  18. ^ ab Smits, H. y Pshigoda, G., 2007, agosto. Implementación de Scrum en una organización de desarrollo de software distribuido. En Agile 2007 (AGILE 2007) (pp. 371-375). IEEE.
  19. ^ J. Sutherland, A. Viktorov, J. Blount y N. Puntikov, "Scrum distribuido: gestión ágil de proyectos con equipos de desarrollo subcontratados", 40.ª Conferencia internacional anual de Hawái sobre ciencias de sistemas (HICSS'07) de 2007, Waikoloa, HI, 2007, págs. 274a-274a, doi: 10.1109/HICSS.2007.180.
  20. ^ ab Hossain, E., Babar, MA, Paik, HY y Verner, J., 2009, diciembre. Procesos de identificación y mitigación de riesgos para el uso de Scrum en el desarrollo de software global: un marco conceptual. En 2009, 16.ª Conferencia de Ingeniería de Software de Asia y el Pacífico (pp. 457-464). IEEE.
  21. ^ Holmström, H., Fitzgerald, B., Ågerfalk, PJ y Conchúir, E.Ó., 2006. Las prácticas ágiles reducen la distancia en el desarrollo global de software. Gestión de sistemas de información, 23(3), pp.7-18.
  22. ^ Berczuk, S., 2007, agosto. Back to basics: The role of agile principles in success with a distributed scrum team (De vuelta a lo básico: el papel de los principios ágiles en el éxito de un equipo Scrum distribuido). En Agile 2007 (AGILE 2007) (pp. 382-388). IEEE.
  23. ^ Sutherland, J. (28 de febrero de 2020). Equipos distribuidos: cómo mitigar un riesgo empresarial significativo del coronavirus. Recuperado el 13 de mayo de 2020 de https://www.scruminc.com/distributed-teams-how-to-mitigate-a-significant-business-risk-of-the-coronavirus/
  24. ^ Bose, I., 2008. Lecciones aprendidas de proyectos de software ágil distribuido: un análisis basado en casos. Communications of the Association for Information Systems, 23(1), p.34.
  25. ^ Ramesh, B., Cao, L., Mohan, K. y Xu, P., 2006. ¿Puede el desarrollo de software distribuido ser ágil?. Communications of the ACM, 49(10), pp.41-46.
  • Manifiesto Ágil
  • Glosario ágil
  • Patrones ágiles
Retrieved from "https://en.wikipedia.org/w/index.php?title=Distributed_agile_software_development&oldid=1230970549"