¿Cuál es la mejor manera de dividir el trabajo de desarrollo de una aplicación entre dos o más desarrolladores separados geográficamente?

Abordaría la situación desde el punto de vista del problema: ¿qué problema ve o espera?

  • Estilo de comunicación : oh chico, no voy a entrar en detalles sobre los diferentes estilos de comunicación entre culturas. Se han escrito libros allí. Experimenté más calor que en cualquier otro problema personalmente. Entonces, si la comunicación es su problema, sugiero dividir el trabajo a lo largo de las líneas de falla de “se requiere la menor comunicación entre equipos”.
  • Disciplina : Soy alemán, cuando te digo que el trabajo se realizará el jueves a las 16:00, será allí. Si no, te avisaré temprano y explícitamente. Algunas culturas consideran comunicar malas noticias … malas. Entonces llegar tarde no se comunica. Algunas culturas consideran que medio día fuera del objetivo está absolutamente bien, mientras que enfurecen a los otros miembros del equipo con lo que se percibe como descuido, sabotaje o falta de compromiso.
  • Presión de tiempo : si el tiempo es esencial, siempre coloque su probador en la zona horaria después de los desarrolladores, preferiblemente con su día comenzando cuando los desarrolladores cierran la sesión.
  • Presupuestos : coloque a los desarrolladores de productos de alto costo cerca del cliente, preferiblemente en el mismo país. Asegúrese de que sus diseñadores de UI estén cerca del cliente (como capaces de escuchar sus comentarios), o puedan iterar / adaptarse muy rápidamente a los comentarios.
  • Confusión : use Storyboard y otras ayudas visuales tanto como sea posible. No confíe en las especificaciones de 1200 páginas para realizar el trabajo. Dé la mayor cantidad de información visual posible.
  • Pruebas automáticas : concéntrese en crear casos de prueba y realmente usarlos. Es una molestia en la parte trasera, pero preferible a la diversión de enviar un producto defectuoso.
  • Responsabilidad clara : debe haber una persona responsable de la IU general. Uno. Tiene que haber una persona responsable de la persistencia. Uno.
  • Robustez : Iterar, Iterar, Iterar. Tenga en cuenta que es posible que necesite más personas que describan y verifiquen los productos de trabajo que los codificadores. Descargo de responsabilidad: Iterar no significa volver a trabajar. Significa acercarse al estado final deseado con tantos ciclos de control de calidad como sea posible con el cliente.
  • Arquitectura del sistema : descubrí que es posible mantener la lógica de negocio / UI bastante agrupada en un nivel de página de la aplicación, siempre que haya guías de estilo sólidas y el nivel de persistencia se controle centralmente. Por lo tanto, un equipo puede hacer la página de destino, otro un grupo específico de páginas de funcionalidad, la otra configuración, etc. La persistencia y los estilos de interfaz de usuario son el pegamento.

Las herramientas son herramientas. Todos tienen sus pros y sus contras. Lo más importante es la comunicación y la gestión de conflictos.

Independientemente de la herramienta que utilice, es importante que TODOS la utilicen y lo hagan con fidelidad. De esa manera, si la persona B está utilizando un código común y lo extrae de la biblioteca, ese desarrollador está DE SEGURO que es la última copia de trabajo. Los desarrolladores necesitan hablar entre ellos si algo que están haciendo puede afectar el trabajo de otro. No puedo contar la cantidad de veces que me han dicho que mis cosas no funcionan solo para descubrir que algo que estaba usando cambió sin que me informaran.

Las reuniones por razones de coherencia son importantes. Por supuesto, * I * siempre tengo la mejor idea para lidiar con algo (risas), pero si uno de los desarrolladores está usando la herramienta XXX java para un calendario, probablemente no debería usar YYY. Agrega gastos generales y confunde a aquellos que pueden tener que venir más tarde para trabajar en ello.

Asegúrese de que el trabajo se divida tanto como sea posible para que los conflictos de recursos se mantengan en un mínimo absoluto PERO asegúrese de dar tiempo para asegurarse de que las piezas individuales funcionen bien juntas, y arregle esos lugares donde no lo hacen.

Personalmente en mi equipo, aunque estamos ubicados, utilizamos bitbucket, tienen muchas más funciones, como privacidad, enlaces a / para otros servicios diferentes, incluso para el nivel gratuito. También proporcionan JIRA, que es una metodología ágil, aunque discutible, pero defendiendo cómo está estructurado y administrado su proyecto, aún puede aprovechar lo mejor de ágil incluso para equipos dispersos.

Puede leer aquí para conocer la opinión de otras personas (¿Agile puede trabajar con equipos dispersos geográficamente?)

Encontré esta situación. Resultó que no era un gran problema. Teníamos tres personas y cada una manejó una parte del proyecto (servidor Android iOS) para que no hubiera demasiados conflictos. Los códigos se reposicionaron en Bitbucket, que también proporcionaba seguimiento de problemas y registros.

Normalmente en el trabajo, a menudo tenemos colegas que “trabajan en casa”. Gracias a Internet, esa es una situación similar para pequeños equipos separados geográficamente.