En 2001, le Manifeste pour le développement agile de logiciels a formulé une prise de position des développeurs contre la gestion top-down des projets logiciels.

Les principes de ce manifeste sont difficiles à contester, et ils ont le mérite d’être d’une simplicité rafraîchissante. Tout se résume à faire fonctionner le logiciel le plus vite possible, à intégrer le client dans l’équipe, et à s’adapter au changement — plutôt que de tout planifier en amont, de livrer, et d’attendre que ça parte en vrille.

Sauf qu’en 2017, « l’agile » est devenu quelque chose que le management veut imposer aux développeurs. Et il a ramassé pas mal de bagages en chemin.

Comme les cochons dans La Ferme des animaux d’Orwell, les adeptes de Scrum finissent par ressembler aux disciples obsédés par la méthodologie contre lesquels le manifeste agile originel s’était justement rebellé.

Scrum, une méthode spécifique de gestion de projet, est devenu presque synonyme du mot agile. Comme c’est souvent le cas dans les cultures portées par les développeurs, il a accumulé protocoles, tactiques et jargon, à la manière d’une boule de neige qui dévale une pente. Quand Scrum ne tient pas toutes ses promesses, la réponse habituelle est que vous ne l’appliquez pas correctement ; si vous n’avez pas embrassé chaque élément de Scrum dans sa totalité, vous faites du « faux agile » et votre projet est condamné. Il vaut la peine de mettre cela en regard du manifeste agile originel. Comme les cochons dans La Ferme des animaux d’Orwell, les adeptes de Scrum finissent par ressembler aux disciples obsédés par la méthodologie contre lesquels le manifeste agile originel s’était justement rebellé.

Illustration Scrum

Rien de tout cela ne signifie que l’agile, ni même Scrum, soient de mauvaises choses. Obtenir du code fonctionnel au plus tôt ; faire des démos et itérer dans des cycles réguliers et limités dans le temps ; intégrer le client à l’équipe et utiliser un backlog pour gérer les évolutions — ce sont des principes que nous appliquons chez Made Media. Mais on parle ici du cycle de développement logiciel. Or, la conception d’un site ou d’une appli ne se réduit pas au développement logiciel au sens strict. Scrum n’a pas vraiment de place pour le design à l’échelle macro. Nous combinons donc les processus de développement agile avec un pragmatisme global de projet : juste assez de conception en amont pour éviter les impasses, et sans déléguer entièrement la QA à des tests unitaires qui mesurent la qualité à travers le seul prisme du code.

Ce phénomène se manifeste généralement quand le rôle du chef de projet évolue vers une activité consistant à demander à l’équipe de production ce qui se passe, puis à mettre à jour son diagramme de Gantt pour mieux coller à la réalité. La réalité qui remue le chien fictif par la queue.

L’agile est souvent opposé à la méthode Waterfall, où toutes les tâches sont préplanifiées sur un immense diagramme de Gantt qui ressemble de plus en plus à une œuvre de fiction au fur et à mesure que le travail avance. Ce phénomène se manifeste généralement quand le rôle du chef de projet évolue vers une activité consistant à demander à l’équipe de production ce qui se passe, puis à mettre à jour son diagramme de Gantt pour mieux coller à la réalité. La réalité qui remue le chien fictif par la queue.

Illustration pluie

Oui, le Waterfall a ses problèmes. Mais souvent, quand on pointe du doigt des méthodes comme PRINCE2 ou des certifications comme PMP, les partisans de l’agile se trompent sur la vraie finalité de ces méthodologies. PRINCE2, par exemple, a en réalité très peu de choses à dire sur la livraison du projet. Ses origines se trouvent dans l’achat public, où la livraison est le plus souvent assurée par un prestataire externe (comme nous !) et est considérée comme l’affaire du prestataire. La vraie vocation de PRINCE2 n’est pas de livrer le projet, mais de produire suffisamment de documentation C.Y.A. pour prouver que ce n’est pas la faute du chef de projet quand le budget double et que le produit reste introuvable.

Ce qui ne veut pas dire que PRINCE2 est mauvais en soi. Son objectif est de maîtriser la gouvernance du projet, pas sa livraison. S’assurer qu’un projet est lancé avec un business case solide. Définir à quel moment il faut tirer le signal d’alarme. Anticiper et consigner les risques. Ces garde-fous sont importants quand vous devez rendre des comptes sur vos budgets. C’est une question de vision d’ensemble.

Les projets web sont un terrain risqué. Le périmètre est si difficile à définir par écrit qu’on ne sait jamais vraiment ce qu’on va obtenir — ni même ce qu’on veut — avant de le voir. C’est l’une des raisons pour lesquelles nous préférons les wireframes aux listes de spécifications. Mais personne ne va vous signer un chèque en blanc pour votre projet web, et vous allez devoir donner à votre conseil d’administration, ou à votre commanditaire, quelques garanties sur ce qu’ils ont en échange de leur argent. Il faudra donc inévitablement s’engager concrètement sur des fonctionnalités, des budgets et des délais dès le départ. C’est précisément ce que les méthodologies portées par les développeurs ont tendance à esquiver. Vous devinez pourquoi ? Parce que les développeurs sont à l’aise pour écrire du code, pas pour faire des promesses commerciales.

Chez Made Media, nous sommes conscients que les budgets de projet ont souvent pris des années à obtenir, et qu’ils ont été accordés avec des attentes précises quant aux résultats. Les méthodologies de développement agile ne nous dispensent pas de notre engagement à honorer ces attentes. En travaillant à budget fixe, nous devons tempérer Scrum avec quelques réalités commerciales. Nous estimons en heures, pas en pseudo-abstractions comme les story points. Même si ça casse parfois le flow d’un développeur.

Chez Made Media, nous utilisons donc une méthode qui emprunte beaucoup à Scrum, et un peu à DSDM et Kanban. Les clients sont les bienvenus aux réunions de sprint planning, voire aux stand-ups quotidiens s’ils le souhaitent. Mais un appel et une démo hebdomadaires, c’est le minimum. Pour ce qui est du cadrage, de la gouvernance, du reporting et de la redevabilité, nous fonctionnons plutôt selon les lignes de PRINCE2. Et il n’y a aucune contradiction là-dedans.

Lectures recommandées

  • Peopleware Demarco et Lister démontrent que les principaux problèmes du développement logiciel sont humains, pas techniques.
  • The Mythical Man-Month indispensable pour quiconque gère des projets complexes.
  • Agile Manifesto à la recherche de meilleures façons de développer des logiciels, en pratiquant et en aidant les autres à faire de même.
  • Scrum un cadre de développement logiciel agile, itératif et incrémental, pour gérer le développement produit.
  • DSDM méthode de développement dynamique de systèmes.
  • Kanban un système de planification pour la production allégée.
  • Une critique de Scrum illustrée avec des mèmes de premier ordre.

Le mois prochain : L’innovation avec un sens