Le logiciel, une industrie en « crise »

Même si les choses s'améliorent petit à petit, les projets de développement de software réussissent rarement. C'est une affirmation très approximative, puisque décider de la réussite ou de l'échec d'un projet reste dans une certaine mesure subjectif.

Le Chaos Manifesto, l'une des rares études un peu rigoureuse s'intéressant au sujet, propose les catégories suivantes :

• un projet réussi est un projet livré en respectant les budgets et délais impartis et fournissant les fonctionnalités préalablement requises ;
• un projet challengé est livré avec des retards, des dépassements de budget et / ou moins que les fonctionnalités demandées ;
• un projet échoué est tout simplement abandonné avant sa complétion, ou est livré mais jamais utilisé.

En 2012, à peine 39% réussissent d'après cette étude. Notez que d'autres contestent ces chiffres et donnent des résultats plus positifs.

Dans tous les cas, gardons à l'esprit que ces études restent au mieux approximatives et font intervenir une forte dose de subjectivité. D'ailleurs, la version 2015 du Chaos Manifesto a redéfini les critères de réussite pour faire intervenir une mesure de satisfaction client.

Pour juger de la difficulté de créer des logiciels, il reste les mesures « au doigt mouillé ». Anecdotes et expériences personnelles. Ressenti de développeurs. Témoignages d'entrepreneurs. Aucun professionnel censé ne prétend que construire un logiciel est une sinécure.

Cédric Bodin, rencontré lors de MixIT 2015 à Lyon, est l'auteur d'une excellente conférence intitulée le pourquoi de l'agilité. Il y explique l'évolution des méthodes et des pratiques de l'industrie du développement logiciel en les replaçant dans leur contexte historique, et décrit comment sont apparues les démarches agiles.

L'agilité est née d'une volonté de se doter d'outils et de pratiques adéquates, adaptées aux spécificités du développement logiciel.

Naissance de l'agilité

La littérature est abondante sur ce qu'est l'agilité. J'ai tenté de répondre succinctement à la question lors de la conf pour que tout le monde puisse suivre, mais j'ai bien conscience que c'était difficile à suivre pour des néophytes.

« Agilité » est un terme récent : il ne s'applique au développement logiciel que depuis 2001 et l'apparition du manifeste agile.

En 2001, 17 passionnés de l'industrie du développement logiciel se réunissent dans une station de ski. Ils vont tenter de répondre à cette question : « comment peut on procéder pour réussir à fabriquer des logiciels de manière plus fiable et efficace ? ».

En un week-end, aidés par le vin blanc et la fondue, ils vont réussir à publier quelque chose : le fameux manifeste agile. « Manifeste » est un terme quelque peu pompeux pour désigner deux pages web contenant à peine quelques lignes de texte.

Mais en terme d'idées, la qualité fait plus que la quantité. Le manifeste agile n'a fait que cristalliser un certain nombres d'idées qui existaient déjà au préalable, mais le fait de regrouper en un « paquet » cohérent a permis de les diffuser de manière massive.

Tout cela ne nous aide toujours pas à comprendre ce qui se cache derrière le terme d'« agilité ». Adopter une démarche agile revient simplement à revenir sur certaines idées reçues en matière de développement logiciel, et à remplacer certaines pratiques par d'autres.

L'agilité pourrait très bien se décrire par la manière dont elle s'oppose aux méthodes « traditionnelles ».

Qu'est-ce que l'agilité ?

Si vous avez déjà une vague idée de comment fonctionne un projet agile, vous pouvez passer direct à la section suivante.

Il existe mille et une façons de piloter un projet de développement logiciel. S'agissant d'une « science » relativement jeune (après tout, les ordinateurs n'existent que depuis quelques dizaines d'années), les pionniers de l'industrie se sont naturellement emparés de techniques qui existaient dans d'autres domaines : l'industrie primaire, l'architecture, etc.

Ces méthodes reposent en grande partie sur une approche prédictive et une volonté de contrôle très fort. Avant de démarrer le projet, on veut savoir combien ça va coûter et combien de temps ça va prendre. Et quand on construit une maison, on ne peut pas poser la première brique avant d'avoir un plan détaillé de l'ensemble.

