En effet, j’ai remarqué que beaucoup de gens connaissaient le terme eXtrem Programming. Malheureusement, pour ces personnes les seules idées qu’ils en restent sont : « XP c’est coder à deux sur un seul PC ? Très peu pour moi… » ou bien « XP c’est coder et ne pas faire de docs ? C’est faire un projet à l’arrache …».

Et bien non ! XP, et plus généralement les méthodes agiles, ce n’est pas ça !

Méthodes agiles … What’s that ?!

Qu’est ce que les méthodes agiles, en quoi ça nous concerne et surtout qu’est ce que cela peut nous apporter ?

Ca me concerne :

D’après les rapports du Standish Group (plus ou moins contesté), les chiffres concernant les réussites de projets informatiques sont très faible, même s’ils évoluent à la hausse :

Pourcentage de réussite des projets informatique.

Mitigés voulant dire : un important retard ou surcoût, ou bien un produit ne correspondant pas aux besoins du client.
Les chiffres sont éloquents, nous avons encore beaucoup de chemin à faire…

Devenir agile, qu’est ce que cela :
Les méthodes agiles sont nées d’un mouvement de protestation face aux méthodes classiques de gestion de projets (cycle en cascade, cycle en V, normes ISO, …) et ont prises leur envol lors de la création du manifeste agile en 2001. Les principes agiles sont :

1 ) Mettre en avant les humains, favoriser leurs interactions et donc donner moins d’importances aux processus et aux outils.
Casser le système de hiérarchie – n’avez-vous jamais eu l’impression des fois de jouer au téléphone arabe ? – et favoriser les contacts (directs de préférence) entre les personnes, notamment entre l’équipe de développement et le client.

2 ) Redonner au client le pouvoir par rapport au cahier des charges.
Actuellement, le cahier des charges a pris une place déterminante dans les projets. C’est à lui que l’on se réfère incessamment. Lorsqu’il est validé, c’est lui qui détient la vérité et non plus le client. Chaque nouvelle demande peut être refusé au titre qu’elle n’est pas spécifiée dans le cahier des charges. Conséquence, les phases de recensement et d’expression des besoins sont par fois très longues et sans réelle fin, le client ayant peur de s’engager.

3 ) Gérer les priorités. Le client doit être le responsable de la priorité des besoins, c’est à lui (aidé éventuellement par l’équipe) de déterminer quelles fonctionnalités sont les plus importantes et méritent d’être développé au plus tôt.

4 ) Accepter le changement. C’est là, que la notion d’agilité prend tout son sens. Actuellement, les changements sont vécus comme une tragédie, certains sont acceptés (mais difficilement vécu par les développeurs qui y voient un surplus de travail), d’autres sont refusés car non inscrit dans le CDC et doivent faire éventuellement l’objet d’un avenant au contrat.
Dans les méthodes agiles, le changement est accepté, car normal. Les besoins sont souvent difficiles à appréhender dans les projets informatique, car complexes et immatériels. De plus, ils peuvent évoluer en fonction de la conjoncture (ex : un concurrent sortant un produit similaire avec des fonctionnalités innovantes). Il est normal d’accepter le changement, dans ce cas là, c’est au client, à tout moment, de remettre à jour les priorités et d’accepter le développement de nouvelles fonctionnalités aux dépend d’autres.
Les fonctionnalités annulées feront soit l’objet d’un autre lot, ou bien seront définitivement supprimées. Est-ce réellement un souci ? Au vu de la présentation de la présentation de Jim Johnson (Keynote speech, XP 2002) la question se pose :

Pourcentage d’utilisation des fonctionnalités implémentées et fonctionnant

5) Utiliser un cycle de développement itératif et incrémental. Il est important de découper les développements en périodes de temps dont la durée est fixe. Ces périodes de temps sont appelées itérations ou sprints.

Au début de chaque itération :

• le client décide des fonctionnalités à traiter en priorité,
• les développeurs estiment la durée de chaque fonctionnalités,
• en fonction de la vélocité (que l’on pourrait raccourcir à la productivité de l’équipe) on détermine les fonctionnalités qui feront partie de l’itération.

Il est important que les itérations restent courtes (de 2 à 6 semaines max). A la fin de l’itération les fonctionnalités livrées sont testées, intégrées et utilisables. Le client peut ainsi décider de passer en production le produit après n’importe qu’elle itération, s’il le trouve suffisamment avancé.

L’intérêt de ce découpage en itération et multiple :

• stimuler les équipes et éviter l’effet ‘gaz parfait’. En effet, un développeur (et tout être humain ) a tendance à consommer tout le temps aloué à la réalisation d’une tâche, même si celui-ci est surévalué.
• supprimer l’effet tunnel. Dans un cycle de développement classique, après la phase de spécification, le projet rentre dans ‘la boîte noire’, ou le client est totalement aveugle. Puis, il ressort plusieurs mois après, quand les développements sont finis, et devient enfin visible pour celui-ci. Difficile d’identifier les dérapage ou bien même de se rendre compte des erreurs contenues dans les spécifications.
• recalculer la productivité. Après chaque itération on peut en effet recalculer la vélocité de l’équipe et ainsi remettre à jour le planning et prévoir en conséquence, et ce, très tôt dans le projet.

Et les méthodes Agiles prennent :

D’après une étude d’août 2007 sur les méthodes agiles, effectués par le cabinet Forrester, on se rend compte que les méthodes agiles ne sont plus d’obscures pratiques utilisées en cachette par quelques geeks.

D’autant plus que d’après ce rapport, ces chiffres sont à revoir à la hausse, la question ayant été posée aux grands décideurs des entreprises, qui ne sont pas forcément au courant de l’ensemble des méthodes pratiquées par leurs chefs de projets.

Attention, aux fausses idées :

Les fausses idées sur les méthodes agiles ont encore la vie dure, les principales sont pour moi :

• Dans un projet agile, le planning n’est pas très précisément défini, c’est donc forcément un projet sans fin. C’est faux! Dans les méthodes agiles ont retrouve également une phase d’estimation initiale qui permet de fixer une durée et une enveloppe au projet. Là ou cela change, c’est qu’après on n’essaye pas de faire un plan de tout le projet. On ne réalise le planning fin que pour la prochaine itération.
  Sur ce point la j’irai même plus loin, en affirmant que les projets gérés de manière ‘classique’ peuvent même être plus risqués et sans fin. En effet, dans ce type de projet le client n’a pas forcemment conscience des dérives et lorsque l’on s’approche des dates critiques, les parties les plus importantes pour lui ne sont pas forcemment celles qui ont été développées, et donc il ne peut rien faire de ce début d’application qui a été développée. Au contraire, dans les méthodes agiles, le client, à tout instant, a la vision précise de l’avancement des développements, car après chaque itération un produit fonctionnant lui est livré. A la fin du temps imparti initialement, il est sure que les parties développées correspondent aux fonctionnalités les plus importantes.
• Cela ne marche pour des contrats au forfait. Si! Mais il faut prévoir dans ce cas la, un contrat différent de ce que l’on fait actuellement. Et même, si le client ne souhaite pas s’impliquer, on peut utiliser quand même certains concepts agiles en interne, en désignant dans l’équipe une personne représentant le client et en réutilisant le concept d’itération.
• Les méthodes agiles ne fonctionnent que pour certains types de projets bien précis. Faux. Les méthodes agiles ont été testées sur tout types de projets, et l’on a remarqué qu’elles étaient les plus efficaces sur les projets critiques, les projets risqués avec des spécifications mal définies initialement.

Voila, je m’arrête là pour le moment. J’ai essayé ici de vulgariser les concepts agiles que je trouve extrêmement intéressant (désolé pour les approximations ou les raccourcis). Je ne me suis pas trop arrété sur les concepts de qualité que mettent en avant les méthodes agiles, en effet, même si l’on doit à celles-ci un regain d’intérêt pour les tests et l’apparition de méthodes tels le TDD (Test Driven Development), je pense que ces méthodes ne sont pas incompatibles avec la gestion de projets classiques et que ce n’est pas la un point de divergence fort.

Dans un second temps je vous présenterai la méthode Scrum et je ferais un petit résumé du livre de Véronique Messager Rota que je viens de finir et qui est extrèmement intéressant.

Une présentation sympa en est faites ICI.