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

28

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?

Carlos Gavidia-Calderón
fuente
55
@mike: el software de la nave espacial es un poco diferente a la mayoría del software. Tiene que funcionar perfectamente todo el tiempo, o puede producirse la pérdida de vidas y activos extremadamente caros. Ver fastcompany.com/28121/they-write-right-stuff
Robert Harvey
9
Supongo que el equipo offshore es más barato, ¿es también el doble del tamaño del equipo de diseño? ¿Tiene algunas ventajas reales sobre el equipo interno? por ejemplo, ¿hablan el lenguaje natural de los usuarios finales mientras que usted no? ¿Tienen algún tipo de talento que no tienes en casa? Si no, veo que su compañía tiene un caso grave de intoxicación por PHB .
ZJR
1
@mike: Creo que sería más exacto decir que en la mayoría del software se considera aceptable un pequeño número de errores, porque el software libre de errores es una asíntota y eliminar esos errores restantes es muy costoso.
Robert Harvey
9
Le sugiero que comience a buscar otro trabajo de inmediato. Los programadores no son engranajes intercambiables, que es el supuesto subyacente de este tipo de arreglo. Separar el diseño del desarrollo de esta manera, onshore u offshore, garantiza una desconexión entre el cliente y los desarrolladores que hace que la falla sea muy probable.
Steven A. Lowe

Respuestas:

36

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.

Tulains Córdova
fuente
2
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.
Robert Harvey
32
... Lo cual es parte de por qué gran parte del desarrollo está regresando a tierra en los Estados Unidos; Este enfoque de diseñar en tierra, desarrollar en alta mar, y luego depurar en tierra requiere que tenga los mismos recursos en tierra que usaría para desarrollar todo el caldo hasta las nueces en primer lugar. En cualquier otro proceso de producción, donde los materiales directos y la mano de obra para hacer la cosa son altos, el enfoque offshore tiene sentido. Cuando el diseño de lo que está haciendo no es solo la mayor parte de su costo, sino que también podría ser el producto final, el desarrollo offshore se vuelve más obviamente redundante.
KeithS
@KeithS Gran comentario. Estoy de acuerdo% 110 contigo.
Tulains Córdova
2
Obligarlos a usar las clases e interfaces que se les ocurrió sin haber escrito ningún código usted mismo es una receta para el desastre.
Mike Weller
2
@Euphoric Hay un largo tramo entre escribir abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()y realmente implementarlo.
Tulains Córdova
26

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.

Robert Harvey
fuente
¿Puedes detallar un poco más sobre "muy específico"? ¿Tenía que llegar al nivel de pseudocódigo del método de inclusión?
Carlos Gavidia-Calderón
8
El seudocódigo mejorará sus posibilidades de obtener el código del equipo offshore exactamente como lo desea. Como otros han señalado, el proceso de hacer que la deslocalización funcione con éxito puede ser más costoso que simplemente mantener todo el trabajo en la empresa. Pero esa no es tu decisión.
Robert Harvey
2
No debería ser eso It's very expensive when it goes wrong. :-)
LarsTech 01 de
@LarsTech: Es por eso que el gasto adicional de hacerlo bien es justificable.
Robert Harvey
Al pseudocódigo le gusta hacer el mismo esfuerzo que escribir código real, + gastos generales de comunicación en alta mar
Web Devie
16

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.

Jon Raynor
fuente
¿Utiliza algún proceso ágil particular? ¿A la medida, tal vez?
Carlos Gavidia-Calderón
2
No era puramente ágil, más como iteraciones planificadas. Todo se planeó por adelantado y luego se dividió en iteraciones de 2 semanas. Utilizamos procesos ágiles en cada interacción. Se utilizan gráficos de velocidad y de quemado, soporte diario estándar seguido de una o dos llamadas telefónicas en alta mar. Definitivamente pasamos mucho tiempo al teléfono en alta mar, pero nuestro día ideal de desarrollo fue de 6 horas para dar cuenta del tiempo de comunicación.
Jon Raynor
2
Nota personal: elimine los vehículos recreativos de futuras iteraciones de software.
Robert Harvey
¿Crees que tu éxito tuvo más que ver con elegir el equipo offshore adecuado o simplemente confiar en ellos para que hagan lo correcto sin microgestión? ¿Crees que tu técnica de "iteraciones planificadas" fue crítica para tu éxito?
Robert Harvey
1
@Jess: no, el equipo solo es responsable de entregar las historias y características aprobadas (funcionalidad). La funcionalidad futura no se entrega, aunque el diseño del software generalmente permite algún tipo de flexibilidad, pero solo entregamos lo que se solicitó.
Jon Raynor
2

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.

alistairw
fuente
1

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é.

imel96
fuente