Comment faire face à différents styles de développement (top-down ou bottom-up) au sein d'une équipe?

Supposons que vous venez de commencer à travailler dans une très petite équipe sur un projet {actuellement relativement petit, mais espérons-le plus gros ultérieurement}. Notez qu'il s'agit d'un projet réel destiné à être utilisé par d'autres développeurs du monde réel, et non d'un projet académique destiné à être abandonné à la fin du semestre.
Toutefois, le code n’ayant pas encore été communiqué aux autres, aucune décision n’est encore gravée dans le marbre.

Les méthodologies

L'un de vous aime commencer à coder et faire en sorte que les pièces s'emboîtent l'une après l'autre avant d'avoir nécessairement une idée claire de la manière dont tous les composants vont interagir (conception ascendante). Un autre d'entre vous aime d'abord faire le design dans son intégralité et préciser les détails de tous les composants et de la communication avant de coder une solution.

Supposons que vous travaillez sur un nouveau système plutôt que d’imiter les systèmes existants. Il n’est donc pas toujours évident de définir le bon design final. Ainsi, dans votre équipe, différents membres de l'équipe ont parfois des idées différentes sur les exigences même nécessaires pour le produit final, sans parler de 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 problèmes futurs envisagés dans la conception, même si le code peut résoudre le problème en question, estimant qu'il est plus important que la conception soit correcte. avant de tenter de coder la solution au problème.

Lorsque le développeur descendant essaie de résoudre l'intégralité de la conception et des problèmes envisagés avant de commencer à écrire le code, le développeur ascendant le rejette car il ne pense pas que certains 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 bottom-up finit par perdre du temps, car le développeur top-down décide souvent que la solution écrite par le développeur bottom-up doit être abandonnée à cause d'un défaut de conception, d'où la nécessité de -écrire le code.

Le développeur descendant finit par perdre son temps, car au lieu de paralléliser le travail, il s’efforce fréquemment de trouver la bonne conception avec le développeur bottom-up, en sérialisant les deux au point d’être encore plus rapide. pour 1 personne pour faire le travail que 2.

Les deux développeurs souhaitent continuer à travailler ensemble, mais il ne semble pas que la combinaison les aide réellement dans la pratique.

Les objectifs

Les objectifs communs sont évidemment de maximiser l’efficacité du codage (c’est-à-dire de minimiser les pertes de temps) et d’écrire des logiciels utiles.

La question

En termes simples, comment résoudre ce problème et faire face à cette situation?

La seule solution efficace à laquelle je puisse penser sans perdre de temps est de laisser chaque développeur suivre son propre style pour la conception. Mais c'est plus difficile qu'il n'y paraît lorsque vous révisez le code et que vous devez réellement approuver les modifications apportées par les autres et lorsque vous essayez de concevoir un cadre cohérent que les autres utilisateurs pourront utiliser.

Y a-t-il un meilleur moyen?

De toute évidence, ils ont tous les deux tort.

Le responsable de bas en haut manipule le code et ne produira jamais quelque chose qui fasse ce qu'il est censé faire - ce sera un roulement continu tant que les exigences inconnues seront déterminées.

Le gars du haut peut passer aussi longtemps sur la vision architecturale et ne rien faire de productif aussi.

Cependant, un terrain d'entente est idéal - si vous connaissez les objectifs visés (obtenus dans le cadre d'un travail de conception étendu) et que vous procédez au codage (sans planification détaillée), vous récolterez les fruits d'un système à la fois organisé et développé efficacement.

Soit dit en passant, il s'appelle Agile (ce n'est pas la version BS de Agile que certaines personnes pratiquent lorsque les procédures sont plus importantes que les logiciels utilisés), mais véritablement agile, qui poursuit son travail vers un objectif final communément décrit et compris.

Pour résoudre le problème ici, essayez une approche agile (le kanban est probablement la meilleure), ce qui forcera le responsable hiérarchique à faire un travail et obligera le responsable hiérarchique à planifier ses objectifs.

Les deux développeurs doivent maintenir un respect mutuel .

La personne de haut en bas doit respecter le fait que la personne de bas en haut a pu proposer quelque chose qui fonctionne réellement. Comme l’a dit l’un de mes professeurs "quant", "un modèle opérationnel 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 utile pour éviter les efforts inutiles, résoudre le mauvais problème, sortir du sujet, etc. Le codeur ascendant doit au moins garder à l'esprit la personne du haut en bas essaie de le faire et essaie de répondre au moins aux préoccupations du client, telles qu'elles sont exprimées dans le cadre. Ce serait vrai même si le bas en haut était en désaccord avec des parties du cadre lui-même.

