Faut-il vraiment renier les méthodes agiles ?
Suite à mon précédent article, il m’a été demandé si j’allais me mettre à critiquer les méthodes agiles. Désolé, il n’en est rien. Je ne renierai, et ne critiquerai pas les méthodes agiles.
Ma raison est très simple :
J’ai eu la chance de faire de l’agilité sans le savoir, à une époque ou personne ne parlait d’agilité en France. Par la suite, un collègue m’a fait découvrir l’Extreme Programming (XP). Ce fut une vraie révélation. Depuis, l’amélioration continue est devenue ma façon de vivre le développement logiciel.
Donc non, je ne peux pas critiquer l’agilité. Je reconnais qu’il y a une véritable mode à ce sujet depuis quelques années. Une sorte de tendance à suivre... (ou pas).
Pourquoi ?
Si vous êtes attentifs, vous vous rendrez compte que nombre de détracteurs de l’agilité vantent les métrites du DevOps, ou du DevSecOps, tout en reniant Scrum, et/ou le manifeste agile.
Vous vous dites peut-être que je tends à faire une grosse généralité, et que je mélange tout. Très bien, vous êtes attentifs, et comprenez le sujet. C’est exactement là que je souhaite vous mener.
Au sujet du manifeste agile :
j'avoue que je ne suis pas fan. À mon sens, ce n'est pas utile. Il s'agit d'une déclaration d'intention à laquelle tout le monde ne doit pas être tenu. Chaque équipe doit être libre, et doit faire évoluer sa méthode en fonction de ses propres objectifs, et de sa maturité.
L’agilité : « comptable désignée » ?
Avec le temps, l’agilité est devenue un gros four tout purement commercial pour certains. Cela va de l’ESN, aux coachs agiles, en passant par les AMOE, AMOA, et chefs de projets convertis à la hâte en Scrum Masters.
Oui, je mets les coachs agiles dans ce panier de crabes. Tous ne sont pas concernés pour autant. Je désigne ici le coach qui travaille 100% de son temps pour une même équipe depuis des années… Pourquoi cette équipe ne vole-t-elle toujours pas de ses propres ailes ?
L’agilité a été un beau business. Mais certains clients se sont rendu compte que les promesses n’étaient pas au rendez-vous.
Par chance, DevOps est arrivé (« sans se presser, le grand Zorro… »).
Il fallait donc changer de méthode, et blâmer l’agilité. Sans pour autant se rendre compte que l’agilité était une composante de DevOps. Mais ceci est un autre sujet.
Conclusion
Je pense donc que le problème est lié aux personnes qui ont fait de l’agilité leur business, mais qui n’ont pas su adhérer aux méthodes.
Et la suite ?
Peut-être, pensez-vous que DevSecOps est arrivé et qu’il faut chasser DevOps. Désolé, je ne critiquerai pas DevOps au profit de DevSecOps. J’ai toujours considéré que la sécurisation de la chaine de production, et livraison faisait partie du package. Pour moi, DevSecOps est un nouveau terme marketing. Mais s’il peut faire comprendre que la sécurité doit être incluse by design dans le DevOps, je ne peux pas non plus le critiquer.
Comme l’agilité, DevOps n’est pas figé, et s’inscrit dans une logique d’amélioration continue.
Exemple :
La disparition progressive des Personnel Access Token dans Azure DevOps, n’est pas « une nouveauté DevSecOps ». C’est une évolution qui s’inscrit parfaitement dans la logique Zero Trust que nous devrions tous adopter. En 2025, combien de ces tokens finissent encore dans des repos Git ?