Comment faire face à différents styles de développement (top-down vs bottom-up) dans une équipe?
Supposons que vous venez de commencer à travailler dans une très petite équipe sur un projet {actuellement relativement petit, mais avec un peu de chance plus tard}. Notez qu'il s'agit d'un projet réel destiné à être utilisé par d'autres développeurs dans le monde réel, et non un projet académique destiné à être abandonné à la fin d'un semestre.
Cependant, le code n'est pas encore rendu public, donc aucune décision n'est encore figée.
Les méthodologies
L'un d'entre vous aime commencer à coder et à assembler les pièces au fur et à mesure avant d'avoir nécessairement une idée claire de la manière dont tous les composants interagiront (conception ascendante). Un autre d'entre vous aime d'abord faire la conception entière et clouer les détails de tous les composants et de la communication avant de coder une solution.
Supposons que vous travaillez sur un système nouvea plutôt que d'imiter les systèmes existants, et donc ce n'est pas toujours évident à quoi devrait ressembler la bonne conception finale. Ainsi, dans votre équipe, les différents membres de l'équipe ont parfois des idées différentes sur les exigences qui sont même nécessaires pour le produit final, et encore moins sur la façon de le concevoir.
Lorsque le développeur de bas en haut écrit du code, le développeur de haut en bas le rejette en raison de futurs problèmes potentiels envisagés dans la conception, malgré le fait que le code puisse résoudre le problème actuel, estimant qu'il est plus important d'obtenir une conception correcte avant d'essayer de coder la solution au problème.
Lorsque le développeur de haut en bas essaie d'élaborer la conception complète et les problèmes envisagés avant de commencer à écrire le code, le développeur de bas en haut le rejette parce que le développeur de bas en haut ne pense pas que certains des problèmes se poseront réellement dans la pratique , et pense que la conception devra peut-être être modifiée à l'avenir lorsque les exigences et les contraintes deviendront plus claires.
Le problème
Le problème qui en a résulté est que le développeur ascendant finit par perdre du temps parce que le développeur descendant décide fréquemment que la solution que le développeur ascendant a écrite doit être abandonnée en raison d'un défaut de conception, ce qui entraîne la nécessité de re -écrire le code.
Le développeur de haut en bas finit par perdre du temps car au lieu de paralléliser le travail, le développeur de haut en bas s'assoit désormais fréquemment pour élaborer la conception correcte avec le développeur de bas en haut, sérialisant les deux au point où il pourrait même être plus rapide pour 1 personne pour faire le travail que 2.
Les deux développeurs veulent continuer à travailler ensemble, mais il ne semble pas que la combinaison les aide réellement dans la pratique.
Les buts
Les objectifs communs sont évidemment de maximiser l'efficacité du codage (c'est-à-dire de minimiser la perte de temps) et d'écrire des logiciels utiles.
La question
En termes simples, comment résolvez-vous ce problème et comment faire face à cette situation?
La seule solution efficace à laquelle je peux penser qui ne perd pas de temps est de laisser chaque développeur suivre son propre style pour la conception. Mais cela est plus difficile qu'il n'y paraît lorsque vous passez en revue le code et avez réellement besoin d'approuver les changements des uns et des autres, et lorsque vous essayez de concevoir un cadre cohérent pour les autres.
Y a-t-il une meilleure façon?
De toute évidence, ils ont tous les deux tort.
Le gars de bas en haut pirate le code et ne produira jamais quelque chose qui fait ce qu'il est censé faire - ce sera un désabonnement continu à mesure que les exigences inconnues seront déterminées.
Le gars du haut vers le bas peut consacrer autant de temps à la vision architecturale et ne rien faire de productif aussi.
Cependant, un terrain d'entente est idéal - si vous connaissez les objectifs vers lesquels vous travaillez (que vous obtenez à partir d'un vaste travail de conception) et continuez à le coder (sans aucune planification détaillée), alors vous récoltez les fruits d'un système qui est à la fois organisé et développé efficacement.
Cela s'appelle Agile d'ailleurs (pas la version BS d'agile que certaines personnes pratiquent lorsque les procédures sont plus importantes que les logiciels de travail), mais véritable agile qui continue de travailler vers un objectif final communément décrit et compris.
Pour résoudre le problème ici, essayez une approche Agile (Kanban est probablement la meilleure) qui forcera à la fois le gars de haut en bas à faire un peu de travail et forcera le gars de bas en haut à planifier ce qu'il essaie de réaliser.
Les deux développeurs doivent maintenir une mutuelle respect l'un pour l'autre.
La personne de haut en bas doit respecter le fait que la personne de bas en haut peut avoir trouvé quelque chose qui fonctionne réellement. Comme l'un de mes professeurs "quant" me l'a dit, "Un modèle de travail vaut 1000 suppositions." Si tel est le cas, la personne de haut en bas devrait envisager de refaire sa "conception" pour s'adapter au travail de la personne de bas en haut.
La personne ascendante doit également respecter le "cadre" de la personne descendante et se rendre compte que cela peut être bon pour éviter le gaspillage d'efforts, résoudre le mauvais problème, sortir du sujet, etc. Le codeur ascendant doit au moins garder à l'esprit ce la personne du haut vers le bas essaie de faire, et essaie de répondre au moins aux préoccupations du descendant, telles qu'exprimées dans le cadre. Cela serait vrai même si le bas-haut n'était pas d'accord avec certaines parties du cadre lui-même.
Vous pouvez minimiser la perte de temps de chaque développeur si vous divisez des tâches volumineuses en plusieurs tâches plus petites et plus ciblées. Demandez-leur de travailler en étroite collaboration afin qu'aucun des deux ne devienne trop loin l'un de l'autre. Les sprints courts et les petits livrables vont très loin. Il est plus facile de corriger une petite erreur qu'une grosse.
Cela peut sembler contre-intuitif à votre objectif, mais la programmation par paires fonctionne. Il y a des choses que vous n'attraperez pas tout de suite tout de suite, parfois pendant des heures, voire des jours. Si travailler directement sur des tâches ensemble est hors de question, essayez de réviser le code/standups plus fréquemment tout au long de la semaine.
Tenez tout le monde informé!
Si vous voyez des développeurs jeter du code parce qu'ils n'étaient pas dans leur propre monde, vous devez attraper et réconcilier les conflits aussi rapidement et efficacement que possible. Votre patron l'appréciera et l'équipe appréciera de ne pas avoir à perdre une semaine de travail parce qu'il ne savait pas ce que faisait l'autre gars.
Vous devriez également les voir travailler ensemble comme une bénédiction. Le fait qu'ils travaillent ensemble et corrigent leurs erreurs au fur et à mesure est un bon signe. Je l'ai fait à mi-chemin de votre post en pensant "l'homme ces deux se détestent probablement ..." et à ma grande surprise, vous avez dit qu'ils voulaient continuer à travailler ensemble.
Je pense que cette citation est appropriée compte tenu de votre scénario.
"Si deux personnes sont d'accord sur tout, l'une d'elles n'est pas nécessaire." ~ Un vieil homme
Cela ressemble en fait à un scénario idéal pour moi. Là encore, je suis ces deux développeurs en même temps. J'aime rédiger la "vue d'ensemble" sous forme de notes qui finissent par se retrouver dans un outil de suivi des problèmes. Ensuite, je commence à penser aux détails de la mise en œuvre de bas en haut. La vue d'ensemble évolue à mesure que je comprends mieux comment les pièces s'emboîtent, et les pièces évoluent à mesure que les exigences changent et que j'obtiens de nouvelles idées.
C'est peut-être un bon modèle pour plusieurs cerveaux.
À mon avis, ce sont des profils complémentaires et peuvent finir par très bien se porter. Le codage et la conception sont des phases nécessaires de la programmation et vous ne voulez pas vous retrouver dans une équipe où personne ne veut faire X, tout ce dont vous avez besoin est un peu de organisation (voir je peux avoir un caractère gras Parole aussi!)
Cela peut être fait par la supervision, comme d'autres l'ont souligné, mais encore mieux par accord mutuel sur un calendrier d'itération du moment de la conception et du moment du codage, et en évitant en général de coder ce qui est actuellement en cours de conception.
Point bonus, dès qu'un projet est divisé en modules plus petits, le programmeur de haut en bas peut concevoir des choses sur lesquelles le programmeur de bas en haut ne travaille pas actuellement, ce qui en fait une phase où les deux font ce qu'ils veulent. Cela implique cependant une capacité des deux à faire les ajustements nécessaires lorsque vient le temps de tout assembler.
Une note: tu as dit
Supposons que vous travaillez sur un nouveau système plutôt que d'imiter les systèmes existants, et donc ce n'est pas toujours évident à quoi devrait ressembler la bonne conception finale.
Cela fait partie du problème: à moins que vous ne travailliez sur un petit projet pour un problème déjà résolu, il n'y a pas de bonne conception finale . Il existe de nombreux modèles possibles. Gardez à l'esprit qu'à moins que vous ne le fassiez pour stimuler votre ego en raison de la beauté de votre code, l'objectif final est une application qui fonctionne. C'est ça. Comment y arriver n'est pas pertinent, et la meilleure façon de les laisser aller vite est de les faire travailler ensemble, de manière complémentaire.
Comme d'autres l'ont dit, les deux points de vue peuvent être corrects à certains égards. Il est loin d'être inhabituel pour deux développeurs de ne pas être d'accord sur les pratiques, en particulier pour quelque chose d'aussi subjectif que les processus de conception et de développement. Vous avez ici deux personnes qui sont passionnées par ce qu'elles font et qui savent comment le faire: adoptez cela!
Il y a ici un grand potentiel pour permettre aux deux personnes de travailler à leur manière, tout en faisant correspondre les éléments pour obtenir une application qui fonctionne.
J'aimerais que les deux s'assoient et discutent, les encourageant à le voir du point de vue de l'autre.
Après cette discussion, vous pouvez commencer à parler de planification: cela devrait être fait en équipe, étant entendu que ni l'un ni l'autre ne doit "concéder" à l'autre, mais des compromis devront être faits. Il existe de nombreuses façons de planifier l'architecture d'une base de code qui permet de l'étendre assez facilement plus tard, sans introduire une tonne de code supplémentaire.
Une fois que vous pouvez les amener à une sorte de trêve, laissez-les se déchaîner! Laissez le "gars du haut vers le bas" piloter la planification de l'architecture de haut niveau, des interfaces, des hiérarchies, etc. Demandez-leur d'accepter formellement d'accepter les méthodes de l'autre comme bonnes pour le projet global: La planification pour permettre des changements futurs faciles est bonne, mais elle n'a pas besoin d'être codée de cette façon tout de suite. Créez des interfaces et stub out méthodes pour obtenir la structure du code et accepter qu'une bonne partie du code pour le futur ne sera pas réellement écrite tant que cela ne sera pas nécessaire.
Demandez-leur de revoir fréquemment la conception et le code. Parcourez des cycles où vous plongez profondément dans certains segments de l'architecture, planifiez plus en détail et écrivez ces parties.
C'est probablement le point le plus important: Facilitez les points du cycle où ils ne parlent que du processus, plutôt que du travail en cours. Réfléchissez à la dynamique en cours de construction: vous devez vous poser quatre questions. Qu'est-ce qui s'est bien passé que nous devrions continuer à faire? Qu'est-ce qui s'est mal passé que nous devrions arrêter de faire? Que nous manque-t-il? Que pouvons-nous faire au sujet de ce qui nous manque?
Cela demandera du travail: vous devez les amener à accepter de travailler ensemble à leur manière. Il n'est pas facile pour certaines personnes d'admettre qu'il n'y a pas une seule façon correcte de faire les choses. L'important n'est pas de savoir comment vous travaillez, ni à quoi ressemble le code à la fin; l'important est que ces deux personnes compétentes et bien informées apprennent à mieux travailler ensemble. Ce n'est pas quelque chose que vous pouvez simplement leur dire; tout ce que vous pouvez faire est de les guider tout au long d'un processus d'apprentissage. Tout comme il n'y a pas une bonne conception, il n'y a pas une seule bonne façon pour les gens de travailler.
Généralement, d'après mon expérience au cours de ma carrière, il y a insuffisant design à l'avant. Et la conception qui se produit à l'avance est basse qualité. C'est mauvais. Principalement parce que le résultat est (plus ou moins) de jeter de la boue contre le mur et de voir ce qui colle. La dette technique est absorbée dès le départ.
De haut en bas est généralement supérieur de bas en haut. Bien que je n'exclue pas entièrement la méthode ascendante. La raison en est que le haut vers le bas vous oblige à réfléchir plus largement au problème et à demander meilleures questions. Cela renforce le premier point ci-dessus ... conduit à une conception de meilleure qualité et influence généralement fortement une grande partie du travail de niveau inférieur. Cela réduit les retouches considérables qui sont souvent autrement nécessaires si les composants de niveau inférieur sont construits en premier.
Il existe un risque non négligeable que si les composants ascendants sont construits en premier, la pression de développement essaie d'adapter les exigences de l'entreprise aux composants qui ont été conçus. C'est aussi mauvais. Les exigences commerciales doivent guider la conception, ce qui doit conduire la mise en œuvre. Tout ce qui va dans l'autre sens conduira à des résultats inférieurs.
Aucune des deux approches n'est suffisante. Il semble que chacun d'entre eux soit intelligent ou suffisamment expérimenté pour réaliser les lacunes de l'autre approche (peut-être qu'ils se sont brûlés?) Mais ne parviennent pas à voir les lacunes de leur propre approche sélectionnée ...
La vérité est qu'une approche mixte est nécessaire:
- il est presque impossible de trouver le "bon" design dès le départ; un certain degré d'expérimentation est nécessaire pour identifier les points douloureux, les goulots d'étranglement, ... (indice: ils ne sont jamais là où vous pensez qu'ils seront)
- il est presque impossible d'aller n'importe où simplement en "allant", vous êtes plus susceptible de terminer quelque part que vous ne vouliez pas, ou simplement tourner en rond, qu'autre chose
Cependant, en mélangeant les deux, vous pouvez:
- avoir un croquis approximatif donnant des directions et un squelette d'infrastructure
- et développer des composants adaptés à cette vision
Étant donné qu'aucun système existant répondant à cet objectif n'existe, il est important de comprendre dès le départ que:
- l'expérimentation/prototypage sera nécessaire
- l'itération sera donc nécessaire
Il faut donc mettre l'accent sur l'atteinte d'un système "fonctionnel" dans les plus brefs délais, quitte à ignorer les caissons d'angle, etc ... C'est le concept de la "fine tranche verticale": au lieu de construire les fondations de la maison , puis les murs, puis la structure du toit, ... et n'obtenir que quelque chose utilisable à la toute fin (ou ne jamais l'obtenir, ou il ne peut pas vraiment être utilisé) ... il vaut mieux construire à la place un équipement entièrement équipé chambre d'abord, comme la salle de bain. Il est utilisable immédiatement et peut être utilisé pour recueillir des commentaires.
Cependant, pour que les commentaires soient utiles, il est préférable d'aborder une partie essentielle.
Alors, que faire de vos collègues?
La première chose est que tous les deux doivent comprendre le besoin de collaboration et le besoin de s'entendre sur une voie à suivre: se faire réprimander constamment, comme ils le sont, ne manquera pas de vous énerver et d'affecter votre motivation. J'ai présenté ci-dessus ce que j'ai trouvé bien fonctionner dans la pratique sur plusieurs projets, vous pouvez l'utiliser comme suggestion.
Ensuite, ils doivent s'entendre sur qui fait quoi. Notez que dans l'approche du terrain d'entente soulignée ci-dessus, les deux devraient définir des tâches qu'ils apprécient.
Notez que la construction des squelettes et la construction des briques sont mieux abordées progressivement.
- Les deux devraient obtenir un croquis approximatif du squelette, puis décider ensemble de la "tranche mince" sur laquelle se concentrer en premier.
- Le gars de bas en haut devrait commencer à travailler sur le morceau de "tranche mince" le mieux compris
- Le type descendant devrait commencer à étoffer le squelette, en abordant idéalement les pièces les plus bloquantes en premier pour terminer la tranche
Rincer et répéter jusqu'à ce que la tranche fonctionne; accumuler des commentaires le long du chemin vers Tweak selon les besoins.
Attention: il s'agit d'un prototype, les deux doivent être prêts à le jeter et à repartir de zéro sur un design complètement différent.
Ce dont vous avez besoin, c'est d'un leader (ou d'un superviseur) qui comprenne le développement de logiciels et qui décide de l'approche à utiliser dans le projet. Si nécessaire, le leader ordonne aux développeurs de travailler d'une manière particulière, quelles que soient leurs préférences personnelles.
La seule solution efficace à laquelle je peux penser qui ne perd pas de temps est de laisser chaque développeur suivre son propre style pour la conception.
En fait, cela pourrait être très inefficace ... car il y a de fortes chances qu'il y ait beaucoup de conflits et de retouches. Pire encore, vous pouvez vous retrouver avec un échec total du projet.