Le Scrum: quand le monde du sport transmet ses méthodes et ses valeurs à l’univers de l’informatique

Modèle schématique des méthodes agiles

Les méthodes agiles sont des groupes de pratiques pouvant s’appliquer à divers types de projets, mais se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel). Les méthodes agiles ne sont pas apparues avec l’Agile manifesto en 2001, mais celui-ci détermine leur commun dénominateur et consacre le terme d’« agile » pour les référencer. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d’un contrat de développement.

Les méthodes agiles reposent sur une structure (cycle de développement) commune (itérative, incrémentale et adaptative), quatre valeurs communes déclinées en douze principes communs desquels découlent une base de pratiques, soit communes, soit complémentaires.

Parmi ces méthodes on trouve le SCRUM. Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s’articule en effet autour d’une équipe soudée, qui cherche à atteindre un but, comme c’est le cas en rugby pour avancer avec le ballon pendant une mêlée.

Du Scrum du rugby au Scrum du développement informatique, il n y qu’un pas!

La méthode Scrum a été conçue lors de projets de développement de logiciels. Elle peut aussi être utilisée par des équipes de maintenance. La méthode Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de son principal promoteur Jeff Sutherland.

Les trois piliers de Scrum

• La transparence: garantit que tous les indicateurs relatifs à l’état du développement sont visibles de tous ceux qui sont intéressés par le résultat du produit.
• L’inspection: est faite à des moments typiques du cérémonial (quotidiennement et à chaque sprint) et porte sur des indicateurs qui montrent la tendance
• L’adaptation: Si une dérive est constatée pendant l’inspection, le processus doit alors être adapté rapidement pour minimiser les futures déviations.

Les rôles

• Propriétaire du produit (Product Owner): est le représentant des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit développé.
• ScrumMaster est responsable de la méthode, ill doit s’assurer que celle-ci est comprise, et bien mise en application. Ce n’est pas un chef de projet, ni un intermédiaire de communication avec les client
• Développeurs: L’équipe de développeur ne comporte pas de rôles prédéfinis, elle est auto-organisée et pluridisciplinaire.

Les événements

• Le Sprint: est une période d’un mois au maximum, au bout de laquelle l’équipe délivre un incrément du produit, potentiellement livrable. Une fois la durée choisie, elle reste constante pendant toute la durée du développement. Un nouveau sprint démarre dès la fin du précédent. Chaque sprint possède un but et on lui associe une liste d’éléments du carnet du produit (fonctionnalités) à réaliser.

•  La mêlée: quotidienne ou réunion quotidienne (Daily Scrum), permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées. Cette réunion dure 15 minutes au maximum. Le Scrum Master s’assure que la réunion ait lieu à heure fixe. Le propriétaire du produit n’est pas présent.
• La réunion de planification (Sprint Planning Meeting) Tout le monde est présent à cette réunion, qui ne doit pas durer plus de 8 heures pour un sprint d’un mois. Pour un sprint plus court, la durée est réduite proportionnellement. La réunion de planification se passe en deux temps. Dans la première partie, l’équipe de développement cherche à prévoir ce qui sera développé durant le prochain sprint. A l’entrée de cette phase, l’équipe doit avoir à sa disposition le carnet du produit priorisé, l’incrément réalisé à la dernière itération, la capacité de production de l’équipe lors des dernières itérations, ainsi que la capacité de production prévue pour la prochaine itération. L’équipe et le propriétaire du produit cherchent alors à déterminer le but du sprint.
• La revue de Sprint: à la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au maximum 4 heures. L’objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. L’équipe commence par énoncer les items du carnet de produit qu’elle a réalisés. Elle effectue ensuite une démonstration du logiciel produit. C’est sur la base de cette démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint. Une fois le bilan du sprint réalisé, l’équipe et le propriétaire de produit proposent des aménagements sur carnet du produit et sur la planification provisoire de la release. Il est probable qu’à ce moment des items soient ajoutés, modifiés ou réestimés, en conséquence de ce qui a été découvert.
• La rétrospective du sprint est faite en interne à l’équipe (incluant le ScrumMaster). Elle dure 3 heures pour un sprint d’un mois, et réduit selon la durée du sprint. L’objectif est de comprendre ce qui n’a pas bien marché dans le sprint, les erreurs commises et de prendre des décisions pour s’améliorer. Il est tout à fait possible d’apporter des aménagements à la méthode Scrum dans le but de s’améliorer. Il faut être très vigilant à ne pas retomber dans les pratiques rigides des méthodes plus classiques.

