1. La méthode classique
Elle consiste à analyser les besoins, définir un produit à travers un cahier des charges exhaustif, concevoir le produit, le développer et le tester. Un projet peut donc durer entre plusieurs mois et plusieurs années. Le chef de projet doit définir des jalons pour chacune des phases. Les phases d’étude et d’analyse restent totalement théoriques jusqu’à ce que les développeurs se heurtent à certains problèmes que personne n’avait pu anticiper. Le temps de développement d’un projet est donc particulièrement imprévisible et dépasse souvent la durée et/ou le budget initialement prévus.

2. Les méthodes agiles
Ces méthodes ont débuté en 2001 aux États-Unis suite au constat du nombre d’échecs croissant de projets de développement. Une équipe d’experts s’est donc réunie et a rédigé un manifeste décrivant l’attitude à adopter pour mieux s’adapter au changement et ainsi mieux répondre aux attentes des clients.
Le principe de ces méthodes est de découper le projet en plusieurs itérations qui définissent chacune des fonctionnalités composant le produit final. Il y a plusieurs avantages à travailler sur des mini projets plutôt que sur un gros projet :
• Les développeurs n’ont plus cette impression de ne pas avancer.
• Les clients participent régulièrement aux phases de tests de chaque fonctionnalité et donnent leur avis au fur et à mesure).
• Un cercle vertueux se met en place.


La méthode Scrum

La méthodologie Scrum
Scrum est la plus populaire des méthodes Agile. Elle consiste à définir toutes les fonctionnalités de l’application dans un backlog. L’équipe de développement se réunit toutes les 2 ou 4 semaines pour définir les fonctionnalités qu’elle va implémenter pendant les 2 ou 4 semaines suivantes. Le cycle se répète jusqu’à ce que le backlog soit vide. On appelle ces itérations des sprints. Une fois un sprint terminé, on debrieffe et on recommence avec de nouvelles fonctionnalités.
Je trouve cette méthode valable si on enlève toutes les réunions qu’elle engendre. En effet, voici une liste de toutes les fois où l’équipe doit se réunir pour discuter :
• Sprint planning : c’est là où on définit les priorités pour le sprint à venir (prévoir une demi-journée par sprint)
• Daily scrum : tous les matins, on se réunit quelques minutes pour que chacun parle de ce qu’il a fait la veille, des difficultés rencontrées et de ce qu’il va faire aujourd’hui. En théorie, elle ne doit durer que 15 minutes, mais il suffit qu’une personne de l’équipe ait tendance à parler un peu trop et votre matinée est déjà presque terminée.
• Backlog refinement : ici on estime la durée de chaque tâche. Cette durée est estimée en points. Donc en plus d’être totalement arbitraire et incompréhensible (1 point = combien d’heures ?), le temps passé à estimer la fonctionnalité aurait souvent suffi à la développer (prévoir une demi-journée par sprint).
• Sprint review : c’est le moment où on fait le point sur le sprint que l’on vient de terminer. Conclusion : on se rend souvent compte que le nombre de tâches prévu était trop important, et on s’organise pour que le sprint suivant soit parfait ! (le sprint suivant se passe en réalité aussi mal que le précédent et en plus il fautprévoir une demi-journée par sprint).
Toutes ces réunions sont chronophages. En moyenne,une équipe de 4 développeurs perd “10 jours hommes” en réunion toutes les deux semaines.
Le terme agile ne veut plus rien dire. En théorie, l’équipe devrait pouvoir s’adapter immédiatement aux changements. J’ai malheureusement assisté à des réunions où le chef de projet ne pouvait pas ajouter une petite tâche au sprint en cours car cela “allait à l’encontre de la méthodologie Scrum”.
Pour conclure, les sprints et les itérations rapides proposés par la méthode Scrum sont une réelle évolution dans la gestion de projets. En revanche, le trop grand nombre de réunions et le manque d’adaptabilité réduisent les bénéfices de cette méthode.

Dans le prochain article je vous parlerai de GitHub!