MENER SON EQUIPE

Après plus de 5 ans de pratique des démarches agiles et lean, ma pratique du rôle de scrummaster a largement évoluée pour s'éloigner de sa définition initiale.

A une phase tournante de mon engagement sur mon projet actuel, j'en profite pour faire un point sur le rôle initial de scrummaster et ce qu'il est devenu après plus d'une vingtaine d'itérations mensuelles. Cette évolution me semble si significative que le rôle strict de scrummaster me parait désormais sous-optimal.

SCRUMMASTER

Selon les fondateurs de Scrum, le scrummaster se doit de

• retirer les obstacles qui gênent l'équipe dans sa poursuite des objectifs d'itération;
• agir comme un tampon entre l'équipe et les influences perturbatrices;
• se mobiliser pour que la démarche Scrum soit mise en pratique conformément à sa définition;
• garder l'équipe concentrée sur les objectifs d'itération et les tâches en cours;

GESTIONNAIRE

Le rôle de scrummaster est bien loin du gestionnaire d'équipe (alias manager) qui pratique souvent un pilotage solitaire et analytique sur la base de métriques et d'indicateurs. Le manager gère des ressources sans forcement avoir recours à la pratique du leadership.

MENEUR

Le rôle de scrummaster s'apparente d'avantage à celui du meneur d'équipe (alias leader) même s'il n'en prend pas toute la force. En effet, le scrummaster est souvent présenté comme un facilitateur ou un animateur recherchant à tout prix le consensus au sein du projet. Ce rôle mou et peu engagé à mon avis n'est pas encore celui du meneur d'équipe.

Le meneur d'équipe mène son équipe (pléonasme).

S'ENGAGER

Mener son équipe c'est s'engager avec elle dans la poursuite de ses objectifs. Que cela soit bien clair: le leader échoue si l'équipe échoue. Le leader est bien dans la même barque que ses équipiers. Le leader doit donc contribuer à la poursuite des objectifs de son équipe. Il doit mettre ses compétences et son action au service de la réussite des équipiers.

Quelles sont ces compétences et cette action?

MONTRER L'EXEMPLE

Le meneur d'équipe doit montrer l'exemple. Il ne s'agit pas de dire ce qu'il faut faire, mais de montrer ce qu'il faut faire. Pour cela, il faut faire! On y revient encore: le leader est dans l'action. Il doit pratiquer pour montrer la voie à suivre. (Que penser du scrummaster facilitateur et non développeur?)

PRATIQUER

Un leader ne peut exiger de ses équipiers un comportement que lui-même n'a pas. Si le leader exige de ses équipiers que leur code soit testé, sans duplication, explicite et le plus court possible, alors lui-même se doit d'écrire du code testé, sans duplication, explicite et le plus court possible (j'en imagine certains qui sourient et d'autres qui grincent des dents). C'est à ce prix que le leader sera légitime et que ses équipiers accepteront de mettre en pratique les standards.

Ainsi, mener l'équipe c'est ouvrir la voie pour que l'équipe la prenne à sa suite.

ENSEIGNER

Il ne suffit pas au leader de pratiquer pour montrer la voie, puis d'exiger de ses équipiers qu'ils suivent cette voie. Le leader doit absolument enseigner le métier. Il doit enseigner

• la pratique en expliquant comment nous travaillons dans l'équipe (quels sont les standards?).
• la philosophie en expliquant pourquoi nous travaillons de cette manière dans l'équipe. L'enseignement de la philosophie est primordial car nous pratiquons de manière d'autant plus efficace que nous comprenons pourquoi nous pratiquons ainsi. L'objectif est de faire adhérer aux pratiques. Aussi (et surtout!), comprendre pourquoi est un pré-requis pour améliorer les pratiques.

Le pair-programming est une manière très pertinente d'organiser l'enseignement. Dans un tel cadre, le leader doit binômer et il doit s'assurer que les anciens binôment.

Petit rappel pour le plaisir: Pour enseigner il faut pratiquer.

FAIRE REUSSIR

L'objectif du meneur est de faire réussir ses équipiers. Une manière d'y parvenir est de mener les équipiers à l'autonomie, de les pousser à se perfectionner et à donner du sens à leur travail.

MENER A L'AUTONOMIE

L'autonomie a un impact positif sur la motivation, l'efficacité et l'engagement. Le leader se doit de pousser les équipiers à devenir autonomes.

Par exemple, il s'agit de ne pas de donner la solution à un problème posé, mais de mettre sur la voie, d'accorder du temps pour traiter le problème, puis de s'assurer que le problème est en cours de résolution.

Le meneur d'équipe doit pousser ses équipiers à le remplacer. Ainsi, les plus anciens participent à former les plus jeunes; chacun pilote un chantier de résolution de problème (et donc d'amélioration!); les daily-stand-up-meetings, planifications et rétrospectives peuvent être préparés et animés de manière tournante, etc.

Il est important d'organiser le travail pour que les équipiers puissent décider par eux-même de leurs activités. Les backlogs (priorisés par définition!), les faits techniques priorisés, les kanbans et taskboards, les standards et modes opératoires, les indicateurs visuels de pilotage, les andons sont des outils d'aide à la décision dont la bonne utilisation engendre l'autonomie.

En matière d'autonomie, les objectifs du leader peuvent être les suivants:

• s'il s'absente, l'équipe assure l'intérim;
• s'il quitte l'équipe, un équipier peut prendre son rôle;
• les équipiers identifient les tâches à mener;
• un équipier motivé peut mener une autre équipe.

CONDUIRE LE PERFECTIONNEMENT

Le leader doit pousser ses équipiers à se perfectionner. Des équipiers performants résolvent les problèmes et établissent des standards efficaces qui permettent de bien développer de bons produits. Le perfectionnement est également une grande source de motivation personnelle.

La mise en situation, le pair-programming et la résolution de problèmes sont des outils efficaces pour aider les équipiers à se perfectionner. Le leader peut utiliser ces moyens pour entretenir un rythme de perfectionnement.

DONNER DU SENS

Le leader doit expliquer aux équipiers quels sont les bénéfices pour l'entreprise, pour les clients, pour leurs collègues et pour eux-mêmes de leur travail et de leur manière de travailler. La conscience des bénéfices de son travail impact positivement la motivation et l'engagement.

CONDUIRE LA RESOLUTION DES PROBLEMES

Le scrummaster doit retirer les obstacles qui gênent l'équipe dans la poursuite de ses objectifs. En résolvant lui-même ces problèmes, le scrummaster ne mène pas ses équipiers à l'autonomie et il ne conduit pas leur perfectionnement. Lui seul développera ses compétences.

C'est pourquoi le meneur d'équipe doit conduire la résolution des problèmes. Il s'agit

• d'enseigner une démarche structurée de résolution de problème;
• d'expliquer en quoi cette pratique développe les compétences des équipiers;
• d'expliquer en quoi cette pratique améliore la performance de l'entreprise; puis
• d'allouer les chantiers dans l'équipe (ou de s'assurer que les équipiers s'allouent des problèmes à résoudre); et
• d'animer ou suivre l'avancement des chantiers de résolution de problèmes.

