Tout savoir sur Scrum

A travers de cet article, j’aimerais partager avec vous quelques points essentiels concernant l’introduction et la pratique de la méthode Scrum dans une entreprise. Cet article est en quelques sorte un aide-mémoire des bonnes pratiques dont certaines acquises avec le temps et d’autres tirées depuis d’autres articles, des magazines et de livres traitants de Scrum.

Tout d’abord un court rappel de la définition de Scrum:

Scrum est une méthodologie «agile» de développement reposant sur des itérations incrémentales et de durées courtes, appelées «Sprint».

Avant toute chose

Voici quelques points importants à garder en mémoire avant de se lancer avec Scrum :

  • Si vous êtes au courant qu’il y aura de nombreux changements pendant votre projet, assurez-vous que votre gestion de projet permet de les gérer.
  • Les commentaires et remarques sont essentiels pour développer un bon produit. Plus vous obtenez ces remarques tôt, plus il est facile de les intégrer dans le développement afin que votre produit final soit optimal.
  • Scrum vous permet de vous adapter à ce qui doit être fait dans les futures itérations, mais ne vous autorise pas à modifier le cours de l’itération déjà commencée. L’équipe de développement s’engage, en revanche,  à livrer le travail du dernier sprint.
  • Essayez de faire le plus souvent possible les tâches que vous ne faites pas bien, ou tout ce qui vous pose problème. Ainsi, vous arriveriez à progresser.
  • L’atout majeur des cycles de développement de durée fixe et courts est qu’ils vous autorisent à estimer la quantité de travail que vous êtes capable de fournir en un cycle. Ce qui vous permet ainsi de confronter vos estimations à la réalité, et affiner la précision de vos projections.
  • Ne détaillez que les fonctionnalités dont votre client a besoin rapidement. Car avec Scrum, ce sont ces fonctionnalités que vous allez livrer en premier. Choisissez les plus essentielles au début de chaque sprint. Et ne faites que ce qui apporte le plus de valeur ajoutée.
  • Scrum oblige le client de s’assurer que toute l’équipe de développement comprenne correctement ce dont il a besoin. Cela implique donc un contact régulier. Cependant, si le client ne souhaite pas s’investir à ce point, alors le projet suffisamment important à ses yeux. Dans ce cas, vous devriez considérer d’annuler le développement sans plus tarder!
  • A chaque sprint, le product-owner à la responsabilité de prioriser les tâches que l’équipe devra réaliser à chaque sprint. Et cette priorisation se fait en collaboration avec toutes les parties concernées. Il construit une liste d’exigences qui s’appelle le product backlog . Le product backlog est la liste de tout ce que le logiciel doit être en mesure de faire. Cette liste est ordonnée selon la valeur de ses éléments.

L’utilité de Scrum

  • Avec Scrum, l’équipe de développement est intégralement responsable des résultats qu’elle produit; en conséquence, elle se gère elle-même. Ses membres décident de leur façon de travailler et de leurs outils. Ce que produit l’équipe est déterminé par le product-owner, mais la manière dont cela est produit est décidé par l’équipe.
  • Le Scrum master est chargé de s’assurer que le processus Scrum est proprement exécuté, et que le rythme est maintenu.
  • Le Scrum master n’est pas le chef. Il est simplement responsable de l’efficience et de l’efficacité du processus.
  • Le chef de projet traditionnel, qui organise dans le détail le travail de l’équipe, n’est plus nécessaire. L’équipe gère son travail de façon autonome.
  • L’équipe, sur la base des priorités fixées par le product-owner, construit elle-même le planning de chaque sprint. Elle répartit le travail et contrôle son avancement de façon compréhensible et transparente.
  • Scrum est un processus de gestion de projet rigoureux et détaillé. L’organisation du travail y est très disciplinée. L’autogestion de l’équipe est institutionnalisée dans la méthode elle-même.
  • Le rôle de chef de projet reste valable dans le cadre de projets externalisés. Ce rôle est cependant différent de celui d’un chef de projet traditionnel. Il se focalise sur l’environnement externe du projet et coordonne les relations avec le reste du monde: budget, reporting, relation client, groupes de travail, contrats, etc. Du point de vue de l’équipe, ce chef de projet est très différent du rôle habituel; il possède néanmoins une véritable valeur ajoutée.

