Les logiciels ont beaucoup évolué au cours des deux dernières décennies. (Cela va sans dire, n’est-ce pas ?) Et, plus important encore, ils ne cessent de changer. Naturellement, le processus de développement logiciel en fait de même. 

Cela dit, il n’est pas viable d’inventer constamment de nouveaux processus de développement logiciel. Ne serait-il pas préférable de créer un processus qui soit suffisamment souple pour s’adapter aux évolutions et aux changements dans le domaine du développement logiciel ? C’est pour cela que les méthodes agiles ont été conçues. 

Le développement logiciel agile est une approche itérative et adaptable du développement logiciel. Dans cet article, nous allons analyser l’un de ses cadres les plus populaires : la méthode Scrum. 

Méthode Scrum : définition ?

La méthode Scrum (également appelée cadre Scrum) est un cadre agile pour le développement logiciel.

Qu’est-ce que cela signifie exactement ?

Les processus traditionnels de développement logiciel fonctionnent de manière linéaire : d’abord la planification, puis le développement, puis les tests, et ainsi de suite. Le développement logiciel agile, quant à lui, adopte une approche itérative. Les projets sont divisés en courtes périodes de temps appelées sprints (qui durent généralement entre deux semaines et un mois). 

À chaque sprint, l’équipe de développement ajoute et améliore des fonctionnalités afin de livrer progressivement le meilleur produit possible. Les phases de test et de développement sont fréquentes et se chevauchent souvent. (Vous souhaitez en savoir plus sur le développement agile ? Nous avons rédigé un article pour tout vous expliquer !)

Il existe un certain nombre de cadres de travail qui relèvent de l’approche agile, dont la méthode Scrum.

Cette dernière se caractérise par l’importance qu’elle accorde au travail d’équipe et à la collaboration. De fait, le nom Scrum vient des mêlées de rugby, une partie du jeu qui nécessite un effort d’équipe coordonné. Au cours de chaque sprint, les équipes Scrum se réunissent quotidiennement pour suivre leur progression, identifier et traiter les obstacles et maintenir le projet sur la bonne voie. (Nous reviendrons plus tard sur les différents types de réunions Scrum).

Principes de Scrum fondamentaux

Le cadre Scrum s’articule autour de six principes essentiels. Chaque aspect de cette méthode, des réunions de sprint quotidiennes aux artefacts Scrum, reflète ces principes. Explorons-les en détail. Les six principaux principes Scrum sont les suivants :

1. Contrôler les processus empiriques : en mettant l’accent sur la transparence, l’adaptation et l’évaluation fréquente, la méthode Scrum aide les équipes de développement à tester et à améliorer leur produit à chaque étape du processus.

2. Auto-organisation : pour utiliser efficacement le cadre Scrum, chaque membre de l’équipe doit adhérer pleinement au processus. Cela exige un haut niveau d’indépendance et d’auto-organisation.

3. Collaboration : pour livrer le meilleur produit possible, une équipe de développement logiciel doit travailler ensemble. Les équipes partagent les responsabilités et les devoirs tout au long de chaque cycle. Leur cohésion est indispensable à leur réussite. 

4. Priorisation basée sur la valeur : l’une des caractéristiques principales de Scrum est sa flexibilité. Pour s’adapter et répondre aux nouvelles demandes et exigences du projet, les équipes Scrum évaluent et redéfinissent constamment la priorité de chaque tâche à accomplir.

5. Time-boxing : dans la méthode Scrum, chaque élément d’un sprint possède une frise chronologique clairement définie. Le sprint lui-même dure deux semaines, mais les réunions quotidiennes se déroulent également dans des délais strictement fixés.

6. Développement itératif : compte tenu de la nature agile de Scrum, les produits sont créés de manière itérative. Cela favorise l’amélioration continue, la flexibilité et, en fin de compte, la qualité du produit livré. 

Qu’est-ce qu’une équipe Scrum ?

Nous venons de parler de l’équipe Scrum, examinons maintenant de quoi il en retourne. À un certain niveau, le concept est explicite : une équipe agile Scrum est simplement une équipe de développement logiciel utilisant le cadre Scrum. Mais cela ne s’arrête pas là. 

Pour garantir le bon déroulement de chaque sprint, cette méthode définit trois fonctions (souvent appelées rôles Scrum) que chaque équipe Scrum est censée comporter : le Product Owner, l’équipe de développement et le Scrum Master. Continuez votre lecture pour découvrir les rôles et les responsabilités de chacun. 

Chef de produit (product owner)

Pour livrer le meilleur produit possible, une équipe de développement doit avoir une compréhension approfondie des besoins et des attentes du client. Cela nécessite une ligne de communication ouverte entre les deux parties. Comment y parvenir ? C’est le rôle du Product Owner. 

Le Product Owner doit connaître le produit de fond en comble et partager ces informations. Il est le premier point de contact entre le client et l’équipe de développement. Il traite les exigences du client et les traduit en éléments d’action, notamment en créant et en tenant à jour le backlog produit. 

Chaque équipe Scrum dispose d’un Product Owner (il ne doit jamais s’agir d’un rôle partagé). 

Équipe de développement

Celui-ci est assez simple : les équipes de développement sont les collaborateurs qui développent concrètement le produit. Les équipes de développement Scrum doivent être petites et disposer d’un large éventail de compétences en comprenant à la fois des designers et des programmeurs. 

Vous vous souvenez des principes fondamentaux de Scrum ? C’est ici que la collaboration est importante. Les membres d’une équipe de développement Scrum doivent se transmettre mutuellement leurs compétences afin d’éviter les goulots d’étranglement. L’équipe de développement Scrum étant chargée de rédiger le code à proprement parler, elle est responsable de l’estimation et de l’affectation du temps et des ressources nécessaires pour chaque élément du backlog. 