Pour montrer l'exemple et pour développer ses propres compétences, le leader se doit de mener lui-même des chantiers de résolution de problèmes.

La pratique en continue de la résolution de problèmes est un outil très performant pour développer les compétences. En effet, elle exige des équipiers qu'ils comprennent en profondeur les problèmes (avec symptômes, impacts et causes racines) et qu'ils identifient et mettent en place des contremesures efficaces.

AMELIORER LES PRATIQUES

La pratique en continue de la résolution de problème est également un outil très performant pour améliorer les pratiques (ou standards) de l'entreprise. En effet, ces chantiers font évoluer les standards pour intégrer les contremesures identifées.

Donc, là encore, le leader doit conduire la résolution de problèmes. Il doit tout particulièrement s'assurer que les équipiers enrichissent les standards avec les enseignements de leur chantiers.

RECHERCHER LE CONSENSUS

Bien sur, le meneur d'équipe doit en priorité rechercher le consensus au sein de l'équipe. L'adhésion aux décisions sera d'autant plus aisée.

Par contre, par moment, le consensus ne sera pas obtenu et c'est normal. Si je finançais mon projet avec mon argent propre, je ne laisserai pas les experts et les anciens ramer pour obtenir un consensus alors que leur expérience leur révèle la solution. Le prix d'un expert et d'un ancien est le prix de son expérience. Il se doit d'utiliser son expérience pour empêcher les plus novices de commettre les mêmes erreurs. Certes, nous apprenons par nos erreurs, mais si nous pouvions éviter d'en faire trop, ce serait tout même préférable pour le projet. Dans un tel cas de figure, une solution issue de l'expérience et imposée sans consensus doit être expliquée afin de rechercher au mieux l'adhésion des équipiers.

ET RECURSIVEMENT

Tout ce qui a été dit pour le meneur d'équipe me semble également valable pour le meneur de l'équipe des meneurs d'équipes. Et ainsi de suite ...

A méditer!

RÉSOUDRE LES PROBLÈMES UN A UN POUR AMÉLIORER LES PRATIQUES

Lorsque nous abordions le Lean pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:

• la définition de la valeur,
• la cartographie du flux de valeur,
• le flux continu,
• le flux tiré et
• le perfectionnement.

Cette approche, très centrée sur le process, nous a amené à reprendre des outils issus du Lean qui ont été efficaces chez d'autres et à les mettre en oeuvre chez nous: value stream mapping, kanban, just in time, autonomation, jidoka, andon, etc ...

