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 :
(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écient les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes… (voir les explications en commentaire)
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.
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.
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.
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.
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
Tout le plaisir est pour moi. N’hésitez pas à m’écrire pour partager vos expériences !
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?
Je suis très troublé par cette phrase :
Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…
Peut-être pourriez vous nous éclairer sur le fait que les autistes sont un poids pour l’équipe selon vous ?
@Siegfried : Ce n’est pas ce que j’ai dit. Il faut relire le paragraphe en entier. J’y parlais des équipes qui devraient théoriquement être auto-gérées, en disant que je n’en ai jamais vu fonctionner correctement. Car, pour fonctionner, il faut « des développeurs très compétents, avec de l’expérience, et surtout qui apprécient les contacts humains ». Sauf que ce n’est que rarement le cas.
Les “autistes”, au sens de personnes ayant « des difficultés dans les interactions sociales et la communication » (définition Wikipedia) ne sont pas plus un poids de manière absolue que les stagiaires ou les personnes qui ne sont pas très bonnes techniquement. Tout est question de mesure. Il est important d’avoir des stagiaires, ça fait partie de la formation, et c’est ce qui permet d’alimenter le bassin d’emplois. Les personnes qui ont des lacunes techniques peuvent avoir d’autres qualités, et les meilleures équipes que j’ai vues étaient constituées de personnes de niveaux variables (pas uniquement de cadors) mais qui se complétaient les unes les autres.
Je disais donc que la belle théorie d’avoir des équipes qui se gèrent elles-mêmes doit être confrontée à la réalité du terrain et à la pluralité des profils qui travaillent ensemble en entreprise.
Les autistes ne sont pas que des personnes avec des difficultés dans les interactions sociales. Il y a surtout d’énormes difficultés sensorielles que vous ni le corps médical ne pouvez concevoir. Et même là on est loin, très loin d’avoir fait le tour de la question.
Les utiliser comme insulte pour désigner ceux qui ont du mal à s’intégrer dans vos équipes est tout simplement abject, car ces personnes que vous décrivez n’ont rien à voir avec l’autisme réel, et cela contribue a stigmatiser les vrais autistes d’une part, d’autre part, vous encourager vos lecteurs à rester dans la validisme ou capacitisme qui les caractérise déjà malgré eux, et à leur insu
Avez vous au moins déjà travaillé avec un autiste dans votre équipe pour oser porter de tels propos ? Je suis sûr que non.
Laissez les autistes tranquilles et changez votre texte.
De ce que je comprends (je n’ai aucune prétention à ce niveau), les troubles du spectre de l’autisme recouvrent différents niveaux de sévérité. Donc ce n’est pas quelque chose de binaire, et ce que vous appelez l’autisme réel est sujet à discussion (et ce n’est pas le lieu pour cela).
Je persiste à dire que je n’ai pas plus insulté les autistes que je n’ai insulté les stagiaires. Et je ne parle nulle part de « ceux qui ont du mal à s’intégrer dans [mes] équipes ». Vous faites une lecture très incorrecte et très biaisée de mon article.
Encore une fois, je dis au contraire que toutes les équipes sont constituées de profils variés, et non pas de développeurs “parfaits” fantasmés.
Il m’est arrivé de travailler avec des personnes qui avaient des symptômes autistiques, sans qu’ils ne soient pour autant ce que vous qualifiez sûrement de vrais autistes (sic).
Je comprends que le sujet semble vous toucher personnellement, ce qui explique peut-être votre interprétation “à charge” de mon article. Mais je vous suggère de faire la part des choses et de relire l’article calmement.
On pourrait disserter sur l’utilisation du mot “malheureusement” (dans la phrase « Et malheureusement, toutes les équipes ont leurs stagiaires(…) ») ; mais je pense que tout le monde aura compris qu’il est utilisé en contradiction de la vision fantasmée que je réfute. Je ne dis pas du tout que c’est malheureux pour les équipes !
Mais on ne va pas disserter : je réagis assez mal aux invectives m’intimant de modifier mes textes en les traitant d’abjects.
Vous êtes bien loin d’être la première victime de votre psychophobie mais quand ça va commencer à se payer en visibilité il y en a un qui va changer juste un mot dans son texte quand même.
A très vite 😉
@Siegfried : C’est quand même dommage d’en arriver à des menaces, là où il aurait été possible de me le demander gentiment et poliment, non ? Depuis le début vous êtes dans une démarche de donneur de leçons acerbe − qui aime manifestement donner des ordres.
Je vous invite à écrire à votre tour 289 articles en 12 ans. On verra si absolument personne ne trouvera rien à redire à l’intégralité de vos textes, et si vous aurez la patience de vous plier en quatre pour répondre aux injonctions impératives et agressives qui vous seront faites… 🙄
Soit dit en passant, j’aurais pu ne pas valider vos commentaires belliqueux, mais j’ai ouvert la discussion en toute transparence. Vous préférez les menaces. Soit.