Vous pouvez minimiser les pertes de temps de chaque développeur si vous divisez de grandes tâches en plusieurs tâches plus petites et plus ciblées. Demandez-leur de travailler en étroite collaboration pour qu’aucun d’eux ne devance trop l’autre. Les sprints courts et les petits livrables vont un long chemin. Il est plus facile de réparer une petite erreur qu'un gros.

Cela peut sembler contre-intuitif à votre objectif, mais la programmation par paires fonctionne. Il y a des choses que vous ne voudrez tout simplement pas comprendre tout de suite, parfois pendant des heures, voire des jours. S'il est hors de question de travailler directement sur des tâches ensemble, essayez de réviser le code / de vous lever plus souvent au cours de la semaine.

Gardez tout le monde au courant!

Si vous voyez des développeurs jeter du code parce qu'ils étaient dans leur propre monde, vous devez résoudre et résoudre les conflits le plus rapidement et le plus efficacement possible. Votre patron l'appréciera et l'équipe appréciera de ne pas avoir à perdre une semaine de travail car il ne savait pas ce que faisait l'autre gars.

Vous devriez aussi 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 suis arrivé au milieu de votre message en pensant que «ces deux-là 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 est inutile." ~ Un vieil homme

Cela ressemble vraiment à un scénario idéal pour moi. Là encore, je suis ces deux développeurs en même temps. J'aime rédiger la "grande image" sous forme de notes qui finissent par se retrouver dans un outil de suivi des problèmes. Ensuite, je commence à réfléchir aux détails de la mise en œuvre de bas en haut. La situation dans son ensemble évolue au fur et à mesure que je comprends mieux la façon dont les pièces s’assembleront, et à mesure que les exigences évoluent et que de nouvelles idées me parviennent.

Peut-être que c'est un bon modèle pour plusieurs cerveaux.

À mon avis, ce sont des profils complémentaires et peuvent finir par bien se comporter. 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 de X, tout ce dont vous avez besoin est d’un peu d’ organisation (vous pouvez aussi avoir un mot audacieux!)

Cela peut se faire par supervision, comme d'autres l'ont fait remarquer, mais encore mieux par accord mutuel sur un calendrier d'itérations indiquant quand et où coder, et en évitant en général de coder ce qui est 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 éléments sur lesquels le programmeur de bas en haut ne travaille pas actuellement, ce qui en fait une phase dans laquelle les deux font ce qu'ils veulent. Cela implique toutefois une capacité de chacun à faire les ajustements nécessaires lorsque vient le temps de tout mettre ensemble.

Une note: vous avez dit

Supposons que vous travaillez sur un nouveau système plutôt que d’imiter les systèmes existants. Il n’est donc pas toujours évident de définir le bon design final.

Cela fait partie du problème: à moins que vous ne travailliez sur un projet minuscule pour un problème déjà résolu, il n’existe pas de conception finale adéquate . Il y a beaucoup de conceptions possibles. Gardez à l'esprit qu'à moins de faire cela pour améliorer votre ego en raison de la beauté de votre code, l'objectif final est une application qui fonctionne. C'est ça. La façon dont vous y arrivez est sans importance et la meilleure façon de les laisser aller rapidement 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 n’est pas inhabituel que deux développeurs s’entendent sur des pratiques, en particulier pour des questions aussi subjectives que les processus de conception et de développement. Vous avez deux personnes ici qui sont passionnées par ce qu’elles font et qui savent comment le faire: embrasser ça!

Il existe un grand potentiel pour vous permettre de laisser les deux personnes travailler à leur manière, tout en faisant correspondre les éléments pour obtenir une application fonctionnelle.

1. Je les aurais tous les deux assis pour discuter et les encourager à le voir du point de vue de l'autre.

2. Après cette discussion, vous pouvez commencer à parler de planification: ceci devrait être fait en équipe, sachant que ni l'un ni l'autre ne doit «céder» à l'autre, mais des compromis devront être faits. Il y a de nombreuses façons de planifier l'architecture d'une base de code permettant de l'étendre assez facilement ultérieurement, sans introduire une tonne de code supplémentaire.

3. Une fois que vous pouvez les amener à une sorte de trêve, laissez-les se déchaîner! Laissez le lecteur 'top down' planifier l'organisation de l'architecture de haut niveau, des interfaces, des hiérarchies, etc. Laissez le 'gars du bas' faire son entrée et commencer à écrire du code une fois que quelques modules sont prévus. Faites-les accepter formellement d'accepter les méthodes des autres comme étant bonnes pour le projet dans son ensemble: Planifier pour permettre des changements faciles à l'avenir est une bonne chose, mais il n'est pas nécessaire de le coder immédiatement. Créez des interfaces et des méthodes de remplacement pour obtenir la structure du code, et acceptez qu'une bonne partie du code pour le futur ne soit réellement écrit que si nécessaire.

