ii) Level of focus, mouais.. si dans les méthodes de soft (RUP, scrum xp..) la « figure » du client est en gros le résumé coté métier, utilisateurs, il reste qd même que le 1er principe agile est directement lié à la V.A. pour l’entreprise. Autre point: pourquoi « projet » ; il me semble que en agilité, on se concentre plus sur **l’appli** que sur le projet

iii) ver & val: alors là, je suis choqué , comme d’autres commentateurs, ce qui est cité c’est le contraire de l’agile

iv) variation: là encore, on retrouve effectivement le côté simplificateur de l’agile: la figure du Client ou PO qui gère cet aspect, sachant quand même que, côté outil informatique, on « accueille les changements » (ah, le fameux embrace change de Kent B.)

v) prédiction: ok, mais là aussi, je me demande si la différence fondamentale entre hard et soft est vraiment prise en compte.

ça me rappelle, y’a bien des années (ah.. je fais mon ancien combattant maintenant..) une histoire que l’on racontait à propos de chefs de chantier du batiment, grand professionnels, qui se moquaient de ces informaticiens infoutus de tenir un planning et qui s’étaient eux aussi cassés les dents…
On fait un métier formidable quand même

Il est important de préciser que James pour autant qu’il soit convaincu par le Lean n’est absolument pas un adversaire de l’Agile.

On arrive à un point intéressant maintenant, celui où nous pouvons commencer à mesurer non seulement en quoi agile et lean sont comparables, mais aussi ce en quoi il sont différents…

Ceci écrit le « agile » décrit dans ce comparatif ne semble pas correspondre à une méthode publiée (toutes débordes sur au moins un des points mentionnés vers le lean)…

Pour ce qui est de l’architecture, globalement les méthodologies représentées lors de l’écriture du manifeste agile ne laissent pas l’architecture de côté…
… d’où le principe : « Une attention continue portée à l’excellence technique et à la qualité de la conception améliore l’agilité »

Trois exemples :
- XP : 2 heures de conception par jour, sans compter ses origines dans la communauté des patterns, et quelques figures « de proue » de l’architecture (Martin Fowler, Eric Evans)
- FDD : on commence par la modélisation du domaine, on fait une revue de conception avant de procéder à la réalisation de la fonctionnalité, …
- Crystal : on utilise la stratégie du « squelette ambulant » qu’on va étoffer…

En gros l’idée initiale était que ce n’est pas parce qu’on est réactif que cela nous dispense d’être pro-actif…
… je me demande quand cela s’est perdu ?

Merci pour ce billet !

Si je me mets du coté client, quel est la plus value apportée par le temps passé à déplacer l’immeuble d’1 cm même pour un coût faible ?

Je pense qu’il faut trouver un équilibre et que l’on peut mixer les 2 approches, le Lean qui préconise de concevoir un logiciel tolérant aux changements (donc avec une étape préalable d’analyse du système et de ses interactions) et l’agilité qui propose de faire quelque chose rapidement, prendre le feedback, et améliorer ce qui a été fait.

On gagne sans doute beaucoup à suivre cette préconisation dans la création d’un chaine de montage ou dans le BTP, tant le coût de l’erreur est grand.

Mais si on l’applique au logiciel, on travaille de façon sub-optimal parce qu’on passe à côté d’un caractéristique fondamentale du génie logiciel, qui permet à tout instant de « déplacer tout l’immeuble d’un cm » à coût quasi nul.