Vue synthétique du processus Scrum

Risques de la méthodologie Scrum

Conséquences de l’absence de communication ou de mauvaise communication dans les projets

Dans Scrum, les risques, en particulier de dérives, sont multiples. Ils ne sont pas présents et dans la même proportion dans tout projet. Néanmoins, ces risques deviennent de plus en plus courants avec la montée de Scrum. Le risque majeur dans l’utilisation de Scrum est une application allant à l’encontre même des principes fondateurs de son fonctionnement. On peut en citer deux, mais il en existe bien d’autres :

• un Scrum Master directif: L’un des plus graves risques de Scrum est la violation du principe même de son fonctionnement qui met l’équipe de développement au cœur même du processus. Il n’est pas rare que le Scrum Master soit un chef de projet déguisé ou officiel et qu’il applique un contrôle trop strict sur les membres de son équipe. Dans ce contexte, on demande aux développeurs de s’impliquer comme s’ils étaient responsables du projet mais en réalité ils ne le sont pas, puisque le Scrum Master qui est le chef de projet a le dernier mot pour tout et peut effectuer des choix arbitraires. Ce qui peut apporter des frustrations côté développeur. En outre, dans ce type de configuration, le Scrum Master qui n’en est plus un, n’endosse plus les responsabilités du Scrum Master : être le protecteur de l’équipe, objectif, garde-fou, garant de la méthodologie appliquée, etc. Les bénéfices de l’agilité peuvent ainsi disparaître : défiance de l’équipe vis-à-vis du Scrum Master, conflit à l’intérieur même de l’équipe, non-dit, désengagement qui engendre baisse de la qualité et absence de bonnes pratiques.

• la communication constructive laisse la place aux reproches.La surexposition dans Scrum prend sa source dans les différentes réunions d’équipe telles que la quotidienne matinale, censée informer et apporter des solutions aux problèmes de la veille. Sur certains projets, ces réunions se transforment en blâme des membres n’ayant pas réussi à mener à bien leurs tâches de la veille. Les conséquences dans ce cas peuvent prendre la forme de discussions houleuses ou de conflits plus ou moins durables entre membres de l’équipe. On constate aussi parfois à l’inverse une manière différente d’appréhender la réunion quotidienne : non-dit ou propos vagues en ce qui concerne les problèmes rencontrés. Ainsi, les réunions peuvent se passer de façon plus courtoise mais un risque de ne plus chercher le support de l’équipe en cas de difficulté pourrait apparaître. Ce qui va à l’encontre même des principes de Scrum.

Conclusion

Le Scrum est un processus de développement de logiciels qui s’intéresse plutôt à l’organisation du projet qu’aux aspects techniques. Son cadre de travail est sa force, si bien que cette méthode pourrait être appliquée à d’autres domaines. Son approche incrémentale et basée sur les besoins priorisés du client lui confèrent une flexibilité extrême. Elle incarne bien par là l’état d’esprit de la mêlée de rugby : avancer tous ensemble vers un but commun, la réussite du projet.

Les pratiques de Scrum sont essentiellement orientées sur la maîtrise d’une livraison d’incréments (sprint) mais réfutent la possibilité de modifier les fonctionnalités en cours de réalisation (dans le backlog de sprint). Cette limite interdit la mise en œuvre d’une conception émergente comme celle d’XP ainsi que celle d’ itération, base de l’adaptabilité (possibilité d’affinement par modification permanente). Scrum, ne disposant pas de métrique de gestion du changement à ce niveau, nécessite donc une importante spécification préalable à la mise en production (backlog produit) et, du fait de cette prédictibilité imposée, ne peut pas être considéré comme réellement itératif, donc adaptatif.

Scrum est un processus intéressant comme premier pas vers les méthodes Agiles : il est facile à comprendre et à pratiquer. La seule difficulté relève plutôt de l’environnement organisationnel

Source principale.