Conseils pour favoriser une collaboration productive au sein d’équipes agiles | de Taylor Wagner | décembre 2022

Comment capitaliser sur les forces de chacun et construire le meilleur produit possible

Avoir un début non traditionnel dans ma carrière technologique m’a donné une ultra-conscience de mes forces et de mes faiblesses. Le bootcamp à mon rythme que j’ai choisi était parfait pour ma situation, me permettant de continuer à travailler et à subvenir aux besoins de ma famille tout en poursuivant ma passion. De même, le cursus bootcamp m’a doté de nombreux outils que j’utilise au quotidien dans mon rôle d’ingénieur qualité.

Cependant, un inconvénient majeur du style d’éducation à son rythme est le manque de collaboration. J’ai reçu un mentorat 1: 1 et j’ai appris le contrôle de version git, mais je n’ai pas acquis l’expérience de la création d’une application en collaboration de manière agile. Les quelques exemples de programmation jumelée que j’ai eus ont été phénoménaux et m’ont montré le grand pouvoir de travailler avec d’autres pour créer un excellent produit, mais je savais que le manque d’expérience dans une équipe agile allait être une faiblesse pour moi au début de le travail.

Après sept mois de travail et faisant partie de plusieurs équipes agiles, j’ai acquis quelques stratégies à emporter qui, selon moi, améliorent les performances des membres de l’équipe, favorisent la camaraderie et améliorent la qualité du code. J’aimerais partager ces conseils avec vous. Plongez avec moi !

Ce qui fait des équipes agiles la structure optimale pour la création de logiciels est double : 1) chacun a un rôle avec des tâches spécifiques, et 2) chacun vient dans l’équipe avec ses propres compétences et connaissances de base. Mais comment tirer parti des diverses compétences et connaissances des membres de l’équipe ? Supposons que votre équipe est chargée d’utiliser FastAPI pour un projet. Alors que le membre de l’équipe A peut avoir une tonne d’expérience avec Djangole membre de l’équipe B connaît parfaitement Ballon.

La grande partie est que ces deux frameworks s’appuient sur Python, donc même si des nuances peuvent se présenter, il existe un terrain facile pour fusionner des maîtrises individuelles pour le plus grand bien de l’équipe.

Lorsque le membre de l’équipe A et le membre de l’équipe B discutent de choses à propos de FastAPI qu’ils ne comprennent pas, il est très utile de s’appuyer sur ce qu’ils comprennent et de s’aider à se guider mutuellement vers le « ah ha ». Il s’agit d’articuler correctement et de trouver la bonne question.

Le membre de l’équipe B pourrait dire quelque chose comme ceci : « Le flacon utilise Jinja pour la modélisation et peut échapper automatiquement des fichiers communs comme .html avec render_template(). Django a-t-il quelque chose de similaire? Je me demande si FastAPI le fait parce que, pour ce cas d’utilisation… « Le formatage de la conversation de cette manière permet au membre de l’équipe A d’en savoir plus sur Flask, donne au membre de l’équipe A une chance de répondre avec ce qu’il sait sur Django et de s’appuyer sur cette expérience, et garde la conversation s’est concentrée sur le projet en cours.

Les hypothèses sont une pente glissante et un piège dans lequel il est facile de tomber. Il est naturel de penser que « le membre de l’équipe A a déjà utilisé AWS, donc il sait comment créer un Stratégie IAM pour un compartiment S3‘, mais mettez-vous en garde contre le fait de vous pencher sur ce processus de pensée en tant que loi. L’« expérience » d’une personne avec un outil est rarement unique. Essayez de poser des questions lorsque vous communiquez avec les membres de l’équipe autant que possible pour vous donner une meilleure clarté sur ce avec quoi ils viennent à la table, puis continuez une fois que vous êtes entré dans le vif du sujet.

Jusqu’à présent, le thème a été la communication, ce qui peut sembler assez évident lorsque l’on travaille avec des gens, mais ne signifie pas nécessairement qu’il est naturel de le mettre en œuvre. Des hypothèses peuvent même apparaître lors du partage d’écran et de la discussion d’un peu de code. Que vous soyez le conducteur ou le navigateur, cela fait gagner beaucoup de temps et aide à aligner les conversations de résolution de problèmes lorsque les membres de l’équipe commencent par « dans le helpers répertoire, fichier logIn.helper.tsligne #17…”

Je suis rapidement confus lorsqu’un membre de l’équipe dit quelque chose comme « dans le bloc de code là… » Il est facile de supposer que votre coéquipier sait exactement à quel morceau de code vous faites référence, mais est-ce trop difficile d’être précis dès le saut ?

L’heure du lancement d’un projet où les membres de l’équipe reçoivent la biographie de chaque personne est une excellente occasion d’en apprendre davantage sur l’individu et sur la façon de bien travailler avec chacun. Vous avez un peu plus de temps dans votre journée ? Planifiez une réunion 1: 1 pour développer la biographie, le réseau et en savoir plus de l’individu. La réunion peut être aussi courte que 15 minutes pour briser la glace, mais elle peut finir par économiser des tonnes de temps et des maux de tête en cas de mauvaise communication tout au long de la durée de vie du projet et du temps passé à travailler ensemble. Ce « travail préalable » est essentiel à une accord de travail Rencontre.

