Soyez (vraiment…) agiles

Aujourd’hui, si vous regardez les offres d’emploi pour les boîtes d’informatique, la très grosse majorité entretient un discours du type « regardez, on est hype, on utilise les méthodes agiles« . Le problème, c’est que comme pour le métier de de chef de projet technique, derrière on trouve absolument tout et n’importe quoi.

Débloque les + belles offres tech en 10 mins

Les méthodes agiles, c’est quoi ?

Les méthodes agiles sont parties de plusieurs constats simples : le client ne sait souvent pas exprimer ses souhaits correctement, et par ailleurs la qualité n’est souvent pas au rendez-vous pour cause de délais compressés. Bref le traditionnel cycle en V, utilisé dans l’industrie, n’est pas applicable au monde du logiciel. L’idée pour pallier à ces problèmes a donc été de mettre en place un système de release early, release often afin que le client puisse voir souvent des versions de l’application en fonctionnement. Pour la qualité on utilise des méthodes telles que l’extreme programming, le continuous delivery, ou encore le Test Driven Development (TDD), et pour l’organisation une méthode comme Scrum est souvent appliquée. La livraison de l’application est faite « quand c’est prêt », c’est à dire quand tout le monde est content du résultat obtenu. (Bon maintenant faut pas abuser non plus sur les retards…) L’idée derrière tout ça est aussi de réduire la pression sur les développeurs, de façon à ce qu’ils travaillent moins à l’arrache. Maintenant voyons les dérives engendrées par ces méthodes, si mal appliquées.

Release often, release a lot

Dans de nombreuses organisations, les méthodes Agile ont été mises en place dans l’idée « c’est génial, maintenant on va pouvoir faire en trois semaines ce qu’on faisait avant en six semaines ». Néanmoins les développeurs se retrouvent à devoir travailler quinze heures par jour, ou à venir le samedi (en travaillant souvent gratos). La qualité en pâtit car il faut à tout prix tenir les délais, sinon c’est le coup de tatane de la part de la hiérarchie, avec parfois des licenciements à la clef. Et si l’application est livrée dans les temps, la qualité étant bien souvent alors déplorable, certains développeurs sont licenciés aussi histoire d’accentuer la pression sur les autres.

Il va sans dire qu’on se retrouve dès lors dans une logique « perdant-perdant », les développeurs étant perdants au niveau de leur santé, l’entreprise étant perdante au niveau de la réputation qu’elle a auprès de ses clients. Mais bon, ça satisfait les dirigeants à vision court-termiste, qui peuvent dire dans leur bilan « vous voyez on a cassé les prix », donc tout va bien dans le meilleur des mondes…

Un petit florilège de situations que j’ai pu voir lorsqu’une telle politique était appliquée :

• Un manager qui dit, pour une application qui a été chiffrée à quatre mois sans interroger les techs : « on va faire de la qualité sans transiger sur les délais ».
• Dans un autre cas, pour l’appli ils commencent à appliquer les bonnes pratiques, et voyant que du retard à été pris, ils commencent à désactiver les tests unitaires ainsi que Sonar sur le projet. Et à la fin, la direction réunit tout le monde et dit le plus sérieusement du monde : « on n’a pas le temps d’écrire les tests » et peu après « je ne veux plus aucune régression ».

Enfin dans un sprint Scrum, il est courant d’avoir plus de travail que la capacité de l’équipe histoire que celle-ci ne se retrouve pas à rien faire en milieu de sprint. Cela ne signifie pas qu’il faut tout faire pendant le sprint, juste correspondre à la capacité de l’équipe. A bon entendeur.

Scrum c’est chouette, on partage l’information

Oui c’est vrai que c’est bien de pouvoir partager l’information, ça change des situations où pour protéger leurs postes les gens préfèrent garder une partie des informations capitales pour eux. Sauf que les directions s’en servent aussi lors de l’entretien annuel pour dire : « tu vois, je ne vais pas t’augmenter. Et de toute façon si tu pars quel est le problème ? Les autres connaissent les mêmes informations que toi, donc il n’y aura aucun souci pour te remplacer ». Et là c’est encore une grave erreur car le turn-over est probablement encore plus catastrophique pour une application développée en méthodes agiles qu’une autre. En effet en Scrum, par exemple, ce sont les développeurs qui s’assignent leurs propres tâches, ce qu’un nouveau ne sera par essence pas capable de faire. D’autre part comme tout a été fait à l’arrache, rien n’est documenté et le nouveau, en plus d’être plus long à monter en compétences, risque de casser des trucs. Et ça ne sera vu que bien plus tard, puisque les tests automatisés n’ont pas été mis en place.

