Dans ce second article sur qu’est-ce que sait d’être agile, nous allons-nous intéressé sur le deuxième grand principe des méthodologies Agiles. « Le développement logiciel doit primer sur la documentation exhaustive. »
On voit beaucoup de gens qui se disent « Agile » parce qu’il n’aime pas produire de la documentation. Mais, les méthodologies Agiles, ne disent justement pas qu’il ne faut faire de la documentation. Il faut faire de la documentation lorsque c’est nécessaire, et surtout utilisé une organisation de cette documentation pour qu’elle soit simple et facile à comprendre.
Ce principe est survenu par l’expérience de projets qui ont eu à produire d’énormes documents pour encadrer le développement de leur application. La production d’un document volumineux, de 100 pages et plus, que personne, à part son auteur ne lit vraiment, est-ce utile à produire ? Laissons la question ouverte pour le moment.
Tout comme, produire un document de plusieurs pages, quand les contraintes et les limites des fonctions pourraient s’expliquer en quelques liges ou avec l’aide de quelque digramme UML ou présentation PowerPoint.
Beaucoup de projets, passent des semaines, des mois à documenter les différentes fonctionnalités. Durant cette période, le client, ne se voie que passer devant lui que des piles de papier, et souvent qu’il ne va lire qu’en diagonale en se disant intérieurement qu’il a hâte voir fonctionner l’application.
Il suffit de faire l’exercice une fois, de montrer un prototype, même à moitié fonctionnel, à un client. Pour savoir, ce qu’il veut le faire avec.. c’est de l’essayer comme un nouveau jouait pour un enfant. N’importe quel client veut pour le voir, le toucher, ce logiciel le plus rapidement possible. Lui servir des beaux documents, se n’est que le faire languir, et ce, même la qualité du rédacteur ou du document.
De plus, qui n’a pas vécu, ou même entendu parler d’un projet, que le jour de la livraison, ou encore quelque temps après, que la documentation fonctionnelle ne correspondait plus vraiment à ce que le logiciel effectuait ! Je me souviens d’un projet de conversion d’application, sur laquelle je devais travailler sur une fonctionnalité particulière. La documentation de la version courante avait disparu, quelque chose qui n’arrive jamais ! Mais, un jour en passant dans un couloir, j’ai vue une série de cahiers anneaux, portant le nom du système.
En les voyants, c’est avec empressement, que je suis allé voir l’architecte fonctionnel et propriétaire du système, pour lui demander sa documentation en question était à jour. Devinez la réponse de l’architecte, je vous la donne en mille… « Ha oui.. c’était la version de la documentation livrée avec le système… » Ce n’a pas pris longtemps pour comprendre qu’il m’était inutile de dépoussiérer ces cahiers à anneaux. Elles étaient depuis longtemps plus à jour.
De plus, soyons francs, connaissez-vous un programmeur qui aime lire un document de plus qu’une demi-page. Moi, je n’en connais pas .. ! Donc, pourquoi s’astreinte à produire une documentation que personne ne va pas la lire.. !
Aujourd’hui, il existe tant d’outils, pour faire des prototypes, pour montrer l’interaction des écrans. Des outils qui permettent de découper étapes par étapes des algorithmes complexes. D’expliquer ce qu’on veut que fasse une fonction dans un système donné.
La production de la documentation, doit être au service du développement du logiciel, et non pas un frein. Ce que veut tout client, c’est un logiciel qui correspond à ses besoins. Et plus rapidement, qu’il y aura accès à son application, plus il pourra valider et corriger le tire. Produire de la documentation à outrance, pendant des moins, il y a risques, que lorsqu’on livre au client un système qui soit complètement dans le champ. Il est plus facile d’ajouter une pièce à une maison, quand les séparations ne sont pas construites, que quand tous les meubles sont à l’intérieur.
En livrant rapidement de petits morceaux de logiciels, à qui le client aura accès rapidement. Livrez 200 moreaux d’une application que client n’a pas accès, qui ne peut pas faire des essaies avec, cela ne sert à rien. Par exemple, un système de 100 fonctions, si on lui livre en quatre coups de 25, le client risque de ne pas avoir le temps de tout vérifier dans un délai très court.
A l’inverse, si lui régulièrement un très petit groupe de fonction de 4 ou 5 fonctions à la fois, il pourra rapidement nous informer de toute erreur ou incompréhension. On pourra ajouter la correction, ou amiloration, d’une ou deux fonctions, dans le cycle de développement c’est facile. Mais, en corrigé 15-20, partez à la recherche d’un chargé de projet de 150k et plus, au plus vite ! Et surtout avertissez, vos équipes de développement qu’elles vont faire beaucoup de temps supplémentaires.
L’agilité de livrer de petit morceau rapidement aux clients, c’est aussi de pouvoir les corriger et les ajuster rapidement.
Aussi en livrant de petites fonctions, il est plus facile d’appliquer au processus le contrôle de qualités sur celles-ci. N’importe quel programmeur va avoir faire à la mémoire du code qu’il y a fait, il y a 2 jours. Il aura beaucoup de facilité à le corriger.
Une autre chose qui aide à livrer rapidement des logiciels de qualités, s’est l’automatisation des tests. J’entends déjà crier quelqu’un dans le fonds de la salle, automatisé les tests unitaires. Oui, il faut automatiser les tests unitaires, on devrait le faire dans tout type de projet, qu’il soit en agile ou non.
J’entends par l’automatisation des tests, pas seulement les tests unitaires. Mais, aussi, les tests fonctionnels, les tests intégrés.. Toutes formes de tests qu’un ordinateur peut faire aussi bien, peut-être mieux qu’un humain. La raison est fort simple, parfois en changeant une virgule dans programme, cela peut faire changer son comportement.
C’est aussi d’utiliser des moyens qui permettent de reproduire simplement et efficacement la série de tests qui doivent être appliqués avant la livraison au client, qu’il soit fait avec l’aide l’ordinateur ou non.
Il ne faut pas oublier que de livraison en livraison, le client peut s’amuser à retester une ancienne fonctionnalité, et il ne doit pas voir de différences (si aucun changement n’a pas été demandé). En passant toujours par la même moulinette de tests, on s’assure d’une non-régression généralement.
Le but de cet article n’était pas de parler l’automatisation des tests, tant son importance que des outils pour y arriver. Je dirais simplement que l’automatisation des tests, est l’un de moyens pour livrer, rapidement des morceaux d’une application fonctionnelle.
En livrant rapidement de petits morceaux d’application, cela nous aide à mieux comprendre le besoin du client. Il arrive parfois, que le besoin et la manière de le combler, ne soient pas clairs pour les parties impliquées.
Le client peut très bien exprimer quelque chose que lui est tout à fait simple, mais pour son auditoire, est très complexe. En donnant accès rapidement, étape par étape, aux fonctions de l’application, tant le client que les professions qui les construisent, ils arrivent à une meilleure compréhension de part et d'autre, sur les moyens nécessaires à combler le besoin.
Le but ultime de tout projet informatique, est de livrer un logiciel qui couvre toutes les fonctionnalités d’un client pour l’excursion d’un travail donné.
Un client peut demander un marteau pneumatique pour construire une cabane à oiseaux. Mais, parfois en lui faisant essayer un petit marteau avec manche en bois, il pourra s’apercevoir qu’il comble parfaitement son besoin.
Nombreux projets, tant les clients que les professionnels informatiques ont voulu en faire ce que j’appelle « un trip technologique », faire une voiture qui vole, qui roule et qui peut plonger dans l’océan pour aller voir le Titanic.
Les « trip technologiques » , c’est bien joli dans les laboratoires de recherche et mais pas dans la vraie vie. Notre premier travail, en plus de développer le logiciel, s’est d’abord d’accompagner le client dans sa compréhension de son besoin et surtout dans son expression.
Je me rappelle d’une étude de cas, que j’avais fait à l’université (ça remonte à plus 13-14 ans maintenant). La solution que mes confrères d’étude préconisaient coutait à l’œil plus de 100 000 $, pour petit système de facturation. A l’inverse d’eux, moi et un vieux sénior aux cheveux gris, on a proposé un bon vieux « pad de facture » et un petit système informatique (genre fortune1000 (logiciel comptable vendu en boite)) au bureau mère de l’entreprise.
L’entreprise en question était une petite compagnie d’aviation qui travaillait (transport de marchandises et de personnes) dans le Nord du Québec (donc pas d’électricité dans le nord). A l’époque le cout de portable était exorbitant (5000 $ et +) et en plus il aurait fallu une génératrice dans le nord. Vous comprenez que les couts s’approchaient du 100 000$.
Pourtant, ce que le client avait demandé, c’était un système « informatique » dans lequel il pourrait tout faire le suivi des transports de marchandises et de personnes.
Par contre, deux autre étudiants, moi (un jeune fou aux idées révolutionnaires) et une éminence grise (un vieux sénior en informatique qui faisait son baccalauréat pour s’amuser), préconisait était une solution beaucoup plus simpliste. Un logiciel de comptabilité en boite, genre Forturne 1000 (Logiciel comptable très respecter par les professionnels de la comptabilité) pour le bureau principal, et bon vieux pad de facture (Papier) et bon de livraison pour gérer les transports dans le nord.
Tout informatiser l’ensemble des processus, mettre le tout sous ordinateur auraient été un maudit beau « trip technologique ». Mais, est-ce que ça aurait répondu aux besoins, honnêtement je ne crois pas.
Devinez, c’est quoi la solution que le professeur accepta, et qui jugeait la meilleure, était bien celles du Pad de facture. Le plus drôle de l’histoire, c’était un cas réel que lui avait exécuté par le professeur lui-même. Il avait suggéré la seconde alternative, à quelque détail prêt et elle fut acceptée par le client.
Devinez, c’est quoi la solution que le professeur accepta, et qui jugeait la meilleure, était bien celles du Pad de facture. Le plus drôle de l’histoire, c’était un cas réel que lui avait exécuté par le professeur lui-même. Il avait suggéré la seconde alternative, à quelque détail prêt et elle fut acceptée par le client.
L’approche des petites livraisons, aurait surement aidé plusieurs confrères à mieux comprendre le besoin. Et surtout, à livrer au client ce dont il avait vraiment besoin.
Donc, ce dire agile, ce n’est pas, en ne faisant pas de documentation. Mais, c’est en produisant celle qui est nécessaire pour la compréhension de la fonctionnalité et d’assurer la qualité du logiciel. C’est aussi de garder en tête, que la documentation sert à la production d’un logiciel fonctionnel, et ce, le plus rapidement possible.
C’est aussi de livrer une solution simple et efficace pour résoudre le besoin exprimé par le client. Afin, de lui permettre une utilisation efficace de l’outil produit.
Bien entendu, en impliquant rapidement le client, et ce, rapidement dans le processus, cela va demander une approche différente avec le client. Mais, il ne faut pas oublier que le client reste le personnage le plus important dans tout projet informatique. Pas clients, pas de logiciel à produire.
Avant, le client s’investissait au début et à la fin du processus. Au début pour expliquer ce qu’il voulait. Et la fin, on lui demandé une période instance pour tout valider, soit plusieurs jours, plusieurs semaines prisent dans un bloc pour tout valider.
En agile, on ne lui en demande pas moins d’effort, mais on va la répartir différemment, quelques heures par cycles pour valider rapidement ce qui a été fait. (Un prochain article, traitera de la gestion des cycles et de leurs durées)
Je ne sais pas ce que vous en pensez, manger une banane par semaine, est beaucoup facile qu’un régime d’un seul coup.
Être agile, ce n’est pas de changer les choses, c’est simplement pensé différemment. Gardons ce qu’on fait de bien, et améliorons ce qui doit être amélioré.
L’équipe de Génération Agile.