Sur la base des biographies et des réunions 1: 1, j’encourage fortement la mise en place d’un moment où tous les membres de l’équipe se réunissent pour débusquer des idées pour établir un accord de travail accessible à tous. Ce que j’aime le plus, c’est le double sens du mot ‘travailler’ devant le mot ‘accord’.

« Travailler », c’est-à-dire comment nous travaillonsmais aussi « travailler » comme dans l’accord est dans les ouvrages. Des accords de travail ne sont pas gravés dans la pierre, des pavés inajustables. C’est un document qui peut être modifié en fonction des besoins fluctuants du produit et des membres de l’équipe. Indépendamment des changements qui se produisent inévitablement, un accord de travail est une excellente stratégie pour responsabiliser les membres de l’équipe d’une manière non menaçante et non personnelle. J’aime penser aux accords de travail comme à un pacte.

La documentation est une tâche redoutée pour la plupart des développeurs. C’est une tâche qui est souvent tergiversée. Cependant, la documentation est essentielle pour maintenir la durée de vie du code et pour que plusieurs personnes puissent y contribuer. Même en comprenant l’importance de la documentation, j’ai souvent fait l’expérience d’un brusque changement émotionnel qui se produit lorsque j’accomplis finalement une tâche difficile (super élevé !), qui est rapidement suivi par la prise de conscience que je devrai expliquer aux membres de mon équipe comment le reproduire (super basse !).

Quelques astuces que j’ai trouvées utiles pour éliminer un peu la peur:

• Échafaudez votre processus de documentation. N’essayez pas de tout faire d’un coup mais plutôt petit à petit et dans le temps.
• Écrivez des notes – ou conservez un document avec des notes – selon votre préférence. Prenez des notes sur les chemins qui vous mènent à la solution mais aussi aux barrages routiers (et comment vous avez surmonté ces blocages) !
• Ajoutez des sites Web utiles à vos favoris.
• Essayez de vous moquer d’exemples de très bonne documentation.
• Capture d’écran! Peut-être même créer un répertoire pour les captures d’écran pour aider à expliquer les processus étape par étape.
• Cousin des captures d’écran – Enregistrement d’écran.

La création, la révision et l’approbation des demandes d’extraction étaient complètement nouvelles pour moi lorsque j’ai commencé mon travail. Bien que j’étais à l’aise avec git, je n’avais jamais collaboré formellement avec qui que ce soit sur un référentiel auparavant. Examen des PR [Pull Requests] peut être une tâche opportune, mais elle est essentielle pour une véritable collaboration au sein d’une équipe. Les pull requests sont une formidable opportunité d’apprendre concrètement des membres de l’équipe.

Lors de la création d’un PR avec votre travail, pensez aux questions que vous pouvez poser aux membres de votre équipe qui pourraient aider à améliorer la réutilisabilité du code, facilitant ainsi la vie de chacun plus tard dans le projet. Je pense que laisser des questions sur vos propres relations publiques montre à vos coéquipiers que vous êtes ouvert à leur contribution, et ils pourraient prendre plus de temps pour vraiment les examiner.

De plus, restez ouvert d’esprit et attendez-vous à des commentaires qui pourraient vous obliger à apporter des modifications. Un collègue a dit un jour : « ne tombez pas amoureux de votre code ». Il est important de ne pas prendre personnellement les critiques et les commentaires de relations publiques car, plus que probablement, ce n’est pas le cas.

Passez en revue autant de PR que vous avez la bande passante pour. Lire et comprendre le code de quelqu’un d’autre peut être une rampe de lancement pour écrire un meilleur code pour vous-même. Si un membre de l’équipe a rédigé une fonctionnalité d’une manière que vous n’aviez pas anticipée, mais dont vous avez beaucoup appris, laissez un commentaire encourageant sur le PR. C’est un moyen facile de remonter le moral et la confiance de votre coéquipier. Si un membre de l’équipe a rédigé une fonctionnalité d’une manière qui, selon vous, laisse place à l’amélioration, envisagez d’envoyer un message Slack, une réunion 1: 1 et / ou un jumelage. Il peut être intimidant et décourageant pour un développeur de montrer son travail, et quelqu’un le déchire dans une critique.

J’espère le plus sincèrement que ces conseils vous ont été utiles, et il y a ici une petite pépite de mon expérience que vous pouvez ajouter à votre boîte à outils. J’apprends toujours et je cherche à être le meilleur coéquipier possible, alors j’aimerais entendre vos réflexions sur ces conseils et suggestions sur les conseils que j’ai peut-être laissés de côté ! Je suis ouvert aux commentaires et accueille les commentaires si vous vous sentez obligé! Nous sommes plus grands ensemble.