Scrum Master

Si vous ne l’avez pas encore compris, disons-le clairement : le cadre Scrum prévoit de nombreuses réunions. Et quelqu’un doit planifier, coordonner et modérer ces rencontres. C’est là que le Scrum Master entre en jeu. 

Le domaine du Scrum Master englobe tout ce qui concerne Scrum. Comment l’équipe met-elle en œuvre la méthode Scrum ? Existe-t-il des domaines qui nécessitent une mise au point ou une amélioration ? Comment l’équipe peut-elle s’améliorer à chaque sprint ?

En outre, ils sont chargés de veiller à la planification et au bon déroulement des réunions Scrum. 

Artefacts Scrum :

Nous avons abordé une grande partie du jargon Scrum, mais nous n’avons pas encore tout vu. Dans Scrum, un artefact désigne simplement un mécanisme, ou un outil, de gestion et d’achèvement du travail. Il existe quatre artefacts Scrum principaux :

Backlog produit

Le backlog produit, géré par le Product Owner, est une liste d’exigences pour le produit final. Au fur et à mesure que les priorités évoluent, le Product Owner remanie et réorganise le backlog. Au début de chaque sprint, les équipes Scrum sélectionnent un certain nombre de tâches dans le backlog produit à traiter pendant ce cycle. 

Carnet de sprint (sprint backlog)

À chaque sprint, les tâches sélectionnées dans le backlog produit sont placées dans le backlog du sprint. Celui-ci est géré et exploité exclusivement par l’équipe de développement. Souvent, ces tâches sont organisées sur un tableau Scrum, un cadre visuel permettant de suivre la progression et la priorité de chaque tâche. Ces dernières sont classées en colonnes sur le tableau : stories, à faire, en cours et terminées. Au fur et à mesure que les tâches sont accomplies, l’équipe de développement les déplace d’une colonne à l’autre. 

Récit utilisateur

Les user stories sont un moyen de décrire les éléments du backlog. Le backlog produit est fondamentalement une liste de fonctionnalités qui doivent être incluses dans le produit final. Les user stories décrivent ces dernières du point de vue de l’utilisateur : pourquoi a-t-il besoin de cette fonctionnalité et comment se présentera-t-elle en pratique ?

Incrément de produit

À la fin de chaque sprint, vous vous retrouvez (avec un peu de chance !) avec une montagne de tâches achevées qui, ensemble, constituent l’incrément de produit. En d’autres termes, l’incrément de produit est simplement la version provisoire du produit à la fin d’un sprint. 

Événements Scrum :

Nous avons évoqué les réunions Scrum (et leur nombre) à plusieurs reprises sans aucune explication, mais la voici ! Le cadre Scrum repose sur un certain nombre d’« événements ». Voici quelques-uns des événements Scrum les plus courants et les plus importants :

Sprint

Le sprint est la pierre angulaire du développement logiciel agile, c’est la base du processus Scrum. Les sprints, qui durent généralement entre deux et quatre semaines, sont l’élément central de cette approche. Le travail est planifié en sprints, les réunions sont programmées autour des sprints, etc.

Sprint planning 

Si vous partez en voiture vers une direction inconnue, vous ne commencez pas directement par prendre le volant. (Ou peut-être que vous le faites, mais le résultat n’est pas nécessairement très efficace.) Il est préférable de consulter une carte et de déterminer le meilleur itinéraire pour atteindre votre destination. 

De la même manière, les équipes Scrum ne se contentent pas de sélectionner quelques tâches du backlog et de se lancer pêle-mêle dans un sprint. Elles passent beaucoup de temps à planifier. Une réunion de sprint planning, tenue au début d’un sprint, doit durer plusieurs heures : prévoyez deux heures pour chaque semaine de sprint. Pendant cette réunion, vous et votre équipe devez répondre à quelques questions : qu’allons-nous réaliser au cours de ce sprint ? Et comment allons-nous y parvenir ? Soyez aussi précis que possible. 

Réunion quotidienne

Les réunions quotidiennes, également appelées daily scrums ou stand-up meetings, sont des réunions courtes (idéalement quinze minutes) qui se tiennent à la même heure chaque matin. Au cours de ces réunions, l’équipe de développement discute de ce qu’elle a accompli la veille et de ce qu’elle compte accomplir dans la journée. 

Sprint review

La méthode Scrum incite à la transparence entre toutes les parties prenantes. Les réunions de sprint review y contribuent. Organisées à la fin de chaque sprint, ces rencontres permettent à l’équipe Scrum de présenter l’itération actuelle du produit aux autres parties prenantes. En fonction des commentaires recueillis lors de cette réunion, le Product Owner affine le backlog produit. 

Rétrospectives de sprint

Les réunions de sprint review sont suivies par un certain nombre de parties prenantes, mais les rétrospectives de sprint sont réservées à l’équipe Scrum. Ces rencontres ont lieu à la fin de chaque sprint et donnent aux membres de l’équipe l’occasion de revenir sur le sprint précédent. 

Pendant les rétrospectives de sprint, posez une série de questions à votre équipe Scrum : qu’est-ce qui s’est bien passé ? Qu’est-ce qui a mal tourné ? Et, plus important encore, comment pouvons-nous améliorer le prochain sprint ?

Les avantages de Scrum

Avec un peu de chance, vous avez acquis les principes de base de Scrum. Et maintenant ? Vous devez décider si la méthode Scrum pourrait être utile à votre équipe. 

Les avantages de la méthode agile Scrum résident en grande partie dans son approche itérative. En utilisant le cadre Scrum, votre équipe sera en mesure de s’adapter au monde en constante évolution du développement logiciel et de livrer un produit qui s’améliore à chaque sprint.