Scrum comme outil de flicage

On trouve aussi parfois des organisations qui regardent à chaque sprint le nombre de user stories traitées par chaque membre de l’équipe, histoire de sanctionner ceux qui en ont moins fait que les autres. On s’approche alors du Stack Management employé chez Microsoft, un système qui a eu l’effet exactement inverse de ce qui était initialement prévu. Sauf qu’un tel système fait que plus personne ne s’occupe de la maintenance technique du projet, avec des tâches de refactoring ou d’amélioration de la qualité, vu que ce ne sont pas des user stories. Et c’est comme ça qu’on arrive à une dégradation de la qualité.

Entreprises, remettons les choses dans leur contexte

Les méthodes agiles n’ont clairement pas pour but de permettre de livrer plus vite, mais bien de livrer mieux. Autrement dit, lorsque vous mettez en place les méthodes agiles, il est même possible qu’au début vous constatiez un ralentissement des livraisons, avant que celles-ci ne reprennent leur rythme antérieur. Cela dit, l’idée est qu’on puisse obtenir des applications qui à la fois satisfont davantage le client et sont plus maintenables techniquement et mieux testées.

Et c’est à ce titre qu’à terme, les méthodes agiles peuvent, je dis bien peuvent, vous faire gagner en vitesse de livraison. En effet ce qu’on trouve souvent dans le monde du logiciel est le « fast, slow, slower ». Autrement dit on commence à faire une application à l’arrache, et les fonctionnalités sortent rapidement, puis peu à peu le tout s’essouffle car il devient très compliqué de rajouter quelque chose sans casser le reste, jusqu’au point où il devient pratiquement impossible d’ajouter quoi que ce soit. Au contraire, une application correctement développée en TDD avec une bonne couverture de tests, autrement dit au moins 80%, commencera certes plus lentement mais on pourra continuer à la développer toujours à la même vitesse.

En ce qui me concerne j’avais développé comme ça une appli serveur en TDD, un truc en PHP/Symfony 2. Au départ quand je suis arrivé dans l’entreprise en question on avait énormément de retard, et quand je parlais de certaines méthodes agiles telles que le TDD et l’intégration continue, tout le monde m’a rigolé au nez. Finalement, au bout d’un mois et demi de travail j’avais un truc qui dépassait largement fonctionnellement tous les besoins des autres équipes qui n’utilisaient pas le TDD, et elles en étaient encore empêtrées dans les bugs. Six mois plus tard je glandouillais sévère alors qu’elles étaient empêtrées dans leurs bugs, toujours les mêmes, et quand je leur parlais de TDD ils me disaient « mais non ça ne sert à rien »…

Et si vous voulez mettre en place l’extreme programming

Pour résumer l’extreme programming, c’est une méthodologie où il y a deux développeurs sur un poste, l’un code et l’autre commente. Au départ on écrit un test unitaire sur ce qui doit être développé. Celui-ci doit échouer, comme en TDD, et ensuite le développeur sur le clavier doit coder l’appli de façon à ce qu’il passe au vert. Une fois que c’est fait, on committe les changements, et on inverse les rôles.

Il faut savoir que cette méthode est extrêmement épuisante mais permet aux gens de monter en compétences entre eux, et si c’est bien appliqué bien souvent d’augmenter les rendements. Par contre ne soyez pas choqués si vos développeurs qui appliquent ça travaillent au maximum 35h par semaine, c’est normal, ils ne pourront pas davantage car ils seront lessivés. Pour info un développeur en mode « normal » ne devrait pas travailler plus de 40h par semaine sous peine de produire du code moisi.

Le mot de la fin

Développeurs, si vous voyez une entreprise qui vante ses méthodes agiles, n’hésitez pas à poser un maximum de questions pour savoir comment ça se passe. Si vous tombez dans les cas cités au-dessus, fuyez !

Entreprises, les méthodes agiles ne sont pas des solutions miracles mais des solutions basées sur du bon sens. Si vous les détournez pour augmenter la pression et le flicage sur les gens vous avez tout faux, et à terme vous risquez de le payer. A bon entendeur.

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Ecrire du code testable en Java/JEE
• Le métier de chef de projet technique par rapport au métier de développeur

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn