The blog of blog of blogs

Les aventures d'un ethnologue dans le grand monde

Les 5 réponses de l’Agile 30 octobre 2014


 

Les responsables d’entreprises et les responsables de services informatiques n’ont que l’embarras du choix sur les méthodes et les outils qu’ils peuvent utiliser pour mener à bien les projets liés aux systèmes d’information.

CMMI, ITIL, ISO, ISTQB sont autant de références incontournables aujourd’hui et font partie du vocabulaire de base des équipes de management. La contrainte de mise en qualité et la volonté de faire de bons produits permet à chacun de jongler avec ces méthodes et il n’est pas rare de retrouver du CMMI, du ITIL et du ISO dans la même organisation.

 

L’expression « méthodes agiles » perce parfois ce consensus avec un succès variable.

Les acteurs de l’industrie logicielle, grands ou petits, abordent les méthodes agiles avec une certaine confusion, ne sachant pas ce qu’elles sont, ce qu’elles ne sont pas et ce qu’elles recouvrent en termes opérationnels. La simplicité du Manifeste Agile n’aide pas vraiment non plus à situer les enjeux…
Pourtant, le développement logiciel agile n’est pas nouveau et il tient la comparaison d’ancienneté avec les autres méthodes citées précédemment.
L’acte de naissance des méthodes agiles remonte officiellement à 1981, lorsque James Martin a breveté la méthode rapide de développement d’application (Rapid Application Development –RAD). Cette méthode RAD consiste en une suite de développements livrés aux utilisateurs tous les 90 jours en moyenne, qui a évolué ensuite avec les méthodes Dynamic Software Development Method (DSDM), Unified Process (UP) ou encore Scrum.
Avec Scrum, le délai de livraison d’une fonctionnalité aux utilisateurs tombe à 30 jours en moyenne. C’est ce qu’on appelle un ‘sprint’.

 

Pourtant, les craintes liées à l’aspect informel des méthodes agiles freinent leur adoption dans les entreprises malgré la publicité faite autour de celles qui les utilisent avec succès.
Les responsables informatiques sont donc face à un dilemme : agile ou pas agile ? Quels risques prenons-nous avec les méthodes agiles ? En quoi les méthodes agiles sont mieux que le modèle de gestion de projet « en cascade » ? Vais-je faire partir mes meilleurs développeurs si ça ne leur plait pas ?

Il semble de toute façon que, avec ou sans les méthodes agiles, il n’existe toujours pas de solution miracle pour faire réussir un développement ou un projet…

.

Les méthodes agiles soulèvent régulièrement cinq critiques qui sont autant d’épouvantails et d’idées préconçues. Il s’agit davantage de prédictions auto réalisatrices que de critiques argumentées (« ça va pas marcher, ça va pas marcher, ça va pas marcher ! ») et nous allons les passer en revue pour apporter des éléments de réponse plus concrets.

  • Les méthodes agiles, c’est du travail de hacker

Ce reproche fréquent réduit ces méthodes de développement à une anarchie à peine contrôlée, et qui voudrait travailler dans ces conditions ?
La réalité est plus nuancée et heureusement plus structurée.

Les « agilistes » font des plannings, ils rédigent leurs cahiers de tests en fonction des priorités du client et ils vérifient souvent leurs résultats avec les utilisateurs pour valider les livraisons. Certaines équipes particulièrement bien calibrées embarquent même des ethnologues pour rendre compte des pratiques des utilisateurs, afin de concevoir au mieux le produit en même temps qu’il est fabriqué… Ce que les équipes agiles attendent des responsables et du client, c’est qu’ils fournissent les priorités à suivre et qu’ils participent conjointement pour proposer des ajustements.
En d’autres termes, les méthodes agiles ne transforment pas ce qui est fait, elles modifient seulement comment le travail est fait… comme n’importe quelle autre méthode de qualité.
A ce titre, les méthodes agiles ne sont pas du travail de hacker et surtout, le concept même de hacker est contraire à l’esprit d’équipe.

  • Elles ne peuvent pas s’appliquer aux grands projets

L’origine des méthodes agiles remonte en effet à des projets informatiques de taille modeste et encore aujourd’hui, elles sont parfois préconisées pour les charges estimées à moins de 100.000 lignes de code.
Avec le temps cependant, même les grands projets sont devenus sensibles à l’incertitude et aux changements de spécifications en cours de travail.
Les grandes entreprises et les organisations gouvernementales pouvaient se permettre de fonctionner comme l’industrie ‘lourde’ en adoptant des procédures rigides et un avancement en cascade, chaque livraison étant basée sur des besoins exprimés par le client au tout début du projet, soit parfois des mois ou des années avant.

 

