Blog Arolla

Quand la vitesse génère de la frustration – Episode 3


Nous vous proposons une série d'articles pour traiter les problématiques liées au rythme de production d’un logiciel, les frustrations engendrées et les solutions qui peuvent être apportées pour améliorer la vie de l’équipe.
Dans le premier épisode, nous avons abordé le besoin pressant de vitesse. Ensuite dans le deuxième, nous avons évoqué le sujet de la dette technique engendrée par la précipitation au détriment de la qualité.
Dans ce troisième épisode, nous abordons en quoi l'organisation de l'équipe impacte la vitesse.

Seul, on va plus vite. Ensemble, on va plus loin (proverbe africain)

Les discussions trop fréquentes sont bien souvent perçues comme une perte de temps, un frein à la production. Pourtant, même si cela ne parait peut-être pas au premier abord, chaque choix fait par un intervenant du projet peut avoir des répercussions sur la vitesse des autres.
En tant que décideur ou décideuse, s'engager sur une date de mise en production, sans consultation de l’équipe en charge de la réalisation sur la faisabilité, peut suffire à creuser l’écart entre temps nécessaire et temps imparti pour un développement donné. Puisqu’il est attendu de l’équipe qu’elle s’adapte aux délais, elle se retrouve préalablement à toute action de sa part en situation défavorable. La priorisation des livrables est mise en difficulté car l’échéance ne découle pas d’une analyse des risques techniques.

Il arrive que des choix techniques soient imposés à l’équipe de développement, non pas à cause de la reprise de code préexistant, mais parce qu’ils ont été faits par une équipe dont le domaine de compétence était différent, pensant peut-être alléger les coûts. Par exemple, une équipe commerciale dont le besoin est de réaliser des phases d’AB testing, autrement dit de tests comparés d’une fonctionnalité avec des variations par groupe d’utilisateurs, achète la licence d’un outil du marché. Lorsqu’il est demandé par la suite à l’équipe technique sa mise en place, il est découvert que cette solution a une faille de sécurité et est une source de ralentissement de l’application.

Bien souvent, les représentants du métier se sentent pressés entre le marteau des exigences des clients, et l’enclume du mur de refus des développeurs d’avancer plus vite. Avec ces derniers, la confiance s’étiole et l’incompréhension grandit. Conscients de ne pas exercer le même métier, ni de parler le même langage, désireux de bien se faire comprendre, la présentation de la demande de développement est détaillée jusqu’à la décision de la solution souhaitée. Mais les conséquences de ce choix ne sont pas celles espérées. L'intérêt métier d’une fonctionnalité et la motivation de son ajout ne leur étant pas communiqués, l’équipe technique, commet des erreurs de jugements. Si le temps manque pour terminer une tâche, elle ne peut se fier qu’à sa première impression pour décider de ce qui peut être raboté et de ce qui compte vraiment. Une erreur d'appréciation peut vite mener à investir du temps dans une solution jetable : ce n’était pas du tout ce qu’il était demandé.

De plus, la complexité d’une implémentation ne transparait pas dans la simplicité de l’énoncé d’un besoin. L’équipe technique est contrainte par la structure du code existant, héritée de la succession des choix de conceptions passés, qui oriente fortement ses choix futurs. En ne sollicitant pas son expertise, le projet se prive de solutions plus optimales, plus rapides et moins coûteuses restées ignorées.

Afin de stopper ces dérives, il est nécessaire que les différents rôles impliqués dans le projet collaborent en tant que membres d’une même équipe. Dans plusieurs de ses livres dont « Specification by example », Gojko Adžić propose de réunir différents rôles, expert du domaine, développeur, testeur (et toute partie prenante du besoin) afin de discuter ensemble d’une fonctionnalité à réaliser. Il nomme ces réunions « tres amigos » (trois amis). Chacun peut poser des questions, contribuer avec sa vision, alerter sur les points d’importance métier et de risque technique, et la connaissance est partagée. En allant plus loin, dans un état d’esprit BDD (Behaviour Driven Development), le recours à des exemples explicite les scénarios de comportement attendus, qu’il est possible de retrouver ensuite tels quels dans le code, sous la forme de tests automatisés guidant l’implémentation, palliant ainsi les approximations de compréhension métier-technique. Ensuite, le langage de formalisme, voire le vocabulaire, peut devenir commun. D’après les travaux du sociologue Karl Weick, une réussite collective aide les membres d’une équipe à se faire confiance davantage, à augmenter le moral et les performances.

Il ne faut jamais aller plus vite que sa vitesse (Philippe Labro)

