Cet article est une synthèse d’un échange sur une mailing-list interne Octo, qu’il nous a paru intéressant de partager. Merci à Jonathan Scher, Ludovic Cinquin, Yannick Martel, William Montaz et les autres pour leurs contributions. Bonne lecture !
Un de nos consultants est embarqué chez l’un de nos clients, dans un projet de dev d’une application web innovante, à interface très riche. Ce projet est conduit par le client suivant une bonne vieille méthode en cascade…
Il se trouve dans l’équipe en charge du développement du « front ». Le reste du projet (web-services et stockage) est réalisé par une autre équipe.
Et il et se désole tous les jours des freins qu’il rencontre à la production d’une application de qualité : IDE imposé et obsolète, système de gestion de versions inutilisable, batailles sans fin avec l’équipe d’architecture transverse qui impose des technologies obsolètes et incompatibles avec l’ambition du projet.
Les specs sont relativement contraignantes et conduisent au développement d’une appli assez pauvre sur le plan architectural (domaine anémique, code passe-plat…)
Au-delà de ces aspects techniques, le projet souffre également des défauts de la cascade : les écrans sont produits par une web-agency depuis longtemps, et l’intégrateur web à déjà créé 2 mois de stock en amont des développeurs, quand notre consultant se rend compte que le HTML produit sera inutilisable en l’état. Il faut reprendre HTML et CSS, ce qui donne des sueurs froides au chef de projet (planning), et à l’intégrateur web (qui n’a pas très envie de revenir sur 2 mois de travail).
Stocks, défauts qui s’entassent dans la chaîne de production … c’est-à-dire des freins à une production efficiente (cf Lean ou encore la théorie des contraintes de Goldratt)
Autant de raisons qui poussent notre consultant à argumenter en faveur de l’Agile auprès de notre client… mais il se voit opposer un certain nombre de contre-arguments.
Le design émergent voué à l’échec ?
L’agile ne serait que le développement de petites fonctionnalités les unes derrière les autres, sans penser au lendemain, et où l’on passe un temps très coûteux à refactorer. Notre client, lui, préfère penser au logiciel dans son ensemble tout de suite, prenant en compte immédiatement les besoins fonctionnels et non-fonctionnels pour définir dès le début l’architecture cible.
Pour Jonathan :
On est dans le pari classique du « Big Design Up Front » vs « architecture émergente ».
Lorsque je fais du BDUF, je fais le pari suivant : « Je passe du temps à concevoir quelque chose de générique et de réutilisable ».
Dans la pratique, on se rend compte que dans 80% des cas, la généricité n’est pas utilisée. Et elle ajoute une couche de complexité.
D’autant que dans le Big Design Up-Front, il faut penser à tout, tout de suite. Hors, nos projets sont de plus en plus complexes : appréhender le système dans sa globalité (infra, intégration, stockage, performance, sécurité, ergonomie…) est mission impossible. Surtout dans un contexte d’innovation.
Jonathan :
Lorsque je fais du design émergent, je fais le pari suivant : « Je fais du spécifique. Je passerai ensuite du temps à réutiliser mon code. Mais je passerai moins de temps à le faire que ce que j’aurais perdu à rendre TOUT réutilisable ».
La facture se paye, mais d’un côté on la paye tout au début, par une grande analyse, et de l’autre côté on la paye en refactoring. Et le refactoring, nous faisons tout pour qu’il soit le moins cher possible, notamment grâce au harnais de tests.
Enfin, quelque chose que je recommande sur tous mes projets : prendre en compte très tôt dans le projet les besoins non fonctionnels. Il faut 10’000 utilisateurs en même temps ? Je mets en place un test le prouvant dès le début, et je surveille tout au long du développement.
Mais comme le souligne William :
Le client a généralement du mal à accepter de passer du temps (ie. dépenser de l’argent) sur une révision de l’archi en cours de projet. Il perçoit ça comme une trahison, un mensonge sur la vitesse de livraison. Mais en fait l’agile ne promet pas d’aller plus vite.
L’une des promesses de l’Agile, c’est qu’au contraire, on PEUT se permettre une révision de l’archi. Introduire un ORM dans une couche d’accès aux données, découper un modèle de données en sous-parties et les déplacer dans l’infrastructure, changer de framework d’IHM … tout ça sont des chantiers qui bousculent le socle d’une appli et qui sont certes difficiles, mais néanmoins faisables. Surtout si on a mis en place un harnais de tests suffisamment complet.
Ce genre de chantier est carrément irréaliste en cascade, car on s’en aperçoit souvent trop tard, et il serait trop risqué et/ou coûteux de changer son fusil d’épaule.
En fait, faire du « design émergent » ne signifie pas qu’on arrête de travailler sur l’archi, bien au contraire ! Ca permet même aux architectes de se concentrer sur des problématiques moyen-terme (au travers de dossiers d’archi, de POC, de tests…), en faisant confiance aux développeurs pour prendre un certain nombre de décisions plus court-terme par eux-mêmes.
L’agile inadapté au « monde réel » ?
Mais au-delà de cela, pour ce client, l’agile est une belle utopie qui ne résiste pas au « monde réel » : celui de la contractualisation. Un budget doit être évalué en amont, le projet doit aboutir à la date convenue, le livrable doit être conforme au cahier des charges (obligation de résultat), et le tout doit respecter le « droit » en vigueur (contractualisation interne ou avec le fournisseur).
Jonathan :
Effectivement, le modèle même du forfait est la cause de beaucoup de problèmes. Faire un forfait « dans le monde réel », c’est :
– Réfléchir à ce dont j’aurai besoin dans un an
– Rechercher un prestataire capable de s’engager à y répondre.
Et ça ne marche pas.
Si tu pars de l’idée que tu ne sais JAMAIS ce que tu veux un an à l’avance, ce qui est vrai pour tous les projets « innovants », l’agile devient une solution. On va construire ensemble ce que vous utiliserez dans deux mois, puis on améliorera. Et, oui, c’est très difficile à contractualiser.
C’est le modèle même, qui diffère :
D’un côté, la vision prônée par l’Agile : L’informatique doit être un centre de gains, non de coûts. Pour cela, il faut répondre au plus vite et au plus près des besoins utilisateur.
En face, il y a le « vrai » monde. Celui qui contractualise, qui ne prend pas de risque, qui a plus à coeur de respecter un droit informatique que d’évoluer.
Et, oui, introduire un modèle d’innovation, c’est prendre un risque.
Et, comme le rappelle William, passer d’un modèle au forfait à un autre modèle beaucoup plus impliquant pour le client, car beaucoup plus collaboratif, ne se fait pas sans peine :
Dur à vivre pour le client en fait, habitué à être serein tout le long du projet et à serrer la vis sur la fin…
Habitué à serrer la vis sur la fin, ou encore qui trouve normal de passer des nuits blanches à intégrer les projets en provenance de plusieurs équipes et qui ne s’intègrent pas comme prévu dans la spec !
Alors, comment introduire le changement ?
Comment convaincre ce chef de projet ? Comment lui-même peut-il convaincre sa hiérarchie d’aller vers l’Agile ?
Pour Ludo,
On est dans les contre-arguments classiques de l’agile. Et on est modèle contre modèle, ce qui ne mènera pas bien loin.
Il a visiblement sa conception du monde et aucune douleur qui ne justifie qu’il la change.
Il a donc raison… :)
Yannick :
La douleur est encore le meilleur facteur pour pousser quelqu’un au changement, mais il faut encore que celui-ci reconnaisse qu’il puisse être aidé et te laisse une ouverture, te fasse une demande, bref comme dirait Sinek que son cerveau reptilien soit réceptif…
Et en général sa demande va être pour l’aider à lever la douleur, et pas se voir proposer un modèle (plus ou moins controversé et à la mode : SOA, Agile, programmation objet… on les a tous vu).
Voilà peut-être le coeur du problème : considérer l’Agile comme un modèle à déployer comme ce qu’il-est-écrit-dans-le-bouquin.
L’entreprise, ou l’organisation, doit penser son propre modèle de production, adapté à son besoin d’innovation, son business, ses collaborateurs.
Et puiser dans la boite à outil de l’Agile (ou d’autres approches : Lean, DevOps…) ce qui est adapté à son contexte.
11 commentaires sur “Quand l’Agile peine à s’imposer…”