Cette démarche s'est greffée sur notre déjà longue pratique du développement logiciel agile, centrée sur l'eXtreme-Programming (d'abord!) et Scrum (pour la forme). Naturellement, le terrain de rencontre de ces deux démarches a été le Lean Software Development.

Nous sommes fiers d'avoir obtenus de très bons résultats sur de gros projets, dans des domaines à priori peu réceptifs à ces pratiques et d'avoir été félicités par nos clients pour la tenue des jalons, la qualité des produits et notre transparence.

Pourtant nous traînons encore des problèmes de longue date (en terme d'années!) qui nous ralentissent, réduisent notre performance et attaquent notre moral.

Comment cela est-il possible alors que nous pratiquons un développement logiciel agile et Lean qui a lentement évolué pour s'adapter à notre domaine? Sommes-nous réellement sur la bonne voie?

Des aides extérieures et des recherches nous ont permis de prendre conscience que nous pratiquions un Lean scolaire. Cette pratique consiste à enrichir notre démarche issue de l'eXtreme-Programming et de Scrum avec des outils du Lean qui ont fait leurs preuves, sans pour autant assimiler le coeur du Lean.

Depuis, nous essayons d'aborder le Lean de la manière suivante:

• visualiser le production pour révéler les problèmes,
• réagir immédiatement,
• puis résoudre les problèmes un à un
• pour améliorer les pratiques.

Nos précédentes initiatives nous ont déjà conduit à "visualiser la production pour révéler les problèmes et réagir immédiatement". Nous continuons à peaufiner cette pratique. Par contre, nous essayons désormais de sérieusement nous attaquer au pan du Lean que nous avons trop négligé, c'est à dire résoudre les problèmes un à un pour améliorer les pratiques.

Attention, il ne s'agit pas là de la rétrospective d'itération ou de la collecte des obstacles par le ScrumMaster lors des réunions quotidiennes dans l'objectif d'aplanir la route devant l'équipe!

Il s'agit d'une discipline de tous les jours, pour tous, à tous les niveaux, qui consiste à avoir toujours un problème à résoudre. Ce problème doit être analysé, décortiqué et compris pour être éventuellement résolu si le retour sur investissement le justifie.

Pour les problèmes coriaces, la démarche est structurée. Par exemple pour nous, cela consiste à suivre les étapes suivantes:

• décrire le problème tel qu'on le perçoit;
• identifier et quantifier les impacts du problème pour notre client et pour notre organisation;
• décrire comment les choses devraient se dérouler, puis décrire comment elles se déroulent réellement. Décrire l'écart entre les deux.
• identifier les causes racines du problème et pondérer leur impact sur le problème;
• pour chaque cause racine, identifier des solutions candidates qui l'élimineraient;
• classifier les solutions candidates en fonction de leur coût de mise en oeuvre et de leur impact sur la résolution du problème;
• mettre en oeuvre les solutions par retour sur investissement décroissant jusqu'à ce que le retour sur investissement n'en vaille plus la peine;
• si elles ont été efficaces, standardiser les nouvelles pratiques mise en oeuvre;
• communiquer les leçons.

Cette discipline individuelle et d'équipe nous aide en ce moment à résoudre (entre autres) un problème que nous traînons depuis un an. Pour la première fois depuis longtemps, nous constatons une réelle amélioration du phénomène et ce pour un très faible investissement. Ceci nous ouvre de belles perspectives d'amélioration!

Le plus motivant à mon avis est que cette discipline est une école d'experts. En effet, puisqu'elle exige de passer par une profonde et complète compréhension des problèmes, elle pousse les acteurs de la démarche à développer leur expertise. Même si la résolution du problème n'est pas déclenchée par manque de retour sur investissement, les acteurs sauront ne pas commettre la même erreur à la prochaine occasion. Puisque tous sont concernés par cette discipline, tous sont amenés à développer leurs compétences.

Finalement, il se s'agit pas plus d'appliquer "un bon processus qui fait un bon produit" mais plutôt "d'appliquer une démarche qui développe des experts qui sauront mettre au point un bon processus qui fait un bon produit" (vous me suivez toujours?). L'effet premier recherché est l'implication et le développement des compétences. L'effet secondaire est l'amélioration des pratiques.

Avec cette nouvelle perspective, nous essayons de passer d'une démarche d'amélioration discontinue faite d'initiatives personnelles basées sur des intuitions à une démarche collective d'amélioration continue rigoureuse et disciplinée.

Cette discipline clarifie également le rôle des "leaders". Pour eux, il s'agit d'enseigner la démarche à leur équipe et à "challenger" leurs équipiers pour qu'ils analysent et résolvent leurs problèmes. Le "leader" est lui-même "challengé" par son leader/coach/manager/mentor, et ainsi de suite ...

Un prochain billet sera d'ailleurs consacré au rôle de leader, tel que décrit par Scrum, par l'eXtreme-Programming, par le Lean et tel que nous le pratiquons.

Merci encore pour l'aide extérieure!

UN BON CODE ...

Dans l'ordre, un bon code

1. passe ses tests avec succès;
2. ne peut être mal utilisé;
3. ne contient pas de redondance;
4. exprime clairement l'intention;
5. est aussi court que possible.

Paraphrase ...
A peu de choses près, les points 1, 3, 4 et 5 sont une citation de Kent Beck, créateur de l'eXtreme-Programming. Praticien de la programmation par contrat, j'y ai rajouté le point 2. (Qu'est-ce que je ne ferai pas pour citer les travaux de Kent Beck et Bertrand Meyer dans le même billet :o)

... néanmoins utile
J'ai la chance de relire beaucoup de code, de binommer avec de nombreux développeurs et d'enseigner. Dans le cadre de ces activités, cette citation en cinq points m'est très utile. Je m'en sers beaucoup et je la cite souvent. Je dois sûrement passer pour un extrémiste dogmatique et têtu ... (Après tout dans un équipe, il est bon d'atteindre un certain ratio développeur extrémiste / développeur laxiste)
N'empêche qu'il y a beaucoup de sagesse empirique dans cette citation. Entre autre, l'ordre des critères est très important.

1. Tu testeras
Les tests occupent le haut du podium. Un code qui n'est pas testé n'a pas de valeur. C'est du code sans garantie. Toute ligne d'instruction doit être couverte par un test. Cela se vérifie très bien avec les outils d'analyse de la couverture structurelle.

2. Tu détromperas
Un code qui ne peut être mal utilisé est un code détrompé. Il contribue à la gestion préventive des défauts dans l'application. La programmation par contrat est une excellente pratique pour détromper le code. Quitte à parler de programmation par contrat, il serait plus exacte de dire: "Un bon code garantie sa postcondition si sa précondition est garantie par son appelant". Pour en savoir plus sur cette pratique rare mais vraiment efficace, vous pouvez lire un précédant billet sur ce sujet.

3. Tu ne te répèteras pas
La duplication est source de défauts multiples et de reprises multiples. Elle nuit à la clarté des intentions. Admettons que j'"hérite" d'un code non testé. Sans hésitation, je préfère consacrer du temps à le tester qu'à en éliminer les redondances. (En fait, j'éliminerai les redondances dès que les tests passeront :o)

4. Tu seras clair et explicite
Le code est bien plus souvent lu qu'écrit - y compris par son auteur! D'ailleurs, l'écrivain est avant tout son propre lecteur. Autant faciliter la vie de tous ces relecteurs. Comme pour le point précédant, je préfère tester que renommer et découper. (Pareil, je renommerai et découperai dès que les tests passeront :o)

5. Tu seras bref
La brièveté du code arrive en dernier car elle peut entrer en conflit avec les points 1, 3 et 4. Dans un tel cas de figure, la brièveté n'est pas prioritaire.
Pour rendre un code testable, il faut souvent créer des interfaces pour injecter des dépendances à la construction des objets. Cela augmente la taille du code. Le test amène également à découper en petites classes et il y a un talon déclaratif à payer pour cette modularité.
Un code sans duplication peut amener à créer une opération pour 2 lignes dupliquées. Au total, en comptant le surcroit de déclaration, cette pratique peut augmenter le nombre de lignes. D'ailleurs, avez vous remarqué que les exemples de code remanié sont TOUJOURS plus longs que leur code d'origine? (voir Clean Code)
Pour rendre un code plus explicite, nous sommes amené à homogénéiser le niveau d'abstraction dans le code des opérations. Pour cela, nous encapsulons le code de niveau d'abstraction inférieur dans une opération. Là encore, nous payons une taxe pour la déclaration des opérations.

Et le code des tests?
Ce codex en 5 règles s'applique au code, mais aussi aux tests, car les tests sont du code. On peut penser qu'il ne faut pas tester les tests sinon on n'en finit jamais. Pourtant, la pratique du Test Driven Developpment issue de l'eXtreme-Programming intègre par construction le test du test!
En effet, lorsque nous commençons par écrire un test qui échoue, puis nous modifions le code jusqu'à ce que le test passe avec succès, nous vérifions la justesse du test. Ce tte démarche en 2 étapes est le test du test.

Un de plus (violation du critère 3!)
Désolé, ceci était le 1379ème billet visant à définir un bon code. Plusieurs livres y consacrent leurs pages. C'est un peu comme les chaînes de chance/malchance. Lorsqu'on lit un de ces billets, on se doit d'en écrire un à son tour ...

INTEGRATION CONTINUE + ANDON = JIDOKA

Nous avons configuré notre outil d'intégration continue pour qu'il envoie un mail d'alerte à chaque équipier lorsqu'un build automatisé (compilation et tests) échoue. Notre priorité est alors de revenir au plus tôt à une situation nominale caractérisée par un build réussi.

Mais voilà, notre attention n'est pas concentrée sur notre messagerie. Nous avons beau être nombreux dans l'équipe, certains builds échoués restent non détectés plusieurs heures. Il arrive également qu'un build échoué soit détecté, mais qu'il ne soit pas corrigé dans l'heure. Alors les équipiers s'inquiètent car ils ne sont pas certains que quelqu'un soit en train de résoudre le problème.

De sa propre initiative, l'équipe a décidé de se mettre la pression. Elle a réfléchi à la solution la plus simple pour mettre en place un andon. Il s'agit d'un signal lumineux visible de tous qui signale une anomalie.

Un équipier a alors acheté un i-buddy pour le poste d'intégration continue. Lorsque le build incrémental et le build complet sont tous deux réussis, la tête de l' i-buddy est verte. Si un de ces deux builds échoue, la tête de l' i-buddy est rouge. Lorsqu'un build échoué est en réparation, le tête de l'i-buddy est bleue.
La loupiote est posée sur l'écran du poste d'intégration continue. Une légende explicative attachée à l'i-buddy rend l'interprétation de son signal lumineux évidente pour tous (application du 5S) .

Cette petite initiative a plusieurs avantages:

• un signal lumineux visible de tous signale clairement les problèmes de build;
• le signal lumineux rouge, visible de tous, motive les équipiers à rapidement corriger le problème détecté;
• le signae lumineux bleu rassure l'équipe sur le fait que des équipiers se chargent du problème détecté;
  
• c'est une petite pratique sympa dont l'équipe est fière. Elle soude ses membres en contribuant à son folklore.
  

Bref, intégration continue + i-buddy = jidoka

PS: Il est de bon ton se caser quelques mots en japonais comme andon et jidoka dans son billet ;o)

L'INTÉGRATION CONTINUE EST UN SYSTÈME MULTITACHE

Ce billet est consacré à une pratique de l'intégration continue et au parallèle que nous pouvons dresser entre le développement concurrent avec intégration continue et les systèmes multitâches.

3 IDÉES

• Je vais commencer par vous expliquer comment nous pratiquons une forme sécurisée de l'intégration continue.

• Ensuite, j'évoquerai un problème propre à l'intégration continue et je présenterai les solutions que nous avons mis en place pour y remédier.

• Enfin, pour illustrer mon propos je ferai un parallèle entre développement concurrent avec intégration continue et les systèmes multitâches.

INTÉGRATION SÉCURISÉE

Pour qu'un développeur de notre équipe contribue au projet en délivrant ses travaux, il utilise un script qui automatise les activités suivantes:

1. Identification des modifications: Il s'agit du "commit" ou "checkin" des fichiers modifiés de l'espace personnel de travail. Un éditeur texte est ouvert pour que le développeur justifie ses modifications.
2. Synchronisation de l'espace personnel: L'espace personnel de travail est synchronisé par rapport à la référence du code en y important les nouveautés de la référence du code.
   
3. Build et test de l'espace personnel: Le build est lancé et l'intégralité des tests xUnit sont exécutés dans l'espace personnel. Cette étape s'assure que les modifications du développeur sont compatibles de la référence du code.
4. Synchronisation de la référence: Si le build et tous les tests ont réussi, alors les modifications de l'espace personnel sont délivrées dans la référence du code.
5. Build et test de la référence: En moins d'une minute, l'outil d'intégration continue détecte la modification de la référence du code et lance un build incrémental avec rejeu de tous les tests xUnit. En général, le défaut type détecté par cette étape est un nouveau fichier source introduit dans le produit par le développeur et non géré par l'outil de gestion des versions.
   

Il s'agit d'une démarche de contribution sécurisée car le développeur ne peut délivrer des modifications incompatibles avec la référence du code. En effet, l'étape 3 interdit la livraison des modifications si le build ou le test de la version intégrée échoue. La référence du code est donc protégée contre l'injection de défauts.
Cette synchronisation est fluide car elle est automatisée et courte. Elle ne dure que de 2 à 3 minutes environ. Ainsi, chaque développeur se synchronise plusieurs fois par jour pour entretenir une intégration continue du produit en développement.

INTÉGRATION CONTINUE OU INTÉGRATION PERPÉTUELLE?

Néanmoins, il existe un point faible dans cette démarche, entre l'étape 2 et l'étape 4. Pour le comprendre, analysons le scénario suivant.
Supposons que Jacques et Paul soient deux développeurs de notre équipe. Jacques a terminé une étape de son travail et souhaite la délivrer dans la référence du code. Il lance le script d'intégration. A l'étape 2, il a récupéré chez lui les nouveautés de la référence du code. Il en est à l'étape 3: les tests sont en cours d'exécution dans son espace personnel.
Il se trouve que Paul avait commencé une synchronisation quelques minutes ou secondes avant Jacques. Alors que Jacques en est encore à l'étape 3, Paul en est déjà à l'étape 4: il délivre le résultat de son travail dans la référence du code.
Maintenant, c'est au tour de Jacques de passer à l'étape 4 et de délivrer son travail. Mais la référence du code a changée car elle a été enrichie des travaux de Paul. Donc, Jacques vient de finir son intégration et pourtant il n'est déjà plus synchronisé avec le version de référence du code! Il ne peut donc pas délivrer son travail et il doit reprendre son intégration depuis le début, à l'étape 1.

Ce petit scénario n'est pas bien grave. Jacques n'a perdu que 3 minutes. Maintenant, comprenez que notre équipe est composée de plus de 15 développeurs qui se synchronisent plusieurs fois par jour. Ce scénario de collision a donc une forte probabilité d'occurrence et l'intégration de Jacques peut durer des heures. Pour Jacques, l'intégration continue est devenu une intégration perpétuelle.

LE PROBLÈME

Nous nous sommes rendu compte qu'un seul développeur de l'équipe peut intégrer à la fois. L'intégrateur doit bénéficier d'un accès exclusif à la référence du code pour intégrer ses travaux sans être perturbé par les modifications d'autres développeurs. L'outil de gestion de configuration de gère pas cette exclusion mutuelle car l'intégration est composée de plusieurs commandes atomiques de gestion de versions.

GIZMO, OU L'EXCLUSION MUTUELLE EN INTÉGRATION

Depuis plusieurs projets, nous avons décidé de régler ce problème à l'aide d'une simple peluche, baptisée Gizmo par l'équipe. Pour intégrer ses travaux, un développeur doit poser cette unique peluche sur son écran. A la fin de sa synchronisation, il libère la référence du code en retirant le Gizmo de son moniteur. Ainsi, nous avons très simplement organisé l'intégration exclusive des travaux dans la référence du code.
Il se trouve que la pratique du Gizmo a deux autres bénéfices très importants expliqués en détail dans la description de nos pratiques d'équipe.

LE VERROU NUMÉRIQUE D'INTÉGRATION

La pratique du Gizmo suffit pour assurer l'exclusion mutuelle des développeurs en intégration dans le cas où l'équipe partage le même bureau. En effet, il faut visualiser où est Gizmo et pouvoir le prendre. Or, certains (rares) contributeurs à notre projet ne sont pas dans notre open-space. Nous avons alors décidé de doubler la peluche Gizmo par un verrou numérique. La séquence automatisée par le script d'intégration est donc devenue:

1. [Nouveau] Recherche du verrou. Si la référence du code est verrouillée en intégration, la séquence est interrompue et on demande au développeur d'intégrer plus tard;
2. [Nouveau] Verrouillage de la référence du code.
   
3. Identification des changements;
4. Synchronisation de l'espace personnel;
5. Build et test de l'espace personnel;
6. Synchronisation de la référnce du code (si les tests ont réussi!);
7. [Nouveau] Libération du verrou;
8. Build et test de la référence du code par l'outil d'intégration continue.
   

Le verrou est un simple fichier créé et supprimé dans la référence du code. Ce verrou numérique ne remplace pas pour autant le Gizmo en peluche. En effet, l'utilisation de la peluche présente deux autres bénéfices très intéressants (se référer à la description de nos pratiques d'équipe).

DÉVELOPPEMENT CONCURRENT AVEC INTÉGRATION CONTINUE ET SYSTÈME MULTITACHE

Pour comprendre la nécessité d'un verrou d'intégration, il suffit de faire un parallèle avec la programmation concurrente et les systèmes miltitâches.

Une équipe qui pratique le développement concurrent est un système multitâche. En effet, chaque développeur (ou binôme) est assimilable à un thread concurrent qui mène ses activités en parallèle des autres.

Si les développeurs pratiquent l'intégration continue, alors ils se partagent une ressource. Il s'agit de la référence du code. La séquence de synchronisation avec la référence (étapes 1 à 4) est donc une section critique. Un seul développeur à la fois doit la dérouler. Puisqu'il s'agit d'une section critique, il convient d'en assurer une utilisation exclusive à l'aide d'un mécanisme d'exclusion mutuelle, comme les mutex ou les sémaphores. La peluche baptisée Gizmo ou le verrou numérique sont en fait un sémaphore (à un jeton) tel qu'il en existe dans les OS temps-réel pour gérér l'exclusion mutuelle des thread dans les sections critiques.

Autrement dit:

Les développeurs sont les threads concurrents, la référence du code est la ressource partagée, la séquence d'intégration est la section critique et le verrou d'intégration est le mutex. Le développement avec intégration continue est un système multitâche.

Une fois que ce parallèle est admis, alors les règles de la programmation concurrente s'appliquent également pour l'intégration continue. En effet, le temps passé en section critique doit être aussi court que possible car une section critique est un goulet d'étranglement. La pratique de l'exclusion mutuelle en intégration créé une file d'attente d'intégration qui peut pénaliser les travaux si la durée d'intégration est longue ou si l'équipe est nombreuse.

COMMENT FONT LES AUTRES ÉQUIPES?

Je m'étonne toujours de constater que d'autres équipes (même chez nous) ne semblent pas être confrontées à ce problème. Cela n'est pas une question de taille de l'équipe car nous avons instauré cette pratique pour la première fois lors d'un projet développé à 4 développeurs organisés en 2 binômes. Ce problème me semble indissociable du développement concurrent avec intégration continue.
Alors, comment faites-vous?

LOGO EXPERIENCED EXTREME PROGRAMMER

Je ne suis pas à l'aise et cohérent avec ce logo Certified ScrumMaster. D'un côté, je trouve qu'il en jette et qu'il épate ceux qui n'ont pas suivi la formation certifiante Scrum. D'un autre côté, je sais bien qu'il n'a aucune valeur.

Pour je ne sais quelle raison idiote, je n'arrive pas à me convaincre de l'enlever de mon blog. Alors, j'ai décidé de le tempérer par un logo fait maison: celui du praticien expérimenté de l'eXtreme Programming. Ce logo est gratuit et auto-proclamé. Il n'a aucune valeur non plus. Pourtant, je l'aime bien parce que sur ce logo:

• "eXPerienced" se subsititue à "Certified";
• Le binôme se substitue au cycle quotidien et au cycle itératif;
• Un graphisme rustique, monochrome et à la main levée (la solution suffisante la plus simple) se substitue à la belle infographie en couleurs.

Si cela vous amuse, vous pouvez utiliser ce logo: il est gratuit, auto-proclamé, non signé et ne profite à personne ;o) ;o)

