Conception dans une équipe, codage dans une autre

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?

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.

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.

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.

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.

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.