Je suis en ce moment en pleine période de recherche de stage et donc d’entretiens … j’ai mis sur mon CV que j’étais intéressé par les méthodes agiles, et me rends compte que les recruteurs (même techniques) ne connaissent pas vraiment bien celles-ci.
Je pensais vraiment que c’était quelque chose de très répandu dans l’industrie, mais pas encore ! Quelque jour après le passage de l’Agile Tour sur Toulouse, cet article tombe bien …
N’ayant pas de connaissances autres que « théoriques », je me propose ici de récapituler ce que je sais et de vous fournir des liens vers des ressources intéressantes. De plus, je serai très intéressé si vous pouviez me donner d’autres informations afin de compléter mes connaissances sur ces méthodes !
Tout d’abord, commençons par la définition de Wikipédia dont j’ai mis en évidence des mots importants :
Les méthodes Agiles permettent de concevoir des logiciels en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et non d’un contrat établi préalablement.
D’emblée on se met donc dans une position totalement différente vis à vis du client. Certains diront que c’est utopique, mais je pense sincèrement qu’inclure le client (dans un rapport de confiance) au sein du projet de manière régulière peut apporter beaucoup : implication du client, rectification rapide des problèmes de compréhension, motivation de l’équipe à travailler sérieusement.
Lorsque l’on sait que 75% des défaillances sont générées tôt dans le projet (définition et développement), détectées tard (tests et utilisation du logiciel) et que plus on les détecte tard plus cela revient cher à résoudre … on peut prendre le temps de s’intéresser à ces méthodes !
Le principe de base des méthodes agiles est donc de livrer tôt une première version du logiciel, puis de l’améliorer régulièrement par l’ajout de nouvelles fonctionnalités (itérations) … jusqu’à la livraison finale du logiciel souhaité par le client.
Pour être concis, je pense que l’énumération des 4 principes fondamentaux des méthodes agiles suffira à compléter ce premier aperçu :
- Individus et interactions vs. Processus et outils
- Logiciel qui fonctionne vs. Documentation exhaustive
- Collaboration du client vs. Négociation de contrat
- Réponse au changement vs. Suivi d’un plan prédéfini
Il existe plusieurs « types » de méthodes agiles (RAD, XP, Processus Unifié, Scrum …) ayant leurs points communs et différences, cependant je ne pense pas qu’il y en ait des bonnes et des mauvaises mais plutôt que chacun doit piocher ce qui lui correspond dans chacune de ces méthodes. Ceci en fonction de son environnement et du projet.
La méthode SCRUM
D’un point de vue gestion d’équipe et de projet, j’ai été très intéressé par la méthode SCRUM que j’ai découvert lors d’une intervention de Frédéric FAURE (eBusinessInformation) à l’INSA. Le reste a été surtout documenté par la lecture des très bons blogs Aubry conseil en tête, mais aussi http://www.fredericdoillon.com/ pour une mise en application au jour le jour et des réflexions intéressantes.
En effet, cette méthode se démarque de la gestion de projet « classique » en impliquant à la fois le développeur et le client au sein du processus. On trouve 3 rôles pour les membres de l’équipe projet :
- Le ScrumMaster : animateur d’équipe. Son rôle est de s’occuper de toutes les choses non liées au développement (ex: documents administratifs) afin que l’équipe ne soit pas dérangée.
- Le ProductOwner : représentant du (des) client(s) au sein de l’entreprise. Son rôle est de définir les priorités dans les tâches à réaliser (fonctionnalités à développer) et de valider / conseiller les choix effectués (ex: pour une IHM). Cette personne doit bien connaître les besoins du client.
- L’équipe : elle est auto-gérée et il n’y a aucune notion de hiérarchie. Les décisions se prennent ensemble et elles peuvent récupérer des informations auprès du ProductOwner.
- Un point quotidien est fait sur l’état du logiciel (lors du Daily Scrum)
- Le sprint : correspond à une itération du projet livrée en interne, durant laquelle un lot de fonctionnalités (déterminé au départ) est développé. Les buts d’une itération sont fixés au début de celle-ci et ne sont pas (ou peu) changés durant les quelques semaines du sprint.
- La release : constituée de plusieurs sprints, cette étape correspond à un état d’avancement où le produit doit potentiellement pouvoir être mis en production.
Cet article n’est pas terminé mais se fait un peu long … je vous laisse réfléchir et analyser ces quelques lignes.
Une seconde partie présentera les diverses rencontres entre les membres d’une équipe durant le projet, ainsi que les documents et supports clés à la gestion du projet (et des fonctionnalités). De plus, j’essaierai d’établir une liste cohérente de ressources : blogs, présentations, études de cas, logiciels …
Mes sources principales : Wikipédia, Aubry Conseil, Présentations du Sigma T.
