RYTHME (IN)SOUTENABLE

Sur son blog, sur les mailing list XP France et FrenchSUG, David Brocard a relancé la discussion sur la mise en pratique du principe agile du rythme soutenable.

LE RYTHME SOUTENABLE

"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." (Agile Manifesto)

Ce principe est très louable:

• Il privilégie les objectifs à long terme sur les objectifs à court terme.
• Il assure un flux continu et constant de création de valeur qui maintient la qualité du produit, assure l'avancement et améliore la prédictibilité du développement.
• Il instaure un rythme permettant de mettre en place la résolution systématique des problèmes et l'amélioration continue.
• Il rappelle que le développement est réalisé par des hommes et qu'il faut respecter leur rythme de travail - dans leur intérêt, dans celui du projet et des clients.
• Il permet d'enchainer les projets, les uns après les autres, car les développeurs restent disponibles (en bon état ...).

LE PROBLÈME

• En revenant sur plusieurs années de projet, est-ce que le rythme soutenable a été appliqué?
• Est-il compatible de la mise en pratique des autres principes du Manifeste Agile?
• A t-on au moins gagné un rythme plus soutenable qu'auparavant, lorsque nous utilisions des méthodes plus théoriques et (faussement) prédictives?
• Après 150 jours ouverts de développement sur un même projet, j'avais écrit que nous étions passé de l'itération au sprint sur notre projet en perdant le rythme soutenable (voir billet). Qu'en est-il après 350 jours ouvrables de développement sur ce même projet?

LE PLUS DUR EST A VENIR

Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable le long du V descendant. Pour tenir un jalon intermédiaire (spécification, conception, codage) il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.

Puis, le rythme devenait bien plus désagréable lors de la remontée du V. L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point (et réécrire) ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...

Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.

C'EST DUR TOUT LE TEMPS

Avec la pratique du cycle de vie itératif et incrémental court, le stress et les heures de travail n'ont pas disparu. Ils ont été lissé assez uniformément le long du développement (il reste des pics lors des itérations qui précèdent une livraison formelle). Aussi, le stress et le surcroit de travail apparaissent très tôt dans le développement.

Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.

Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité (et d'autres indicateurs) peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.

Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles lissent tôt et tout au long du projet le stress qui culminait auparavant vers la fin (théorique) du développement.

Notez que la technique du Heijunka dans la Lean recherche spécifiquement ce lissage de la charge de travail et du stress.

SANS PIC NI RELÂCHE

Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de relâche. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un daily-stand-up-meeting, avec le burndown chart actualisé quotidiennement, avec un build publié et avec des tests de recette automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!

Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.

LA COURSE A LA VÉLOCITÉ

Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.

STRESSANTE TRANSPARENCE

Au rythme s'ajoute le stress de la transparence. Il faut du courage pour afficher sa courbe de productivité et sa courbe de non-qualité. Il faut du courage pour mettre une lumière qui devient rouge lorsque le build est cassé. Il faut du courage pour montrer ses problèmes. Donner des indicateurs, cela peut aussi être donner le bâton pour se faire battre. Être transparent, c'est aussi accueillir la critique: "Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire" (François Brun).

NOUVEAUX SYMPTÔMES

Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un riche folklore d'équipe. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que "le Gizmo", "le Perfect", "le saut de la troisième corde", "le J'off" et bien d'autres encore.

Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des mécanismes collectifs de protection contre la souffrance au travail. Malheureusement, c'est un fonctionnement très classique étudié par la psychodynamique du travail. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.

Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.

QUEL QUE SOIT LA MÉTHODE

Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux (pour des raisons économiques) et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les périodes de charrette (période intense de travail pour terminer à temps une commande, une tâche sous contrat).

NÉANMOINS

Les démarches de type agile ont la particularité de lisser cette charge de travail dans la durée et de monter très tôt le rythme. Ce rythme est sans pic ni relâche. A cela s'ajoute le stress de la transparence. Clairement, il faut du courage pour pratiquer une démarche du type agile.

La variable d'ajustement reste le curseur de la vélocité. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent (très facilement) en faire.
Ces démarches sont diablement efficaces et motivantes mais elles ne peuvent bien sur pas tout résoudre.

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)

AGILITE AU SALON DU BOURGET

Nous avons eu la chance d'être invités au Salon du Bourget. Nous avons eu le plaisir d'y voir deux porteurs pour lesquels nous avons développé des logiciels de vol en appliquant les méthodes agiles.

Ces deux logiciels ont été livrés à temps et avec la qualité attendue. Très discrètement et pour certains initiés, les méthodes agiles étaient à l'honneur au Salon du Bourget!

