Blague à part, la communication en dehors des groupes techniques est un domaine que la plupart des développeurs doivent améliorer. Pour commencer, comprendre quel problème doit être résolu et pourquoi il s'agit d'un problème est une compétence qui doit être affinée. Cette compréhension est cruciale, car elle nous aide à écrire un meilleur code et nous rend plus engagés dans le projet. Une communication efficace nous relie en tant qu'équipe, garantissant que nous comprenons tous le problème et que nous pouvons travailler ensemble pour le résoudre.
Nous devons coder dans un but précis. Pas d'objectif, pas de code. J'ai entendu un jour un chef d'équipe orienté vers les affaires dire : "Nous ne sommes pas là pour écrire du code, mais pour vendre des produits. Nous sommes là pour vendre des produits." L'entreprise avait un objectif plus important que celui-là, ce qui éloignait encore plus le codage des projecteurs.
Pour les développeurs, il est essentiel de comprendre cet objectif supérieur, les objectifs de l'entreprise. Elle donne un sens à notre code et fait de notre travail plus que de simples lignes de texte. S'engager avec les parties prenantes et, plus important encore, comprendre leurs besoins, comprendre leurs besoins est essentiel pour s'aligner sur leurs objectifs. Parfois, ces objectifs peuvent nécessiter une exploration plus approfondie, et il est de notre responsabilité de plonger plus profondément dans la conversation jusqu'à ce que leurs objectifs soient clairs comme de l'eau de roche.
Des questions telles que "Quelle solution cloud recherchez-vous ?", "Quelle pile technologique répond le mieux à vos besoins ?", "Le bouton doit-il être orange ou magenta ?", et "Penchons-nous vers Figma ou Balsamiq ?" ne sont pas les bonnes. Pas à ce moment précis.
Un développeur peut être initié à Scrum en rejoignant une équipe qui se réunit quotidiennement pour discuter de ce qu'il a fait la veille, tandis qu'un développeur de longue date est désigné comme Scrum Master. Tous deux peuvent ne pas comprendre la raison d'être du cadre ou les problèmes qu'il résout, et en conclure que "Scrum n'est pas fait pour nous".
Pour les développeurs, comprendre les objectifs du projet et planifier pour les atteindre, à la fois en tant qu'équipe et en tant qu'individus, ne se résume pas à écrire du code. Il s'agit de savoir quand écrire du code, quelles sont les pratiques techniques et humaines à suivre, et de se soucier de la qualité de la solution que nous créons pour atteindre l'objectif du produit, puis de la qualité de la mise en œuvre. Ce parcours d'apprentissage continu et d'amélioration des compétences nous permet de rester motivés et inspirés.
Pour mettre en pratique les rudiments de compétences complexes, nous les décomposons en petits morceaux et les exécutons par petites étapes afin d'obtenir un cycle de retour d'information plus rapide, ce qui permet d'apprendre et de corriger le cap plus rapidement. À cette fin, un sprint de deux semaines sur un projet réel peut sembler décourageant lorsque nous devons livrer quelque chose à la fin de la période.
Et si nous exercions ces compétences au cours de trois sprints en trois jours ? Est-ce trop court ? Ajoutons un projet dont vous ne savez pas grand-chose et une équipe de personnes que vous venez de rencontrer. L'équipe et ses membres apprennent rapidement à quel point leurs compétences en matière d'estimation sont bonnes (et pourraient généralement être meilleures), comment gérer le mélange de voix fortes et de voix faibles, et comment affiner leur collaboration pour atteindre leurs objectifs.
Si vous vous sentez concerné ou attiré par cette méthode, n'hésitez pas à vous inscrire à notre programme Application de Scrum professionnel pour les développeurs de logiciels.
