24h chrono de Scrum…
Caroline | 07/05/2010 | 08:23
Scrum… Cela fait désormais 4 ans (depuis que je m’intéresse au milieu du jeu vidéo en somme) que j’entends parler de Scrum, de l’Extreme Programming et des méthodes dites agiles. J’ai essayé de me pencher sur le sujet de nombreuses fois, mais sans vraiment comprendre leur logique. Mais la semaine dernière à l’ENJMIN, nous avons eu un TP de Scrum entre programmeurs et chef de projets et j’ai pu un peu mieux comprendre Scrum. Car en management, plus que la théorie, c’est la pratique qui fait la différence.
Notre équipe était constituée de 4 programmeurs et 2 chefs de projet, et il s’agissait de développer un jeu de plateforme comportant un personnage qui se déplace, des plateformes mobiles, des obstacles et des ennemis qui tirent. Le tout en 9h en applicant la méthode Scrum au pied de la lettre, et en effectuant 3 sprints de 3 heures chacun.
Je vous livre donc mes impressions suite à cette journée “expérimentation scrum” et vais essayer d’expliquer de façon claire et concise en quoi cela consiste. Si des pros passent par là et voient certaines incohérence dans mes propos, n’hésitez pas à commenter l’article pour m’éclairer sur les points un peu flous, car c’est aussi (surtout même) le but de cet article. 
Scrum : kesako?
A la base, et pour faire court, c’est une méthode de management développée par des programmeurs dans l’industrie du logiciel.
Dans le jeu vidéo, la méthode Scrum est souvent utilisée par les studios de développement mais le plus souvent elle est adaptée aux besoins de l’entreprise. Elle n’est donc pas prise au pied de la lettre car un poil rigide pour l’industrie du jeu vidéo où l’on développe les jeux en cycle itératif et non en cycle en V comme pour le logiciel.
Scrum en 4 étapes
Plus qu’une méthode de travail, Scrum c’est surtout des outils. Petit résumé en 4 points clés :
- Le backlog
Le backlog s’apparente à une liste des tâches. En gros, c’est tout ce qu’on a envie de mettre dans le jeu. Il s’agit d’écrire sur des post it tout ce que l’on veut mettre dans le jeu (tout en sachant qu’au cours du projet on va piocher dans cette liste mais qu’il est possible qu’on ne les aura pas tout utilisé à la fin du projet).
Ensuite, il s’agit de prendre ces post it et de les placer dans 4 catégories : “à faire”, “en cours”, “fini”, “validé” (ce qui veut dire pour ce dernier que l’on a testé l’élément et qu’on s’est assuré qu’il n’était pas/plus buggé).
Généralement, en fonction de la personne qui fait telle ou telle tâche, celle-ci annote son nom sur le post it.
Cela permet d’avoir une vision d’ensemble du projet et de savoir à quel stade se situe chaque tâche et qui en est propriétaire (qui s’en charge ou s’en est chargé).
- Les stand up meetings
La méthode scrum préconise de faire des “stand up meetings” de façon régulière. L’équipe se rassemble de façon fréquente (tous les jours, tous les lundis matins, ou autre, cela dépend du management de l’entreprise ou du groupe) en faisant des réunions courtes (pas plus d’une 1/2 heure) et les personnes restent debout, ce qui favorise la réunion “court terme” et l’écoute de chacun. L’objet de ces réunions est de dire quelle tâches on a fait la veille et celles que l’on s’apprête à faire le jour-même. Cela permet aussi de parler des problèmes rencontrés jusqu’alors et ce que l’on compte mettre en place pour les résoudre ou de demander à ses coéquipiers comment s’y prendre.
Les stand up meetings sont sensés favoriser la transparence et la communication entre les membres d’une équipe ainsi que leur réactivité.
- Le burndown chart
Le burndown chart est un graphique qui permet d’évaluer si on est en retard ou en avance sur un sprint.
On trouve deux courbes sur ce graphique : la durée estimée pour les tâches d’un sprint, et la durée réelle que l’on a mis pour effectuer ses tâches.
- Les sprints
Selon moi, un sprint c’est un peu une liste de tâche à court terme.
Dans les grandes lignes, on pourrait assimiler les sprints à des tronçons de planning (des mini todolist en somme) et pour chaque sprint, on définit des tâches données à effectuer.
Pour que cela soit plus parlant, prenons l’exemple du jeu de plateforme que nous devions développer pendant la journée Scrum.
Lors du 1er sprint de notre journée “SCRUM”, nous avons décidé avec les programmeurs de coder un personnage de type stickman qui se déplace sans animation. On a également choisi de développer des plateformes fixes.
Pour le 2e sprint, nous avons décidé d’ajouter une fonction “saut” au personnage (toujours sans animation), ainsi que des plateformes mobiles, des obstacles fixes par dessus lesquels il faut sauter, ainsi que des ennemis qui se déplacent.
Et enfin lors du 3e sprint, les programmeurs ont ajouté quelques détails pour rendre le jeu cohérent. Ainsi ils ont codé des ennemis qui tirent des balles de couleur, un fond graphique avec un ciel bleu et des arbres et des bruitages se déclenchant lorsque le personnage saute.
“AAAAAAAAAH SCRUM” ou le concept du rouleau compresseur !
Personnellement, je trouve tout ça un poil rigide. C’est pour ça qu’à mon avis il est nécessaire d’adapter Scrum en fonction des besoins de l’équipe et de leur tolérance par rapport à leurs outils. Une personne ayant expérimenté Scrum de façon rigide en entreprise, à qui on aura imposé des méthodes et des techniques comme si on la faisait marcher sur du verre pilé ne voudra pour rien au monde avoir affaire une fois de plus à ce type de management.
En revanche, une personne à qui on aura fait utiliser Scrum de façon utile et intelligente en fonction de ses besoins sera plus encline à récidiver l’expérience par la suite.
“Look at my scrum, my scrum is amazing….”
On utilise tous Scrum au quotidien sans le savoir. Qui n’a jamais affiché des post it sur son mur pour se rappeler ce qu’il a à faire de sa journée ou de sa semaine ? Parfois même, certains iront jusqu’à organiser leurs papiers de toutes les couleurs en catégories “A faire”, “En cours” ou “Fait”… Ca ne vous rappelle rien ?
Pour le coup, c’est comme ça que je m’organise chez moi et quand j’ai entendu parler de Scrum tout s’est enclenché de façon logique dans ma tête. Il est donc simple d’adapter une méthode de management qui peut paraître très rigide sur le papier.
Pour ce qui est des mini-projets sur lesquels je travaille actuellement à l’ENJMIN, j’ai voulu mettre en place ce système de tâche. Comme je l’ai expliqué dans mon précédent post, j’ai donc mis en place une todolist (un backlog) en ligne sur un google doc éditable en ligne par toute l’équipe.
Le document est séparé en onglets. Il y a un onglet par spécialité, ce qui permet de circuler dans le document de façon libre afin de savoir où chacun en est et si certaines tâches sont interdépendantes.
On utilise un code couleur et des pourcentages pour savoir où en sont les tâches. Une tâche noire est “à faire”, une tâche rouge est “en cours” et effectuée entre 0 à 50%, une tâche orange est “en cours” et effectuée de 50 à 100% et une tâche verte est “faite” et validée donc effectuée à 100%.
Pour ce qui est des stand up meetings, j’ai décidé de ne pas en faire. Trop rigide. J’aime autant me déplacer et aller voir chaque personne de l’équipe pour voir les problèmes évalués et quelles solutions sont envisagées. En revanche, nous tenons en ligne un document où chacun écrit 3 lignes sur les tâches qu’il a faite, qui sont en cours et à faire. Cela permet de faire le point et tout le monde peut le lire pour aller aider la personne concernée.
Pas de burndown charts ni de sprint. Du moins pas de sprint à proprement parler. Je pense que notre processus de développement par itération (X tâches à réaliser pour telle date) peut s’apparenter à du sprint mais je préfère ne pas choisir ce terme car il est trop connoté de façon négative (sprint = rush = stress = mauvaises conditions de travail).
Et comme je suis avant tout pour la bonne ambiance dans l’équipe, et que je prône le principe du “prendre son travail au sérieux, mais ne pas se prendre au sérieux soi-même”, lorsque le travail est bien fait ça se solde généralement comme ça :
Voilà, c’était le mot de la fin… Vous en saurez plus sur les mini-projets bientôt… Soit lorsque le devblog sera en ligne soit dans un prochain article sur Like a Gamer !
Pour le moment, je m’attèle à la recherche d’un hébergeur sympa… Si vous avez des suggestions, n’hésitez pas !
Vraiment sympa ton blog, je dois bien avouer apprendre beaucoup de choses ^^ ! Notamment cette méthode !
Merci ! Contente que mon blog t’apprennes des choses, il est là pour ça ! D’ailleurs, j’ai vu que tu avais postulé à l’ENJMIN, donc si tu as des questions sur certains points n’hésite pas à me mailer, ça me donnera des idées d’articles
Article intéressant.
La dernière photo me fait penser au concept de “maman de projet” inventé l’année dernière par des enjminiens
Parce que la carotte est tout aussi (voire (bien) plus) importante que la baguette, et que des gens bien chouchoutés c’est des gens qui bossent bien. Je taperai bien quelques lignes de code chez vous pour pouvoir gouter vos muffins-oreos…
Concernant les stand-up meetings, le concept important c’est la conversation décomplexé. Toi tu as mis ça en place en mélange un petit résumé écrit par personnes, plus une centralisation des infos où tu rends visite et chacun et tu fait circuler. L’essentiel c’est justement que ça circule. Il m’est arrivé de travailler avec des gens qui faisaient des réunions de 1h30 ou qui n’en faisait pas et qui ne communiquait par aucun autre biais (pas de conversation à la machine à café). Ben ça n’avance à rien du tout…
J’ai préféré m’orienter vers des muffins et des cupcakes plutôt que des packs de bières, effet garanti
Blague à part, je suis tout à fait d’accord qu’une bonne ambiance au sein de l’équipe facilite la motivation sur un projet et en découle donc plus d’implication. Chacun y trouve son compte et ça permet au projet de suivre son cours comme il faut.
Néanmoins je pense que le plus important au sein d’un groupe de travail est surtout la cohésion d’équipe. Sans consensus, difficile de faire aboutir les choses et de garder l’équilibre entre chacun. J’ai fait l’erreur sur un de mes deux projets pendant les exercices sous Game Maker, et je compte bien éviter de récidiver.
C’est pour ça que je préfère aller voir chaque personne individuellement (ou par spécialité) plutôt que faire des stand up meetings. C’est beaucoup plus personnel et ça permet de déceler les problèmes de façon plus aboutie s’il y en a (et ça permet surtout de s’en rendre compte plus tôt). Car même si l’objectif des stand up meetings c’est la “conversation décomplexée” comme tu le dis si bien, il ne faut pas oublier le facteur humain qui peut amener certaines personnes à éviter certains sujets ou de se mettre en mode “carapace”.
Une expérience humaine que la gestion de projet vous dis-je !
Bonjour,
Super sujet et intéressant car je me suis souvent demandé comment les jeux étais codé par rapport a des applications web plus conventionnel.
Parce qu’ils ont toujours des deadlines et des impératifs de qualité importante, en plus des performances dans les jeux.
Est ce que vous pourriez me conseiller quelques infos, sur les méthodes de développement lié au jeux ?
Je voudrais savoir comment ils font pour toujours tenir les délais.
Comment ils travaillent en équipe
Bonjour Sylvain, je vais tenter de répondre à ta question en piochant dans ce qu’on nous a appris en cours et ce que quelques développeurs ont pu me dire sur l’industrie (sans pour autant prétendre que ce que je vais dire tienne de la vérité “absolue”, car à mon stade d’apprentissage, je suis loin de connaître toutes les ficelles du métier).
Ce qu’il faut savoir, c’est que tout projet repose sur 3 éléments essentiels : la qualité, le coût et le délai (que l’on pourrait représenter par un triangle que tu peux consulter ici). Alors même si la qualité demeure le critère de première importance dans tout projet de jeu vidéo, parfois il est difficile de se tenir à cet objectif afin de pouvoir tenir les délais imposé par l’éditeur. C’est pour cela qu’il y a beaucoup de jeux vidéo qui perdent en qualité malheureusement afin de “toujours tenir les délais”. Sinon les éditeurs finissent par ne plus leur faire confiance, et ne leur confient plus de projet et c’est la catastrophe (parce qu’à la fin y’a plus d’argent dans la caisse pour manger à la fin du mois).
Pour ce qui est des méthodes de développement liées aux jeux vidéo, il y en a plusieurs. Comme citées dans l’article il y a Scrum, l’ Extreme Programming mais également le Rapid Development (connu sous l’acronyme RAD).
Ensuite, tout dépend de la structure du studio (studio externe ou studio interne à un éditeur, studio divisé par pôles de compétences ou par équipes de projet…) et de sa taille. Un petit studio externe de 3 personnes qui travaille sur un projet indépendant (je pense notamment à Swing Swing Submarine) ne va pas fonctionner de la même façon qu’un gros studio interne (comme chez Ubisoft par exemple).
Merci, si tu as d’autres info sur le développement de jeux appliqué a scrum cela m’intéresse.
Quelques informations par rapport a ton article.
Il y a pleins de chose à dire. Je vais essayer de rester clair.
Deux points qui me semble important, tu as raison de dire que scrum doit etre
adapté a l’entreprise. Si cela deviens rigide, ce n’est plus scrum.
Deuxième point, “On utilise tous Scrum au quotidien sans le savoir”.
C’est exact, scrum n’a rien inventé et n’est que du bon sens.
Ceci est mon avis, le backlog n’est pas une liste de tache.
Je l’appellerais pour rester dans l’esprit de cet article, un thème ou une descriptions en gros pour plusieurs taches.
Prenons l’exemple, du sprint 1,
Thème/Description Globale : Coder un personnage qui se déplace
Tache 1: déplacement a gauche
Tache 2: déplacement a droite
Thème/Description Globale :Créer une plateforme fixe
Tache 1: faire une plateforme de x dimension
Tache 2: ajouter des couleurs
Etc…
Pour le codage des couleurs, cela ne me semble pas intéressant.
Puisqu’on a déjà les post-it. c’est soit en cours, fait. ou bloqué.
Tu dit que tu vas voir chaque personnes séparément. Je trouve cela dommage, car si les gens étais en réunion, ils serait au courant immédiatement du problème que rencontre les autres développeurs. Plutôt que d’aller consulter après coups un fichier.
Scrum, c’est la communication et transparence.
Le burndown charts est utilisé pour estimé le RAF, utile quand on a des clients devant nous qui veulent avoir une estimation pour savoir quand on pense avoir terminé.
Le but final du sprint, est de permettre au développeur de montrer ce qu’il a fait. et de valider que les fonctionnalités sont faite.
C’est aussi l’occasion des sprint reviews qui permette de capitaliser sur les problèmes rencontres.
Maintenant, c’est juste mon expérience. Elle peut ne pas s’appliquer sur d’autre projets. Et scrum n’est pas rigide bien au contraire
Alors oui je suis d’accord sur le fait qu’il faut favoriser la communication en groupe pour présenter les choses. C’est pour ça qu’on fait une réunion hebdomadaire afin de se retrouver tous ensemble. Mais au cours de la semaine, les personnes de l’équipe travaillent en tandem et communiquent les informations importantes entre eux. Etant donné qu’ils se situent dans un même box et que je suis à l’écart (à cause de la disposition des boxes dans notre école car on a voulu privilégier un maximum d’espace pour les programmeurs et les graphistes), c’est la raison pour laquelle je vais voir chaque personne ou binôme de façon quotidienne afin de me tenir au courant.
Ca me permet également de vérifier où en est le backlog puisqu’on vient de mettre un place un tableau de façon physique dans le boxe du projet afin que chacun y appose ses tâches sur des post-it. Pourquoi ai-je changé de fusil d’épaule ? Parce que je me suis rendue compte, certes un peu tard “but still”, que la todolist en ligne était un poil trop rigide et qu’un backlog physique permet à l’équipe de mieux spatialiser qui travaille sur quoi et où en sont les tâches d’un simple coup d’oeil (au lieu de cliquer d’onglet en onglet dans notre document en ligne).
Je ne sais plus si je l’avais précisé dans l’article, mais on fait également des sprints mais que l’on appelle des “points projets” car nous avons tous un peu de mal avec le langage scrum (brrr).
En tout cas, merci pour tes précisions, ça permet de clarifier certains aspects de scrum.
Encore une chose
Chez nous les post it indique aussi deux chiffres en bas.
Ils indiquent la complexité et la priorité (ces deux chiffres sont obtenu avec une séance de scrum poker)
Et au dos, on y mets le test d’acceptance.
Bonne idée pour mettre la priorité sur les post-it, j’en ai parlé à mon équipe, ils m’ont même proposé d’essayer d’évaluer les temps impartis par tâche (pour que ça les aide à mieux les évaluer pour nos projets de Master 2 l’an prochain).
Quand tu dis “nous”, tu parles de quel studio ?
On ne développe pas pour un studio de jeux, mais pour l’industrie auto.
Je suis fasciné par ce qui se fait ailleurs.
Pour le temps impartis par tache, nous faisons les estimations au cours de seances de scrum poker et nous discutons des estimations. Si l’estimation est elevé, c’est que la tache est surement trop grosse ou mal définit(EPIC) . Tres fascinant en tout cas cette méthodologie.