Il y a quelques jours, j\u2019ai pris part \u00e0 une discussion sur LinkedIn o\u00f9 l\u2019on affirmait de mani\u00e8re p\u00e9remptoire :<\/p>\n\n\n\n
\n\u00ab\u202fL\u2019agilit\u00e9 est une approche complexe avec des co\u00fbts plus \u00e9lev\u00e9s que le waterfall.\u202f\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n
Curieuse<\/strong> de savoir sur quelles \u00e9tudes ou quels chiffres reposait cette affirmation, j\u2019ai demand\u00e9 \u00e0 la personne (que j\u2019appellerai \u201cPedro\u201d pour pr\u00e9server son anonymat) de me pr\u00e9ciser ses sources. Sa r\u00e9ponse ?<\/p>\n\n\n\n
\n\u00ab\u202fAucune. C\u2019est mon exp\u00e9rience et le bon sens. Livrer plus souvent oblige \u00e0 faire plus de travail donc co\u00fbte plus cher. (\u2026)\u202f\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n
Ma r\u00e9action a \u00e9t\u00e9 de sugg\u00e9rer poliment que peut-\u00eatre<\/em> une seule exp\u00e9rience personnelle, aussi pointue soit-elle, ne suffisait pas pour g\u00e9n\u00e9raliser<\/strong>. J\u2019ai salu\u00e9 sa franchise de reconna\u00eetre qu\u2019il n\u2019existait aucun fondement objectif\u2026 mais<\/strong> je me suis aussit\u00f4t fait balayer d\u2019un condescendant :<\/p>\n\n\n\n
\n\u00ab\u202fJe te donne un exemple simple : en agilit\u00e9 tu testes \u00e0 chaque livraison, parfois tous les jours ou toutes les 5 minutes\u2026 Ne pas admettre que \u00e7a ne co\u00fbte pas plus cher que tester le m\u00eame syst\u00e8me une fois tous les 3 mois est un manque de connaissances clair des activit\u00e9s li\u00e9es au d\u00e9veloppement software.\u202f\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n
Autrement dit<\/strong> : j\u2019\u00e9tais cens\u00e9e accepter b\u00e9atement que tester souvent est forc\u00e9ment plus co\u00fbteux et que mon d\u00e9saccord traduirait mon \u00ab\u202fmanque de connaissance\u202f\u00bb<\/em> \u2014 alors que j\u2019\u00e9volue dans la tech depuis plus de 25 ans. Voil\u00e0 ce que j\u2019appelle une bonne dose de mansplaining accompagn\u00e9 de paternalisme naus\u00e9abond. Non merci. Sans fa\u00e7on. Vraiment.<\/p>\n\n\n\n
Quand on manque de fondements, on brandit l\u2019argument d\u2019autorit\u00e9<\/h3>\n\n\n\n
Sur le fond<\/strong>, on constate surtout que Pedro ne pr\u00e9sente aucune donn\u00e9e concr\u00e8te<\/strong>, aucun chiffre, aucune \u00e9tude pour \u00e9tayer son point de vue : \u00ab\u202fl\u2019Agilit\u00e9 co\u00fbte plus cher que le waterfall\u202f\u00bb<\/em>. Il se contente d\u2019affirmer que c\u2019est une \u00e9vidence.<\/p>\n\n\n\n
\n
- Or, affirmer<\/strong> ne prouve<\/strong> rien. On aurait aim\u00e9 voir des cas pratiques, un comparatif chiffr\u00e9, un rapport d\u2019audit s\u00e9rieux, bref quelque chose de plus solide que \u00ab\u202fmon exp\u00e9rience et mon bon sens\u202f\u00bb.<\/li>\n\n\n\n
- De plus, r\u00e9duire<\/strong> l\u2019agilit\u00e9 au seul fait de \u00ab\u202ftester tout le temps\u202f\u00bb traduit une vision incompl\u00e8te<\/strong> (voire erron\u00e9e) de ce qu\u2019est v\u00e9ritablement l\u2019Agilit\u00e9 (Scrum, XP, DevOps, Lean, etc.).<\/li>\n<\/ul>\n\n\n\n
Sur la forme<\/strong>, sa fa\u00e7on de balayer mes questions en m\u2019\u00e9non\u00e7ant \u201cun exemple simple\u201d – simpliste – et en me reprochant un \u201cmanque de connaissances\u201d rel\u00e8ve clairement d\u2019une attitude condescendante, voire toxique<\/em>. Je n\u2019ai ni besoin qu\u2019on m\u2019explique la vie comme si j\u2019\u00e9tais une d\u00e9butante, ni qu\u2019on minimise mon exp\u00e9rience et ma comp\u00e9tence sous pr\u00e9texte que je suis une femme dans l\u2019industrie logicielle.<\/p>\n\n\n\n
(Re)Mettre les pendules \u00e0 l\u2019heure sur l\u2019agilit\u00e9 et ses co\u00fbts<\/h3>\n\n\n\n
D\u2019autant qu\u2019il y a beaucoup<\/strong> \u00e0 dire sur les id\u00e9es re\u00e7ues li\u00e9es \u00e0 l\u2019agilit\u00e9. Voici, en r\u00e9sum\u00e9, quelques-uns des points essentiels :<\/p>\n\n\n\n
La fr\u00e9quence des tests n\u2019est pas forc\u00e9ment synonyme de surco\u00fbt<\/strong><\/p>\n\n\n\n
\n
- L\u2019automatisation<\/strong> est un pilier de l\u2019agilit\u00e9 moderne : elle permet de lancer des tests \u00e0 chaque commit sans intervention humaine, une fois la plateforme de CI\/CD en place<\/li>\n\n\n\n
- Le co\u00fbt initial <\/strong>de mise en place existe, certes, mais il est rapidement amorti et r\u00e9duit le risque de d\u00e9couvrir des bugs trop tard.<\/li>\n<\/ul>\n\n\n\n
Le co\u00fbt cach\u00e9 des bugs tardifs<\/strong><\/p>\n\n\n\n
\n
- Un bug non d\u00e9tect\u00e9 pendant des mois peut affecter plusieurs pans du code, rendant sa correction plus complexe et plus co\u00fbteuse.<\/li>\n\n\n\n
- Ne pas tester r\u00e9guli\u00e8rement revient \u00e0 accumuler silencieusement des anomalies qui exploseront\u2026 potentiellement en fin de projet au moment o\u00f9 cela coute le plus cher de les fixer.<\/li>\n<\/ul>\n\n\n\n
Tester souvent ne veut pas dire une arm\u00e9e de testeurs manuels<\/strong><\/p>\n\n\n\n
\n
- On confond parfois \u00ab\u202flivrer fr\u00e9quemment\u202f\u00bb et \u00ab\u202fmultiplier les tests manuels\u202f\u00bb. En r\u00e9alit\u00e9, l\u2019automatisation et l\u2019int\u00e9gration continue limite la mobilisation humaine sur les tests r\u00e9p\u00e9titifs.<\/li>\n\n\n\n
- Le r\u00f4le de la QA \u00e9volue vers la conception de tests intelligents, la maintenance du framework d\u2019automatisation et des tests exploratoires.<\/li>\n<\/ul>\n\n\n\n
L\u2019investissement en automatisation est amorti<\/strong><\/p>\n\n\n\n
\n
- S\u2019il peut sembler \u00e9lev\u00e9 de prime abord, c\u2019est un investissement rentable \u00e0 moyen\/long terme.<\/li>\n\n\n\n
- Feedback loop plus rapide, d\u00e9tection pr\u00e9coce des d\u00e9fauts, meilleure satisfaction client, r\u00e9duction de la dette technique\u2026 Tous ces gains, bien document\u00e9s, sont au c\u0153ur de la d\u00e9marche agile\/DevOps.<\/li>\n<\/ul>\n\n\n\n
Non la qualit\u00e9 n\u2019est pas une variable d\u2019ajustement<\/strong><\/p>\n\n\n\n
\n
- Rogner sur la qualit\u00e9 sous pr\u00e9texte de \u201crespecter un budget Waterfall\u201d (??) est souvent le signe d\u2019une mauvaise mise en \u0153uvre de l\u2019agilit\u00e9, et non pas une fatalit\u00e9 li\u00e9e \u00e0 l’agilit\u00e9 elle-m\u00eame.<\/li>\n\n\n\n
- L\u2019agilit\u00e9 implique un v\u00e9ritable changement de paradigme : on ne se contente pas d\u2019instaurer des sprints et des daily scrums. On revoit la mani\u00e8re de prioriser, investir \/ budg\u00e9ter et de suivre la qualit\u00e9 dans la dur\u00e9e.<\/li>\n<\/ul>\n\n\n\n
Non, l\u2019agilit\u00e9 n\u2019est pas \u00ab\u202fforc\u00e9ment plus ch\u00e8re\u202f\u00bb<\/h3>\n\n\n\n
\n
- Oui<\/strong>, il faut un investissement initial (notamment pour l\u2019automatisation et la mise en place de CI\/CD).<\/li>\n\n\n\n
- Non<\/strong>, cet investissement ne rend pas l\u2019agilit\u00e9 syst\u00e9matiquement plus co\u00fbteuse, bien au contraire. De nombreuses \u00e9tudes (Standish Group, Accelerate, etc.) et retours concrets d\u2019entreprises (Spotify, Amazon, etc.) d\u00e9montrent que la d\u00e9tection pr\u00e9coce des bugs, le time-to-market r\u00e9duit et la robustesse accrue du produit compensent largement<\/strong> la mise de d\u00e9part – cf Ressources<\/li>\n<\/ul>\n\n\n\n
Et le f\u00e9minisme dans tout \u00e7a ?<\/h3>\n\n\n\n
J\u2019en viens \u00e0 la dimension f\u00e9ministe<\/strong> de ce post. Nous sommes encore trop nombreuses \u00e0 subir<\/strong> ce type de comportements condescendants<\/strong> dans les m\u00e9tiers techniques. C\u2019est le quotidien de beaucoup de femmes en tech, et \u00e7a ne devrait pas l\u2019\u00eatre<\/strong>.<\/p>\n\n\n\n
\n
- En tant que Leader, <\/strong>mon r\u00f4le c\u2019est aussi refuser ce ton paternaliste et rappeler que non<\/strong>, on ne laisse pas passer les attaques sur notre pr\u00e9tendu \u201cmanque de connaissances\u201d quand on a prouv\u00e9 l\u2019inverse des centaines de fois.<\/li>\n\n\n\n
- C\u2019est s\u2019engager \u00e0 faire \u00e9voluer<\/strong> la culture d\u2019entreprise et la communaut\u00e9 tech, pour que ces attitudes toxiques ne freinent plus les talents f\u00e9minins (et pas que f\u00e9minins d\u2019ailleurs, tout le monde y gagne quand il y a plus de diversit\u00e9).<\/li>\n<\/ul>\n\n\n\n
Quant \u00e0 \u201cPedro“, je l\u2019ai purement et simplement blacklist\u00e9<\/strong> : inutile de perdre mon temps et mon \u00e9nergie avec des comportements toxiques<\/strong>. On n\u2019est pas l\u00e0 pour \u00ab\u202f\u00e9duquer\u202f\u00bb celles-ceux qui aggressent et ne veulent pas se remettre en question.<\/p>\n\n\n\n
Merci<\/strong> \u00e0 celles et ceux qui, chaque jour, font avancer la Tech vers plus de respect, de collaboration, et de qualit\u00e9 dans nos pratiques de d\u00e9veloppement.<\/p>\n\n\n\n
Pour aller plus loin\u202f: jetez un \u0153il aux resources ci-dessous. C\u2019est autrement plus \u00e9clairant qu\u2019un \u201cje l\u2019ai toujours fait comme \u00e7a\u201d.<\/em><\/sub><\/p>\n\n\n\n
\n\n\n\nRessources<\/h3>\n\n\n\n
Standish Group \u2013 CHAOS Reports<\/strong><\/p>\n\n\n\n
Depuis 1994, le Standish Group publie r\u00e9guli\u00e8rement ses CHAOS Reports analysant la r\u00e9ussite et l\u2019\u00e9chec des projets IT. Les rapports indiquent souvent que les projets ayant adopt\u00e9 des approches plus it\u00e9ratives (dont Agilit\u00e9) ont un higher success rate (r\u00e9duction des d\u00e9lais, meilleur alignement sur le besoin).<\/p>\n\n\n\n
Site : https:\/\/www.standishgroup.com<\/a><\/p>\n\n\n\n
DORA (DevOps Research & Assessment) \u2013 State of DevOps Reports<\/strong><\/p>\n\n\n\n
DORA, cofond\u00e9 par Nicole Forsgren, Jez Humble et Gene Kim, publie chaque ann\u00e9e une \u00e9tude (State of DevOps Report) mesurant l\u2019impact des pratiques DevOps et agiles sur la performance (fr\u00e9quence de d\u00e9ploiement, lead time, taux d\u2019\u00e9chec, etc.). Les rapports mettent en \u00e9vidence une corr\u00e9lation forte entre l\u2019adoption de pratiques d\u2019int\u00e9gration continue, des tests automatis\u00e9s, la livraison fr\u00e9quente et l\u2019am\u00e9lioration des m\u00e9triques de delivery (tout en r\u00e9duisant les co\u00fbts li\u00e9s aux incidents).<\/p>\n\n\n\n
Site : https:\/\/cloud.google.com\/devops\/state-of-devops<\/a><\/p>\n\n\n\n
PMI \u2013 Pulse of the Profession<\/strong><\/p>\n\n\n\n
Le Project Management Institute (PMI) publie r\u00e9guli\u00e8rement des \u00e9tudes sur les tendances en gestion de projet. Pulse of the Profession <\/strong>inclut souvent des donn\u00e9es sur l\u2019agilit\u00e9 et la comparaison entre des approches traditionnelles (waterfall) et it\u00e9ratives.<\/p>\n\n\n\n
Site : https:\/\/www.pmi.org\/learning\/thought-leadership\/pulse<\/a><\/p>\n\n\n\n
Ressources acad\u00e9miques<\/h3>\n\n\n\n
IEEE Xplore :<\/strong> Site : https:\/\/ieeexplore.ieee.org\/<\/a> ou ResearchGate<\/strong> \/ Academia.edu<\/a> : De nombreux chercheurs en informatique et en ing\u00e9nierie logicielle partagent leurs articles de comparaison Agile vs. Waterfall, parfois incluant des analyses de co\u00fbts. Exemples de mots-cl\u00e9s pour tous les Pedro de l’univers : \u201cAgile Waterfall Cost Comparison\u201d, \u201cTCO Agile vs. Waterfall\u201d.<\/p>\n\n\n\n
Pour celles\/ceux qui pr\u00e9f\u00e8rent les livres :<\/h3>\n\n\n\n
Agile Testing :A Practical Guide for Testers and Agile Teams <\/strong>de Lisa Crispin et Janet Gregory<\/p>\n\n\n\n
Deux des praticiennes et consultantzs en tests agiles les plus exp\u00e9riment\u00e9es du monde: Lisa Crispin et Janet Gregory, se sont associ\u00e9s pour apporter les r\u00e9ponses d\u00e9finitives \u00e0 ces questions et \u00e0 bien d’autres.<\/p>\n\n\n\n
Accelerate: The Science of Lean Software and DevOps <\/strong>Nicole Forsgren, Jez Humble, Gene Kim<\/p>\n\n\n\n
Bas\u00e9 sur plusieurs ann\u00e9es de recherche et sur les donn\u00e9es collect\u00e9es via les State of DevOps Reports, ce livre d\u00e9taille comment des \u00e9quipes hautement performantes obtiennent des d\u00e9ploiements plus fr\u00e9quents, moins de pannes et, paradoxalement, un co\u00fbt global de maintenance r\u00e9duit.<\/p>\n\n\n\n
Continuous Delivery <\/strong>Jez Humble, David Farley<\/p>\n\n\n\n
Ouvrage fondateur sur la mise en place de pipelines d\u2019int\u00e9gration et de d\u00e9ploiement continu (CI\/CD). Pr\u00e9sente les b\u00e9n\u00e9fices concrets (r\u00e9duction du risque, feedback rapide, qualit\u00e9 accrue, co\u00fbts ma\u00eetris\u00e9s).<\/p>\n\n\n\n
Cas pratiques d\u2019entreprises<\/h3>\n\n\n\n
Spotify :<\/strong> le blog de la R&D regorge d’article qui expliquent techniquement comment cette entreprise – r\u00e9f\u00e9rence mondiale en mati\u00e8re d’agilit\u00e9 – assure \u00e9galement en mati\u00e8re de qualit\u00e9 et de s\u00e9curit\u00e9 grace \u00e0 des pratiques d’ing\u00e9nierie et de QA modernes https:\/\/engineering.atspotify.com\/<\/a><\/p>\n\n\n\n
Amazon : <\/strong>Amazon a souvent communiqu\u00e9 sur ses pratiques de d\u00e9ploiement continu (des milliers de d\u00e9ploiements par jour) dont l\u2019objectif est de minimiser le co\u00fbt de la non-qualit\u00e9 par la livraison en continu permettant de d\u00e9tecter tr\u00e8s t\u00f4t les probl\u00e8mes. https:\/\/aws.amazon.com\/fr\/devops\/continuous-delivery\/<\/a> et https:\/\/d1.awsstatic.com\/fr_FR\/builderslibrary\/pdfs\/going-faster-with-continuous-delivery.pdf<\/a><\/p>\n\n\n\n
Netflix<\/strong> est r\u00e9put\u00e9 pour son approche \u201cchaos engineering\u201d et son pipeline de livraison continue. L\u2019investissement en automatisation (tests, canary releases) r\u00e9duit drastiquement les pannes \u00e0 grande \u00e9chelle et, de fait, le co\u00fbt associ\u00e9.<\/p>\n\n\n\n
\n
- https:\/\/www.infoq.com\/fr\/news\/2014\/10\/netflix-chaos-engineering\/<\/a><\/li>\n\n\n\n
- https:\/\/business-digest.eu\/comment-netflix-a-deploye-une-culture-agile-incontestable\/<\/a><\/li>\n\n\n\n
- https:\/\/hackernoon.com\/lang\/fr\/La-sauce-secr%C3%A8te-de-Netflix,-les-Devops-derri%C3%A8re-votre-vision-excessive<\/a><\/li>\n<\/ul>\n\n\n\n
Et je suis sure que vous trouverez plusieurs retour d’exp\u00e9rience concrets et utiles \u00e0 Agile Testing Days, QCon, DevOps Enterprise Summit, Agile Alliance events, etc.<\/p>\n","protected":false},"excerpt":{"rendered":"
Il y a quelques jours, j\u2019ai pris part \u00e0 une discussion sur LinkedIn o\u00f9 l\u2019on affirmait de mani\u00e8re p\u00e9remptoire : \u00ab\u202fL\u2019agilit\u00e9 est une approche complexe … <\/p>\n","protected":false},"author":1,"featured_media":193,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,5],"tags":[],"class_list":["post-192","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-stuff","category-thinking","latest_post"],"_links":{"self":[{"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/posts\/192","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/comments?post=192"}],"version-history":[{"count":1,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/posts\/192\/revisions"}],"predecessor-version":[{"id":194,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/posts\/192\/revisions\/194"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/media\/193"}],"wp:attachment":[{"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/media?parent=192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/categories?post=192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/racheldubois.fr\/de\/index.php\/wp-json\/wp\/v2\/tags?post=192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}