Vous pourriez avoir cette impression parce qu'agile est VRAIMENT nul pour le développement de logiciels.
Voici pourquoi...
Parlons du processus pour faire un excellent travail. Pour faire un excellent travail, il faut deux choses (essentiellement).
- Se montrer chaque jour pour améliorer le produit.
- Se montrer chaque jour pour vous améliorer.
Lorsque les gens font ces deux choses simples chaque jour, ils font un excellent travail. Et cela fonctionne dans presque tous les domaines auxquels vous pouvez penser.
Et c'est l'anthèse de la façon dont la plupart des gens et des entreprises utilisent réellement agile. Le but d'agile n'est pas un grand travail. C'est autre chose.
Ce sur quoi la plupart des gens se concentrent dans le monde du développement logiciel agile, ce sont les histoires, les estimations et les sprints. Fondamentalement, la plupart des gens croient que s'ils prennent un morceau de travail, le découpent en tout petits morceaux et les crachent avec une cadence semblable à celle d'une usine, ils vont magiquement respecter les délais, avoir des estimations précises et expédier PLUS !
Le problème avec cela, c'est que le véritable objectif de la direction est le mot PLUS. Vous voyez, expédier PLUS les fait paraître meilleurs. Respecter PLUS de délais, expédier PLUS de fonctionnalités, pour obtenir PLUS d'argent et PLUS de promotions. C'est juste un grand jeu de PLUS.
Alors, chaque fois qu'un sprint ou une épopée arrive, ils veulent PLUS de fonctionnalités, dans un délai PLUS agressif, pour vendre PLUS de clients sur PLUS de promesses qu'ils ont faites.
Mais devinez-moi ce Batman...
Si vous avez une quantité fixe de ressources et que vous continuez à pousser pour PLUS, que se passe-t-il ? Des merdes arrivent.
Comme le disait la vieille chanson de blues (et la reprise de Zepplin), "Si ça continue à pleuvoir, la digue va céder"
Donc, dans tous les scénarios agiles auxquels j'ai participé, ils semblent tous se diriger lentement vers un désastre parce qu'il y a un désir infini de PLUS de la part de nombreuses personnes impliquées.
Cela ressemble généralement à un cocktail d'un gros contrat, d'un délai impossible, et d'équipes de développeurs qui se démènent dans un FIRE DRILL complet pour travailler tard et être misérable dans l'espoir de survivre au lancement. L'épuisement professionnel se produit (généralement pour les plus performants) et après deux ou trois séries de cela, les meilleures personnes en ont marre et partent.
Il n'y a aucun moyen de contourner cela parce que les incitations en place poussent toutes à faire PLUS et c'est le contraire de faire MIEUX.
Vous voyez, dans chaque système ou activité, il y a une répartition 80/20 de l'efficacité. Le travail le plus efficace est fait dans les premiers 20% de l'effort, et après cela, les rendements décroissants entrent en jeu.
La poussée constante pour PLUS est en fait une poussée constante vers des rendements décroissants. Chaque heure supplémentaire passée a moins de valeur que la précédente. Finalement, chaque heure passée produit une valeur négative et vous êtes moins bien loti que si vous aviez arrêté plus tôt.
Par exemple, la plupart des travaux de programmation productifs sont effectués en environ 2 à 3 heures par jour. Après disons deux heures de codage réel, les rendements décroissants entrent en jeu et les programmeurs commencent à tourner en rond.
Le scénario idéal serait que les programmeurs se présentent au travail, fassent 2-3 heures de travail de qualité et rentrent chez eux. Ramassez le travail le plus valable que vous pouvez, faites quelques bons progrès, et arrêtez.
C'est ainsi que vous maximisez le rendement des programmeurs. Cela ne nécessite pas du tout la méthode agile. Il ne nécessite pas d'histoires, de sprints, d'estimations ou de délais. Les Scrum masters ne sont pas nécessaires. Les réunions quotidiennes ne sont pas nécessaires. A peu près toute la pompe et la circonstance n'est pas nécessaire.
Mais... ce que j'ai décrit n'est pas comment fonctionne agile. Ce n'est pas comme ça que les environnements de travail modernes sont conçus. Les gens sont censés s'asseoir sur une chaise pendant 40 heures par semaine pour percevoir un chèque. Les programmeurs doivent aller à des tonnes de réunions absurdes pour "collaborer" au lieu de simplement écrire du code. Des heures et des heures sont passées en négociations inutiles sur "est-ce que cette fonctionnalité va s'intégrer dans ce sprint" au lieu de simplement coder ladite fonctionnalité et de passer à autre chose.
Donc, les programmeurs (qui aiment être payés), jouent le jeu des absurdités de l'agile parce qu'une partie du travail consiste à jouer le jeu de l'agile. C'était la même chose avec waterfall avant lui. Aucune de ces méthodes ne fonctionne en fait particulièrement bien parce que cela se résume vraiment à ceci :
La programmation est une activité solitaire qui devrait plutôt ressembler à un forgeron qui martèle sur une enclume. Jour après jour, affiner leur métier, façonner des idées en manifestations physiques.
Au lieu de cela, nous avons pris cette activité solitaire transformée en une usine de logiciels remplie de cubicules ou de bureaux ouverts qui sont si ridicules qu'ils sont facilement lampés par Dilbert, The Office, et Office Space (qui sont tous effroyablement précis). C'est probablement la façon la moins efficace d'organiser notre travail, mais l'optimisation de l'efficacité ou de la qualité des programmeurs n'a rien à voir avec tous les propriétaires, gestionnaires, GP, coachs agiles, etc. qui courent après le PLUS.
La réponse serait de courir après le MOINS, mais qui est assez fou pour faire cela ? Personne au pays de l'agilité, c'est certain.
-Brian