Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : 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 :

Scrum

(image © Avangel, Wikipedia)

  • Le directeur de produit : (aussi appelé Product Owner) 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 tant 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 techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions 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écifications 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 point 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 questions à 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.

6 réponses sur “Scrum : introduction”

  1. Question pratique : Le rôle de directeur (ou chef de projet) et de scrum master pourrait être tenu par la même persone ?

    En lisant la description du scrum master, je me rends compte que cela correspond déjà un peu aux objectifs d’un chef de projet.

    En tous cas, cette méthode ressemble beaucoup à ce qui se passe sur un projet de type TMA. Effectivement, contrairement à un gros projet de build, sur une TMA, on va essayer de lotir toutes les évolutions et de rationnaliser les différentes phases (conception, réalisation, intégration).

    Sans connaître cette technique, je me rends compte que naturellement, on tend à travailler de cette façon
    .

    Comme tu le précises, est-ce sensus stricto une méthode agile ? Car c’est déjà bien structuré et correspond à une ébauche d’industrialisation.

  2. Oui, Scrum est vraiment une méthode agile. Une des plus connues, avec l’extrem programming. Donc il ne faut pas croire que les méthodes agiles sont antinomiques avec des processus formels et industrialisables à grande échelle.

    Pour répondre à ta première question, on peut imaginer que le directeur de produit et le Scrum Master soient la même personne, mais ce n’est habituellement pas recommandé. Le directeur de produit est souvent un représentant du client qui est présent pour faire l’interface. Il peut donner les priorités, clarifier les spécifications et faire les choix qui garantiront la satisfaction du client.
    Le Scrum Master n’a pas besoin de faire partie de l’équipe au sens strict. Je sais que dans certains cas, l’équipe de développement ne voit le Scrum Master qu’une fois par semaine. Mais c’est justement par son rôle de « bouclier », qu’il protège l’équipe des perturbations extérieures.
    Les deux rôles peuvent être joués par la même personne, si elle a bien conscience du double aspect de son travail.

    Mais même si un chef de projet (au sens habituel du terme) gère certains aspects du travail du Scrum Master, il a normalement des tâches bien plus complexes à prendre en charge. Attention aussi à ne pas confondre le travail d’un chef de projet fonctionnel et celui d’un chef de projet technique. J’en parlerai dans un prochain article.

    Par contre, je ne vois pas pourquoi cette approche serait plus facile à mettre en place sur un projet TMA que sur un projet de développement plus classique… Scrum est pensé en priorité pour des équipes de développement.
    Le fait de découper un projet en plusieurs lots est à la base de la quasi-totalité des méthodes de travail.

  3. Disons que sur tous les projets sur lesquels j’ai été amené à travailler, le chef de projet tenait en partie ces responsabilités. Ce qui me paraît logique. C’est lui qui est en relation direct avec le client, il connaît au mieux ses contraintes et ses exigences.
    Et c’est lui qui connaît le mieux son équipe.
    Le chef de projet est donc bien placé sur les décisions stratégiques à prendre.

    Le fait d’identifier une personne physique pour tenir ce rôle ne me choque pas non plus. Je suis moi-même responsable d’un processus (parmi d’autres) qui doit être suivi et respecté sur plusieurs projets. Je suis donc amené à faire du suivi sur plusieurs projets et échanger avec les différents CdP concernés.

    Pour en revenir à la TMA, je disais juste que c’est encore plus vrai sur ce type de projet. Bien-sûr que sur de gros projets de buid, on est obligé de lotir. Mais honnêtement, des gros projets comme ça, aujourd’hui, il y en a de moins en moins. Ou alors, ce sont des projets de migration, ce qui n’est pas tout à fait la même chose que du build.
    Sur une TMA, on est quasiment dans du temps réel. Cela implique une grande rigueur et de la méthodologie. On ne peut pas naviguer à vue. Je trouve donc que la méthode dont tu parles s’y applique encore mieux.

  4. Bonjour,
    je tenais vraiment à vous remercier pour votre site. Je suis depuis quelques mois dans un studio de jeux vidéo, et je me suis retrouvée chef de projet entre autre chose, et votre site m’a beaucoup aidé!!
    merci merci,

    Lou

  5. Je suis assez troublé par la définition donnée ici du scrum master. Je cite : « C’est un personnage très spécial qui prend en charge tous les aspects non techniques (…). C’est un rôle qu’on pourrait approcher de celui que je tiens – en tant que directeur technique – (…). ». Le scrum master serait un « directeur technique » qui prend en charge les aspects non techniques?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.