Au vu de l’expansion de l’agilité dans les projets informatiques ces dernières années, une question légitime se pose sur ses avantages comparés à des méthodes plus classiques de gestion de projet en cycle en V par exemple.
Bien qu’il soit difficile de trouver des études fiables sur le sujet, il semble que ce changement soit dû au fait que les projets agiles ont plus de succès en général, ou du moins c’est ce que l’on pense d’eux.
Cependant, ce n’est pas une solution miracle pour autant : il reste un grand nombre de projets menés en mode agile qui rencontrent des difficultés ou qui échouent complétement.
Quels sont les indicateurs à la disposition des équipes et des entreprises qui permettent de savoir si un projet progresse correctement ? Quels éléments peut-on comparer entre les projets pour connaître ceux qui s’en sortent le mieux ?
Une des métriques les plus connues et utilisées dans les projets agiles est la vélocité. Elle correspond à la somme des story points des tâches finies et validées dans un sprint donné, les tâches qui ne sont pas dans cet état ne sont pas prises en compte. Cet indicateur permet d’avoir une idée approximative pour les sprints suivants du nombre de story points pouvant être traités.
Sur une vision plus long terme, cela permet de prévoir des dates possibles pour des livraisons importantes pour le client et le rassurer. Cela est notamment visible grâce au burnup chart des sprints qui permet de voir l’évolution de l’avancement dans chaque sprint passé.
Cependant la vélocité ne doit pas être utilisée comme outil absolu.
Elle sera rarement complétement stable (par exemple si sur une semaine donnée il y a un séminaire ou des personnes en vacances ou malades) et ne doit pas non plus être utilisée par l’entreprise comme moyen de pression sur les équipes. Par ailleurs, c’est un indicateur utile localement mais inadapté pour comparer les projets entre eux. Enfin il n’y a pas d’étude détaillée sur l’apport concret de la vélocité dans les méthodes agiles comparées aux méthodes standards.
En complément de la vélocité, il est intéressant de calculer la prédictibilité.
C’est le ratio entre la somme des story points livrés à la fin du sprint et la somme totale de story points prévus pour le sprint. Ce ratio doit rarement décroitre d’un sprint à l’autre, plus les personnes travaillent ensemble sur le projet, plus elles sont censées être capables d’estimer leur travail. Il est donc intéressant de suivre cet indicateur sur toute la longueur du projet pour être sûr qu’il n’y a pas de problèmes d’estimation dans l’équipe qui pourrait engendrer des retards ou des coûts supplémentaires.
Un autre indicateur intéressant est la fiabilité, soit le nombre de bugs découverts après la validation des user stories. Si ce nombre est grand à chaque sprint, il y a de grandes chances pour que le projet prenne du retard ou dépasse son budget puisqu’il faut revenir en permanence sur ce qui est développé à chaque sprint.
Enfin, si on reprend l’essence du manifeste agile, il est intéressant de regarder le ressenti des clients et des équipes. En effet, si à chaque sprint il est demandé aux clients ce qu’ils ont pensé du travail effectué et de le symboliser par une note entre 1 et 10, cela permet de savoir facilement si le projet avance bien du point de vue client. La même chose peut être faite dans les équipes, car leur satisfaction est le gage d’un travail bien fait.
Il existe de nombreux autres indicateurs qui permettent de suivre l’avancement d’un projet agile mais il n’y a finalement pas de solution qui fonctionne à coup sûr. Cela dépend entre autres du projet, des personnes qui travaillent dessus, de la méthode utilisée…
Si on part du principe que l’auto-organisation des équipes impliquent pour elles de choisir librement leurs indicateurs, cela empêche toute comparaison transverse en intra-entreprise ou en inter-entreprises. Alors qu’il existe des solutions qui permettent des comparaisons universelles entre les projets, comme la méthode COCOMO ou la méthode des points fonction, elles gagneraient à être plus connues et mises en avant dans les équipes projets.
Auteur : Quentin