Les méthodes Agiles

Agile

« Que pouvez vous me dire sur les méthodes Agiles? ».
C’est une question qui revient souvent en entretien et que je trouve vraiment intéressante, et ce pour plusieurs raisons que voici:

La première est que ces méthodes sont une vraie révolution mondiale sur la gestion de projet en informatique.
Pas forcément un franc succès, mais une révolution.
En tant que telle, il est normal d’attendre d’un bon candidat d’être capable d’en parler pendant quelques minutes et d’avoir un avis critique.

Deuxièmement, c’est devenu un argument marketing que les entreprises usent et surtout abusent, car c’est connu les bon développeurs travaillent en Agile.

Quand un candidat lit : Ingénieur Développement Agile, il se doit, si il répond à l’offre, de vraiment comprendre ce qu’est le développement en mode Agile, et d’être capable à la fin de l’entretient de savoir si l’équipe concernée travaille vraiment Agile ou non.

Et enfin troisièmement cela donne une bonne introduction pour parler des outils et techniques utilisées lors du cycle de vie d’un projet informatique.

Pourquoi n’y a-t-il pas une réponse claire et arrêtée?

Les méthodologies Agiles reposent sur un manifeste assez abstrait : Le manifeste Agile.

C’est un document qui a été écrit pour rassembler sous une même bannière plusieurs initiatives moderne de gestion de projets informatiques.
De nos jours il est fréquent qu’un chef de projet pioche des concepts de plusieurs méthodologies et les mélanges à sa sauce, selon son expérience, ses convictions et surtout la liberté qui lui est donné.

Et là on va séparer deux types de managers.

Les managers techniques, pour qui chaque phrase du manifeste fait sens, et qui comprennent en quoi ces méthodologies sont bonnes puisqu’elles résolvent les problèmes classiques rencontrés durant une carrière de dev.

Les non techniques, qui ne saisissent pas l’essence même des méthodes agiles et qui cherchent à appliquer ces méthodes comme on suivrait une recette de cuisine, en violant allègrement certains principes pourtant fondamentaux.

Souvent, ce deuxième type de manager, après avoir suivi des stages découverts et autres certifications aussi inutiles qu’onéreuses, gèrent leur projet en pensant être Agile. C’est comme repeindre en rouge une Twingo en lui rajoutant un aileron et un nouveau pot d’échappement, ça n’en fera pas une Ferrari.

Je cite un commentaire qui me parait bien résumer ce problème:

« Après avoir vu diverses tentatives plus ou moins honnêtes de mise en œuvre de Scrum, force est de constater que c’est vrai. Le problème de base, c’est que l’agilité cherche à mettre le développeur au centre du processus de développement. Et ça, malheureusement, personne dans le management de la DSI, à fortiori de l’entreprise, n’en a envie. Le point de vue réel est de considérer les développeurs comme des pions interchangeables, des « ressources ». Et là, en réalité, on est aux antipodes de l’agilité. Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l’absence de specs. »

L’honnêteté. Voilà un pilier des méthodes Agiles. Honnêteté du chef de projet qui ne va pas simplement tout faire pour que le développeur travaille le plus possible jusqu’à épuisement, mais aussi honnêteté du développeur qui a envie que le projet réussisse, il cherche l’excellence par professionnalisme mais aussi par respect de la confiance qu’on lui accorde.
En bonne intelligence il apprécie les conditions de travail qui lui permettent de donner le meilleur de lui-même et ne va pas tout gâcher en profitant de la liberté qui lui est donné pour bâcler son travail.

Ce commentaire souligne un élément important des méthodes agiles : il n’est pas trivial pour un individu lambda de trancher si une équipe travaille en agile ou pas. C’est ce qui fait qu’aujourd’hui beaucoup d’équipes pensent et déclarent travailler agiles tout en étant à côté de la plaque.
A lire : http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-why-agile-has-failed.html

Comment reconnait-on une équipe Agile?

On reconnait une gestion de projet agile à trois qualités essentielles:
De la bonne volonté, du bon sens et beaucoup de communication.
Si vous gérez un projet agile, vous vous rendez compte que le plus important c’est l’équipe. Les personnes de l’équipe doivent communiquer le plus possible, s’entraider, identifier les problèmes, les résoudre.
Elles doivent chercher a quotidiennement améliorer le processus pour éviter de perdre du temps sur des tâches répétitives pour pouvoir se concentrer sur celles à forte valeur ajoutée.