Le processus Scrum

  • Scrum s’appuie sur des cycles de développement courts, de durée fixe. Ces cycles sont appelés sprints. Un sprint a une durée fixe de 2 à 4 semaines.
  • Avec Scrum, le logiciel est toujours prêt. A n’importe quel moment, il est possible de livrer le produit. La version livrable est au pire vielle de la durée d’un sprint.
  • Les équipes Scrum sont de préférence petites. La règle est de limiter le nombre de personnes à 7, plus au moins 2 personnes. Aussi, afin de favoriser la communication interne, l’équipe peut être installée dans la même pièce.
  • Un sprint démarre avec une présentation de ce qui doit être réalisé durant le sprint. Cette liste porte le nom de sprint backlog. L’équipe peut poser autant de questions qu’elle le souhaite, jusqu’à comprendre parfaitement ce que l’on attend d’elle.
  • Durant la réunion de planification de sprint (sprint planning), tous les éléments du sprint backlog sont divisés en tâches distinctes. Ces tâches sont appelées des unités de travail, et doivent chacune aboutir à un résultat tangible. Une unité de travail ne devrait pas plus de 2 à 4 heures d’effort, et ne jamais dépasser 2 jours de charge.
  • S’il n’est pas possible de diviser une tâche importante en tâches plus petites, cela signifie que ce qui doit être fait n’est pas suffisamment clair. De telles tâches sont des causes de retard, et ne devraient pas être planifiées. Il faut au préalable identifier ce qui manque, et le traiter dans un sprint ultérieur.
  • C’est l’équipe qui se charge de subdiviser le travail et de construire un planning réaliste. L’équipe doit ensuite s’engager à respecter ce plan.
  • Le stand-up meeting a un objectif très clair: s’assurer que la journée qui débute sera la plus productive possible pour l’équipe.
  • Les obstacles sont des barrages qui empêchent l’équipe de terminer le sprint conformément au planning et qui doivent, en conséquence, être éliminés avant le stand-up suivant. C’est au Scrum master de s’en assurer.
  • Le Scrum master doit s’assurer également qu’une réunion de coordination quotidienne a lieu. Cette réunion porte le nom de stand-up meeting. Elle doit se tenir chaque jour à heure fixe, et dure au maximum 15 minutes. Durant le stand-up, chaque membre de l’équipe doit répondre à trois questions: Qu’as-tu réalisé depuis hier? Que vas-tu réaliser aujourd’hui? Quels problèmes rencontres-tu ?

Le Manifeste Agile

Dans le monde Agile, il existe une sorte de loi, une table de loi se nommant le Manifeste Agile. Voici ce qu’elle stipule:

  • Les individus et leurs interactions sont plus importants que le processus et les outils.
  • Un logiciel opérationnel est plus important qu’une documentation exhaustive.
  • La collaboration avec le client est plus importante que la négociation contractuelle.
  • Être réactif au changement est plus important que de suivre un plan.

L’adoption de Scrum

  • Introduire Scrum dans une organisation ne demande pas une longue phase de préparation. Il s’agit avant tout d’accepter la philosophie sous-jacente. Une fois acquis le bon état d’esprit, vous pouvez démarrer immédiatement.
  • Acceptez que le périmètre fonctionnel ne soit pas intégralement figé au démarrage de votre projet. Cette flexibilité nécessite cependant un feedback régulier. Une fois que vous avez pris cette décision, vous pourrez sans problème piloter strictement la qualité, les coûts et les détails.
  • Avec Scrum, vous pouvez fixer des objectifs généraux à vos projets, adossés à un budget et à des délais très stricts. Le périmètre exact n’a pas besoin d’être défini en détail dès le départ. Il peut ne l’être que pour le prochain sprint.
  • Scrum n’est pas une simple adaptation de votre processus, mais également une nouvelle façon de piloter vos développements. Il s’agit d’un changement de paradigme. En tant que tel, il suppose un changement culturel dans les équipes de développement, puisque ces derniers se voient confier des grandes responsabilités, ainsi qu’un contrôle absolu sur leur façon de travailler.
  • La dynamique d’équipe est un facteur essentiel de succès dans la mise en place de Scrum. Fixez des objectifs explicites, et rendez-les transparents. Donnez de l’importance à l’équipe. Vous constaterez qu’elle agira en conséquence.
  • Scrum aide à se focaliser sur la qualité. Le logiciel est prêt beaucoup plus vite, et il est donc possible de le tester, et d’en vérifier la qualité, beaucoup plus tôt, et beaucoup plus souvent. En fait, les tests sont réalisés à chaque sprint.
  • Avec Scrum, vous pilotez un projet d’après ce qui sort des cycles de développements, ses extrants, à destination des clients et utilisateurs; et vous pilotez les préconditions du développement, ses intrants. Ainsi, vous pouvez exploiter à plein le talent de vos ingénieurs, leur donner plus de plaisir et de confiance en eux.
  • Il est préférable de ne pas confier à un chef de projet traditionnel le rôle de Scrum master. Si un ancien chef de projet devient Scrum master, la plupart des développeurs attendront de lui qu’il résolve leurs problèmes. Ils le renverront, pour parler ainsi, dans son ancien rôle, celui dans lequel il était chargé de toute la responsabilité.

