Diseño en un equipo, codificación en otro

Participaré en un proyecto en el que todo el diseño del software lo realiza un equipo local y estos diseños se envían a un equipo offshore para su codificación.

Esta es la primera vez que enfrento un proyecto con estas características y para mí es un poco extraño: los gerentes esperan que hagamos documentos de diseño muy detallados para que no haya margen de error para el equipo offshore; desde mi punto de vista, nos están haciendo codificar en papel mientras que podemos hacerlo en un IDE.

Entonces, mi pregunta es si este enfoque es bueno, ¿o está bien? ¿Cuáles son las principales consideraciones que debe tener nuestro proceso de software para tener éxito en nuestro proyecto?

Mi opinión:

Si todo lo que le dará a la gente offshore son documentos y diagramas, tendrá una gran falta de comunicación y decepción .

Mi recomendación

• No les proporcione tantos documentos, sino más bien interfaces y clases abstractas para encadenarlos en sus objetivos de diseño .

• Requerirles que usen un estándar de nombres conocido.

• Requerirles que usen pruebas unitarias.

• Envíe a uno de sus diseñadores / arquitectos en alta mar a sus instalaciones para supervisar el proceso, aún será más barato que la codificación interna, pero obtendrá mejores resultados.

Se llama Big Design Up Front, también conocido como Waterfall. No es ampliamente considerado como una metodología altamente exitosa. Pero lo he visto funcionar, y cuando funciona, funciona muy bien. Es muy costoso hacer lo correcto.

También es lo que sus empleadores le han pedido que haga.

Los equipos offshore no funcionan como lo hacen los equipos onshore. Tienes que ser muy, muy específico sobre exactamente lo que quieres, de lo contrario no obtendrás lo que quieres.

El último proyecto que hice fue el diseñador de software. Todo el desarrollo fue en alta mar. Tuvimos éxito Entonces este proceso puede funcionar.

Produje mucha documentación, pero de ninguna manera era completa y de ninguna manera instrucciones detalladas o detalladas para nombres de clase, nombres de funciones, etc. Por ejemplo, produje diagramas de secuencia, casos de uso, flujos de trabajo, sistema e integración diragramas, así como una documentación de diseño más detallada según sea necesario.

Realmente depende de cuánto confíes en el desarrollo offshore. Confío en que mi equipo offshore sea un desarrollador competente. Dicho esto, proporcioné la dirección general, pero les di margen para implementar lo que el equipo offshore encontró agradablemente satisfactorio. En el pasado estaban más microgestionados. En ciertas situaciones, los guiaría utilizando los patrones de diseño según sea necesario. También realicé regularmente revisiones y análisis de código sobre el código que escribieron y recomendaría refactorizar o limpiar los esfuerzos. Además, dado que parte del equipo tuvo accidentes con vehículos recreativos, terminé codificando algunas de las historias durante la implementación, ya que terminamos teniendo pocos recursos.

Además, creo que este proceso realmente solo tiene éxito gracias a la solidez de su (s) cliente (s) técnico (s) en el proyecto y la comunicación entre empresas, diseñadores, clientes potenciales y desarrolladores. Pasamos mucho tiempo revisando cada característica e historia y nos aseguramos de que los clientes potenciales / recursos offshore estuvieran bien informados sobre cuáles eran los requisitos. Si no están haciendo preguntas durante la revisión de la función / historia, espere algunos problemas. Además, el trabajo no se consideró completo hasta que hubo un cierre comercial. Eso hizo que todos fueran responsables, ya que todo se rastreaba en una herramienta que gestionaba el desarrollo ágil.

Como una de las otras respuestas ya ha aludido, el proceso de desarrollo incluyó estándares de nomenclatura (reglas de intercambio integradas), cobertura de casos de prueba (usaba TDD, burlas, etc.), por lo que si hay un buen proceso y procedimiento de codificación, aumentará Sus posibilidades de un proyecto exitoso.

El principal costo del desarrollo offshore es la comunicación. La documentación es una forma de comunicación, sin embargo, los documentos no pueden cubrir todos los detalles y posibles cambios por lo general.

No estoy seguro de cuán grande es su proyecto. Supongo que es grande, de lo contrario no es valioso utilizar el equipo de desarrollo offshore. Por lo tanto, mi experiencia es

1. Defina el código esqueleto, la interfaz pública, la interfaz de servicio, etc., y revisen juntos
2. Definir las pruebas de aceptación con el otro lado.
3. Divida el documento grande en historias pequeñas, trabaje en base a las historias pequeñas. El documento grande es solo una imagen general de todo el sistema
4. Configure los puntos de control de las historias, una o dos semanas.

1 y 2 en realidad se trata del desarrollo, para asegurarse de que la otra parte entienda bien el requisito y que ambas partes estén usando el mismo patrón. 3 y 4 es parte de la metodología de desarrollo ágil, pero para el desarrollo offshore, es difícil utilizar el proceso ágil completo.

Creo que hasta cierto punto todos trabajamos así. Alguien en algún lugar diseña algo y codificamos algo que es parte del sistema o que funciona con él. Algunos ejemplos son la creación de aplicaciones basadas en un marco, como las aplicaciones que no son juegos en dispositivos móviles. El equipo de diseño de las personas que construyeron el marco tomó muchas decisiones sobre la interfaz de usuario. Controlaron todo, desde aprender a escribir una aplicación hasta vender su aplicación. Si desea ver por qué este modelo fue exitoso, solo mire la cantidad de documentación y herramientas proporcionadas por algunos proveedores.

Otro ejemplo son las aplicaciones web con muchas de ellas tratando de implementar el estilo REST. Este realmente no dice cómo implementar algo, aunque cuando hay especificaciones sobre cómo usar HTTP. De todos modos, hay especificaciones y principios rectores a seguir. Si ve la cantidad de discusiones sobre la implementación de REST en stackexchange o en el lugar de trabajo, es como si hubiera un arquitecto diciéndole a la gente que implemente algo de ciertas maneras. Todavía es un modelo exitoso, creo, con tanta gente siguiendo el estilo.

A partir de esos dos ejemplos, puede ver cómo se propagan los diseños, algunos como especificaciones de papel, otros vienen con libros, herramientas y ejemplos. Puede ver cómo las personas preguntan (en volumen), tratando de entender correctamente con diferentes grados dependiendo de qué estándares / diseños están tratando de seguir. Solo ve a stackoverflow y mira;)

Si me das tu especificación, te lo preguntaré. Si me das una prueba unitaria, codificaré y probaré.