Cela n’est plus vrai aujourd’hui : un projet qui dure plusieurs mois est en grand danger s’il ne réactualise pas les besoins du client régulièrement. Le produit fini risque de ne plus être d’aucune utilité ou d’utiliser une technologie déjà obsolète. Je vous renvoie à mon article sur le système embarqué dans le robot Curiosity, qui se balade en ce moment même sur la planète Mars : deux millions de lignes d’instructions développées en code C, avec un taux d’erreur de un pour mille. Tout cela réalisé par des équipes agiles.
Si les projets en eux-mêmes peuvent conserver une gestion basée sur un modèle classique (management, reporting, planification, etc.), leur aspect ‘’développement’’ et ‘’systèmes d’information’’ doit prendre en compte un niveau d’incertitude qui rend propice l’adoption des méthodes agiles.

C’est le dosage et la cohabitation avec les méthodes habituelles qu’il faut apprendre à gérer.

Pour les besoins des logiciels de Défense, les armées ont régulièrement innové pour parvenir à une grande qualité de leurs produits, des produits qui atteignent assez souvent le million de lignes de code ou plus et des équipes comptant jusqu’à 250 développeurs.


Compte tenu des enjeux opérationnels, on comprend aisément qu’un bug inopiné ou des spécifications inadaptées puisse entraîner directement des pertes irréparables en combattants ou en matériel, ou plus radicalement la perte d’une guerre.

Toutes les équipes de développement militaires et leurs sous-traitants utilisent aujourd’hui les méthodes agiles, à divers degrés, ce qui prouve que ces méthodes s’appliquent bien aux grands projets et qu’on peut les utiliser effectivement à divers degrés.
Voir à ce sujet : Paul E. McMahon : “Lessons Learned Using Agile Methods on Large Defense Contracts” in Cross talk, 2008. Magazine d’ingénierie logicielle de la Défense, US Air Force. http://www.stsc.hill.af.mil/crosstalk

Les adaptations peuvent porter notamment sur l’écart entre les livraisons aux utilisateurs, qui peuvent passer à six ou douze mois au lieu de 30 ou 120 jours. Une étude du Jet Propulsion Laboratory présente un projet de 200 années / homme mené par IBM Federal Systems, dont les livraisons se sont faites en 45 itérations, à chaque fois dans les délais et sous le budget fixé.
Voir : W. H. Spuck : Management of Rapid Development Projects. Editions du Jet Propulsion Laboratory, D-8415, A. 1991.

De plus, on remarquera que le CMMI est lui-même issu des préoccupations de l’armée américaine dans les années 1980, qui s’inquiétait de la multitude de sous-traitants et des difficultés à harmoniser leur niveau de qualité.
En pratique, si l’on parle aujourd’hui de l’utilisation des méthodes agiles dans les projets de Défense aux États-Unis, cela implique que ces méthodes sont obligatoirement employées dans un environnement CMMI. Les deux n’ont donc rien d’incompatible.

  • Elles ne fonctionnent pas si les équipes sont géographiquement distantes

Les équipes géographiquement distantes (ou ‘’distribuées’’) peuvent l’être dans différents bâtiments ou continents. Les pratiques de développement offshore font régulièrement travailler ensemble de personnes basées sur différents fuseaux horaires avec -bien sûr- différentes cultures professionnelles.
L’un des enseignements des projets offshore est que, quelle que soit la méthode utilisée pour gérer l’activité, la documentation écrite ne peut pas résoudre tous les problèmes. Plus exactement : la documentation écrite est une source de problèmes. Problèmes d’interprétation, de références, de vocabulaire, de délai de rédaction et de diffusion, etc.
Les interactions plus fréquentes par téléphone, visioconférence, intranet, écrans d’affichage, e-mail et les outils de travail partagés accroissent l’agilité en dépit de la distance, même si l’objectif n’est pas de mettre en place les méthodes agiles.   Voir : R. L. Daft : Organization Theory and Design. Editions West Publishing, 1992.

L’enjeu est alors de créer des mécanismes qui permettent à chacun d’accéder aux sources d’information dont il a besoin, plutôt que de devoir contrôler le flux d’informations émanant de la direction du projet. La communication elle-même doit être un aspect majeur du management, comme un élément à part entière que l’on doit promouvoir et faciliter, dans et au-delà de la ligne hiérarchique.
Les individus ne doivent pas hésiter en particulier à se parler de site à site, parce que la tendance naturelle pour les équipes est de développer un sentiment d’appartenance géographique, un ‘’esprit de clocher’’ qui favorise la rétention d’information et casse la cohésion de l’ensemble. En termes d’organisation c’est bien une équipe entière qu’il faut parvenir à créer et à maintenir et non pas plusieurs équipes distantes étalées sur différents sites.

  • Elles ne permettent pas de gérer les problèmes complexes d’architecture

