Les méthodes Agile sont très populaires à l’heure actuelle. Tous les gestionnaires de développement logiciel ont le mot Agile sur les lèvres. Tous et chacun ont développé leur méthodologie. Tous discutent de méthode Agile. Les journaux et magasine décrivent les méthodes Agile partout. Même Scott Adams en parle dans une bande dessinée de Dilbert. Tout le monde informatique est Agile et pragmatique.
Il y a bientôt 3 ans que je regarde l’évolution des méthodes Agile. Bien que le nom Agile soit de plus en plus entendu dans tous les milieux, je me rends compte qu’il n’est pas compris. Je ne compte plus le nombre de fois que j’ai rencontré des clients, fournisseurs et collègues qui ne comprennent pas les fondements du manifeste Agile. Pour la majorité des gens que j’ai rencontrés, tous s’entend pour avoir de courtes livraisons mais rien sur les autres principes Agile. Quand les problèmes surviennent, la notion de partenaire prends le chemin des poubelles et ont retourné à une relation client-fournisseur. On fixe la date de livraison et le budget et on s’en remet à un plan fixe. Les fonctionnalités sont soumises sans travail de priorisation et d’organisation. Lorsque la date et le budget survienne et qu’il reste des fonctionnalités à développer, le client se retranche dans un campement contractuel prétextant qu’on avait promis de faire le travail. Le manifeste est complètement ignoré.
À l’autre extrême, il y a les gestionnaires qui ne planifient plus, qui ne mettent plus de processus en place, ne documente plus rien et n’apporte pas d’attention aux détails contractuels. Cette attitude est proche du laisser-aller et n’est pas approprier pour la majorité des clients. Il en est toujours que les clients désirent avoir une bonne idée du budget et de la date de livraison.
D’autre gestionnaire argumenterons que les projets Agile conterons moins cher ou seront complétés plus rapidement. Cette notion est aussi fausse. Comme Ryan McNimm de Unspace.ca explique dans son vidéo, les projets Agile sont généralement plus dispendieux et plus long qu’un projet standard. Cette déclaration semble dénuée de sens et suicidaire financièrement pour le programmeur. Si un projet Agile est plus cher et qu’il prend plus de temps à réaliser, il faut se demander quel est le gain véritable d’utiliser les méthodologies Agile?
La qualité d’un projet Agile mené tel que le manifeste et les principes Agile le présente est la qualité du produit réalisé. En ayant des d’itérations régulière, le client est apte à porter un jugement éclairé sur la qualité du logiciel produit. Ici il faut lire que la qualité est fonctionnelle et qu’on ne parle pas de la qualité du code. La qualité est supérieure, car le client vérifie à chaque itération les fonctionnalités. Suite à la revue, le client a l’opportunité de fournir un nouvel ensemble de fonctionnalité ou conclure le projet. Il n’y a aucune honte à arrêter le projet. Nous avons une certaine fierté à toujours compléter nos entreprises débutés même si nous savons pertinemment que le projet est voué à l’échec. La méthode Agile permet de ne pas sur concevoir et réduire les coûts en cas de route vers l’échec.
Le projet devrait toujours être en fait en temps et matériel du leur nature hautement variable. Martin Fowler compare la programmation à une commande d’art de l’ancien temps. Bien que l’artiste à une indication de la direction de la réalisation, il continuera son travail jusqu’à la satisfaction du client. Il ne faut pas croire que la programmation est un acte de production. Tout comme l’artiste, le développement logiciel fait appel à des techniques et des enseignements des maîtres et des pairs. Tous comme l’artiste, il est possible de mieux travailler et de fournir un meilleur travail de qualité avec du travail et de l’expérience. Seulement lorsqu’il est possible de faire du travail répétitif et prévisible seront nous capable de prédire le coût du développement logiciel. À partir de ce moment, ce n’est plus du développement logiciel, mais de la gestion d’opération.
Est-ce que tout est fini pour le manifeste Agile? Est-ce que nous devons donc déclarer forfait et retourner à des méthodes traditionnelles Waterfall? Je crois que non. Pour ceux qui comprennent les méthodes Agile et suivent les méthodes Agile comme un guide et non une finalité, c’est de notre responsabilité de communiquer à notre entourage professionnel les bienfaits des méthodes. Il est très difficile d’expliquer les bienfaits de la qualité. Il est difficile d’expliquer que le logiciel ne coûtera pas moins cher, mais au contraire généralement plus cher. Il est difficile d’expliquer que le client aura un avantage concurrentiel à utiliser ses méthodes. Comme écrit dans le manifeste :
Nous avons découvert des techniques pour développer du logiciel et nous désirons en faire profiter nos pairs.
C’est pourquoi je crie haut et fort : « Arrêtez la perversion du manifeste Agile » Manifeste Agile (traduction M2i3)
