Garry Berteig says:
I mentioned an example of agile effectiveness in terms of Visa.
The waterfall example is to have to go to the bank for a loan, fill out forms in a meeting, reschedule for approval, and sign off on contract. On the other hand Visa lets the borrower make the decisions about how much and how often within a predetermined limit.
People go for Visa because it allows for iterations that are self determined, and very frequent compared to a bank loan process.

Il reste à se demander qui est l'équivalent de Cofidis, Sofinco et Finaref...

Vianney Lecroart explique comment recruter un mauvais ingénieur informatique. Dans l'ensemble, les règles décrites dans ce billet me semblent bien illustrer certaines erreurs classiques de recrutement dans le développement logiciel.
Malheureusement, ces règles ont un défaut. Elles laissent transparaître, de manière diffuse, un des travers que l'on retrouve de plus en plus souvent chez les agilistes : la croyance que constituer une équipe de développement consiste principalement à réunir un ensemble de personnes très ouvertes au dialogue et capables d'acquérir les connaissances qu'elles n'ont pas.

Je propose donc ici quelques règles supplémentaires qui peuvent permettre de se laisser définitivement phagocyter par cette idéologie.

Hier soir, j'ai regardé une émission de télé-réalité de France 3.
Je n'ai pas pour habitude d'aller chercher des exemples d'agilité ou de non-agilité dans des domaines qui n'ont qu'un très lointain rapport avec le développement logiciel mais, sur ce coup, le discours de certains protagonistes m'a inévitablement fait penser à quelque chose de connu.

L'an dernier, Pascal Roques, bien connu pour ses ouvrages sur UML, avait publié un article décrivant une démarche de modélisation "agile". Il est récemment revenu sur le sujet en publiant un exemple d'utilisation de cette démarche.

Cette démarche est décrite de la manière suivante :
Une démarche de modélisation "agile" pour passer des besoins utilisateurs au code. Le processus que nous vous proposons de suivre pour le développement d’applications Web se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code. Il s’inspire également des bonnes pratiques prônées par les tenants de la modélisation agile (Agile Modeling).
Passons sur la qualification d'approche minimaliste à la mode centrée sur le code dont est affublé XP (il y aurait beaucoup à dire là dessus, j'y reviendrai peut être un jour) pour nous intéresser à l'agilité effective de la méthode présentée. Il ne faut pas reprocher aux gens qui ont des idées (et même souvent de bonnes idées) sur les moyens de développer du logiciel de les faire connaître mais on peut légitimement s'interroger sur le qualificatif "agile" qui semble être devenu un terme marketing à la mode pour énoncer une certaine rupture avec des méthodes de développement cérémonieuses et vieillottes.

Beaucoup de sociétés impliquées dans du développement logiciel mettent en avant leur démarche qualité. Rien de très étonnant à cela. Les contraintes du marketing font que si les autres font de la qualité (et le font savoir) et que soi même on n'en fait pas (ou on ne le fait pas assez savoir), les autres seront considérés comme faisant de meilleurs produits ou rendant de meilleurs services.
Il faut cependant remarquer qu'il y a qualité et qualité. La démarche qualité dans l'industrie du logiciel est avant tout une histoire de processus : maîtriser au mieux les étapes qui vont de l'expression des besoins au produit fini. Si on a de la chance, on aura aussi un processus en amont pour aller des attentes du client jusqu'à l'expression des besoins. Faire un produit de qualité, c'est autre chose. C'est faire un produit que le client, l'utilisateur considèrera, avec toute sa subjectivité, comme étant de qualité ! La démarche et les processus qui auront servi à arriver au résultat n'auront, en fin de compte, que bien peu d'importance.

Les méthodes agiles, et tout particulièrement XP, sont réputées pour ne s'intéresser que de loin aux formalisations des démarches qualité mais où se situent-elles vraiment pour ce qui est de réaliser des produits de qualité ?

Je viens de lire un échange intéressant où Fabien Benoit s'interroge sur la mise en oeuvre effective de méthodologies opposées par des guerres plus ou moins religieuses et Aurélien Pelletier répond en faisant un tour d'horizon des pratiques actuelles et en concluant qu'il n'y a pas de méthodes idéale : tout est une question de dosage en fonction du contexte. Fabien acquiesce en faisant remarquer qu'il ne peut donc pas y avoir de méthode "prête à l'emploi" contrairement à ce qu'espèrent proposer divers vendeurs de solutions miracle.

Je me permets de venir ajouter mon grain de sel à la discussion en abondant dans le sens des conclusions déjà établies. Force est de constater que lorsque des personnes communiquent des retours d'expérience sur des méthodes récentes, c'est principalement pour en vendre une mise en oeuvre plus ou moins packagée (je n'ai rien contre la société mentionnée à travers le lien, c'est juste un exemple).
RUP, XP, Scrum et consorts sont devenus autant de mots-clef marketing qui servent aussi bien à des prestataires de services pour s'ouvrir de nouveaux marchés qu'à des entités internes aux sociétés pour mettre en exergue leur façon de travailler et dégager ainsi les budgets adéquats. "Nous faisons de la bonne qualité avec notre méthode eXtreme Programming. Si vous voulez que l'on vous fasse cette fonctionnalité X, il va falloir payer une paire de développeurs supplémentaire".

Peu de voix s'élèvent pour dire que, en fin de compte, mettre en place une méthode de développement qui fonctionne réellement, c'est avant tout une histoire de bricolage pragmatique qui pioche des idées ici ou là et les assemble en fonction du contexte et de la sensibilité des intervenants. Je voudrais donner ici un exemple d'un tel bricolage.