Le premier Sprint

  • Vous pouvez apprendre à utiliser et apprécier Scrum en l’appliquant dans un premier temps à la lettre. De cette façon, vous découvrirez automatiquement ce qui fonctionne, et comment cela fonctionne dans votre situation singulière.
  • Une erreur fréquente, dans beaucoup d’organisations, consiste à adopter Scrum avant même d’avoir commencé à l’utiliser. Elles ignorent alors les concepts qu’elles ont écartés inconsciemment. Le problème est qu’elles n’ont pas conscience de ce qu’elles abandonnement, et sont de ce fait incapables d’en mesurer l’impact réel.
  • La vélocité désigne la quantité de travail qu’une équipe est en mesure de réaliser durant un sprint. A chaque sprint, cette vélocité est mesurée. Grâce à la vélocité, une équipe est en mesure de déterminer à l’avance la quantité de travail qu’elle peut s’engager à terminer au cours d’un sprint.
  • Le planning Poker est la technique d’estimation de Scrum. Il s’appuie sur un consensus de groupe. Chaque membre de l’équipe estime individuellement la charge de travail que nécessite un développement; cette estimation est ensuite confrontée à celle des tous les autres. Les raisons des écarts sont alors discutées, et un nouveau vote (secret) est organisé jusqu’à obtention d’un consensus.
  • Les écarts d’estimation lors du planning poker sont les bienvenues. Ils permettent d’approfondir la discussion, et de garantir que toute l’équipe comprend parfaitement ce qui doit être fait. À ce titre, les discussions sont plus importantes que les estimations à proprement parler.
  • Estimer sur la base d’une unité abstraite, telle que les points de complexité, plutôt qu’en temps idéal présente l’avantage de supprimer les erreurs structurelles d’estimation. En effet, vous pourrez déterminer avec le temps le nombre de points que vous pouvez prendre dans un sprint, indépendamment de la charge réelle des unités de travail que cela représente. Les jours idéaux s’apparentent davantage à l’estimation de charge classique, en jours-homme. Ils sont sources d’erreurs et de confusion.
  • L’essence de la planification n’est pas de prédire l’avenir, mais de devenir prédictible.  Comparer les estimations avec le travail réalisé permet d’apprendre, et de progresser. Une équipe devient plus prédictible si elle utilise cette connaissance pour ses futures estimations.
  • Le suivi des unités de travail est réalisé au travers d’un tableau de bord Scrum. Ce tableau de bord possède trois colonnes : une colonne À faire, une colonne En cours et une colonne Terminé. Une fois que toutes les unités de travail ont été drainées vers la colonne Terminé, le sprint est achevé avec succès.
  • Le tableau de bord Scrum fournit à l’équipe un indicateur visuel du statut et de l’avancement du sprint. Il leur indique également ce qui doit être fait ensuite. Les unités de travail y sont listées par ordre de priorité et de dépendance. L’unité de travail située en faut est la plus importante, et doit être traitée en premier.