TOUCHE PAS A MON SCRUM!

J'écris ce billet en réaction à un test paru en ligne, intitulé Scrum But, dont les questions et réponses auraient été proposées par Jeff Sutherland. Je n'en veux pas à la personne qui a mis en ligne ce test, mais plutôt à celle qui l'a inspiré. (quel parricide! ;o)

QUESTIONS & RÉPONSES

Reprenons certaines questions et réponses qui m'ont chagriné. D'abord, il faut savoir que le score maximum de 8/8 est obtenu en répondant à la dernière réponse de chaque question.

Question 2 : Pratique des test

Pas d'Assurance Qualité (QA)
Le code est testé unitairement
Les fonctionnalités sont testées
Les fonctionnalités sont testées dès qu'elles sont finies
Le logiciel passe des tests d'acceptation
Le logiciel est déployé

Personnellement, je préfère un logiciel testé unitairement ET qui passe ses tests d'acceptation ET qui est déployé à un logiciel déployé. Il est peut-être sous-entendu qu'un logiciel déployé est aussi testé unitairement et passe aussi ses tests d'acceptation. Ceci dit, ce sous entendu est dangereux: Je connais des équipes qui périodiquement déploient "de la merde".
Si nous prenons le raccourci du sous-entendu, alors la meilleure réponse n'est qu'une interprétation de Scrum. En effet, le produit doit être potentiellement mis en production avec son incrément à la fin de chaque itération. Le déploiement systématique me semble être une interprétation dogmatique.

Question 3 : Spécifications

Pas de requirements
De lourds documents de requirements
Des user stories mal détaillées
De bons requirements
De bonnes user stories
Des spécifications Agile
De bonnes user stories couplées à des spécifications Agile si nécessaire

Les pratiques de Scrum incluent pas "De bonnes user stories couplées à des spécifications Agile si nécessaire". Il s'agit d'une bonne pratique - parmi d'autres. Là, on confond modèle et implémentation. Je connais des contextes où Scrum est appliqué avec succès et où "de bons requirements" sont absolument nécessaires à la réussite du projet.

Question 4 : Product Owner

Pas de Product Owner
Un Product Owner qui ne comprend pas Scrum
Un Product Owner qui dérange l'équipe
Un Product Owner qui n'est pas impliqué avec l'équipe
Un Product Owner avec un product backlog
Un Product Owner qui construit sa roadmap de release en se basant sur la vélocité de l'équipe
Un Product Owner qui motive l'équipe

Désolé, je vais pinailler, mais où avez-vous lu que le Product Owner doit motiver son équipe? Il me semble qu'il doit maximiser le retour sur investissement du projet. Motiver l'équipe est une manière agréable et louable d'y parvenir mais cela n'est pas l'objectif.

Question 6 : Estimation

Le Backlog de produit n'est pas estimé
Les estimations ne sont pas faites par l'équipe
Les estimations ne sont pas faites en utilisant le planning poker
Les estimations sont faites par l'équipe en utilisant le planning poker
L'erreur sur les estimations est <>

Il me semble que le planning poker est une bonne pratique d'estimation - sans être la meilleure. Pour moi, la meilleure pratique d'estimation est la plus adaptée au contexte du projet. De plus, le planning poker n'est pas une pratique Scrum. Il s'agit d'une bonne pratique compatible avec Scrum. Là encore, on confond modèle et implémentation.

Question 8 : Dérangement de l'équipe

Le manager ou le chef de projet dérange l'équipe
Le Product Owner dérange l'équipe
Le manager, chef de projet ou chef d'équipe assigne les tâches
Présence de chefs de projet en plus des rôles Scrum
Personne ne dérange l'équipe, uniquement des rôles Scrum

Les rôles Scrum sont très pertinents mais affirmer que seuls le PO et le SM peuvent "déranger" l'équipe me semble dogmatique. D'autres rôles peuvent apparaitre dans certains contextes.

EN CONCLUSION

En synthèse, il me semble que ce questionnaire confond modèle et implémentation. Je regrette que la note maximale soit obtenue par conformité à l'implémentation suggérée dans les réponses et non par conformité au modèle. Je rigole doucement, car c'est l'excellent argument mis en avant par le SEI pour défendre le CMMi. De plus, je peux affirmer que l'application des pratiques suggérées peut faire échouer certains projets!

Aussi, cela me dérange que le questionnaire soit sanctionné par une note - comme une évaluation ou une certification. Cela me rappelle l'autre modèle souvent confondu avec des implémentations ;o)

Bref, personnellement, je préfère encore le test Nokia. Il teste la conformité de votre implémentation de Scrum par rapport au modèle et non par rapport à une implémentation suggérée. Relisez-le, vous constaterez que les questions ont un niveau d'abstraction supérieur. Aussi, le test Nokia ne sanctionne pas par une note. Il ne vous permet que de réfléchir à votre implémentation de Scrum. N'est-ce pas l'essentiel?

Ces deux derniers jours, le test Scrum But et le site suivant m'ont tout deux troublé. Attention à la dérive de l'évaluation et de la certification! Ai-je bien fait de mettre le logo Certified ScrumMaster sur mon blog? Scrum saura t-il rester humble? Je me considère praticien de Scrum et pourtant je ne me reconnais pas dans ce test.
Je suis sûr qu'une collègue me dira: "Bôf, c'est pas grave ..."

AGILE, LEAN ET LOGICIEL CRITIQUE

C'était osé de croiser trois domaines tels que l'agilité et le Lean, le logiciel critique et le logiciel libre (d'ailleurs, cela m'a permis de comprendre la symbolique du logo du projet Open-DO).
Ce mélange est bien à l'image d'AdaCore qui a organisé cet évènement très réussi, baptisé The Lean, Agile Approach to High-Integrity Software.

J'ai beaucoup apprécié plusieurs choses:

DU LOGICIEL ET DES HOMMES

D'abord, je trouve cela vraiment agréable de mettre des visages sur les outils qu'on utilise, sur les lignes de code qu'on réutilise et sur les signatures des experts qui vous dépannent. Ce genre d'évènement est une des rares occasions de rencontres, de retrouvailles et d'échanges informels et enrichissants entre professionnels du même milieu, parfois même entre concurrents.

DES HOMMES ET DES IDÉES

Ensuite, j'ai vraiment ressenti qu'il y avait confrontation d'idées et divergences d'opinions. Pour moi, l'exemple le plus frappant était l'opposition entre ceux qui privilégient la preuve formelle par analyse statique à la compilation et ceux qui privilégient la preuve expérimentale par test à l'exécution. Attention, j'insiste sur le mot privilégier, car il accorde plus d'importance à un aspect sans pour autant négliger les autres. D'ailleurs, la programmation par contrat est peut-être une pratique qui réunit les deux mouvements, puisque les assertions sont spécifiées, compilées et exercées à l'exécution par les tests.

DES IDÉES ET DES PISTES

Aussi, je ramène toujours d'une conférence au moins une idée, ou plutôt une piste à explorer. Cette fois ci c'est Roberto Di Cosmo qui me l'a soufflé lors de sa géniale présentation. J'ai retenu que pour paralléliser les travaux de nombreux développeurs, certains projets de logiciels libres adoptent une architecture modulaire inspirée de la philosophie Unix. L'architecture s'appuye sur l'utilisation de nombreux modules indépendants ayant chacun une responsabilité (forcément, on repense au Single Responsibility Principle d'Uncle Bob). Dans un premier temps, une série de modules est développée. Puis dans un deuxième temps, une fonctionnalité est développée en s'appuyant sur ce catalogue de modules. Pour un agiliste, la première phase semble être génératrice de stock.

Ceci dit, en parallèle d'une démarche itérative et incrémentale pilotée par les tests de recette des fonctionnalités les plus prioritaires, pourquoi ne pas mener également le développement de modules à une responsabilité dont on sait bien qu'on aura besoin dans l'avenir. Certes, c'est du stock, mais cela peut permettre d'augmenter la vélocité des itérations futures. Ce deuxième flux de travail, en parallèle et en avance de phase, peut par exemple être piloté par simple Kanban. Une telle organisation ne permet pas de réduire les coûts de développement mais elle permet peut être de tenir la course aux jalons. De plus, elle permet d'avancer en parallélisant sans accentuer la pression sur l'architecture. Celle-ci peut donc évoluer au fil des remaniements pour accueillir les fonctionnalités à venir qui intégreront les petits modules préalablement développés. A méditer ...

DES PISTES ET DES SOUVENIRS

Enfin, je ramène de cette rencontre un collector: Mon exemplaire de Lean Software Strategies est désormais signé par l'auteur ;o)

Merci AdaCore!

Références et liens:
Présentation du projet Open-DO par Cyrille Comar;
Compte-rendu par Laurent Morisseau;
Lean vs Agile, par Alexandre Boutin
The Lean, Agile Approach To High-Integrity Software, par Jamie Ayre

LEAN, LA VALEUR

Le premier des 5 piliers du Lean est la Valeur. Il s'agit de spécifier la valeur du point de vue du client final. Pour nous, développeurs, il s'agit le développer le bon produit.

COMMENT PROCÉDONS-NOUS?

L'Extreme-Programming recommande d'adopter une organisation de projet avec un client sur site. Malheureusement, nous ne pouvons pas pas inclure un avionneur, un pilote et un certificateur dans chacune de nos équipes. Alors, comme recommandé dans Scrum, nos équipes ont chacune un Product Owner. Il s'agit d'un expert du domaine qui représente l'avionneur et le pilote. D'autre part, un responsable qualité est affecté à chaque projet. Il est le représentant du certificateur. Ainsi, le point de vue des différents clients est pris en compte.

Le Product Owner exprime la valeur sous forme d'exigences. Il donne ses critères de satisfaction en fournissant des tests de recette à automatiser.

Le Product Owner priorise les exigences dans le Backlog Produit. Ces priorités cherchent à maximiser le retour sur investissement du client. Comme ces priorités pilotent la succession des itréations, c'est le déroulement du développement qui cherche à maximiser le retour sur investissement du client.

Lorsque les équipes sont volumineuses, elles sont redivisées en sous-équipes plus petites. Chaque sous-équipe contient son propre Product Owner. Afin de s'assurer que les priorités de chaque sous-équipe restent compatibles et respectent celles du client final, le projet est piloté par un Super Product Owner. Au delà de la découpe du produit en sous-éléments, il est le garant de la vision produit et du point de vue du client final.

Le prochain billet abordera le second pilier du Lean: le Flux de Valeur. A bientôt!

MOINS CHERS ET PLUS SURS

Aujourd'hui, Alex et moi avons rapidement traversé un labo d'intégration et de validation de logiciels critiques. Tout en discutant nous avons remarqué que:

• plusieurs opérateurs déroulaient des procédures de test à la main;

• un des opérateurs rédigeait un SMS sur son téléphone portable tout en déroulant à la main une procédure de test. Nous ne pouvons pas lui en vouloir, la procédure de test manuelle est sûrement assommante et ce n'est probablement la première fois que l'opérateur déroule cette même procédure. De plus, il ne s'agit pas d'une exécution de test comptant pour une certification de sûreté de fonctionnement.
  

De cette petite visite, nous avons tiré les conclusions suivantes:

• des tests automatisés réduiraient le coût des tests déroulés dans ce labo;

• Alex et moi aurions plus confiance en un logiciel vérifié par un test automatisé qu'en un logiciel vérifié par un opérateur distrait.

Bref, par rapport à des tests manuels, les tests automatisés sont économiquement plus intéressants et améliorent la sûreté de fonctionnement.

Une troisième pensée me vient en rédigeant ce billet. Rien ne vaut aller et constater par soi-même (ou Genchi Genbutsu en Japonais), conformément au Toyota Way. Impossible de parler d'Alex sans évoquer le Lean ;o)

A la prochaine Alex!

