
Envoyé par
qadassi
Certains débats futiles ont le mérite de développer l'argumentation, mais celui là est futile et vide de style.
Le manque de style est qu'il est du genre dialectique (débat pour/contre pour ceux qui ne s'y connaissent pas en littérature) sans nuance supplémentaire capable de mettre en valeur la subtilité de l'auteur.
Quant à sa futilité, la programmation en binôme voire en multinôme existe, et c'est le forking existant dans l'open source! Pour revenir à la remarque sur Linus, loin d'avoir été en solo, c'est l'inventeur de la programmation multinômial! Sauf qu'en entreprise, aucune ne paie des employés pour les envoyer coder sur les même fonctions d'un logiciel (rattraper moi si je me trompe), même pas RedHat.
Quant aux problèmes de communications soulevés, le pire c'est quelles ne sont pas les plus graves, et le plus important dans le forking open-source ou le travail en binôme dans une entreprise serait surtout sur l'objectif des discussions qui peut être, critique, validations, suggestions ou créativité, et comment les réaliser (genre thématique en littérature) et ainsi le débat sera limité à ses 4 issues (qui suivent un modèle analogue au CRUD et au quatre éléments de Platon, donc le modèle n'est pas le sujet du débat) mais il serait plutôt centré sur la manière de les réaliser peut importe la prédisposition introvertion/extraversion ou les problèmes d'égo.
Quelques exemples, et c'est dans cet ordre que ce ferait le débat.
Pour la créativité: ce serait le moment de l'écoute active ou chacun essayerait de s'émerveiller de la solution de l'autre en essayant de montrer qu'il a bien compris ce qu'il avait entendu, sans lui suggérer davantage pour laisser à l'autre la paternité de son idée, ni valider pour ne pas l'interrompre ni le casser pour ne pas le vexer.
Pour la suggestion: ce serait le moment du consensus utopique, l'un propose et l'autre suggère une amélioration, sans critique donc on ne casse pas mais on essaie de construire et d'enrichir l'idée de l'autre sans valider pour toujours repousser le plus loin possible les éventualités, ni proposer sa propre méthode quant l'un à la parole puis de s'échanger les rôles pour proposer son alternative.
Après les suggestions, on passerait à la modélisation ou au codage ou à la livraison, puis de nouveau, le contact serait repris.
Pour la critique: ce serait le moment des tests des scénarios et des tests unitaires, jouer le jeu de rôle attaquant/défenseur mais de manière séparer, le défenseur ne contre attaque pas et l'attaquant se lance à fond sans crainte de se tromper. L'un doit tester les fonctions de l'autres sont les validés avec la plus mauvaise foi ni d'apporter de suggestions avec le plus de retenus ni créer une solution plus efficace dans le plus grand désintérêts, puis d'intervertir les rôles.
Pour la validation: ce serait le moment de récapitulatifs des résultats de tests avec la plus objective et la plus réaliste des démarches sans débats ni suggestions ni propositions, juste de reporter les résultats des tests par le défenseur et l'attaquant individuellement, puis de noter l'écart des résultats et retenir les avis communs, puis de recommencer les tests sur les avis divergents dans la limite du temps et de recourir à un arbitre pour trancher au final.
Ainsi, un bon débat serait de la durer et du nombre de fonctions à évoquer, aux parties communes, aux parties individuelles, ou aux parties partagées à hierarchiser, qui riquerait d'être encore plus compliquer à choisir qu'à réaliser, ceci étant donc l'ouverture de la question " Est-ce que la programmation en binôme convient à tous les développeurs ?".
Bref, ce que j'ai évoqué relève du bon sens de chacun, et n'ai pas sensé être LA BONNE ou encore moins refléter LA REALITE ou pire LA SEULE façon d'aborder le sujet.
Bravo si vous avez lu jusqu'à la fin, et merci d'avance pour les critiques, accords, suggestions ou alternative.
Partager