Le déroulement d’un Sprint

  • Le tableau de bord Scrum (Scrum board) liste toutes les unités de travail par ordre de priorité. L’équipe les draine du haut à droite vers le bas à gauche, comme le ferait un chasse-neige.
  • Le tableau de bord de Scrum est un endroit important, autour duquel se rassemble l’équipe. À l’instar du planning poker, les discussions qui y ont lieu sont plus important que son contenu formel. Ces discussions permettent la coordination à l’intérieur de l’équipe, et le tableau de bord en fournit le support et le déclencheur.
  • Le burn down chart permet de visualiser la vitesse à laquelle l’équipe consomme ses heures de travail en regard du résultat qu’elle s’est engagée à produire. D’un seul coup d’oeil chacun peut contrôler la bonne progression du sprint.
  • Pour déterminer si quelque chose est véritablement terminé, et s’il se conforme à un ensemble de critère de qualités prédéterminées, Scrum utilise un outil: la définition de DONE. La définition de DONE est une liste de critères utilisée afin de contrôler que rien n’a été oublié et que le travail est authentiquement fini.
  • La définition de DONE est également utilisée lors de la réunion de planification de sprint afin de vérifier que l’équipe n’a oublié aucune des unités de travail nécessaires pour finaliser une fonctionnalité ou un développement.
  • Le product-owner détermine uniquement ce qui doit être produit, et non comment cela doit être produit. Les modalités de mise en oeuvre sont sous la responsabilité exclusive de l’équipe.
  • En concentrant les membres de l’équipe sur les tâches à court terme, dont le résultat est mesurable le jour même, Scrum développe leur sens du temps. Cette emphase sur la complétion de tâches discrètes donne à tous un focus clair sur l’objectif réel: obtenir des résultats rapidement.

Les Sprints suivants

  • Le product-owner joue un rôle essentiel dans Scrum. Une fois que l’équipe a mis au point son processus de développement, le résultat reste entièrement tributaire de la qualité des intrants. Le product-owner joue ainsi un rôle majeur dans la qualité des résultats.
  • Le rôle du product-owner est crucial, et en même temps, c’est celui le plus difficile et le moins bien compris dans Scrum. Si le product-owner n’a pas un pouvoir de décision suffisant, ou des lacunes dans sa compréhension du produit, alors la mise en place de Scrum échouera.
  • Il peut se passer du temps avant que chacun dans l’organisation comprenne les tenants et les aboutissements de son nouveau rôle, et en acquière l’état d’esprit. Être bien accompagné et laisser du temps pour l’apprentissage est essentiel pour accélérer le processus.
  • Le product-owner doit s’assurer que le backlog ne décrit pas une solution, mais qu’il liste des demandes d’ajout de valeur. Avec Scrum, cela est réalisé à l’aide d’histoire utilisateur. Une historie utilisateur décrit un scénario d’usage du logiciel, et son contexte. Elle décrit ce que l’on peut faire, qui cela intéresse, et ce qu’il en tire comme bénéfice – le pourquoi. Le comment est sous la responsabilité des ingénieurs, et le product-owner ne doit pas intervenir.
  • Sur la base d’un ensemble d’histoire utilisateur, les membres de l’équipe s’enquièrent des détails auprès du product-owner. Product-owner et équipe tirent chacun des enseignements de cette discussion. La discussion, une fois encore, est plus importante que l’histoire utilisateur à proprement parler.
  • Un product backlog montre une vision pour le futur. Il fournit une destination, un horizon. Il contient toutes les idées, stratégiques ou non. Mais tous ses éléments sont priorisés en fonction de la valeur ajoutée qu’ils apportent, et plus ils sont éloignés dans le temps, plus leur description doit rester abstraite.
  • Un product backlog n’est guère détaillé trop loin dans le temps. Une description détaillée des éléments est largement suffisante. Après tout, sur la base des résultats d’un sprint, du feedback sera obtenu. Des ajustements hautement prioritaires sont susceptibles de se produire. Détailler les choses trop longtemps à l’avance est donc inutile: elles seront traitées en temps voulu, et peut-être même jamais.
  • Vous ne devez jamais prendre en considération des choses qui seront nécessaires uniquement dans le futur. Si vous le faites, alors vous inversez de fait les priorités. L’objectif de la priorisation est précisément de se focaliser sur les choses les plus importantes maintenant. Les autres disparaîtront peut-être.