EXTREME PROGRAMMING EMBARQUÉ

La pratique de l'Extreme Programming est encore assez peu répandue pour le développement de logiciels embarqués.

LES ALÉAS DE L'EMBARQUÉ

En plus de difficultés classiques rencontrées en développement de logiciels, ce secteur est également confronté à des problèmes bien spécifiques.

Le logiciel est souvent couplé à un HardWare (HW) et un OperatingSystem (OS) spécifiques. Parfois même, le HW et l'OS sont développés en parallèle du logiciel et ne sont donc disponibles que tard dans le projet et en faibles quantités. Ainsi, l'intégration avec le HW et l'OS est du type Big-Bang et trop tardive. L'activité de test est alors peu efficace puisque essentiellement composée de séances de debug sur la cible. Aussi, il est regrettable de vérifier des algorithmes métier complexes sur un environnement aussi peu ergonomique que la carte embarquée.

Enfin, les développeurs sont confrontés au temps-réel, à la concurrence et au ressources limitées en charge de calcul et en mémoire.

Historiquement, les projets embarqués ont plutôt la réputation d'être marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Bref, nous sommes bien loin du développement logiciel agile.

EXTRÊME PROGRAMMING EMBARQUÉ

Pourtant, certaines pratiques techniques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels embarqués.

La pratique du pilotage par les tests (TDD) amène naturellement à découpler le code. Pour un logiciel embarqué cela conduit à isoler et réduire les dépendances vers le HW et l'OS pour de simples raisons de testabilité. Une telle conception pilotée par les tests permet alors de jouer des suites de tests sur une machine de développement (et non sur la cible) avec des mocks et stubs du HW et de l'OS. Ainsi, la quasi-totalité du code est testée et intégrée bien avant la disponibilité du HW et de l'OS!

Lorsque la cible est enfin disponible, les suites de tests sont rejouées sur celle-ci. Avec un langage de programmation tel que Ada, la construction des suites de tests avec une version native de la runtime Ada embarquée permet même de rejouer les tests sur la cible sans adaptation particulière (autre que la compilation croisée pour le processeur cible).

Le plus étonnant est que l'indisponibilté du HW et de l'OS, jadis une difficulté, est dévenue un atout! En effet, le découplage exigé par le TDD et rendu possible par un langage de programmation orienté-objet impose de bien concevoir les dépendances en séparant les problèmes. Les interfaces avec le HW et l'OS sont donc isolées du code métier. Les algorithmes métier complexes sont testés d'un côté sur une machine de développement et les les interfaces avec le HW et l'OS sont testés par ailleurs sur la cible.

Ainsi, gràce à la confiance que le développeur a en son code pleinement testé, il sait que les problèmes qu'il rencontrera (peut-être tardivement) en intégrant sur la cible ne concerneront plus que les interfaces avec le HW et l'OS, le temps-réel, la concurrence et les ressources limitées en mémoire et charge de calcul.

EXTRÊME SÛRETÉ

Parfois les logiciels embarqués sont également critiques, c'est à dire sûrs de fonctionnement. Je consacrerai un prochain billet sur cette difficulté additionnelle.

L'HOMME/MOIS (V2)

L'homme/mois fournit un mois de développement par mois.

LE TRAVAIL EN ÉQUIPE

Les hommes/mois se cumulent. Il parait que N hommes/mois travaillant en équipe pendant 1 mois développent comme un homme/mois pendant N mois. Ceci expliquerait pourquoi certains managers raffolent des hommes/mois. Il parait aussi que l'homme/mois est un mythe, comme l'affirme un certain Brooks.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

L'homme/mois apprécie l'architecte car il lui permet de faire sans penser.
L'architecte apprécie l'homme/mois car il lui permet de penser sans faire (Merci Thomas L. pour cette remarque ;o).

THE PRICK, LE SCRUMMASTER ET LE COACH (V3)

Dans une de ses conférences, Ken Schwaber dit avec humour que le ScrumMaster d'un projet est aussi appelé le "prick". Il hérite de ce surnom peu envieux car il est la personne la moins aimée du projet. Il est mal aimé car il harcèle l'équipe pour maintenir la discipline et la qualité. Il ne lâche pas car il est le garant de l'application du processus et de la qualité du produit.

PUSH / PULL

Pour ne pas tomber dans ce travers dans notre organisation, le ScrumMaster est aussi un développeur de l'équipe. Il devient légitime car il applique ce qu'il demande des autres. Il montre le chemin en étant exemplaire dans son respect des pratiques. Il ne cherche pas à pousser les équipiers vers un niveau mais plutôt à les tirer vers le niveau qu'il s'efforce d'atteindre et de conserver. Concrètement, il est plus facile de faire adhérer à la pratique du test-first lorsqu'on l'applique soi-même et qu'on binôme pour l'enseigner.

MANAGEMENT / LEADERSHIP

Nous rejoignons la nuance qu'il existe entre manager et leader. Un ScrumMaster développeur ne fait pas que proposer ("y a qu'à, faut qu'on") . Il entraine les autres par son exemple en montrant une voie. Attention, il ne dicte pas la voie. L'équipe choisit les pratiques. Mais pour exiger légitimement des autres qu'ils appliquent leurs pratiques encore faut-il commencer par les appliquer soi-même.

SCRUMMASTER / COACH

Du coup, le ScrumMaster développeur ressemble beaucoup au Coach XP. Il est un praticien expérimenté qui enseigne par l'exemple.

UN JOB A TEMPS PLEIN?

Sur nos projets, nous constatons d'ailleurs que les activités du ScrumMaster pour une équipe atteignant 9 développeurs ne constituent pas un plein temps. Au delà de 9 personnes, l'équipe se scinde en sous-équipes donc le problème ne se pose pas. Alors, que peut faire le ScrumMaster le reste du temps? Le ScrumMaster peut-il s'investir sur d'autres équipes? Afin d'être légitimement accepté par l'équipe, nous choisissons de ne pas diviser la disponibilité d'un ScrumMaster entre plusieurs équipes. La deuxième partie de son temps est accordée au développement. ScrumMaster développeur est un job à temps plein.

SCRUMMASTER(S)

Dans notre organisation, nous avons une autre particularité. Nous avons plusieurs ScrumMaster développeurs dans l'équipe. Ils ne se marchent pas sur les pieds. Aux contraire, ils se relayent. Ainsi, il y a toujours un garant de la discipline des pratiques et de la qualité, malgré les congés et les moments de fatigue. Il suffit de passer le relai. C'est aussi une manière d'investir sur les équipiers en formant des ScrumMasters praticiens au sein de l'organisation.

SCRUM MOU / SCRUM + XP

Scrum doit se pratiquer avec de solides pratiques techniques. Chaque sprint doit fournir un incrément de produit potentiellement livrable, donc testé et documenté. Avoir un ScrumMaster développeur sur un projet est aussi un moyen de s'assurer que les pratiques techniques ne seront pas délaissées à la faveur des pratiques d'organisation.

A LA MANIÈRE DE TOYOTA

Cette conception du leadership rejoint les principes du Toyota Way:

Principe 9: "Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others."
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) viennent de l'équipe et font partie de l'équipe. Ils font le même travail que les équipiers et sont sur place pour les former.

Principe 12: "Go and see for yourself to thoroughly understand the situation".
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) font partie de l'équipe. Ils comprennent la situation puisqu'ils sont en situation sur le terrain.

EN CONCLUSION

Si vous n'êtes pas le client ou son représentant et que vous contribuez au développement d'un logiciel, alors développez!

LES TESTS SONT DU CODE

LA SOUPLESSE GAGNÉE

L'Extreme-Programming est une sacrée aide. Grâce au TDD, au remaniement et à la conception simple, nous arrivons à mettre au point des logiciels ayant une architecture extensible. Nous ajoutons des incréments de fonctionnalité au fil des itérations. Les tests de recette et les tests développeur sont un tuteur qui aident le logiciel à pousser et un filet de sécurité contre les régressions. Ils permettent au logiciel de conserver sa souplesse, celle du SOFTware .

Nous pratiquons le TDD et le test-first. La couverture du code par les tests est intégrale. De plus, ayant les contraintes de sûreté de fonctionnement du logiciel critique, nous ne lésinons pas sur les cas de tests.

D'ailleurs, en démo nous nous livrons à un petit exercice. Nous proposons au client d'introduire un défaut dans la base de code et nous lui montrons que la suite de tests détecte sa modification.

Depuis plusieurs projets, nous constatons que nous avons plus de deux fois plus de lignes de code de test que de lignes de code de production. Étant donné qu'il faut vérifier de nombreux scénarios, le code des tests est souvent assez répétitif.

Vous voyez où je veux en venir?

LA SOUPLESSE PERDUE

Cette masse de tests est là en partie pour conserver la souplesse du logiciel testé. Elle est un tuteur construit autour de l'application. Mais si nous ne faisons pas très attention, cette masse de tests devient inflexible.

Tous ces cas de tests si ressemblants sont autant de mauvaises occasions de dupliquer du code. Tous ces mocks et tous ces stubs aux comportements légèrement différents doivent tous évoluer si leur interface de base est amenée à changer. Pour modifier une ligne de code de production nous en arrivons à devoir changer plus de 10 lignes de code de test. Le code des tests tend naturellement à devenir une masse pénible à faire évoluer. Les tests deviennent inflexibles. Le tuteur est devenu un massif baobab. Le logiciel perd alors sa souplesse d'évolution parce que les tests sont devenus inflexibles. Avec de bonnes intentions nous avons rendu l'application inerte. Elle a perdue sa souplesse parce que l'échafaudage qui l'enrobe est devenu un gros sac de nœuds.

LA SOUPLESSE GAGNÉE (BIS)

Heureusement, ce constat n'est pas une fatalité. Nous avons de la chance car les tests sont aussi du code. Nous devons donc porter au code des tests le même soin qu'au code de production. Les standards de codage s'appliquent au code de production et au code des tests. Nous devons systématiquement remanier le code des tests pour en éliminer les duplications, en réduire le volume et le rendre clair et expressif.
Il existe une architecture des tests. Si une classe hérite d'une autre alors son test unitaire hérite du test unitaire de la super-classe. Ainsi, nous rejouons des tests hérités sur une instance fille. Ceci nous permet de vérifier le si puissant Principe de Substitution de Liskov.
En remaniant les tests, nous devons faire bien attention à ne pas les faire régresser. Ceci est d'autant plus délicat que le code des tests est écrit sans tests! Quoique nous pouvons assimiler le code testé au test des tests (vous me suivez toujours?). Modifiez un test et vous aurez peut-être la chance de le voir échouer s'il n'est plus en cohérence avec le code testé. Ceci ne marche malheureusement pas si la modification du test l'a rendu plus permissif ...

En tout cas, ce qui est génial, c'est que tester c'est coder!

OU SONT LES GOF?

J'ai noté une mutation dans mon entourage. Peut-être l'avez-vous également remarqué autour de vous.

Il y a quelques années, nous avions tous un exemplaire du GoF sur notre bureau. L'ouvrage Design Patterns de Gamma, Heml, Johnson et Vlissides (le Gang of Four) était Le Livre. Pour nous, ce catalogue était La Référence des programmeurs compétents. Il trônait fièrement sur nos bureaux et nos architectures étaient enrichies de ses enseignements.

Puis, il nous a fallu plusieurs années pour graduellement et efficacement mettre en pratique l'Extreme-Programming. Curieux constat, aujourd'hui le GoF ne trône plus sur aucun de nos bureaux. Le mien est à la maison.

Comment expliquer cette lente mutation? Voici quelques causes possibles:

1. Nous ne concevons plus, nous codons comme des coyotes (alternative sauvage du cowboy-coding);


2. Nous maitrisons les Design Pattern et les mettons en musique de manière intuitive et inconsciente (rien que cela);


3. Nous concevons autrement, piloté par les tests;


4. Nous connaissons suffisamment les design-pattern et nous les faisons émerger avec parcimonie à mesure de la conception pilotée par les tests (fromage et dessert).

Alors, est-ce un abandon, une digestion, une révolution ou une mutation?

Sur plusieurs projets d'affilée, j'ai remarqué que je me fais moins de nœuds au cerveau concernant l'architecture. Avant, nous réfléchissions pas mal avant de nous mettre sérieusement au code. Nous dessinions de nombreux modèles au tableau et nous potassions le GoF à la recherche d'élégantes solutions.

Désormais, nous sommes plus directs. Nous cherchons la solution la plus simple à tester tout en respectant le principe de séparation commande/requête. Les associations, abstractions, héritages et implémentations viennent naturellement sur des critères de testabilité. Une fois que les tests passent, nous remanions notre travail pour réduire le volume de code, notamment en chassant les duplications. Au passage, nous nous assurons que l'organisation des classes respecte les principes de l'Oncle Bob. Et le plus incroyable est qu'au fur et à mesure des projets, il est de plus en plus aisé d'ajouter des fonctionnalités par incrément. Je trouve même que nos architectures sont élégantes. Elles ont l'élégance de la simplicité. Au passage, nous constatons que nos critères d'une bonne architecture sont par ordre de priorité: testabilité, simplicité, pas de dupplication, clarté.

Je ne pense pas pour autant que nous négligeons les patterns du GoF. Après en avoir abusé, nous les appliquons avec plus de parcimonie. En effet, dans nos architectures nous retrouvons toujours une séparation claire des responsabilités de fabrication des instances, d'utilisation des instances, de séquencement des instances et de gestion des états. Par contre, les Singleton sont toujours une vraie plaie pour les tests.

Ainsi, nous n'avons pas brulé nos GoF. Nous avons pris le temps d'en assimiler les enseignements et de les appliquer sans en abuser. Mais, je reconnais que pour nous, le GoF n'est plus La Référence. Nous n'en conseillons plus la lecture aux nouveaux arrivants. Ainsi, nous nous reposons peut-être trop sur l'expérience de ceux qui l'ont lu et l'ont trop pratiqué pour enfin apprendre à bien le pratiquer.

Et vous, il est où votre GoF?