L’agilité en informatique est elle un leurre?

J’ai personnellement été très longtemps septique sur l’approche agile. Je ne suis par ailleurs toujours pas convaincu par certaines pratiques telles que la programmation en binôme ou le développement orienté par les tests.
Mais il faut bien reconnaître que les méthodes agiles promeuvent des principes très séduisants pour améliorer la qualité et la productivité du développement des logiciels.
Ces principes, qui sont en adéquation avec ma sensibilité, sont décrits dans le manifeste agile et valorisent notamment les individus, le produit fonctionnel, la collaboration avec les clients, l’adaptation au changement.

Pour mémo, les douze principes du manifeste agile sont :
1 – Notre priorité première est de satisfaire le client en livrant au plus tôt et de manière constante un logiciel de qualité.
2 – Tout changement, même tardif, des exigences pendant le développement est bienvenu. Les méthodes Agiles transforment le changement en avantage compétitif pour le client.
3 – Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois, en préférant la plus petite périodicité.
4 – Maîtrise d’ouvrage et développeurs doivent collaborer quotidiennement tout au long du projet.
5 – Bâtir le projet avec des personnes motivées. Leur donner l’environnement et le soutien dont elles ont besoin et croire en leur capacité à accomplir le travail.
6 – La plus efficace des méthodes pour transmettre l’information au sein et à destination d’une équipe est le face à face.
7 – Un logiciel qui fonctionne est le meilleur indicateur de progrès.
8 – Les méthodes Agiles favorisent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir ce rythme indéfiniment.
9 – Une attention constante à l’excellence technique et à la qualité de la conception améliore l’agilité.
10 – La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
11 – Les meilleures architectures, spécifications et conceptions sont issues d’équipes auto-organisées.
12 – À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis modifie et ajuste son comportement dans ce sens.

A l’heure ou j’entends parler autour de moi de spécifications fonctionnelles générales, de spécifications fonctionnelles détaillées, de spécifications techniques générales puis détaillées, de clients qui ne valident pas certaines spécifications détaillées, de communications formalisées par des listes de questions ciblant telles ou telles spécifications, de méthodes de chiffrage de charges ou l’on essaye de se prémunir d’une évaluation approximative en appliquant des abaques qui majorent le budget final, de méthodes ou l’on chiffre la production de documents dont on ne sait pas quelles sont les informations qu’ils vont contenir…
En janvier 2013, je me dis qu’il s’agit de méthodes que l’on utilisait au début de ma vie professionnelle… Il y a plus de 20 ans.

Donc en effet, je crois davantage en la valeur d’une relation orientée vers une forme de partenariat entre le client et le fournisseurs plutôt qu’une relation contractuelle entre des donneurs d’ordre et des prestataires de service.
Je crois en la responsabilisation du client (et du fournisseur) qui saurait identifier les fonctionnalités de son produit et prioriser leurs développements.
Je crois à une approche plus pragmatique des besoins du client qui autorise une réactivité permanente à ses demandes.
Je crois également en un cycle de production itératif permettant qui permet d’éviter les effets tunnels que l’on a pu observer sur certains projets, qui permet également de fournir un retour d’informations permanent du client pour vérifier l’adéquation du produit avec les exigences exprimées, et qui apporte une plus grande flexibilité à la construction du produit final.
Je crois à la valorisation de la personne qui contribue au produit et à la mise en place d’un rythme soutenable et non pas oppressant.

Est-on agile parce que l’on applique la méthode Scrum? Surement pas!
L’agilité nécessite de profonds changements dans la relation avec les autres. Le partenariat implique un consentement mutuel.
Au delà des processus visant à rationaliser de la fabrication des produits, je pense que l’agilité met en relief des valeurs plus humaines.
On est encore loin, semble t-il, d’une adoption massive de ce paradigme qui bouleverserait notre façon de fabriquer des produits.

http://www.jperf.com

Publicités

A propos jlerbsc

founder of JavaPerf Consulting Http://www.jperf.com
Cet article a été publié dans Agile. Ajoutez ce permalien à vos favoris.

Un commentaire pour L’agilité en informatique est elle un leurre?

  1. jlerbsc dit :

    Je viens d’intervenir encore sur un projet ou le donneur d’ordre impose à son prestataire une livraison de correctifs dans un délai qui n’a pas donné lieu à une concertation… et encore un prestataire qui, pour rester dans les bonnes grâces de son client, accepte ces conditions de réalisation. Nous marchons sur la tête! Comment voulez-vous que chacune des parties puisse être satisfaite par le résultat. Les premiers attendent dans les délais imposés une qualité des livrables irréprochables, les autres demandent à leur équipe de faire le maximum, et l’équipe travaille d’arrache pied pour satisfaire sa hiérarchie quitte à livrer un produit imparfait (ou plutôt non testé).

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s