4. Demandez-leur de revoir la conception et le code fréquemment, ensemble. Parcourez les cycles où vous plongez dans certains segments de l'architecture, planifiez plus en détail et écrivez ces parties.

5. 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 effectué. Réfléchissez à la dynamique en cours de construction: vous devriez vous poser quatre questions. Qu'est-ce qui s'est bien passé et que nous devrions continuer à faire? Qu'est-ce qui s'est mal passé et que nous devrions arrêter de faire? Que manque-t-il? Que pouvons-nous faire à propos de ce que nous manquons?

Cela demandera du travail: vous devez les amener à accepter de travailler ensemble à leur manière. Ce n'est pas facile pour certaines personnes d'admettre qu'il n'y a pas une seule et bonne manière 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 qualifiées et compétentes 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 du processus d’apprentissage. Tout comme il n'y a pas un seul bon concept, il n'y a pas un seul bon moyen pour les gens de travailler.

De manière générale, selon mon expérience au cours de ma carrière, la conception initiale est insuffisante . Et la conception qui se produit à l’avance est de mauvaise qualité . C'est mauvais. Principalement parce que le résultat est (à un degré plus ou moins grand) de jeter de la boue sur le mur et de voir ce qui reste collé. La dette technique est accumulée dès le départ.

Le top-down est généralement supérieur au bottom-up. Bien que je n’exclue pas complètement le bottom-up. La raison en est que le haut en bas vous oblige à penser le problème plus largement et à poser de meilleures questions . Cela renforce le premier point ci-dessus ... conduit à une conception de qualité supérieure et influence généralement beaucoup la plupart des travaux de niveau inférieur. Cela réduit le travail considérable qui est souvent nécessaire par ailleurs 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 tente de moduler les exigences commerciales en fonction des composants conçus. C'est aussi mauvais. Les exigences commerciales doivent guider la conception, ce qui doit guider la mise en œuvre. Tout ce qui se passe dans l'autre sens mènera à des résultats inférieurs.

Aucune approche n'est suffisante. Il semble que chacun d’eux soit assez intelligent ou suffisamment expérimenté pour comprendre les inconvénients de l’autre approche (peut-être qu’ils se sont fait brûler?), Mais ne parviennent pas à voir les inconvénients de leur propre approche choisie ...

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 où vous pensez qu'ils seront)
• il est presque impossible d'aller n'importe où simplement en "allant", vous êtes plus susceptible de finir quelque part que vous ne vouliez pas, ou simplement tourner en rond, que n'importe quoi

En mélangeant les deux, vous pouvez cependant:

• avoir un croquis donnant des instructions et un squelette d'infrastructure
• et développer des composants correspondant à cette vision

Comme il n’existe aucun système répondant à cet objectif, il est important de comprendre dès le départ que:

• l'expérimentation / le prototypage sera nécessaire
• itération sera donc nécessaire

Par conséquent, il faut mettre l'accent sur un système "opérationnel" dès que possible, même si cela implique d'ignorer les angles, 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 obtenir seulement quelque chose d’utilisable à la toute fin (ou ne jamais l’obtenir, ou ce qui est vraiment utilisable) ... il vaut mieux au contraire construire un local entièrement équipé , comme la salle de bain. Il est immédiatement utilisable et peut être utilisé pour recueillir des commentaires.

Pour que les commentaires soient précieux, il est préférable de commencer par une partie essentielle.

Alors, que faites-vous avec vos collègues?

La première chose à faire, c’est qu’ils ont tous deux besoin de comprendre le besoin de collaboration et le besoin de s’accorder sur une voie à suivre: se faire réprimander constamment, comme ils le sont, est voué à l’énervement et à la 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 médiane soulignée ci-dessus, les deux doivent affiner les tâches qu’ils apprécient.

Notez que la construction des squelettes et celle des briques sont mieux abordées progressivement.

1. Les deux doivent avoir un aperçu du squelette, puis décider ensemble de la "fine tranche" sur laquelle se concentrer en premier.
2. Le gars de la base devrait commencer à travailler sur le morceau de "tranche mince" le mieux compris
3. Le gars de haut en bas devrait commencer à étoffer le squelette, s'attaquant idéalement aux morceaux les plus bloquants en premier pour compléter la tranche

Rincez et répétez jusqu'à ce que vous obteniez la tranche de travail; accumuler des commentaires en cours de route pour peaufiner au besoin.

Attention: ceci est un prototype, les deux doivent être prêts à le jeter et à partir de zéro sur une conception complètement différente.

Ce dont vous avez besoin, c'est d'un chef (ou d'un superviseur) qui comprend le développement de logiciels et qui décide de l'approche à utiliser dans le projet. Si nécessaire, le responsable demande 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 puisse penser sans perdre 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 reprises. Pire encore, vous pourriez vous retrouver avec un échec total du projet.