Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Pourquoi Agile et Scrum sont catastrophiques Sabrina Hadjadj Follow Jun 20, 201

Pourquoi Agile et Scrum sont catastrophiques Sabrina Hadjadj Follow Jun 20, 2017 · 21 min read Avant-propos Le texte qui suit est une version française d’un article publié le 6 juin 2015 par Michael O’Church. Je l’ai écrite pour porter ces idées en France, où Agile et plus particulièrement Scrum n’ont de cesse d’envahir les entreprises privées. Abonnez-vous à Épique, ma newsletter Une sélection de liens commentés avec wit sous forme de chroniques et mini essais — articles de presse, vidéos, segments de podcasts, documentaires, tweets. Email Email . . . L’agilité est sans nul doute une bonne chose, et l’Agile Manifesto n’est pas forcément déraisonnable. Si on la compare à l’imposture logique qu’est Waterfall, la méthode Agile s’avère notablement supérieure. Pourtant, Agile telle qu’elle est pratiquée dans les faits et dans la majorité des cas est profondément nocive ; et dans un premier temps, il ne me semble pas qu’une dichotomie Agile/Waterfall ait jamais été nécessaire à quelque projet que ce soit. Il existe une variante d’Agile, nommée Scrum, que j’ai vu détruire des entreprises, littéralement. Par « détruire », je ne veux pas dire «par la suite, la culture n’était plus si bonne que ça» ; je veux dire que l’action s’est effondrée de près de 90%, en moins de deux ans. Email Signup Email I agree to leave Medium.com and submit this information, which will be collected and used according to Upscribe's privacy policy. Qu’est-ce qu’Agile ? Agile a grandi dans le monde du Web consulting, où elle avait une valeur toute trouvée : lorsqu’on avait à faire à des clients retors qui ne savent pas bien ce qu’ils veulent, deux options s’imposaient : la première était de manager le client ; de solidifier ses attentes, de facturer le travail de manière appropriée, et de maintenir une relation d’égalité plutôt que de soumission. La seconde était d’accepter le manque de cohérence du client (cela dit, beaucoup de designers n’ont tout simplement pas le choix) et d’orienter le travail autour des dysfonctionnements de ce coté là. Les programmeurs ont tendance à ne pas être bon avec la relation client. Nous sommes des gens littéraux, précis. Nous aimons les systèmes qui ont des comportements formellement définis. Travailler avec des personnes non techniques est encore plus difficile pour nous ; nous avons tendance à prendre chacune de leurs requêtes à la lettre, au lieu d’essayer de comprendre leur besoin réel. «Agile» telle que pratiquée en entreprise, empruntée à l’environnement du conseil, va beaucoup plus loin que ça, et feint de croire que les ingénieurs ne sont pas assez intelligents pour comprendre ce que souhaitent leurs clients en interne. Le travail se voit ainsi atomisé en «user stories» puis en «itérations», ce qui, bien souvent, réduit à néant tout sens d’accomplissement et tout espoir de vision à long terme sur le devenir de la production. De manière générale, nous avons tendance à créer deux types de projets de développement : au sein même d’une entreprise, ou bien en tant que client, lorsqu’on décide de sous-traiter. Dans le premier cas, on recrute pour obtenir une expertise que l’on a pas. Dans le second, on se débarrasse de tout ce que l’on ne souhaite pas faire soi-même. Il est évident que si la première catégorie d’employés est respectée, l’autre ne l’est pas. Les agences de conseil mal gérées finissent souvent par se transformer en décharges à travail de piètre intérêt. Scrum semble avoir été taillée pour les carrosseries, dont les relations avec la clientèle sont si mal gérées qu’elles ont besoin de surveiller quotidiennement leurs employés, parce qu’ils sont transformés en dépotoirs destinés à recevoir une besogne sans cohérence professionnelle que personne ne veut faire (et qui n’est probablement pas si importante que ça, si l’on en croit la basse rémunération qui vient s’ajouter au manque de respect.) Transparence ultra-violente Il y a pas mal de trucs à la mode sur nos lieux de travail, capables de rendre une carrière de programmeur extrêmement peu attrayante, en particulier pour cette espèce de jeunes gens créatifs et malins dont nous allons avoir besoin pour pallier aux besoins de la prochaine génération. Les open spaces en sont l’exemple le plus flagrant : ils sont anti-productifs ; il est pénible de s’y concentrer. Ils relèvent de l’anti-intellectualisme, dans la mesure où les salariés craignent d’y être pris entrain de lire des livres, ou simplement de réfléchir à ce sur quoi ils sont entrain de travailler. Quand vous forcez les gens à participer à un jeu parallèle dans lequel ils doivent paraître productifs, ils deviennent moins productifs. Les open spaces n’ont d’ailleurs même pas été conçus pour forcer la productivité dans une but premier : il s’agissait d’une question d’image à soigner. Les startups financées par le capital risque se devaient de rassurer leurs investisseurs : elles utilisèrent cette configuration de l’espace pour que leurs bureaux semblent animés, perpétuellement affairés. (Pour le dire de manière brutale, un programmeur travaillant en open space avait plus de valeur en tant que « mobilier » que pour le code qu’il produisait.) Par la suite, pour toute une variété de raisons culturelles, les open spaces sont devenus «jeunes» et «cools» ; et aujourd’hui, ils ont infecté le monde de l’entreprise en général. Il est bien connu que les créatifs perdent toute créativité lorsqu’on leur demande de s’expliquer pendant qu’ils travaillent. C’est la même chose avec le développement d’applications. Les programmeurs doivent souvent travailler dans des environnements à transparence unilatérale. Ces méthodes Agile, si souvent mal appliquées, exigent d’eux qu’ils fournissent une visibilité humiliante sur leur emploi du temps et sur leur travail, sans bénéficier d’aucune réciprocité. Au lieu de plancher sur d’authentiques projets sur le long terme pour lesquels ils seraient en mesure de s’enthousiasmer, ils sont relégués à travailler sur des «user stories» atomisées, relevants du niveau de la simple fonctionnalité ; de la même manière, il leur est souvent refusé de s’atteler à des améliorations qui ne sauraient être associées avec des besoins business à court terme, immédiats, ayant souvent été évoqués par la direction. Cette variante d’Agile, pervertie mais communément utilisée, élimine les concepts de propriété, d’initiative, ou d’appartenance, et traite les programmeurs comme des composants standardisés et interchangeables. Scrum est la pire méthodologies, avec ses ridicules «itérations» sur deux semaines. Elle introduit une anxiété non nécessaire, qui se matérialise dans les creux des micro-fluctuations de la productivité de chacun. Il n’existe aucune preuve que cette esbroufe permette de produire de manière plus rapide, ou dans une qualité supérieure, sur le long terme. Elle rend simplement les gens plus nerveux, plus préoccupés. Beaucoup pensent que Scrum est une bonne méthode parce qu’en l’appliquant «les gens travailleront plus vite». Ça fait dix ans que je suis dans le développement informatique, j’ai été tour à tour manager, développeur, et…. c’est complètement faux. Problèmes spécifiques à “Agile” et Scrum 1. L’ingénierie business-driven (ou dirigée par les affaires) Agile est souvent considérée comme supérieure lorsque comparée avec «Waterfall». Qu’est-ce que Waterfall ? Waterfall est, de manière tout à fait objective, une chose épouvantable. C’est un modèle type «le travail roule vers l’aval», dans lequel chaque niveau hiérarchique appartenant à une organisation place sur son assiette ce qu’il considère être le «truc marrant», avant de laisser les restes à ses subalternes. Les projets sont définis par la direction, le design assuré par les architectes, les deadlines fixées par les managers, l’implémentation réalisée par l’élite de l’infanterie (les programmeurs), enfin, les tests et le déploiement sont délégués à l’arrière-garde. C’est extrêmement dysfonctionnel. Quand les gens ont le sentiment que les décisions importantes ont déjà été prises, ils perdent toute motivation à donner le meilleur d’eux-mêmes. Waterfall reproduit le modèle social d’une organisation dysfonctionnelle avec une hiérarchie définie. Bien souvent, Agile reproduit le modèle social d’une organisation dysfonctionnelle — sans hiérarchie clairement définie. J’ai une opinion mitigée sur les titres tels que «Senior», «Principal» et autres appellations dans le genre. Certes, ces titres ont de l’importance, et personnellement, je n’accepterais pas un emploi en dessous du niveau de «Principal» ou bien de l’équivalent du niveau de directeur ; mais je déteste qu’ils aient cette importance. Quand on prend le temps de l’examiner, on réalise que Scrum est conçue pour retirer du crédit et de l’autonomie aux ingénieurs les plus compétents et les plus empreints de séniorité, qui se voient contraints d’adhérer à des processus fabriqués pour des débutants (ne travailler que sur des items présents dans le backlog, passer cinq à dix heures pas semaine en status meetings) qui auraient pu écrire leurs premières lignes de code tout juste le mois d’avant. Tel un état communiste en situation d’échec qui nivèlerait les richesses en répandant la pauvreté, Scrum, dans sa forme la plus pure, rabaisse toute l’ingénierie au même niveau ; et si ce n’est jamais clairement énoncé, il est évident que ce dernier se trouve bien en dessous de celui des clients, qui disposent, eux, d’une totale autorité pour décider de ce sur quoi il faut travailler. Agile, telle que bien souvent implémentée, démultiplie la uploads/Finance/ pourquoi-agile-et-scrum-sont-catastrophiques-sabrina-hadjadj-medium-pdf.pdf