Le fin d’un Sprint

  • La réunion de fin de sprint, ou revue de sprint, est l’occasion de faire la démonstration du logiciel dans son état courant, en conformité avec la définition de DONE. Il ne s’agit pas d’une présentation PowerPoint, ni d’un simple prototype de l’IHM. La démo doit faire la preuve de l’avancement des développements, sur la base d’un logiciel parfaitement opérationnel.
  • À la fin de la démo, le product-owner reprend la responsabilité du produit en déchargeant l’équipe, afin de lui permettre de prendre de nouveaux engagements. Cela insuffle rythme et rigueur à l’équipe.
  • Un aspect essentiel de Scrum est que l’équipe est responsable de sa façon de travailler, et que cette façon de travailler doit continuellement s’améliorer. La réunion la plus importante de Scrum, qui permet de travailler sur cette amélioration continue, porte le nom de rétrospective.
  • Durant la rétrospective, qui a lieu au terme de chaque sprint, après la revue de sprint, l’équipe analyse ses performances sur le dernier sprint. Elle recherche à identifier ce qui a bien marché pour pouvoir le reproduire et même l’améliorer. Elle évoque également ce qui s’est mal passé, et décide d’actions pour ne plus répéter les mêmes erreurs.
  • Une rétrospective doit amener des actions. Son unique résultat est une liste de mesures à prendre pour améliorer structurellement le processus. Le sprint suivant devrait toujours être meilleur, plus rapide et plus amusant que le précédent. Avec cet objectif en tête, l’équipe cherchera toujours à se surpasser encore et encore. Il ne s’agit pas de travailler plus, mais de travailler mieux: créer davantage de valeur, en y consacrant de moins en moins d’efforts.
  • La rétrospective est la réunion la plus importante de Scrum. C’est elle, après tout, qui active le levier le plus puissant de Scrum: l’amélioration continue. Mais c’est également la plus difficile à réussir, et de nombreuses organisations n’en tirent pas le bénéfice attendu.
  • Quand la rétrospective consiste simplement à définir des actions potentielles qui ne sont pas suivies d’effet, elle perd son sens. Si les actions d’amélioration décidées lors de la rétrospective ne sont pas déployées, alors Scrum échoue! Parce que sans elles, il n’y aura pas d’amélioration d’un sprint à l’autre, et que sans amélioration, Scrum ne survit pas.

Et pour finir …

  • Scrum met l’accent sur la création de valeur. ce qui porte la valeur ajoutée potentielle la plus importante doit être développé en premier, et livré au client le plus tôt possible sous forme opérationnelle. Dès que le produit est livré, il commence à actualiser sa valeur potentielle. Une fois que les choses les plus importantes sont terminées, il faut prioriser à nouveau la suite. Et cela continuellement.
  • Scrum autorise la qualité, la transparence et la prédictibilité. Scrum, en structurant le développement autour d’itérations courtes, et en mettant l’accent sur un pilotage par les délais très stricts, permet de livrer votre produit aussi souvent que vous le désirez. Au terme de chaque itération, un logiciel opérationnel est produit, chaque fois un peu plus complet que le précédent. Ce mécanisme est fondamental pour établir des relations durables avec vos clients: vous pouvez systématiquement, et de mieux en mieux, tenir vos promesses. Mieux: la qualité s’améliore, et peut être démontrée à chaque itération, encore et encore.
  • Scrum stimule le feedback. Au démarrage, vous savez moins de choses que plus tard dans le projet. Scrum fonctionne parce qu’une approche évolutionniste et expérimentale, adossée à des boucles de feedback très courtes, est la façon la plus appropriée de développer des logiciels. Croire que l’on peut avoir toutes les meilleures idées au départ, et qu’il suffira ensuite de les spécifier, de les développer puis de les tester, est soit naïf, soit prétentieux. Cette croyance doit être abandonnée: au départ, vous connaissez au mieux la direction générale, mais vous n’avez qu’une idée très floue du résultat final.
  • Scrum permet à chacun de prendre du plaisir à faire ce qu’il sait faire. Scrum procure une grande satisfaction aux développeurs, en combinant propriété collective, dynamique d’équipe et responsabilité, tout en conservant une grande simplicité du processus. Il stimule le talent des ingénieurs de la meilleure façon possible. Rigueur et discipline où c’est nécessaire, mais liberté et créativité partout ailleurs.
  • Scrum, c’est juste une question d’action. Vous pouvez commencer à adopter Scrum immédiatement. Vous pouvez réaliser une transition vers Scrum n’importe quand. C’est juste une question d’état d’esprit. Acceptez que seul le futur proche puisse être spécifié et planifié en détail. À partir de là, vous pouvez démarrer Scrum dès aujourd’hui. Tout ce qui vient plus tard peut être, et sera remis en question.

 

Voilà, j’espère vous avoir convaincu de l’utilité de Scrum et que cet article vous aidera à l’adopter et à l’adapter à vos besoins.

Laisser un commentaire

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

quinze − cinq =