2 ANTIPATTERNS DE BINOMMAGE

Nous pratiquons le Pair Programming. Pas 100% du temps, mais le plus possible.

Nous pilotons nos activités avec un Kanban. Chaque étiquette du Kanban est un post-it sur un tableau. Chaque post-it représente une tâche à mener. Sur ces post-it, nous nommons les équipiers qui participent à sa réalisation.

En surveillant la liste des équipiers sur les post-it, nous avons pu identifier 2 antipatterns de Pair Programming. Il en existe bien plus, mais ceux là nous amusent bien.

A + B - B, ou le "Ca pue, je me casse"

Nico est le premier assigné à une tâche. ManU vient binommer avec Nico. Après quelques heures, ManU trouve une tâche plus prioritaire à mener. En fait, après avoir vu ce sur quoi travaillait Nico, ManU s'est mis en tête de trouver une tâche plus prioritaire. Il s'agit d'une manière agilement correcte de dire "Ta tâche pue, je me casse!".

A + B - A, ou le "Je te délègue ma bouse"

ManU est le premier assigné à une tâche. Nico vient binommer avec ManU. Après quelques heures, ManU trouve une tâche plus prioritaire à mener. Il s'agit d'une manière agilement correcte de dire "Je te délègue ma bouse!".

Les patterns sont un langage de travail

Désormais, dans notre open space, nous entendons des développeurs se dire: "Mais, tu ne serais pas en train d'essayer de me faire un A + B - A?".

Pas très agile tout ça

Certains extrémistes s'évertueront à dénoncer qu'il s'agit de manquements aux valeurs, principes et pratiques de l'agilité. C'est vrai, mais parfois nous sommes aussi des hommes. Et puis on se marre bien dans l'équipe ;o)

AGILITY AND LEAN FOR AVIONICS, EN VIDEO

Voici la vidéo de ma conférence donnée chez AdaCore à l'occasion de l'évènement The Lean, Agile Approach To High-Integrity Software. La vidéo est en quatre parties.

Partie 1 sur 4:


Partie 2 sur 4:


Partie 3 sur 4:


Partie 4 sur 4:


Les slides de la présentation sont disponibles ici et l'article ayant servi à préparer la conférence est consultable ici.

Les vidéos ont initialement été mis en ligne sur le site OPEN-DO. Vous y trouverez les vidéos des autres présentations de l'évènement.

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)

PARTIE VISIBLE ET PARTIE INVISIBLE

Dans notre organisation, nous constatons que la partie visible de nos pratiques de développement séduit les décideurs. Cette partie visible correspond aux pratiques de pilotage de projet de développement. Dans notre cas, il s'agit de la pratique de Scrum complétée par le Lean avec le Value-Stream-Mapping et les Kanbans.

LA PARTIE VISIBLE

Ces pratiques séduisent les décideurs pour plusieurs raisons.
D'abord l'équipe développe le bon produit grâce au rôle joué par le Product Owner, grâce à la construction itérative et incrémentale et en évaluant les incréments de produit lors des démonstrations d'itération.
Ensuite, l'avancement est transparent grâce à l'identification, à la priorisation et à l'estimation du restant à faire dans le Product Backlog et l'Iteration Backlog, grâce à la visualisation du restant à faire par les Burndown-Charts, grâce à la mesure de la vélocité et enfin grâce aux incréments de fonctionnalité présentés en démonstration d'itération.
La complexité est maitrisée par la construction itérative et incrémentale du produit.
L'équipe se responsabilise pour tenir l'objectif en planifiant les itérations, en pilotant quotidiennement les activités lors des Daily-Stand-Up-Meeting et en présentant leur travail lors des démonstrations d'itération.
L'équipe améliore ses pratiques en menant les rétrospectives d'itération, en portant un regard critique sur la cartographie du flux de valeur et en traitant les goulots d'étranglement révélés par les Kanbans.

Toutes ces pratiques sont pleines de bon sens. Elles ont aussi le grand avantage d'être visibles et touchent des décideurs n'ayant pas un profil technique.

LE CHAOS

Le développement logiciel est une activité assez chaotique. Or ces pratiques permettent de s'accommoder du chaos car elles se mènent en cycles très courts, permettent de collecter de l'information et apportent de la transparence.
Par contre, ces pratiques génèrent également du chaos. Il s'agit du chaos lié à l'instabilité du produit construit par incrément en cycles très courts. La construction itérative et incrémentale amène à faire évoluer la conception et à reprendre le code déjà écrit. Si cette instabilité n'est pas maitrisée, elle conduit à des régressions. Et tout s'écroule ...

