Comment impliquer au mieux le développeur junior dans la conception d'une application à partir de zéro? [fermé]

Nous sommes une équipe de 3 développeurs (2 développeurs expérimentés et un junior).

Nous venons de lancer un tout nouveau projet. Nous avons conçu l'application, concentré nos efforts sur le choix de la bonne architecture et nous posons maintenant les premières lignes de code. Nous en écrivons le cœur, ce qui sera le fondement de toute l'application.

Ce n'est pas non plus une application facile. Exigences de performance strictes, modèle d'entité complexe massivement distribué, etc.

Nous sommes tous hors de notre zone de confort, surtout les juniors. Il n'a pas l'expérience pour créer un bon design dès le départ. Ce n'est pas un problème cependant parce que moi et l'autre développeur sommes là pour aider et nous croyons tous deux au mentorat et à la constitution d'équipes, mais ... nous ne savons pas exactement quelle serait la meilleure façon de le faire, afin qu'il obtienne une expérience agréable et apprend le maximum de compétences.

Nous avons tous les deux réalisé que nous n'avions pas de junior sur de nouveaux projets, seulement sur ceux existants où c'était plus facile pour le junior parce qu'il avait une base de code entière pour apprendre et inspirer. Mais pour cette application, nous n'avons presque pas de code. Nous venons de commencer.

Nous réfléchissions à quelques approches:

• faites-le essayer par lui-même pendant quelques jours, puis intervenez et refactorisez le code avec lui, dirigez-le dans la bonne direction, puis répétez => Ce ne sera peut-être pas une expérience amusante pour lui car nous signalerons ses erreurs à chaque refactor ;
• demandez-lui de jumeler la programmation avec l'un de nous => il pourrait devenir juste un "spectateur" et être d'accord avec tout ce que nous faisons, sans vraiment apprendre beaucoup ou digérer une grande partie de l'information;
• nous faire construire le squelette de chaque module, avec un design solide et lui donner ensuite le module pour ajouter les pièces manquantes => ce n'est peut-être pas amusant de ramasser après nous et il y a le risque qu'il ne fasse attention qu'à combler les lacunes et non à l'ensemble du design.

Comment pouvons-nous l'impliquer dans la conception afin qu'il ne se sente pas en quelque sorte en dehors de celui-ci et qu'il apprenne beaucoup de l'expérience et gagne suffisamment de confiance pour l'essayer par lui-même?

Je recommande les directives suivantes:

• Impliquez le développeur junior dans vos réunions de conception et sollicitez son avis. Cela lui fera penser à la situation dans son ensemble, même s'il n'est pas prêt à faire lui-même la conception de haut niveau.
• Essayez d'isoler et de définir clairement un module de l'application à attribuer au développeur junior. Décrivez par écrit quelles sont les entrées / sorties et les autres exigences du module. Évitez de lui attribuer un module qui ne peut pas être facilement testé ou qui ne peut être testé que lorsqu'il est intégré à d'autres modules encore à écrire.
• Peut-être que le développeur junior pourrait aider autrement que par coder l'application principale. Par exemple, il pourrait écrire du code de test. Loin d'être un travail subalterne, l'écriture de bons scripts de test apporte une précieuse contribution au projet et donne également au développeur junior une solide compréhension du projet.

Je pense que cela dépend de quel domaine vous souhaitez que ce développeur junior s'améliore. Quand j'étais (très) junior, ils me donnaient des API dont j'avais besoin pour construire une chose confinée particulière, comme:

• cette fonction donne N nombre de personnels de la table Personnel
• cette fonction fournit des statistiques sur le personnel étant donné l'ID du personnel

->

Tâche: créer une page avec une liste de personnels qui affiche ses statistiques lorsqu'un utilisateur clique sur un dossier personnel. Voici un exemple de page simple créée auparavant dans le projet.

L'aspect le plus important de la tâche donnée est d'être résoluble uniquement par ces ressources données et ne nécessite aucune modification.

Les 3 façons me semblent bonnes. En fait, essayer 10 méthodes agiles différentes en même temps devrait vous donner de bons résultats bientôt, au moins vous saurez quelle méthode fonctionne et laquelle ne fonctionne pas (laquelle fonctionnera le mieux dépend beaucoup de la personnalité des joueurs).

Le problème de programmation par paire ne se produira pas si vous vous en tenez au processus avec les chapeaux de frappe / réflexion qui changent toutes les 10 minutes (environ), sans exception, en suivant le processus initialement décrit par Kent Beck (je ne me souviens pas où)

Quant à impliquer d'autres personnes dans la conception - ce que nous avons trouvé utile, c'est que pendant la phase de conception, certains documents de conception (avec certains modèles UML) soient créés. Les autres personnes (votre junior) peuvent ensuite les relire, les réviser, jouer l'avocat du diable. Ce rôle de tierce partie indépendante intacte peut être très bénéfique, par exemple pour les tests exploratoires - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries