SCRUM ? SCRUM ! SCRUM…
Vous ne connaissez pas Scrum? Scrum est la dernière mouture de développement « agile ». C’est une méthode de travail. Elle est sensée améliorer la productivité via l’autonomie. Et d’Ubisoft à Etranges Libellules, la mode, en France, s’appelle SCRUM.
C’est quoi SCRUM ?
Je vous passe l’historique (il est sur wikipédia : http://fr.wikipedia.org/wiki/Scrum).
Scrum consiste à découper le développement en « sprints », des séquences de 1 à 4 semaines fixes (on ne rallonge pas la longueur du sprint) avec un but défini par le directeur produit (généralement le producer). A partir de ce but, sont découpés des tâches et fonctionnalités à remplir, généralement dégrossies par le SCRUM Manager -parfois nommé SCRUM Master (qui est généralement le chef de projet). L’ensemble de ces tâches on le nomme « backlog ». On liste ce qu’on va faire.
Une réunion permet aux développeurs d’estimer, de déduire en sous taches, et de s’attribuer ces tâches, sous la supervisions du SCRUM Master. Chaque fois qu’un déceveloppeur a fini sa tâche, il va en reprendre une autre. Jusque vient le moment prévu où on arrête de code : on teste, corrige les bugs.
Une fois cela fait, on livre (c’est ce qu’on appelle la revue) une version au directeur produit. L’objectif de la revue est de valider ce qui a été produit. L’équipe énonce les features réalisés et celles laissées tombées. Elle effectue ensuite une démo. C’est sur la base de cette démo que le directeur de produit valide (ou non) chaque feature planifiée.
Il faut comprendre que SCRUM postule que le Directeur Produit est « le client », il dit ce dont il a envie ou besoin. Et on va lui livrer une version allant dans son sens.
On part donc de briques plus petites, des évolutions plus fréquentes (1 à 4 semaines fixe) et un suivi régulier. En celà c’est une bonne méthode. L’avantage aussi est de pouvoir limiter les choses développées au temporelement réalisable. Ca permet d’avoir moins de remords lorsqu’une feature est abandonnée, faute de temps.
SCRUM permet aussi de jauger la vélocité de l’équipe. Un gain appréciable. Et puis selon le post mortem que je viens de lire – Brutal Legend, ça permet également de libérer la créativité et de tester les idées folles : http://www.gamasutra.com/view/feature/4308/postmortem_double_fines_brutal_.php
Sauf que …
Scrum repose sur 3 choses :
- Une équipe soudée
- Une équipe motivée par l’objectif
- Une équipe talentueuse.
J’ai déjà entendu parler d’équipe peu soudée ou démotivée, c’est un secret pour personne, ça arrive plus souvent qu’on ne l’admet. SCRUM n’y changera rien. Seul un chef de projet habile pourra redresser la barre. SCRUM n’est ni une baguette magique, ni potion de bonne volontée. Et comme dirait un ami canadien « SCRUM screws with scrubs » (comprendre : SCRUM merde avec les boulets).
En effet une personne qui évalue très mal les tâches, s’attribue les tâches à faire et les fait mal, peut faire dérailler rapidement la mécanique. Il faut le cadrer, et ca colle peu avec la logique SCRUM. L’équipe ne comporte pas de rôles prédéfinis, elle est sensée être auto-gérée. Il n’y a pas non plus de notion de hiérarchie interne. Que faire de vos lead alors ? Quid de l’expérience dans une tâche ?
Et Scrum s’applique pas forcément évidemment aux tâches de l’esprit. SCRUM est génial pour un programmeur. Mais un game designer doit organiser son travail horizontalement (tout décrire succintement) et verticalement (décrire en profondeur les notions importantes). Donc des fois ça donne l’impression d’un chantier perpétuel qui colle assez mal avec l’idée de « on fait une fois, la bonne, et on y retouche plus » souvent liée à SCRUM.
Où les travers du jeu vidéo persistent.
Là où la question devient plus complexe, c’est dans l’intégration de SCRUM dans le jeu vidéo. De ce que j’ai entendu dire, ca ne passe pas si bien, parfois, avec les rapports hiérarchiques usuels; les leads et la direction peuvent avoir l’impressions d’être dépossédés de leurs prérogatives. Ou au contraire, ils les gardent, et l’équipe se sent dépossédée de son autonomie.
J’ai entendu parler de revues qui tournent plus au jeu de massacre qu’à la revue effective de SCRUM, où la direction va recadrer tous les éléments (au mieux, de jeu, au pire de l’équipe) qui ne lui plaisent pas depuis ces deux dernières semaines. Une occasion de casser l’autonomie décisionnelle demandée par l’équipe lors de la mise en place de SCRUM.
Je doute que ça soit efficient.
Pour conclure.
Efficace et intelligent ? SCRUM l’est. Il nécessite cependant une équipe motivée, organisée, talentueuse, soudée, et une direction du même métal, patiente et communicative en plus.
Ne prenez pas SCRUM pour son effet de mode, ou pour une méthode qui va résoudre les problèmes du quotidien, ou pour un moyen de vous débarasser du chef de projet et de la hiérarchie interne à votre profit. Prenez le comme un moyen de mieux maîtriser vos cycles itératifs de développements, qui doit être adapté à votre entreprise.
-
Articles connexes
- Gestion de projet 101 : Ces documents qu'on aime.
- Management : non, non, rien n'a changé
- Management 101 : Un planning pour les gouverner tous
- Développeurs : le crunch nous va si bien...
- Management 101 : Jouez au Risk
Merci pour cet article sur Scrum. C’est vrai que la mise en place de Scrum ne se fait pas sans mal, surtout dans des structures d’organisation qui elles, ne sont pas Scrum. Ayant experimenté la methode depuis quelques temps, je peux te rassurer sur le fait que ça marche, même si tout n’est pas parfait: ni l’équipe, ni le ScrumMaster (moi
, ni le Product Owner. En se focalisant sur la dynamique de groupe on arrive a tirer toute l’équipe vers le haut.
Tant mieux si ça marche
bon courage pour ça d’ailleurs, la mise en place est parfois compliqué.
Par curiosité, peux tu nous dire dans quelle structure – si ce n’est pas indiscret ?