LA PARTIE INVISIBLE

Le chaos lié à l'instabilité du produit est maitrisé par la partie cachée des pratiques de développement. Ces pratiques ont le désavantage de ne pas être visibles. Il s'agit par exemple de l'intégration continue, du développement piloté par les tests, de la programmation par contrat, de la programmation orientée-objet, du strict respect des grands principes de conception orientée-objet et de l'exception visible: le Pair Programming. Ces pratiques combinées et la recherche de l'excellence technique permettent de maitriser l'instabilité d'un produit en train de "pousser" par incréments. Malheureusement, le fait que ces pratiques ne soient pas visibles les rend plus difficiles à valoriser auprès de décideurs et des équipes de développement.

OU EST LE PROBLÈME?

Le risque est que décideurs et équipes de développement n'adoptent que la partie visible des pratiques de développement. Ces projets souffriront beaucoup du chaos et de l'instabilité du produit. L'adoption des nouvelles pratiques sera tenue responsable des échecs. Malheureusement, un échec cuisant peut avoir plus d'effet que plusieurs succès quand à la promotion d'une nouvelle démarche au sein d'une organisation.

DES SOLUTIONS?

Communiquer auprès des décideurs et des équipes en démontrant les pratiques visibles est très efficace pour séduire et convaincre. Cependant, il faut également insister lourdement sur l'absolue nécessité du socle technique.
Aussi, nous avons remarqué que nos équipes qui ont pris le virage avec succès ont commencé par adopter les pratiques techniques. Peut-être qu'il est plus sûr de débuter par la partie invisible et d'attendre que les bienfaits se fassent sentir?

LEAN, CARTOGRAPHIE DU FLUX DE VALEUR

Il s'agit d'identifier toutes les étapes créatrices de valeur en éliminant les activités qui ne créent pas de valeur.

COMMENT PROCÉDONS-NOUS?

Il n'y a pas réellement de pratique agile qui implémente spécifiquement cet objectif. Ceci dit, toutes les pratiques de l'Extreme-Programming implémentent la valeur Simplicité, qui consiste à maximiser le travail à ne pas faire.

Alors, nous pratiquons le Value Stream Mapping du Lean. Les activités à mener en série et en parallèle sont identifiées. Des temps moyens par poste sont mesurés afin de révéler les contraintes et de mesurer une cadence type. Nous avons aussi remarqué que cette cartographie est appréciée par les nouveaux arrivant sur le projet. La cartographie permet de visualiser comment nous procédons pour transformer les besoins en logiciel opérationnel.

IDENTIFIER LES GASPILLAGES

Lorsqu'on pratique le Value Stream Mapping, il faut apprendre à identifier les gaspillages. Il s'agit des pratiques qui ne créent pas de valeur.
Par exemple, dans notre secteur, les développeurs sont terrorisés par le risque que le logiciel ne tienne pas sur la carte embarquée à cause d'un dépassement de charge de calcul ou d'utilisation de mémoire. Alors, nombreux dans notre filière optimisent leur code prématurément. Cette optimisation est pilotée par la peur et non par des faits. Voilà une source de gaspillage: il se peut bien que le code soit suffisamment performant! L'effort consacré à l'optimisation est alors perdu. De plus, le code est devenu plus complexe. C'est pourquoi, notre pratique est de ne pas optimiser prématurément le code.
Par contre, nous nous devons de surveiller les performances tôt et souvent. Le code est alors optimisé au besoin et de manière ciblée sur la base d'informations concrètes. En effet, nous pensions qu'il est plus aisé d'accélérer un code correcte que de corriger un code rapide. La prise de décision est facilitée en automatisant la mesure des performances et le profiling du code.

Néanmoins, cette pratique n'empêche pas d'optimiser prématurément le code. Voilà encore une raison pour laquelle nous pratiquons le Pair Programming. Le navigateur se doit de décourager le pilote d'optimiser prématurément le code.

Le prochain billet sera consacré au flux continu de valeur. A bientôt!

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!

EXTREME PROGRAMMING CRITIQUE

La pratique de l'Extreme Programming est très peu répandue pour le développement de logiciels critiques. Ces applications sont utilisées dans l'avionique, le médical, le ferroviaire, le nucléaire et l'automobile.

LES ALEAS DU LOGICIEL CRITIQUE

Les logiciels critiques doivent être certifiés par un organisme spécialisé pour garantir la sûreté de fonctionnement.

