Première séance de CITCON, je regarde le grand tableau blanc. Les postits de chacun sont maintenant tous cochés, ce qui permet de construire l’agenda de la journée.
(Crédit photo : Cirilo en Natasha)
Je décide de commencer par un débat sur « Testing and Done ! »
Je ne vais pas retranscrire en français toute la discussion, simplement vous donner quelques points discutés par l’ensemble de la salle pendant une heure.
Tout d’abord, si votre responsable vous laisse coder sans limite, à quel moment décidez-vous de vous arrêter ? Comment décidez-vous que votre logiciel, ou votre développement est terminé ? Chacun propose sa définition du « done » (terminé). Un développeur explique que pour lui, c’est lorsque le code source est commité sur le gestionnaire de code source. Un autre répond alors que pour lui, c’est lorsque l’intégration continue a confirmé que son code compilait. Et un autre de répondre, que c’est lorsqu’en plus la version a été installé sur la machine de test… Bref chacun a une vision différente de la notion du Done. Le débat s’annonce passionnant.
Une discussion sur la couverture des tests unitaires s’engage alors. Par expérience, il semble que 80% de couverture des tests unitaires soit un bon chiffre. Cela me rappelle mardi soir dernier, lors de la présentation de Sonar, qu’il y a quelque chose à creuser. Je me souviens d’un écran avec une liste des projets open-source audités par Sonar, et j’avais été étonné de voir que les 25 premiers projets audités se tenaient dans un mouchoir de poche. Après quelques recherches, j’ai trouvé ce que je cherchais. Sur le site Nemo de Sonar vous pouvez visiter des audits de différents projets open-source. Prenez le temps de regarder la couverture en tests unitaires des projets, et vous verrez qu’il est utopique de penser couvrir 100% de votre code (ligne ou branche de code).
Bref 100% de couverture n’a rien à voir avec la notion du Done pour ce qui est purement tests unitaires.
D’autres pensent qu’il est indispensable d’avoir des tests d’acceptance, qui lorsqu’ils passent tous, signent pour vous cette idée du « Done ». Est-ce à dire que 100% de tests d’acceptance validés, font qu’une tâche est validée ? Comme j’ai assisté l’après-midi à une présentation sur les tests d’acceptance, je reviendrai sur ce sujet.
Il y a donc des indicateurs techniques (Cobertura) et des indicateurs marketings (Fitness) mais finalement, tout ceci ne répond pas au problème.
La notion de « shippable » est ensuite discutée, amenée je pense par quelques Scrumistes dans la salle. Un débat s’engage entre ceux qui doivent sortir un produit à date fixe, et qui n’ont donc pas le choix sur la date mais sur la liste des fonctions, et ceux qui doivent livrer un ensemble de fonction, sans que la date de sortie ne soit importante. Dire qu’un projet est terminé, c’est aussi avoir l’ordre de sortir ce produit sur le marché. Et tout le monde s’accorde à dire que parfois, des produits sortent alors que l’on sait qu’il y a des défauts… Mais tant pis ! Il semble donc très difficile d’avoir un produit réellement terminé, sans aucuns bugs. D’où l’existence de support dans notre industrie, et des patches correctifs.
J’écoute tout le monde, et pendant la discussion me vient une idée. Est-ce que finalement, la notion de « Done » que l’on essaye de calquer sur une tâche ou un logiciel, ne devrait pas être pensée de la façon suivante : « Done s’applique à la personne qui réalise, pas à ce qu’elle fait« . Moi en tant que développeur, je peux me marquer comme « DONE » sur le Kanban car j’ai réalisé ma mission. Je passe la main ensuite au testeur, puis à l’intégrateur, et enfin l’équipe de production. Quelque part, j’imagine une chaîne de construction où chaque tâche est séquentielle. Et donc le « Done » dont nous parlons, le « My Task is Done » n’existe pas. Ce serait plutôt « My Job is over/done ».
Qu’en pensez-vous ? Ca sent le Lean, je sais.
Nous réfléchissons ensuite sur l’utilité des tests. Eric « Bob » Mignot propose l’idée que les tests permettent de réduire la peur, l’inquiétude du Product Owner, en affichant des indicateurs de qualité mesurable dans le temps. ll est donc indispensable de travailler sur la mise en place de tests d’acceptance. Et il est important d’ajouter des tests que le chef de produit comprend. Pour améliorer la communication et décider à quel moment, une tâche est « Done ». C’est le client qui décide que sa commande est comme il l’a souhaité.
Un développeur s’insurge contre le marketing qui lui demande de sortir un produit, alors qu’il voudrait encore ajouter des tests. Il explique que pour lui, la notion du Done c’est lorsque le chef de produit décide de venir chercher le logiciel sur lequel il travaille pour le vendre, et qu’il ne décide pas vraiment. Quelque part, je pense qu’il ne faut pas être trop manichéen, et qu’il est important d’avoir un consensus pour décider de la sortie d’un produit, ou de la fin d’un projet.
Pour aller plus loin je vous laisse avec quelques pointeurs sur le sujet. Robert C.Martin (dit « Uncle Bob ») a parlé de la Quintessence, le 5e élément du manifeste Agile lors de la conférence Agile 2008 à Toronto. Il propose de privilégier l’Artisanat par rapport à la Réalisation : Craftmanship over Crap qui est devenu ensuite Craftmanship over Execution dans cet article.
Most software development teams execute, but they don’t take care. We value execution, but we value craftsmanship more.
Dans la salle, beaucoup de personnes comme Antony Marcano de Skills Matter, Gilles Mantel de Valtech, Eric Mignot de Pyxis, et surtout Gojko Adzic qui est passionnant, mais déroutant car lorsqu’il vous parle, on dirait que vous allez passer un mauvais quart d’heure. Je l’ai suivi dans une autre session l’après-midi, et ce gars est vraiment intéressant. Auteur de 2 livres sur les tests d’acceptance, il connaît bien le sujet.
Bon finalement je vous ai livré 960 mots et 1h30 de travail, à ce rythme vous aurez un article par jour, pas plus.
A suivre !
0 no like
Le DONE local, genre « My Job is over/done », n’est pas suffisant, car une série d’optimisations locales peut mener à la catastrophe.
Genre, un négociateur commercial dans le secteur automobile qui a réussi à faire diminuer le prix des roues : tout va bien au début (la première) année, puis sous la pression, le fournisseur se délocalise et pendant une période, c’est toujours pas cher, mais la qualité baisse. Et le cout global augmente et les plaintes aussi. Pire, le fournisseur fait faillite et se fait racheter par un plus gros, et là, le constructeur automobile doit faire face à un fournisseur de taille importante qui peut alors lui dicter ses conditions moins avantageuses. C’est ce qui se passe dans le cadre d’une fonctionnement tactique (local) et non stratégique (global).
Tout ce post est intéressant, et on voit bien qu’il y a différents niveaux d’acceptance, local/global, fonctionnel/technique, etc.
J’ai l’impression qu’il faudrait développer un axe un peu trop rapidement esquissé: « il est important d’ajouter des tests que le chef de produit comprend ».
Derrière cette phrase, il y a l’idée des tests comme un tout, comme appartenant à un ensemble, bref les idées de cohérence et de structure. Cela devrait permettre de faire « tenir le tout » et ainsi, par la même occasion, de construire un discours
(a) Ex de règle de cohérence (forte) : toutes les couches (écran/métier/modèle) d’une fonctionnalité doivent si possible être dans le périmètre d’un test (si une couche est testée, alors les autres doivent l’être aussi).
(b) Ex de règle de cohérence (moyenne) : si un test pour une fonctionnalité réalisant des écritures est défini, alors il faut tester aussi les fonctionnalités permettant de lire les données enregistrées.
(c) Ex de règle de cohérence (faible) : si un test pour une fonctionnalité web est écrit, alors un test doit être écrit pour cette fonctionnalité en version API, par ex, flux RSS.
Attention, je ne dis pas qu’il suffit de respecter les règles de cohérence ci-dessus pour savoir quand livrer ! Simplement, dans mon idée, elles doivent permettre de donner du grain à moudre, de donner de la structure, bref, d’enrichir l’arbre de décision.
J’hésite pour choisir la bonne métaphore que m’inspire ces règles de cohérence. Les dépendances qu’elles indiquent me font penser à un jeu de puzzle ou légo. Et la dernière règle (c) me fait penser à un jeu de couverture. Par ex, si vous avez pour chaque fonctionnalité web, le pendant en mode RSS, il est possible de doubler les tests, mais si tous les flux RSS bénéficient pour leur implémentation d’une mécanique générique, alors un seul test RSS « suffit », i.e. couvre à lui seul N fonctionnalités RSS à tester (qui seraient le pendant de N fonctionnalités web correspondantes).
En fait, ma métaphore préférée (qu’il faudrait que je creuse) est celle d’un jeu de mon adolescence, un jeu de pipelines (à réparer) : http://www.jeuxvideo.com/jeux/amstrad-cpc/00024252-super-pipeline-ii.htm
– il ne faut pas qu’il y ait de fuite => en info = perte de données
– tout réservoir alimenté par un pipeline doit pouvoir se déverser dans un autre pipeline => en info = toute donnée enregistré doit pouvoir être lue
– l’eau doit aller d’un point (A) à un point (B) => en info = toutes les couches écran/métier/modèle doivent être opérationnelles en même temps (et au delà se trouve la notion de cas d’utilisation)
– etc.
Grand fan des analogies, métaphores et autres paraboles, et pour avoir joué sur CPC 6128 aussi, je trouve que ton image du jeu Pipeline est judicieuse. Et elle marche. Merci !
Yep, à y réfléchir à nouveau, ma métaphore pipeline+eau fonctionne pas mal du tout.
Elle rejoint d’ailleurs des conceptions populaires; par ex, il est de bon ton de se méfier de l’eau qui croupit, souvent porteuse de problèmes/maladies.