Les méthodes agiles sont donc le résultat de la prise de conscience de mauvaises pratiques d’une gestion de projet classique répandues dans le monde de l’entreprise. Des mauvaises pratiques qui n’étaient jamais remises en question car elles étaient la norme.
En particuliers :
-Le cycle en V, remplacé par des sprints courts et ses rétrospectives pour une amélioration constante.
-Les spécifications exhaustives remplacées par un recueil de besoin au cours du temps avec des retours clients fréquents, et des réunions de priorisation.
-Le manque global de communication, résolu par les stand-up meetings quotidiens, qui permettent de donner à l’équipe une vision globale projet, de discuter avec l’équipe de difficultés ou problèmes rencontrés…
-Un suivi de l’avancement difficile, combattu par des tableaux de planning avec avancement des taches, et un suivi de la différence entre les taches planifiées et ce qui a été réellement fait (BurnDown), souvent grâce a l’aide d’un logiciel de suivit des incidents, des demandes métiers (Jira).
-Des releases longues et difficiles, véritable enfer du développeur, qui vont être évités grâce à des pratiques d’amélioration continue de la qualité, des builds les plus courts possibles, réguliers ou automatiques, des livraison de version quotidiennes automatiques en environnement de développement et de test, utilisation de métriques sur la qualité de code.
-Des bugs et autres régressions en production, détectés au plus tôt grâce aux tests à plusieurs niveaux, tests unitaires, tests d’intégration, tests manuels…
Lire : la pyramide des tests.

Pourquoi?
Corriger bug dans un programme coûte de plus en plus cher à mesure que le processus de release avance. Un bug trouvé tôt en cours de développement ou de tests manuels est négligeable, lors de phases de tests QA beaucoup plus chers, et en production le cout peut être désastreux.
Pour se protéger contre ce problème, les équipes agiles essayent de tester le plus souvent possible leur code et de façon automatique. Dans l’idéal, chaque commit entraine un nouveau build qui est testé automatiquement. Un autre point positif de cette pratique est d’avoir la possibilité de créer une nouvelle version très rapidement avec plus de confiance sur le fait qu’il n’entraine pas de régression.
-…(cette liste n’est pas exhaustive)

L’extrême programming

Il existe énormément de méthodologies différents : Scrum, RAD, …

J’aimerais me pencher plus spécialement sur la méthodologie XP (pour Xtreme Programming), qui m’a le plus touché pour plusieurs raisons.
C’est une méthodologie précisément décrite, originale et presque subversive dans certains de ses conseils. C’est une méthodologie qui met vraiment le développeur au centre du processus de la gestion de projet, en le faisant par exemple participer à l’évaluation des taches (voir Planning Poker)
Les phases de développement se font en binôme (voir pair programming), et/ou impliquent la validation d’un autre membre de l’équipe avant prise en compte (voir code review).
Ils commencent par l’écriture de tests unitaires (voir test driven développement), et comprennent des phases de remaniement du code pour garder le code propre, lisible et facilement extensible (voir refactoring).
L’attitude à adopter est de chercher la solution la plus facile en premier (voir Kiss principle), et ne chercher à optimiser que si le besoin se fait sentir (Premature optimisation is root of evil).
Après chaque code validé, des builds sont lancés automatiquement par des serveurs de build (voir usines de build), créant le package de la solution, lançant automatiquement les tests unitaires et éventuellement déployant la solution sur des environnements de test.
Les solutions doivent être poussées régulièrement en production.

Les méthodologies agiles encouragent un rythme de travail soutenable : L’équipe ne fait pas d’heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
Elles encouragent aussi l’appropriation collective du code : Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu’il n’a pas écrites. Les tests diront si quelque chose ne fonctionne plus.

Bonne discussion sur les méthodes agiles:
http://www.developpez.com/actu/45768/Les-methodes-agiles-sont-elles-une-arnaque-Les-developpeurs-les-preferent-pour-eviter-de-planifier-et-documenter-selon-un-rapport-de-Voke/

http://www.developpez.com/actu/68946/L-esprit-agile-est-il-en-voie-de-disparaitre-13-ans-apres-la-publication-du-manifeste-agile-un-developpeur-note-l-echec-des-methodes-agiles/

Une entreprise qui met vraiment le développeur au centre de son processus :
http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf

Exemple plutôt complet d’implémentation d’une méthodologie agile:
http://www.jamesshore.com/Agile-Book/
Une liste intéréssante de personnes influentes sur le sujet:
https://www.valueflowquality.com/the-top-20-most-influential-agile-people/
Des développeurs qui se révoltent contre l’agilité:
http://programming-motherfucker.com/

Comments are closed.