Dans certains contextes, pour des raisons budgétaires ou en raison de recrutement en cours, la stabilité de l'équipe est précaire. Certains membres sont contraints d’endosser plusieurs rôles ou d’intervenir sur plusieurs projets. Leur planning est partagé, et cela réduit leur disponibilité et leur concentration. Probablement, une fatigue s’installe et la vitesse de production diminue. Certaines personnes estiment également avoir besoin de libérer leur charge mentale pour libérer leur créativité et trouver des solutions.

Partant du principe que plus on est nombreux sur une tâche plus on abat de travail, les décideurs préfèrent augmenter la taille de l’équipe. Cela peut être une bonne solution à long terme, mais moins meilleure à court terme. En effet, on oublie souvent qu’une nouvelle recrue prendra du temps à ses co-équipiers pour aider à sa montée en compétence en plus du travail attendu pour le livrable. Doubler la taille de l’équipe d’un coup est la garantie d’une vitesse réduite au maximum. Néanmoins, pour les équipes qui n'ont pas de deadlines à court terme, cela peut correspondre à un investissement pour gagner plus tard. Parfois, certains décideurs pensent que la production sera ralentie pour un temps réduit et qu’ensuite l’équipe retrouvera son rythme de croisière. Mais on le voit à force de vouloir gagner du temps, on finit par le perdre. Par exemple, pour finir un module attendu dans trois mois, dans une équipe de cinq personnes déjà débordée, le responsable, confiant, décide de recruter deux nouveaux membres expérimentés. Il considère que l’expérience garantit l’autonomie de ces nouvelles personnes et les dispense de perturber l’avancement du reste de l’équipe. Il donne donc le feu vert pour qu’elles plongent directement dans le code sans partage de connaissance. En l’absence de transfert de compétence et de présentation des règles de l’équipe, les nouveaux venus appliquent leur façon de faire dans le code. Rapidement, les retours de revue de code sont nombreux. La nécessité de discuter et challenger les règles de l’équipe en vue d’une uniformisation se fait sentir. Finalement, les allers-retours (développement/revue de code/correction) finissent par coûter plus cher que prévu et le délai est largement dépassé.

Nous avons vu dans l'épisode 2 qu'un phénomène de goulot d’étranglement se forme dans le flux des tâches (Explaining-flow) et se résorbe en fonction d’une limitation du nombre de tâches en cours. Ce phénomène est aussi dépendant de la structure de l’équipe. En effet, chaque membre en fonction de son rôle a une tâche spécifique, et la complétion de cette tâche est bien souvent la condition au démarrage de la tâche d’un autre rôle. Les développeurs attendent que les besoins soient définis, et les testeurs que les développements soient faits. Dans cette chaine, tel que dans un défilé, le rôle le plus lent dicte la cadence de tous les autres (cf le concept du Rope-Buffer-Drum voir image ci-après).

Dans la majorité des cas, c’est le développeur le rôle le plus lent (ressource goulot ou “drum”). Parfois, c’est l’équipe métier qui n’est pas bien taillée pour sa tâche. On peut observer un phénomène de goulot d’étranglement quand des développeurs se retrouvent sans travail car il n’y a pas encore assez de tâches planifiées. Cela peut être dû à un planning décalé (congés, présence à temps réduit...). Conjointement à la recherche du bon WIP-limit (Work In Progress limit) suggéré à l'épisode 2, deux autres leviers d’accélération à envisager sont la possibilité pour certains rôles d’être support d’autres rôles et la recherche du bon nombre de membres de chaque rôle dans l’équipe. A propos du ratio du nombre de développeurs par BA (Business Analyst ou représentant du métier), il n’y a pas de loi fixe. La composition peut changer en fonction du contexte. Barbara A. Carkenord dans son livre “Seven steps to mastering business analysis” présente le métier de BA comme complexe et annonce une tendance à la spécialisation qui explique qu’il va y avoir plus de BA que de développeurs dans les organisations à l’avenir.

Enfin, pour un meilleur équilibre dans une équipe de développeurs et développeuses, Amir Yasin propose dans son article, d’avoir un ratio de trois profils séniors pour un profil junior. Le but est de garder un bon rythme de livraison tout en faisant monter en compétence les juniors.

Arrivée à bon port

Dans le cas où vous faites face aux situations présentées dans cet épisode, nous espérons avoir apporté des solutions pour vous aider à améliorer votre quotidien et réduire les frustrations face à la difficulté de travailler ensemble, en parfaite cohésion à un rythme coordonné.
Dans le prochain épisode, nous vous proposons d’aborder le manque de vision et le manque de déploiement continu.

Rdv au prochain épisode par ici 😉

Plus de publications
Plus de publications

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *