Mickaël’s Weblog

Le développement logiciel d’un module peux se faire de plusieurs façons différentes. On peut le coder en une fois en prenant en compte tous les cas d’utilisation (connus et potentiels). On peut également en faire une première version en prenant en compte tous les cas d’utilisation connus tout en sachant qu’il faudra la réécrire pour l’étendre. A l’extrême, on peut coder à minima, en ce disant que le design n’est pas important et au final revenir 1000 fois dessus pour coder…tout ce qui manque.

D’où la question: “Quelle est la meilleure ?”

Première remarque: il n’y a pas de méthode “meilleure”, mais elles ont toutes des avantages et inconvénients propres différents, à vous de choisir en fonction de vos objectifs et des moyens à votre disposition. Ce qui est sur: c’est qu’il n’y a pas de (recette) miracle. Au bout du compte, une fonctionnalité a un coup lié à sa complexité/difficulté, et donc requiert un investissement a peu près identique quelque soit la méthode…mais un retour sur investissement différent suivant vos objectifs.

Prenons le cas du codage en 1 fois, plus communément appelé : “usine a gaz”.  L’idée est de confier ce module a un seul développeur qui part “en sous marin” pour coder le module afin de répondre aux besoins connus…mais aussi suffisamment extensible pour intégrer des nouveaux besoins très rapidement. Pour caricaturer, c’est la tendance naturelle d’un développeur, car cela lui permet de ne se consacrer que à cette tâche, il travail seul, décide seul, doit faire appel a ses connaissances d’expert (pour l’extensibilité), et enfin démontre que le management lui fait confiance…c’est gratifiant. Quand on a un développeur capable d’anticiper les besoins futures, de coder de manière efficace et propre, c’est certainement la “méthode” qui permet d’avoir le module complet le plus rapidement…sauf que ça c’est la théorie, et que cela se passe autrement dans 95% des cas. En effet, il y a souvent un nombre important de bugs, l’extensibilité n’est souvent pas au rendez-vous et du coup le moindre besoin supplémentaire demande un “refactoring” important et pas si simple que ça. L’autre effet indésirable, est le non partage de la connaissance du code…et c’est souvent du code assez complexe (d’où le terme ”usine a gaz”). Autre inconvénient majeur: il faut attendre en général d’être aux 9/10 de l’implémentation pour voir quelque chose tourner/fonctionner.

Mon responsable R&D d’il y a 10 ans disait toujours: “de toute manière c’est toujours la 3ième implémentation la bonne…il faut donc toujours tout refaire au moins 2 fois”. On commence a sortir de l’usine a gaz, car les ambitions de la première implémentation sont plus raisonnable et se cantonne aux besoins connus (enfin 90%). De toute manière, y aura la seconde implémentation pour corriger ce qui ne va pas et intégrer les nouveau besoins! Autre avantages: un retour sur investissement plus rapide…même si l’implémentation est moins complète, moins de complexité, et donc aussi en général moins de bugs. Au bout du compte, on va avoir [sur une base de 3 implémentations] investi autant: moins de temps à définir les spécifications, plus en dev, moins en bug fix, moins en QA. Si on a un staff QA plus réduit, on y gagne. On peut mettre sur le marcher ce module plus tôt. Et si on fait faire le développement a différent développeurs, on a un meilleur partage de la connaissance (et on a perdu en efficacité car il faut former chaque développeur).

Poussons le raisonnement du nombre d’implémentations à l’extrême : 1000! On réduit a minima les spécifications, on ne se concentre que sur le plus important (1/1000ième de la fonctionnalité), et on n’anticipe aucun besoins non connu. On ne peut cependant pas se permettre de faire les 1000 itérations/implémentations les unes derrière les autres, avec phase de spécification, implémentation, test, documentation, transfert de connaissance…il faut une extrême fluidité dans la communication associé à une polyvalence de chaque développeur (et oui, il va faire le dev, la QA, la doc et le design).

Au bout du compte, quel est l’investissement total suivant chaque méthode ? Définissons d’abord ce qu’est l’investissement total. C’est l’ensemble des ressources qu’il aura fallut mettre en place pour avoir un module qui fonctionne correctement (les clients en sont satisfaits), et donc le code ne bouge quasiment plus (peu de bugs).

La première méthode apparait comme la plus rentable, mais le risque (devoir refaire une autre implémentation) est très élevé (et là cette solution devient la moins rentable), et souvent la qualité n’est pas au rendez-vous. Deplus, seul un développeur connait le code…ce qui peut poser d’énormes problème de maintenance.

1000 intérations apparait comme la méthode la moins rentable, mais la capacité d’adaptation a des nouveaux besoins est excellente et on délivre bien plus rapidement…et ça, c’est de l’argent. Cela demande cependant d’intégrer redesign et tests a chaque itération.

C’est donc à vous de choisir suivant les ressources, le contexte, le objectifs.

Il y a cependant une pratique dont j’ai pu observer qu’elle ne fonctionne pas quelque soit la méthode. Le fond du problème est la gestion de la dette technique qui mène au “refactoring”. La première méthode consiste a réduire à 0 cette dette pour éviter tout refactoring. Le problème est que le risque est très élever de ne pas y arriver, et on s’en aperçoit souvent trop tard. Augmenter le nombre d’itération consiste à admettre cette dette technique et de la compenser par des itérations/implémentations supplémentaires. Le piège est de consacrer ces itérations uniquement à la dette. Le résultat est d’avoir des itérations sans valeur ajoutée, et du coup une incompréhension du product management quand a leur utilité. La “bonne” pratique consiste a apporter de la valeur ajouter à chaque itération, tout en remboursant une partie de la dette.

Au final, ayez une stratégie de remboursement de dette qui correspond a vos objectifs et à vos resources.

Les méthodes agiles assurent-elles le succès d’un projet de développement?
La réponse est clairement non. Ayant pratiqué plusieurs méthodologies (agiles…ou pas), il m’apparait clairement que c’est avant tout l’existence d’une méthode et son adhésion qui est la condition nécessaire, mais pas suffisante. Ne pas avoir mis en place de méthode est la garantie d’un désastre, et la responsabilité en incombe au management. Il faut de plus que l’ensemble des acteurs y adhèrent: équipe et client. Ce n’est pas chose facile, mais le management n’est pas une chose facile. Il faut enfin que le déroulement du projet ce fasse en toute transparence vis-à-vis de l’équipe et du client.

Mettre en place une méthode efficacement n’est pas aisée. Dans le cadre d’une SSII par exemple, les méthodes agiles sont souvent opposées aux contrats de type forfait. Il est vrai qu’au prime abord cela peut sembler vrai, mais c’est a mon avis juste une question d’approche, et au final les SSII travaillent de plus en plus en mode Agile. Sur ce sujet, Pascal Van Cauwenberghe a écrit 2 excellents articles à ce sujet: Succeding with Agil Fixed Price projects (part 1 et part 2). Les plus gros obstacles sont souvent la méconnaissance ou les fausses évidences.

Le plus important est la mise en place d’une méthodologie, ensuite il faut considérer tous les paramètres du projet dont le contexte d’éxécution (taille d’équipe, durée du projets, objectifs, priorités..etc), et choisir la méthode la plus appropriée, la modifier suivant les besoins et l’exécuter en toute transparence
.

…et notamment dans les secteurs du logiciel et des R&D. La france s’en sort plutôt bien au niveau de la productivité par heure travaillée. Dommage que ces statistiques ne donnent aucun chiffre sur les pays “off-shore” dans le développement logiciel : chine, inde, roumanie…etc.

Je suis tombé sur ce billet du Dr Goulu sur la motivation dans le monde du travail. Il s’appuie sur la présentation faite par Daniel Pink sur la science de la motivation.

Ayant travaillé dans différents environnements (de la startup à la très grande entreprise), j’ai pu clairement constater que la motivation était clé. Je suis persuadé qu’on peut facilement doublée la productivité quand une équipe est très motivée. On peut aussi la diviser par 10 si elle est démotivée. Et surtout, dans un domaine comme le développement logiciel où les solutions ne sont jamais idéales et demandes beaucoup de créativité, une équipe motivée trouvera des solutions souvent bien meilleur.

Daniel Pink plaide que la science a démontré bien des fois que les “bonus” fonctionnent bien pour des tâches plutôt mécaniques ou dont la solution est simple a trouver. Dans les autres cas, les “bonus” dégradent les performances. Cela ne veut pas dire qu’il faut supprimer les “bonus” en développement logiciel (qui demande créativité sur des problèmes complexes et toujours différents), mais que cela ne va certainement pas augmenter la productivité et la motivation. En revanche cela permet d’éviter que vos têtes pensantes n’aillent penser dans une autre entreprise.

La deuxième partie de la vidéo parle de l’autonomie et des expériences prouvant que l’autonomie est source de créativité. Ils parle des 20% de temps que Google accorde a ses employé pour faire ce qu’ils veulent et que au final, la moitié des projets les plus connu de Google…viennent de ces 20%.

J’ai pu constater que la productivité est clairement lié a la motivation, et que l’autonomie est une grande source de motivation. Il passe un peu vite sur les “objectifs” qui a mon sens sont aussi très important. Car même si une entreprise laisse ses employés faire ce qu’ils veulent 20% de leur temps, il est important que les 80 autres pourcents permettent d’atteindre des objectif. Je trouve que les méthodes agiles de développement logiciel sont un excellent moyen d’y arrivé par la responsabilisation des membres de l’équipe et non par un manager qui décide tout, distribue les tâches et centralise la communication.

Bref, une vidéo a voir absolument (anglais, sous-titres français).

In his post “We’re not resources”, Mark Gregory Turansky is writing:

Talent matters.

Winning organizations build winning teams, they don’t schedule resources and they don’t break up a winning team. They pay top dollar for top talent knowing that it’s entirely talent that makes a winning team.

I had the opportunity to see this during my (short) carrier. Large team tends to force this “resource” direction (large company also obviously). Having a small team (lets say 5 to 7) of talent and senior can produce far more than a “regular” team of 30.

In the case of a large team, I prefer split into small teams (preferably using the architecture components as a guidance … yes I know, some agile folks will not agree) with leaders having a good leadership and management skills to do people management, not resource management.

Where I disagree from Mark’s point of view is the direct relation he emphasys between talent and dollars. Sure, talent people are more expensive, but dollars is not a way to get people efficient, simply a way to get them in. This article form Mary Poppendiek highlights very well this point.

Another skill that makes the difference  (in addition to talent) is sense of responsibilities (I’m back to an agile point of view ). The best talented developer will not help that much if he (or she) cares only about his code, do not try to understand code/work of the others, do not try to help level 3 support even if it’s a totally unkown area of the software for him/her.

Having teams sharing the responsibility of what they deliver, composed of talent, and leaded by a people manager (vs resource manager) is one of the best cocktail to quickly create creative softwares.