La certification est obtenue après une série d'audits exigeant la fourniture des preuves des activités menées pour garantir la sûreté de fonctionnement.
Par exemple, l'organisme certifacteur va s'assurer que le logiciel contient exclusivement du code implémentant les besoins opérationnels du produit. L'implémentation de tous les besoins opérationnels et tout le code devront être vérifiés par des tests. Ces tests devront être joués sur la version finale du logiciel. Ainsi, un changement même mineur du code de la version finale implique que l'intégralité des tests devront être rejoués. Ceci peut représenter un coût considérable si les tests sont joués manuellement par un opérateur. Enfin, tous les produits du développement (exigences, documents, traçabilité, architecture, code, tests) devront être revus.

Les projets de développement de logiciels critiques sont clairement marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Le développement logiciel agile et l'Extreme programming en particulier sont-ils applicables dans ce secteur?

EXTREME SURETE

Certaines pratiques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels critiques.
La construction incrémentale pilotée par les besoins opérationnels (les user stories) et les tests d'acceptation assure que le code n'est écrit que pour faire passer les tests d'acceptation d'un besoin opérationnel. Ainsi, le logiciel contient exclusivement du code implémentant des besoins opérationnels.
Les tests d'acceptation systématiques assurent que la prise en compte de tous les besoins opérationnels sont vérifiés par test.
Les tests dévéloppeur systématiques assurent que tout le code est vérifié par test.
La pratique du Test First Programming assure que les tests sont indépendants du code qu'ils vérifient puisqu'ils sont écrits avant même le code.
Les tests d'acceptation et développeur sont automatisés et vérifient leurs résultats. L'intégralité de ces tests est automatiquement rejouée par l'outil d'Intégration Continue dès que le code est modifié. Ainsi, la dernière version du logiciel est toujours intégralement et rigoureusement testée de manière reproductible à faible coût.
Le Pair Programming assure que les produits sont revus en continu.

ADAPTATION

Les pratiques d'XP ne fournissent pas le niveau de formalisme requis par les audits de certification. Certaines pratiques devront être adaptées et d'autres ajoutées. Par exemple, la documentation devra être considérée comme faisant partie du produit. Elle devra alors être incrémentalement rédigée au fil des itérations afin de rester potentiellement livrable.

CONCLUSION

Les pratiques disciplinées et rigoureuses de l'Extreme Programming sont une aide au développement de logiciels critiques. Par contre, les pratiques doivent être adaptées pour fournir le niveau de formalisme requis par les audits de certification.

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.

TESTER LES IHM

Comme beaucoup de monde, nous nous sommes cassé les dents sur l'automatisation des tests d'IHM. Dommage que je ne connaissais pas à l'époque le petit pattern que Michael Feathers a décrit dans ce court article: The Humble Dialog Box.
Dans sa démarche, la couverture par les tests automatisés n'est pas exhaustive, mais elle est déjà bien optimisée. Et puis sa solution a le mérite de la simplicité. Ce n'est pas rien...

Son principe est de ne mettre aucune logique dans les classes des widgets. Ce code est extrait du widget pour être mis dans une classe écrite en Test First Programming et dépendant d'une interface du widget.
Pour les besoins des tests automatisés, l'interface du widget est implémentée dans la fixture du test unitaire par un stub ou un mock (au choix selon les goûts).
En revanche, pour l'application en production, l'interface du widget est implémentée par un vrai widget qui a l'humilité de déléguer le traitement de tous les évènements graphiques à une instance de la classe "intelligente". Ce code de délégation n'est pas testé de manière automatisé mais le risque est limité à du code "humble".

Michael Feathers est un testeur héroique. Il se confronte aux pires cas. Après le test automatisé des IHM, il s'est attaqué au test automatisé du "legacy code", c'est à dire des applications écrites sans tests. Il y a consacré un livre: Working Effectively With Legacy Code.

J'étais déjà tombé par hasard sur The Humble Dialog Box il y a quelques années mais je l'avais négligé à tord. C'est ma lecture du moment xUnit Test Patterns: Refactoring Test Code qui m'a redirigé vers cet article. Je reparlerai plus tard de ce livre assez génial qui impacte beaucoup ma manière de tester en ce moment.

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!

PLANNING EXTREME PROGRAMMING, KENT BECK ET MARTIN FOWLER

Ce livre a été conjointement écrit en 2001 par Kent Beck et Martin Fowler et préfacé par Tom DeMarco. Cela fait trois grosses signatures pour un seul et même ouvrage.

LA GESTION DE PROJET

Les auteurs consacrent le livre à la planification et au pilotage d'un projet mené dans une démarche XP. Ils cherchent à montrer qu'en plus de pratiques techniques, la panoplie XP contient toutes les pratiques nécessaires et suffisantes pour planifier et piloter un projet.

