Conception dans une équipe, codage dans une autre


28

Je serai impliqué dans un projet où toute la conception logicielle est réalisée par une équipe locale et ces conceptions sont envoyées à une équipe offshore pour codage.

C'est la première fois que je fais face à un projet avec ces caractéristiques et pour moi, cela semble un peu étrange: les gestionnaires s'attendent à ce que nous fassions des documents de conception très détaillés, donc il n'y a pas de place pour l'erreur pour l'équipe offshore; de mon point de vue, ils nous font coder sur papier alors que nous pouvons le faire dans un IDE.

Donc, ma question est: cette approche est-elle bonne ou éprouvée? Quelles sont les principales considérations que notre processus logiciel doit avoir pour réussir dans notre projet?



5
@mike: Le logiciel Spacecraft est un peu différent de la plupart des logiciels. Il doit fonctionner parfaitement tout le temps, sinon des pertes de vie et des actifs extrêmement coûteux peuvent survenir. Voir fastcompany.com/28121/they-write-right-stuff
Robert Harvey

9
Je suppose que l'équipe offshore est moins chère, est-ce aussi deux fois la taille de l'équipe de conception? At-il de réels avantages par rapport à l'équipe interne? Par exemple, parlent-ils le langage naturel des utilisateurs finaux alors que vous ne le faites pas? Ont-ils une sorte de talent que vous n'avez pas en interne? Sinon, je vois que votre entreprise a un mauvais cas d' empoisonnement au PHB .
ZJR

1
@mike: Je pense qu'il serait plus exact de dire que dans la plupart des logiciels, un petit nombre de bogues est considéré comme acceptable, car un logiciel sans bogue est une asymptote et la suppression des bogues restants est très coûteuse.
Robert Harvey

9
Je vous suggère de commencer immédiatement à chercher un autre emploi. Les programmeurs ne sont pas des rouages ​​interchangeables, ce qui est l'hypothèse sous-jacente de ce type d'arrangement. La séparation de la conception et du développement de cette manière - onshore ou offshore - garantit une déconnexion entre le client et les développeurs, ce qui rend la défaillance très probable.
Steven A. Lowe

Réponses:


36

Mon avis:

Si tout ce que vous donnerez aux personnes offshore est des documents et des diagrammes, vous aurez beaucoup de malentendus et de déceptions .

Ma recommandation

  • Ne leur donnez pas autant de documents, mais plutôt des interfaces et des classes abstraites afin de les inclure dans vos objectifs de conception .

  • Les obliger à utiliser une norme de dénomination connue.

  • Les obliger à utiliser des tests unitaires.

  • Envoyez un de vos concepteurs / architectes à l'étranger dans leurs locaux pour superviser le processus, ce sera toujours moins cher que de coder en interne, mais vous obtiendrez de meilleurs résultats.


2
Les équipes offshore ne fonctionnent pas comme les équipes onshore. Vous devez être très, très précis sur exactement ce que vous voulez, sinon vous n'obtiendrez pas ce que vous voulez.
Robert Harvey

32
... Ce qui explique en partie pourquoi de nombreux développements reviennent aux États-Unis; cette approche de conception onshore, de développement offshore, puis de débogage onshore nécessite à peu près que vous ayez les mêmes ressources onshore que vous utiliseriez pour développer la soupe entière aux noix en premier lieu. Dans tout autre processus de production, où les matériaux directs et le travail de fabrication de la chose sont élevés, l'approche offshore a du sens. Lorsque la conception de ce que vous faites représente non seulement la majorité de vos coûts, mais pourrait tout aussi bien être le produit final, le développement offshore devient plus évidemment redondant.
KeithS

@KeithS Excellent commentaire. Je suis d'accord avec% 110.
Tulains Córdova

2
Les forcer à utiliser les classes et les interfaces que vous avez imaginées sans avoir écrit de code vous-même est une recette pour un désastre.
Mike Weller

2
@Euphoric Il y a une longue période entre l'écriture abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()et sa mise en œuvre effective.
Tulains Córdova

26

Cela s'appelle Big Design Up Front, alias Waterfall. Ce n'est pas largement considéré comme une méthodologie très réussie. Mais je l'ai vu fonctionner, et quand cela fonctionne, cela fonctionne très bien. C'est très cher de bien faire.

C'est aussi ce que vos employeurs vous ont demandé de faire.

Les équipes offshore ne fonctionnent pas comme les équipes onshore. Vous devez être très, très précis sur exactement ce que vous voulez, sinon vous n'obtiendrez pas ce que vous voulez.


Pouvez-vous détailler un peu plus "très spécifique"? Dois-je arriver au niveau du pseudocode de la méthode include?
Carlos Gavidia-Calderon

8
Le pseudocode améliorera vos chances d'obtenir le code de l'équipe offshore exactement comme vous le souhaitez. Comme d'autres l'ont souligné, le processus de réussite de la délocalisation peut être plus coûteux que de simplement garder tout le travail en interne. Mais ce n'est pas votre décision à prendre.
Robert Harvey

2
Cela ne devrait-il pas être It's very expensive when it goes wrong. :-)
LarsTech

@LarsTech: C'est pourquoi les dépenses supplémentaires pour le faire correctement sont justifiables.
Robert Harvey

Le pseudocode aime faire le même effort que d'écrire du vrai code, + les frais de communication offshore
Web Devie

16

Le dernier projet, j'étais concepteur de logiciels. Tout le développement était offshore. Nous avons réussi. Donc, ce processus peut fonctionner.

J'ai produit beaucoup de documentation, mais ce n'était en aucun cas des instructions détaillées et pas à pas ou détaillées jusqu'aux noms de classe, noms de fonctions, etc. Par exemple, j'ai produit des diagrammes de séquence, des cas d'utilisation, des flux de travail, du système et de l'intégration. diragrams, ainsi qu'une documentation de conception plus détaillée si nécessaire.

Cela dépend vraiment de la confiance que vous accordez au développement offshore. Je fais confiance à mon équipe offshore pour être des développeurs compétents. Cela dit, j'ai fourni une orientation globale mais leur ai donné une marge de manœuvre pour la mise en œuvre, ce que l'équipe offshore a trouvé agréablement satisfaisant. Dans le passé, ils étaient plus micro-gérés. Dans certaines situations, je les guiderais en utilisant les modèles de conception selon les besoins. J'ai également effectué régulièrement des révisions et des analyses de code sur le code qu'ils ont écrit et je conseillerais des efforts de refactoring ou de nettoyage. De plus, comme une partie de l'équipe a eu des accidents avec des véhicules récréatifs, j'ai fini par coder certaines histoires pendant la mise en œuvre, car nous avons fini par manquer de ressources.

De plus, je pense que ce processus ne réussit vraiment que grâce à la force de votre (vos) responsable (s) technique (s) du projet et à la communication entre les entreprises, le concepteur, les prospects et les développeurs. Nous avons passé beaucoup de temps à passer en revue chaque fonctionnalité et chaque histoire et nous nous sommes assurés que les prospects / ressources offshore étaient bien informés des exigences. S'ils ne posent pas de questions lors de l'examen de la fonctionnalité / histoire, attendez-vous à des problèmes. De plus, le travail n'était pas considéré comme terminé jusqu'à ce qu'il y ait approbation de l'entreprise. Cela a donc rendu tout le monde responsable puisque tout était suivi dans un outil qui gérait le développement agile.

Comme l'une des autres réponses a déjà fait allusion, le processus de développement comprenait des normes de dénomination (règles de resharper intégrées), la couverture des cas de test (il utilisait TDD, Mocking, etc.) donc s'il y a un bon processus de codage et une bonne procédure en place, il augmentera vos chances de réussir votre projet.


Utilisez-vous un processus agile particulier? Peut-être un sur mesure?
Carlos Gavidia-Calderon

