XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« Agilité : grandeur et décadence ? | Accueil | Agilité : grandeur et décadence ? »

18 novembre 2008

Agilité : grandeur et décadence ?

Logoscrumalliance Un article de James Shore intitulé "grandeur et décadence de l'agilité" fait du bruit (Cf. par exemple Claude Aubry). Le raisonnement de ce billet tient en deux points :

  • Pour un projet donné, Scrum échoue sur le long terme si aucune méthode d'ingénierie logicielle ne vient compléter Scrum.
  • Avec le temps, la multiplication de ces échecs donnera une réputation calamiteuse aux méthodes agiles, qui feront alors fuir tous les chefs de projets.

J'approuve ce point de vue sur Scrum. Scrum seul est réellement une calamité pour les logiciels à longue durée de vie parce que rien dans Scrum n'aide à bâtir des logiciels maintenables et évolutifs. Or rester agile, c'est-à-dire maintenir un rythme d'itérations courtes, requiert de développer un logiciel qui accepte les évolutions fréquentes. Ce qui n'a rien d'évident.

Pour y parvenir, les bonnes pratiques d'ingénierie logicielle, au premier rang desquelles les tests unitaires (TDD ou non), le refactoring et l'intégration continue doivent compléter les méthodes de management pur déconnectées du métier du software telles que Scrum. Ces pratiques doivent être adoptées pour que l'agilité dépasse la déclaration d'intention. Et pour que la réputation des méthodes agiles ne soit pas mise en danger.

Hélas, ces pratiques ont un succès tout relatif parce que Scrum et son écosystème rémunérateur de certifications est la plus vigoureuse et la plus visible des méthodes agiles.

On en arrive à la thèse de James Shore : la méthode Agile qui est en train de gagner entrainera toutes les méthodes agiles à leur perte.

Certes on a vu récemment des crises plus graves dans des domaines qui se portaient mieux, mais n'est-ce pas pessismiste ? Peut-on revigorer XP ?

TrackBack

URL TrackBack de cette note:
https://www.typepad.com/services/trackback/6a00d8341c871f53ef010535fe60a3970c

Listed below are links to weblogs that reference Agilité : grandeur et décadence ?:

Commentaires

Salut Denis,
Alors toi aussi tu as été marqué par le billet de J.Shore ?

"Rien dans Scrum n'aide à bâtir des logiciels maintenables et évolutifs"
Même si ça reste loin de la technique, il y a quand même toute la mécanique de revue (daily scrum, retrospectives, ...)

Pour le succès de Scrum, il n'y a pas que l'écosystème rémunérateur, il y a aussi l'apparente simplicité de mise en oeuvre.

Mais tout ça reste à mon avis trop pessimiste. Il y a un point dont on ne parle pas trop, c'est l'adoption des bonnes pratiques plus proches du développeur par des environnements où il n'y a pas d'agilité au niveau gestion de projet.

Combien de développeurs sont désormais familiers avec le refactoring, l'intégration continue ou les tests unitaires (le TDD c'est une autre histoire) sans toutefois évoluer dans un contexte "agile" ?

Je parie sur une montée en puissance de l'agilité lorsque ces pratiques seront devenues des évidences, ce qui ne manquera pas d'arriver après quelques années de présence dans tous les IDE et d'enseignement à tous les étudiants.

Salut Olivier,

C'est vrai qu'on peut espérer voir les bonnes pratiques de développement passer dans les mœurs.

Ou pas : avec le succès du Web 2.0, il arrive sur le marché une grosse vague de développeurs Javascript formés en Web agency, pour lesquels l'important est que ça marche à temps pour le lancement du site. J'ai pu constater que le code dupliqué et les méthodes trop longues ne font pas peur à la plupart.

La rusticité des IDE Javascript y est probablement pour quelque chose, Javascript lui-même aussi : le "tout dynamique" limite sérieusement les outils de refactoring (semi)automatiques. IntelliJ par exemple, pourtant réputé, ne sait pas faire d'extraction de méthode. Même le renommage des méthodes est hasardeux (http://beust.com/weblog/archives/000414.html) Je crois que la vogue actuelle des langages dynamiques ou faiblement typés (Javascript, Ruby, Python, PHP) fait reculer le refactoring.

Difficile de rester optimiste quand on voit C# 4.0 apporter le typage dynamique et Java 7 supporter les langages dynamiques.

"Combien de développeurs sont désormais familiers avec le refactoring..." Franchement j'aimerais bien le savoir.

De mon propre avis, il faut les deux : Scrum pour les aspects gestion de projets, cela donne un bon cadre je trouve, et pour l'ingénierie logicielle, des techniques "agiles" issues d'XP par exemple...et Lean pour les aspects organisationnels, mais là, on est déjà trop loin ;)

XP et scrum ont beaucoup en commun côté management. Par exemple l'itérativité, les réunions quotidiennes et les stories font partie de XP.

" le "tout dynamique" limite Je crois que la vogue actuelle des langages dynamiques ou faiblement typés (Javascript, Ruby, Python, PHP) fait reculer le refactoring.

Difficile de rester optimiste quand on voit C# 4.0 apporter le typage dynamique et Java 7 supporter les langages dynamiques."

Ah ben tiens, elle est bonne celle la. Faudra le dire à Ken Beck & consort que Smalltalk est pas fait pour le refactoring hein, j'suis sur qu'ils ne le savent pas !

"Faudra le dire à Ken Beck & consort que Smalltalk est pas fait pour le refactoring hein, j'suis sur qu'ils ne le savent pas"

Oh toi t'as vu Brice de Nice ya pas longtemps :)

Le fond de ta remarque est pertinent. Du coup j'ai été lire l'article de Don Roberts, John Brant et Ralph Johnson sur le refactoring dans Smalltalk pour voir comment ils s'en sortaient (1997, http://st-www.cs.uiuc.edu/~droberts/tapos.pdf ).

En fait ils se heurtent aux mêmes difficultés que les outils de refactoring Javascript. Au chapitre 6.3, on peut ainsi lire que le refactoring "rename method" ne peut être mené correctement à partir d'analyse statique du code. La tentative de solution que proposent les auteurs est de conduire le refactoring à partir d'une analyse dynamique, en faisant tourner le programme et en interceptant les appels à la méthode à renommer. C'est bigrement ingénieux, mais le risque est grand pour qu'une partie du code ne soit pas parcouru (ou ne soit parcouru qu'en production...).

C'est la conclusion du §6.3 : "The major drawback to this style of refactoring is that the analysis is only as good as your test suite. If there are pieces of code that are not executed, they will never be analyzed, and the refactoring will not be completed for that particular section of code."

Connaissant ces limitations, les objectifs des auteurs n'étaient pas de créer un outils de refactoring sûr à 100%, mais "raisonnablement correct" (§1.1 : "The refactorings must be reasonably correct"). Aujourd'hui l'objectif des éditeurs est le 100% et c'est tant mieux pour les développeurs, les projets et les clients.

L'utilisation des commentaires est désactivée pour cette note.