Scrum est une méthode de gestion de projet très intéressant. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l'un de ses concepts-clé : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l'organisation de projet et la gestion d'équipe. C'est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L'image suivante présente d'une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

(image © Avangel, Wikipedia)

• Le directeur de produit : Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l'équipe les fonctionnalités qu'elle devra développer, et de transmettre l'ordre de priorités. Il opère un suivi régulier avec l'équipe de développement, et remonte régulièrement les informations d'avancement au client.
• Le Scrum Master : C'est un personnage très spécial qui prend en charge tous les aspects non techniques pour "protéger" l'équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s'assurer du respect de la méthode. C'est un rôle qu'on pourrait approcher de celui que je tiens - en temps que directeur technique - vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications technique).
• L'équipe de développement : La théorie voudrait que l'équipe soit auto-gérée, et que ses membres prennent eux-même leurs décision de manière collégiale. D'expérience, j'ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu'elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l'expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes...

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée "raisonnable" (2 à 4 semaines). Évidemment, l'ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L'important dans cet exercice, c'est de bien comprendre - et surtout faire comprendre aux autres acteurs - qu'une fois qu'on a défini la liste des fonctionnalités et qu'on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n'est pas possible d'ajouter de nouvelles fonctionnalités ni de changer l'ordre de priorité.

Il existe toutefois un risque, c'est d'entrer dans un tunnel qui fait qu'à la fin du sprint on se rend compte que le développement ne correspond pas vraiment aux souhaits du client. C'est pour cette raison que des réunions quotidiennes (les ScrumMeetings, mais bon, on se fout un peu du vocabulaire) permettent de s'assurer que l'interprétation que les développeurs font de la spécification est conforme à la vision qu'en a le directeur de produit.

Mais que fait-on si le client veut vraiment changer un ensemble de fonctionnalités ? C'est simple, on retire les fonctionnalités en question du sprint, dont on peut raccourcir la durée d'autant. Quand une fonctionnalité est mise de côté, le directeur de produit communique avec le client pour la réintégrer correctement aux spécification du prochain sprint. Par contre, le ScrumMaster doit rester ferme : on n'ajoute pas de nouvelles fonctionnalités à un sprint qui a déjà été commencé.

Le seul cas vraiment délicat, c'est quand il faut trouver la limite entre le développement pour lequel on demande des éclaircissements, et celui qui n'est vraiment pas suffisamment ou correctement spécifié. Dans le premier cas, les ScrumMeetings servent à mettre les choses au points et apporter les réponses que l'équipe de développement attend. Dans le second cas, c'est net, la fonctionnalité est éjectée du sprint.
C'est donc à l'équipe, en accord avec le directeur de produit et le ScrumMaster, que revient la décision de garder une fonctionnalité ou de la sortir. Mais de manière générale, il ne faut pas garder un développement si on se pose toujours des question à son sujet après 2 ou 3 ScrumMeetings. C'est le temps qu'il faut normalement pour que le directeur de produits fasse un aller-retour avec le client, pour éclaircir les détails les plus pointus.

Dernière notion importante, les sprints étant consacrés au développement, ils sont très souvent suivis d'une période consacrée à la stabilisation du projet, aux tests, aux débugages, jusqu'à la livraison du logiciel. Il est généralement une mauvaise idée de vouloir enchaîner deux sprints directement l'un derrière l'autre. Poussés par le client, certains directeurs de produit peuvent être tentés de le faire, arguant que les spécifications du sprint suivant ont été écrites pendant la réalisation du sprint courant. Malheureusement, cela revient à réduire la réalisation de projet au seul développement ; c'est le meilleur moyen d'avoir des briques logicielles qui sont développées mais qui ne sont jamais vraiment terminées et qui ne sont jamais mises en production...

Mon avis personnel, c'est que les sprints sont un aspect pas vraiment très agile, pour une méthode qui se dit agile. Mais d'un autre côté, cela apporte un grand confort qui fait gagner du temps à tout le monde au final. Parce qu'on a tous eu des donneurs d'ordre qui changent d'avis tous les 2 jours, qui nous forcent à entamer des développements alors même que la spécification n'est pas terminée. Les ScrumMeetings assurent l'aspect itératif qui permet de contenter le client, et c'est le plus important.