Le développement logiciel, c’est humain

Imaginez que vous êtes une compagnie de construction résidentielle et que le gouvernement vous approche pour un projet de quartier à construire. Les plans d’architecte sont fournis et il suffit de bâtir. En regardant les plans, vous constatez des enjeux ici et là dans le produit. Cependant, au moment de partager ces inquiétudes, vous constatez que l’architecte est difficilement joignable pour répondre à vos questions. Par moment, vous décidez donc d’y aller avec votre intuition et de faire ce qui aurait le plus de sens.

En raison de cette communication difficile, la construction des résidences prend du retard au point de causer une augmentation des coûts de 30 % ! Néanmoins, le projet est finalement livré et les résidents peuvent prendre possession de leur logement. C’est à ce moment que les plaintes des clients surgissent : « Ce n’est pas ce que je voulais ! », « Ça ne répond pas à mon besoin ! », « Ce n’est pas ce qu’on m’avait présenté avec les plans ! »...

Satisfaction client

Cet exemple illustre les limites d’une approche de développement de projet rigide, similaire à la méthodologie en cascade (Waterfall) en développement logiciel. Dans le modèle en cascade, chaque étape du projet doit être complétée et approuvée avant de passer à la suivante, ce qui signifie que le plan initial est souvent considéré comme immuable. Si des problèmes surgissent ou si des ajustements sont nécessaires en cours de route, cela peut entraîner des retards et des coûts supplémentaires, comme dans le cas de la construction où les problèmes de communication avec l’architecte ont conduit à des décisions basées sur l’intuition plutôt que sur des directives claires.

De même, dans le développement logiciel en cascade, une fois que les exigences sont définies et que le développement est entamé, il est difficile de revenir en arrière pour apporter des modifications sans subir des coûts importants et des retards. Cela peut conduire à une situation où, à la fin du projet, le produit livré ne correspond pas aux attentes ou aux besoins actuels des utilisateurs, tout comme les résidents du nouveau quartier se sont plaints que les maisons construites ne correspondaient pas à ce qui leur avait été promis. Cette approche a tendance à mettre de côté un acteur extrêmement important dans le processus de développement : l’utilisateur !

L’utilisateur final est souvent relégué au second plan, traité comme une variable après-coup plutôt qu’un élément central du processus de création. Cette approche peut mener à des produits qui répondent aux spécifications techniques, sans toutefois satisfaire les besoins réels et évolutifs des utilisateurs. Pour éviter ce piège, qui peut s’avérer fatal pour le succès d’un produit ou même la pérennité d’une compagnie, il est crucial de maintenir une proximité constante avec le client tout au long du cycle de développement.

En impliquant activement le client, en recueillant ses retours d’expérience et en adaptant le produit en conséquence, l’équipe de développement peut s’assurer que le produit développé est véritablement aligné avec les attentes et les exigences de ceux qui l’utilisent au quotidien.

Travail d’équipe

Pour mener à bien un projet, la collaboration entre toutes les parties prenantes est indispensable. Une communication efficace et régulière entre l’équipe de développement, les Product Owners, les testeurs et les designers est la pierre angulaire d’une équipe performante. Dans sa présentation Async Code Reviews Are Killing Your Company’s Throughput, Dragan Stepanović met en lumière les inconvénients des revues de code asynchrones, qui peuvent entraver la productivité et la dynamique d’équipe. En privilégiant des interactions en temps réel, comme le pair programming ou les revues de code en tandem, les équipes peuvent renforcer leur cohésion et leur réactivité. Ces pratiques de collaboration directe favorisent non seulement une meilleure qualité de produit grâce à des rétroactions immédiates, mais elles contribuent également à créer un environnement de travail plus engagé et satisfaisant pour l’ensemble des membres de l’équipe.

Conception versus fabrication

En novembre dernier, lors de l’Agile Tour Montréal, j’ai assisté à une conférence donnée par Félix-Antoine Bourbonnais intitulée : « Conçu au Québec, fabriqué en Allemagne : la programmation, c’est de la conception ». Il a souligné l’importance de deux étapes fondamentales dans le développement d’un produit, qu’il soit physique ou logiciel : la conception et la fabrication.

La principale différence entre la conception et la fabrication réside dans les rôles qu’elles jouent dans le développement de produit. La conception est une étape profondément humaine et créative, où les concepteurs ont la liberté d’explorer, d’innover et de donner libre cours à leur imagination. C’est un processus itératif et souvent non linéaire, où les idées sont générées, testées et affinées. Cette phase est essentielle pour définir l’essence et les fonctionnalités du produit, en tenant compte des besoins et des désirs des utilisateurs. 

En revanche, la fabrication est une étape mécanisée et précise, dominée par des machines et des processus automatisés. Elle nécessite une grande rigueur et suit des spécifications détaillées pour garantir la qualité et la conformité du produit final. La fabrication est caractérisée par sa répétabilité et son efficacité, visant à produire en masse des articles identiques avec une marge d’erreur minimale.

Et l’informatique dans tout ça ?

La conception peut être comparée à la phase de programmation, où l’équipe de développement utilise sa créativité et son expertise technique pour écrire le code et créer des logiciels innovants. Cette étape est flexible et permet une grande liberté dans la résolution de problèmes et la mise en œuvre de nouvelles idées. L’utilisateur final doit faire partie de l’étape de conception en informatique, car c’est lui qui interagit avec le logiciel au quotidien. Sa participation permet d’assurer que les fonctionnalités développées répondent précisément à ses besoins et améliorent son expérience ainsi que d’éviter les erreurs de conception pouvant nuire à l’efficacité ou à l’adoption du produit.

La fabrication, quant à elle, est semblable au processus de compilation, où le code source est transformé en un programme exécutable par une machine. La compilation est un processus systématique et automatisé qui doit suivre des règles strictes pour assurer que le logiciel fonctionne correctement avec le matériel cible. Dans cette optique, l’adoption de techniques telles que le déploiement automatique ou continu incite les développeurs et les développeuses à automatiser davantage la phase de fabrication. Ces approches encouragent la mise en place de chaînes d’intégration et de livraison automatisées qui permettent non seulement une mise en production plus fluide et régulière, mais aussi une standardisation des processus de déploiement. Cela limite les erreurs humaines, améliore la cohérence des environnements de production et accélère le cycle de vie du développement logiciel, garantissant ainsi une fabrication logicielle plus robuste et plus fiable.

Conclusion

L’essence du développement logiciel réside dans sa capacité à allier technicité et humanité. La satisfaction du client doit être au cœur de chaque étape ; de la conception, où l’imagination et l’innovation prennent vie, à la fabrication, où la précision et l’automatisation assurent la qualité et la fiabilité. La collaboration étroite entre toutes les parties prenantes et l’implication active de l’utilisateur final sont des piliers pour la création de logiciels durables et pertinents. À l’aide d’une approche agile et d’une communication fluide, nous pouvons éviter les pièges des malentendus et des attentes non satisfaites. Cela nous permet ainsi de livrer des produits logiciels qui reflètent véritablement les besoins et les aspirations de ceux à qui ils sont destinés.