Le manque de planification et de choix d’architecture au début d’un projet est sans doute le souci le plus sérieux qui peut aboutir à des développements en aveugle. Des problèmes non prévus surgiront dans les cycles ultérieurs, mettront en évidence un mauvais urbanisme et obligeront à une révision coûteuse de l’existant.
Bien entendu, tenter de résoudre toutes les questions d’urbanisme au départ ne garantit en rien qu’il n’y aura pas de soucis à l’avenir ! jl-LeMOIGNE_modelisation-systemes-complexes

Le point fort des méthodes agiles sur ce sujet consiste à considérer avec attention le rapport entre les avantages et les inconvénients d’une architecture planifiée dès le lancement du projet.
La meilleure décision portera sur le point médian -le juste milieu- entre les extrêmes de ‘pas d’architecture du tout’ et l’illusion d’une architecture complète, comme on a pu le voir dans la catastrophe du projet LOUVOIS.

Certaines questions d’urbanisme peuvent être tellement obscures et critiques que vous aurez besoin de toute façon d’investir dans des prototypes jetables pour clarifier la solution à suivre.
Vous pouvez également hiérarchiser les objectifs de vos premières livraisons pour qu’elles éclairent les questions majeures.
Définir quels aspects du projet sont susceptibles d’être stables ou volatils pourra aussi vous aider… pourvu que vous sachiez rester ouvert aux évolutions.

En règle générale, le développement agile favorise les architectures simples et flexibles, qui sont un gage d’adaptabilité en cas de changements ultérieurs.

 

  • Mes clients / mes développeurs ne travailleront jamais comme ça

L’idée préconçue derrière cette affirmation est que les méthodes agiles seraient culturellement incompatibles avec certains projets ; et je serais bien le dernier à affirmer que l’on peut imposer certaines pratiques à des gens qui n’en veulent pas.

Mais à ceux qui se demandent ce qu’ils pourraient perdre, nous demandons plutôt ce qu’ils pourraient gagner. Bien des équipes découvriront qu’elles fonctionnent mieux en utilisant des méthodes agiles et elles pourraient complètement y adhérer… pourvu qu’elles aient pu s’y frotter.
La réussite comptera pour beaucoup dans cette adhésion. L’impression positive qui naît en parvenant à livrer rapidement du code qui fonctionne est un puissant facteur de motivation, pour les clients comme pour les développeurs.
Ironiquement, les développeurs chevronnés ont l’habitude de se plaindre lorsque les managers les poussent à commencer le travail trop tôt, sachant pertinemment que les exigences changeront dans quelques jours ou semaines.
Avec les méthodes agiles, la différence est que le système n’est pas supposé être parfait dès le premier essai (ce qui est vrai à chaque fois, de toute façon !). L’équipe de projet a de multiples itérations devant elle pour affiner son analyse des difficultés, préciser l’estimation des coûts et du planning ou faire émerger de nouvelles exigences.

.

Si on leur en donne la chance, les individus aiment apprendre, en particulier si cet apprentissage leur permet de devenir meilleurs dans leur travail. Après tout, la mise en œuvre de chaque méthode qualité implique ce genre de pari sur l’avenir. Sur ce point non plus, les méthodes agiles ne sont pas différentes des autres.

Ainsi, comme je le disais plus haut, ce préjugé de l’incompatibilité culturelle nous ramène au rôle du management, pour qu’il joue à plein son rôle de pédagogue et de levier pour améliorer les Ressources Humaines. Car dans le domaine informatique comme ailleurs, on remarque une constance des problèmes :

  • Il n’y a pas de solution miracle, il n’y a que des solutions adaptées à un contexte.
  • Le contexte des métiers de l’informatique est propice à l’agilité et le sera de plus en plus.
  • Enfin, le choix d’adopter le développement agile relève d’une décision de management plus que de technique, comme toutes les décisions vraiment importantes.

 

hongkong_agile

A quel point êtes-vous agile…?

.

.

.

 

 

2 Responses to “Les 5 réponses de l’Agile”

  1. […] millions de lignes de code développées en langage C par une filiale d’Intel, WindRiver, en mode agile. Un taux d’erreur de un pour mille et un retour sur investissement incalculable tant il est […]

  2. […] dans votre entreprise ou dans votre administration. De ce point de vue, la mise en œuvre de méthodes comme l’Agile et le Lean permettent de tailler dans le gras et recentrer les procédures et les méthodes sur le […]


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