XP + SCRUM OU XP?

On dit souvent que Scrum apporte aux pratiques techniques d'XP les pratiques de pilotage de projet et d'équipe. Ce livre tend à montrer que XP est déjà auto-suffisant pour la gestion de projet. La sur-couche Scrum ne fait que recouvrir avec son propre vocabulaire et ses rôles des pratiques pré-existantes dans XP. Ceci dit Scrum apporte plus de formalisme et de cérémonial, ce qui est une bonne chose à mon avis.

DE L'EAU DANS LE VIN

D'une manière générale, Martin et surtout Kent ont mis de l'eau dans leur vin. Dans ce livre, je trouve que l'aspect extrême d'XP est diminué. Déjà, en préface, les auteurs rappellent que XP n'est pas une destination mais un parcours. Une pratique conforme au livre d'XP doit servir à identifier ce qui dans la démarche doit être adapté au contexte du projet.

La durée de l'itération est devenue un sujet d'expérimentation. Le cycle hebdomadaire n'est plus une référence. L'essentiel est de rester en dessous du mois et de ne pas glisser!

De même, la pluridisciplinarité de chaque membre de l'équipe n'est plus encadrée par une rotation systématique des binômes sur toutes les parties de l'application. La spécialisation des développeurs est même encouragée à partir du moment qu'elle est liée à une motivation personnelle.

Aussi, les auteurs sont plus permissifs quand à l'existence de bugs dans le produit. La correction de bugs mineurs n'est pas nécessairement une priorité pour l'équipe.

Enfin, les auteurs sont moins impératifs sur la nécessité de développer les fonctionnalités de bout en bout. L'essentiel est désormais que tout ce qui est développé dans l'itération soit testé à la sortie de l'itération.

Personnellement je désapprouve le calcul d'une vélocité individuelle pour chaque développeur. Je suis peut-être un peu Bisounours, mais je ne vois pas comment cela peut rester compatible d'un esprit d'équipe efficace. Je préfère calculer la vélocité de l'équipe pour mesurer sa capacité de travail par itération et éventuellement diviser cette vélocité par le nombre de développeurs pour surveiller l'impact de l'intégration de nouveaux membres dans l'équipe.

Enfin, j'ai apprécié le désaccord entre Kent et Martin portant sur la priorité des fonctionnalités à développer. Kent accorde une plus grande priorité à celles qui apporte le plus de valeur au client alors que Martin accorde les plus hautes priorités à celles qui comportent le plus de risques. C'est le pilotage par retour sur investissement contre le pilotage par les risques.

EN CONCLUSION

Bref, si on connait déjà XP et Scrum, il ne me semble pas que la lecture de ce livre soit si importante. Par contre, si on croit que XP ne contient que des pratiques techniques, alors ce livre est une occasion de se détromper. Il se lit très vite gràce au style reconnaissable de Kent: une succession de petits chapitres de 2 ou 3 pages au plus.

SCRUM AND XP FROM THE TRENCHES, HENRIK KNIBERG

J'ai profité de la traduction en français de ce livre pour enfin le lire.

Loin de la théorie de Scrum, l'auteur décrit de manière très pragmatique son implémentation de la démarche en révélant plein de petits conseils pratiques.

Après avoir lu un ouvrage de Ken Schwaber, ce livre est idéal pour se faire une idée concrète de comment Scrum peut être appliqué au jour le jour. Étant déjà praticien, j'ai trouvé très intéressant de confronter nos pratiques à celles de Henrik. Aussi, dans la multitude de petit conseils pratiques, tout le monde trouvera bien un petit quelque chose à expérimenter sur son projet.

Les 150 pages se lisent tranquillement et agréablement le temps d'un week-end.

Merci à Emmanuel Etasse, Bruno Orsier et leurs compères pour ce travail de traduction. Le livre est gratuitement et légalement téléchargeable ici.

XP Days Paris 2008: Agilité et Avionique

Aux XP Days 2008 à Paris, j'ai eu le plaisir de présenter une conférence sur le thème "agilité et avionique".

Mon objectif était de faire réfléchir les auditeurs sur la question suivante: "Etes-vous prêts à confier votre vie à un logiciel développé par des praticiens de l'eXtreme-Programming?".

Sur la photo, on me voit en 4ème position à partir de la gauche. C'est le moment où le maître de conférence accorde une minute à chaque orateur pour présenter son sujet.

La présentation et l'article ayant servi à la conférence sont disponibles ici.