2
Ce n'était pas purement agile, plus comme des itérations planifiées. Tout a été planifié à l'avance, puis divisé en itérations de 2 semaines. Nous avons utilisé des processus agiles à travers chaque interaction. Graphiques de vitesse et de brûlage utilisés, stand up quotidien standard suivi d'une heure ou deux appels téléphoniques au large. Passez beaucoup de temps au téléphone vers l'étranger, mais notre journée de développement idéale était de 6 heures pour tenir compte du temps de communication.
Jon Raynor

2
Note à soi-même: éliminer les véhicules récréatifs des futures itérations logicielles.
Robert Harvey

Pensez-vous que votre succès a plus à voir avec le choix de la bonne équipe offshore, ou simplement leur faire confiance pour faire la bonne chose sans microgestion? Pensez-vous que votre technique des "itérations planifiées" a été essentielle à votre succès?
Robert Harvey

1
@Jess - Non, l'équipe est uniquement responsable de la livraison des histoires et des fonctionnalités approuvées (fonctionnalité). Les fonctionnalités futures ne sont pas fournies, bien que la conception du logiciel permette généralement une certaine flexibilité, mais nous ne livrons que ce qui était demandé.
Jon Raynor

2

Le coût majeur du développement offshore est la communication. La documentation est un moyen de communication, cependant, les documents ne sont généralement pas en mesure de couvrir tous les détails et les changements potentiels.

Je ne sais pas quelle est la taille de votre projet. Je suppose que c'est grand sinon il n'est pas utile d'utiliser l'équipe de développement offshore. Ainsi, mon expérience est

  1. Définissez le code squelette, l'interface publique, l'interface de service, etc., et passez en revue ensemble
  2. Définir les tests d'acceptation avec l'autre côté
  3. Divisez le gros document en petites histoires, travaillez sur la base des petites histoires. Le gros document n'est qu'une vue d'ensemble de l'ensemble du système
  4. Mettre en place les points de contrôle des histoires, une semaine ou deux semaines

1 et 2 concerne le développement, pour vous assurer que l'autre partie comprend bien l'exigence et que les deux parties utilisent le même modèle. 3 et 4 font partie de la méthodologie de développement agile, mais pour le développement offshore, il est difficile d'utiliser le processus agile complet.


1

Je pense que dans une certaine mesure, nous travaillons tous comme ça. Quelqu'un quelque part conçoit quelque chose et nous codons quelque chose qui fait partie ou travaille avec le système. Des exemples sont la création d'applications basées sur un cadre, comme des applications non liées à des jeux sur des appareils mobiles. Beaucoup de décisions concernant l'interface utilisateur ont été prises par l'équipe de conception des personnes qui ont construit le framework. Ils contrôlaient tout, de l'apprentissage de l'écriture d'une application à la vente de votre application. Si vous voulez savoir pourquoi ce modèle a réussi, regardez simplement la quantité de documentation et d'outils fournis par certains fournisseurs.

Un autre exemple est celui des applications Web dont beaucoup essaient d'implémenter le style REST. Celui-ci ne dit pas vraiment comment implémenter quelque chose, bien qu'il existe des spécifications sur la façon d'utiliser HTTP. Quoi qu'il en soit, il y a des spécifications et des principes directeurs à suivre. Si vous voyez la quantité de discussions sur l'implémentation REST sur stackexchange ou en milieu de travail, c'est comme s'il y avait un architecte disant aux gens d'implémenter quelque chose de certaines manières. C'est toujours un modèle réussi, je pense, avec tant de gens qui suivent le style.

À partir de ces deux exemples, vous pouvez voir comment les dessins se propagent, certains sous forme de spécifications papier, d'autres avec des livres, des outils et des exemples. Vous pouvez voir comment les gens demandent (en volume), en essayant de bien comprendre à différents degrés selon les normes / conceptions qu'ils essaient de suivre. Allez simplement sur stackoverflow et regardez;)

Si vous me donnez vos spécifications, je vous demanderai. Si vous me donnez un test unitaire, je vais coder et tester.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.