Imaginez que vous soyez entrepreneur, que vous souhaitiez faire développer une application (web, ou smartphone, on s'en fout), et que vous contactiez une bonne vieille SSII old school. Le processus risque fort d'être le suivant.

On vous demandera un cahier des charges, et on vous fera un devis en retour. Un chef de projet réalisera un planning extrêmement précis des différentes étapes du développement avec de beaux diagrammes de Gantt. Un « architecte » sera responsable de convertir votre cahier des charges en un ensemble de documents de spécifications. Tel Moïse recevant les dix commandements de Dieu lui-même, l'équipe de développement recevra les spécifications et sera chargée de la convertir en code en respectant le planning édicté plus haut. Au bout du délai imparti, l'équipe termine le développement, réalise les tests, corrige les bugs, livre le logiciel, vous signez le bon de livraison, et peut-être aussi un contrat de maintenance.

On parle souvent de Cycle en V.

Ça c'était la théorie. La pratique est souvent toute autre. Examinons les prérequis au fonctionnement d'une telle méthode de travail.

Commençons par le cahier des charges. Sa rédaction suppose que, avant même le début du projet, vous sachiez avec une très grande précision ce que vous souhaitez obtenir à la fin. Or, c'est impossible, pour moult raisons. D'abord, écrire des logiciels n'est peut-être pas votre métier, et vous n'avez pas forcément une vision très claire des différentes contraintes et difficultés techniques de ce que vous demandez. Une « même » fonctionnalité, d'un projet à l'autre, pourra être réalisée de manières très différentes, et vous n'avez probablement aucune idée du niveau de précision nécessaire dans votre description pour lever absolument toute ambigüité. Ensuite, vous êtes dans une phase de pré-lancement de votre projet, vous ne savez peut-être pas quelles fonctionnalités parmi les centaines envisagées auront la meilleure valeur ajoutée. Peut-être enfin que confronter vos hypotèses (un prototype) à la réalité (les utilisateurs) vous aurait permis d'apprendre certaines choses et de revenir sur un certain nombre de décisions.

Passons maintenant du côté du devis. D'abord, soyez certain·e que l'équipe technico-commerciale chargée de répondre aux appels d'offre minimisera le devis au maximum pour s'assurer de remporter le contrat. Quitte à gratter au maximum pendant le reste du projet ou demander aux devs de réaliser quelques nuits blanches avant la deadline. On présuppose aussi que l'on peut estimer le temps et l'énergie nécessaire à la réalisation du logiciel demandé avec une très grande précision, ce qui est une imposture qui confine au canular. Chaque projet est unique au niveau de l'équipe, des technologies employées, des problèmes rencontrés, des bugs à corriger, etc. Je ne connais aucun dev capable d'estimer avec une précision proche des 100% une tâche de quelques heures. Peut-on prétendre estimer un projet de plusieurs mois ?

Je m'arrêterai là pour ne pas trop m'étendre, mais le reste du projet est à l'avenant. Ces méthodes sont inadaptées, parce qu'elles sont nées d'idées erronées, tout simplement. Et s'il est si difficile de les remettre en cause, c'est parce qu'elles restent malgré tout séduisantes et confortables. Prétendre qu'on peut estimer le coût de développement d'un logiciel permet de vendre sa prestation plus facilement, de la même manière qu'il est plus facile de chercher ses clés sous le lampadaire parce qu'il y a de la lumière même si on les a perdu ailleurs.

Comparons maintenant un projet réalisé par une équipe « agile » (notez que l'exemple qui suit reste un cas concret parmi d'autres, il y a plusieurs façons d'être agile).

Vous contactez l'équipe. Au cours d'un atelier d'une journée, l'équipe vous aide à constituer un référentiel de fonctionnalités, sous une forme très peu détaillée, e.g « en tant qu'utilisateur, je peux accéder à une interface d'administration pour éditer un billet de blog ». Vous choisissez les quelques fonctionnalités qui vous semblent le plus importantes à l'instant T, vous en discutez avec l'équipe, et la réalisation commence. Au bout de deux semaines, on vous livre une version fonctionnelle de ces fonctionnalités. C'est à dire que vous obtenez une première version de votre projet, certes très partielle, très minimaliste, mais tout ce qui est livré est finalisé et testé. À partir de là, libre à vous d'embrayer sur une autre itération, et une autre, et une autre. Vous pouvez réaliser six itérations à la suite jusqu'à obtenir un produit fini, ou partir sur une itération tous les deux mois pour faire vivre et évoluer lentement votre produit.

Bien entendu, dans ce cas là, vous ne savez pas à l'avance combien vous coûtera le développement au final. Mais la vérité, c'est que personne ne le sait. L'équipe agile n'essaye pas de vous rassurer en prétendant le contraire.

Être agile, ce n'est pas travailler à l'arrache

Nombreux sont celles et ceux qui, confronté·e·s pour la première fois aux idées de l'agilité, ont l'impression qu'il s'agit de travail bâclé, au radar, à l'arrache.

C'est loin d'être le cas. C'est même tout le contraire.

Partant du principe que l'incertitude est très forte, et qu'on ne peut pas faire grand chose pour la réduire, on va simplement adopter une approche réaliste et se doter d'outils qui vont permettre aux membres du projet de rectifier très rapidement le tir en cas d'imprévu.

Est-ce que l'agilité fonctionne ?

L'agilité consiste à accepter que certaines idées sont erronées pour abandonner les pratiques qui en découlent pour les remplacer par d'autres. Il semble évident que l'agilité ne peut que mieux fonctionner.

Mais est-ce vrai ? À priori, oui. L'étude citée plus haut le confirme : les projets réalisés avec une démarche agile ont moins de chance d'échouer que les autres. Néanmoins, dans la mesure ou les critères de succès d'un projet sont en partis subjectifs et définis par l'organisation même qui réalise le projet, on se doute que ces chiffres sont à prendre avec un certain recul.

Reste encore une fois le « doigt mouillé », qui semble aller dans le même sens. À titre personnel et en tant que développeur, je peux dire que les projets sur lesquels je travaille actuellement foirent moins qu'avant ma découverte de l'agilité, et mes clients semblent plus souvent satisfaits. Je n'ai certes pas la prétention de constituer un échantillon représentatif, mais nombreuses sont les équipes dont les pratiques s'apparentent à l'agilité et qui réalisent des projets fantastiques, et l'on est bien obligé de reconnaître que les pratiques issues de l'agilité sont bien souvent plus cohérentes avec la réalité.

Malgré tout, un projet informatique n'est pas une tâche automatisable et reste toujours une aventure humaine. Aucune méthode ne peut assurer un taux de réussite de 100%, et un projet réalisé avec de « vieilles méthodes » n'est pas assuré d'échouer. Essayons donc de ne pas nous départir de notre sens critique.

D'excellents produits comme Github ou Firefox n'auraient pas pu être créés d'une manière monolithique, ils sont le résultat d'une lente évolution.

Quand l'agilité foire

Il existe d'innombrables raisons pour lesquelles un projet réalisé avec une démarche agile peut échouer. Mais il existe une erreur qui revient assez souvent, et qui est responsable de l'échec de nombreux projets. J'ai commis cette erreur, je sais de quoi je parle. Le processus est globalement toujours le même.

L'agilité est un terme marketing. C'est à dire que c'est un mot parapluie permettant d'englober plusieurs idées pour en faciliter la diffusion (pas forcément commerciale). Comme tout terme marketing à la mode, il peut être vidé de son sens et employé à tort et à travers, comme le sont souvent les termes « big data » ou « éco-responsabilité ».

Revenons sur la définition de l'agilité.

À la base du manifeste agile, il y a quatre valeurs.

Nous cherchons à valoriser :

1. Les individus et leurs interactions plus que les processus et les outils
2. Des logiciels opérationnels plus qu’une documentation exhaustive
3. La collaboration avec les clients plus que la négociation contractuelle
4. L’adaptation au changement plus que le suivi d’un plan

Tout le monde a au moins une vague compréhension intuitive de ce qu'est une valeur : c'est une idée générale servant à guider le jugement. L'honnêteté est un exemple de valeur.

Une valeur est un concept abstrait, donc non praticable directement. Je ne peux pas directement pratiquer l'honnêteté, pas plus que je ne peux directement « privilégier les humains plutôt que les process ». En revanche, d'une valeur, je peux formuler un certain nombre de principes.

Un principe est une règle de conduite concrète qui permet d'être en cohérence avec des valeurs. « Je paye toujours ma note au restaurant » est un principe qui me permet d'être en cohérence avec la valeur « honnêteté ».

Ainsi, dans le manifeste, des quatre valeurs initiales découlent douze principes. C'est déjà un peu plus concret, mais pas encore tout à fait assez.

Si on veut s'assurer de suivre tous les principes du manifeste, il va nous falloir un cadre un peu plus structurant. Et c'est là qu'interviennent des méthodes comme Scrum ou XP. Scrum n'est rien d'autre qu'un cadre de travail, un ensemble de pratiques et d'outils qui nous permettent de pratiquer les principes et les valeurs du manifeste.

Il est bien évident qu'aborder l'agilité se fait généralement par le bas de la pyramide. Développeur néophyte, vous joignez une équipe qui a mis en place Scrum. Ce que vous verrez de l'agilité, ce ne sont pas les valeurs, qui sont abstraites, mais bien les pratiques concrètes et quotidiennes de Scrum.

Partant de là, il est facile de confondre le conteneur et le contenant, et de se faire la fausse idée que Scrum == Agilité.

On peut comprendre pourquoi une équipe, constituée sur un nouveau projet, en arrive à se dire « soyons agile, utilisons Scrum », alors que peut-être Scrum n'est pas du tout adapté au contexte du projet. Ce genre de décision est le contraire même de l'agilité.

Il est important de comprendre que les pratiques dites agiles (backlog, user stories, itérations, etc.) ne sont que des points de départ, des moyens de pratiquer les valeurs de l'agilité. J'ai déjà croisé des équipes qui se croyaient agile et qui étaient tout sauf ça. Si vous êtes dans ce cas, vous ne bénéficiez pas des avantages de l'agilité ; vous obtenez en fait le pire des deux mondes.

Pourquoi l'agilité fonctionne ?

Il existe une abondante littérature pour faire l'apologie des différentes pratiques de l'agilité. Revenons donc à notre manifeste pour nous intéresser aux quatre valeurs de base. Une question intéressante : pourquoi ces quatre là et pas d'autres ? Et pourquoi sont-elles pertinentes ?

Mon avis est que ces quatre valeurs fonctionnent pour une seule et bonne raison : nous sommes tous des humains. À ma connaissance, aucun robot ou IA n'est à ce jour capable de construire un logiciel, par conséquent chaque software est né d'une équipe d'humains embauchant ou embauchés par des humains pour construire des logiciels à destination d'humains.

En tant qu'humains, nous sommes câblés d'une certaine façons. Certes, les divergences individuelles existent, mais nous sommes tous semblables sur les points essentiels.

L'agilité et au delà

La diffusion des idées de l'agilité a permis une remise en cause massive d'un certain nombre d'idées et de valeur. Et si ces nouvelles idées se répandaient en dehors de la sphère de l'industrie du logiciel ?

La déshumanisation des activités humaines est endémique. La dictature de la démarche qualité se répand dans les organisations et de plus en plus, on nous impose process et objectifs trimestriels.

Nombreux sont les managers qui aimeraient transformer les membres de leurs équipes en robots : pas d'initiative, pas d'erreur. Mais les humains font de mauvais robots. Enlevez leur la nécessité de réfléchir, transformez leurs jobs en une liste de tâches abrutissantes et répétitives, et vous en ferez plutôt des zombies, malheureux et inefficaces.

La tendance est à l'automatisation des tâches automatisables, ce qui est plutôt une bonne chose, à condition que l'on arrive à trouver une organisation sociale et économique qui ne fasse plus de l'emploi la seule condition d'accès à un revenu minimal.

Pratiquer l'agilité nous aide à nous rappeler qu'un chiffre n'est qu'on chiffre, et que nous travaillons à la base pour et avec des humains. En gros, arrêtons de nous considérer les uns les autres comme des vaches à lait ou des machines sur des chaînes de montage.

Zi enned

Pour conclure, tâchons de retenir ceci. Si quelqu'un prétend pouvoir deviner sans faille à l'avance la durée et le coût d'un logiciel, je pense que cette personne est un charlatan. Si quelqu'un prétend qu'une méthode agile va garantir à 100% la réussite de votre projet, c'est un autre charlatan.

J'espère que cette version écrite aura été plus claire et détaillée que la version orale. Au plaisir d'en discuter autour de votre boisson préférée.