La métaphore du scrum (traduit de l’anglais “mêlée” du rugby) apparaît pour la première fois en 1986 dans une publication de Hirotaka Takeuchi et Ikujiro Nonaka intitulée “The New New Product Development Game” qui s’appliquait d’abord au monde industriel. C’est aujourd’hui l’une des méthodologies les plus utilisées dans le développement web et d’applications mobiles. Mais qu’est-ce que la méthode SCRUM ? Comment est-elle appliquée dans une équipe de développement mobile chez Kreactive ? Nous vous donnons la réponse dans cet article. 

Qu’est-ce que la méthode SCRUM ?

SCRUM est un framework de la méthode Agile. C’est un cadre de travail qui permet de définir des règles, des rôles, des outils et des rituels au sein d’une équipe.

• Il apporte une solution d’organisation pour travailler dans un environnement qui est en constante évolution.
• Il permet d’augmenter le niveau de collaboration, communication, et transparence, ce que rendent plus difficiles les méthodes plus classiques de gestion de projet. En effet celles-ci se cristallisent autour de certains acteurs et certains moments du projet.
• Ce framework permet aussi de répondre à un besoin du côté des équipes de réalisation en leur permettant de s’exprimer et de plus les responsabiliser en augmentant leur niveau d’autonomie.
• Enfin, il permet de prioriser les développements dans le sens de la valeur délivrée aux utilisateurs

L’équipe Scrum

Le Product Owner

“Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement”

— Le Guide Scrum

Découvrir les besoins

Le propriétaire du backlog (ou Product Owner) doit s’assurer de collecter les besoins pour concevoir le produit auprès des différentes parties prenantes (utilisateurs, internes, dépendances etc) et d’en définir une vision. Pour cela plusieurs outils sont à sa disposition.

Un des outils les plus importants pour un Product Owner est la questiologie. C’est en questionnant les différentes parties prenantes qu’il va obtenir des informations qui vont lui permettre de construire le produit. Cela peut être fait lors d’ateliers de mise en situation, d’ateliers de définition du besoin, d’enquêtes, de veilles, etc.

Prioriser les besoins de développement

Une fois les besoins collectés, ceux-ci sont consignés dans un backlog produit. C’est ce que l’on appelle des items de backlog. Chaque item possède une estimation de l’effort de réalisation et doit apporter une valeur à l’application mobile. Cette valeur peut être basée sur l’expérience utilisateur ou la technique.

Le Product Owner va ensuite prioriser les items dans le backlog en fonction de la roadmap du produit. Cette priorisation repose sur la valeur apportée par chaque item du backlog produit.

Un travail de décomposition en sous-besoins en échangeant avec l’équipe de réalisation peut être nécessaire pour pouvoir évaluer toutes les tâches à effectuer.

En résumé

Le rôle du Product Owner est le suivant : il représente les utilisateurs et porte la vision du produit auprès de l’équipe de réalisation à travers le backlog produit. Il est en charge de maximiser la valeur apportée aux utilisateurs par la priorisation des items. Il est l’interlocuteur entre les parties prenantes (Business Owner) et l’équipe de réalisation. Le plus important pour lui est de posséder toutes les données nécessaires pour réaliser le projet en conformité avec les besoins du client.

Le Scrum Master

“Le Scrum Master est un servant-leader au service de l’équipe de réalisation, du client et de l’organisation générale de l’entreprise. Il est garant de l’application de la méthodologie Scrum.”

— Paul Dialinas, Scrum Master

Le garant de la bonne organisation des cérémonies Scrum

Il est garant de la bonne organisation des cérémonies agiles mais cela ne veut pas dire que c’est nécessairement lui qui les anime.

Il fournit à l’équipe des solutions afin de maximiser l’intelligence collective dans une démarche d’amélioration continue avec des cérémonies agiles correspondant aux besoins du projet. Le but n’est pas de respecter l’agilité by the book (comme dans le livre) mais plutôt de proposer les rituels adéquats pour l’équipe Scrum.

Un coach projet, pas un chef de projet

Le Scrum Master est au service de l’équipe Scrum dans une posture de facilitateur projet. Il oeuvre pour augmenter le niveau d’autonomie des équipes et s’assure que l’équipe dispose des bonnes informations et des bons éléments pour travailler dans les meilleures conditions à la constitution du produit commun.

Il est là pour faire monter en compétence sur l’agilité les équipes, le Product Owner et l’organisation.

“Délivrer de la valeur de façon performante et continue.”

— Romain Gobert, Directeur des Opérations

Telle est la devise de la méthodologie SCRUM. La performance doit respecter les individualités et le temps de travail de chacun et doit être capable de répondre à l’inconnu, améliorer le système à tout moment.

Le Scrum Master joue un rôle essentiel d’accompagnement et se doit d’encourager les équipes.

L’équipe de réalisation

L’équipe de réalisation varie en fonction de la typologie du produit. Voici un dispositif classique pour une équipe de développement mobile :

Les designers UX/UI

Ils n’ont pas forcément besoin d’être à plein temps dans votre équipe de développement. Chez Kreactive nous vous offrons la flexibilité de faire appel à l’équipe UX/UI sur mesure en fonction de vos besoins. 

UX (eXpérience Utilisateur)

Son rôle est de délivrer une expérience la plus fluide possible sur votre produit. En fonction de vos besoins, les UX designers vont être amenés à réaliser des tests utilisateurs, des wireframes, des parcours utilisateurs ou des user story mapping entre autres.

UI (Interfacte Utilisateur)

L’utilisateur doit se sentir chez lui dans votre App. Les UI designers connaissent par cœur les guidelines respectives d’Apple et Google en terme de design d’interfaces. L’enjeu est de délivrer une application la plus intuitive possible tout en offrant une esthétique qualitative.

Les développeurs mobile

Ce sont eux qui écrivent les lignes de code qui font votre application mobile.

iOS

• Device : les développeurs iOS développent les applications pour iPhone et iPad
• Store : ces applications sont déployées uniquement sur les App Store d’Apple
• Techno : ils développent en Swift et Objective-C

Android

• Device : les développeurs Android développent les applications pour smartphones et tablettes de type Android
• Store : ce sont des applications qui sont ensuite publiées sur les stores Google Play Store, Tencent (Chine) et sur les autres stores qui acceptent les applications Android
• Techno : leurs langages sont Java ou Kotlin

Cross-plateforme (Hybride)

• Device : ils développent des applications pour iPhone, iPad, smartphone et tablette Android
• Store : ils peuvent déployer des applications sur l’App Store d’Apple, Google Play Store, Tencent (Chine) et autres stores acceptant les applications Android
• Techno : React Native, Ionic, Xamarin, Flutter et Cordova sont les technologies de développement cross-plateforme les plus utilisées

Les développeurs web 

Dans une équipe de développement mobile, il peut être nécessaire d’intégrer des développeurs web, voici pourquoi :

Les webservices ou APIs

Sans webservices ou APIs, votre App n’afficherait pas de contenu, elle serait vide. Les webservices sont des services web qui permettent de connecter l’interface que vos utilisateurs utilisent à des ressources (ex : image, texte…) qui se trouvent dans le back-end de votre application mobile.

Le back-office

Vous souhaitez délivrer de la valeur en continu à vos utilisateurs ? Vous souhaitez rendre administrable votre contenu par vos équipes métier et/ou Product Owner ? Alors vous avez besoin d’un back-office. Ce back-office est développé par des développeurs web (et non mobile), il est nécessaire de disposer d’un développeur front et un développeur back pour cela.

Les rituels 

Dans la méthodologie SCRUM, les rituels rythment la vie du projet. Une application mobile se développe de A à Z, il est donc très important d’assurer une excellente communication au sein des équipes.

Ce qui est important c’est d’utiliser ces rituels dans le sens du mindset Agile et d’en comprendre l’utilité. Chaque équipe projet est différente et nécessite par conséquent des rituels adaptés. Nous vous présentons ici les quatre rituels que nous vous conseillons de mettre en place. Ce sont aussi ceux que nous utilisons le plus chez Kreactive :

Le stand-up meeting

Le stand-up meeting consiste à réunir l’ensemble de l’équipe de réalisation tous les matins autour d’un point de 15 minutes maximum. C’est un point de coordination et non de reporting. L’objectif est de développer la collaboration de l’équipe en se synchronisant sur les changements quotidiens par rapport aux avancées ou aux potentiels blocages rencontrés.

“C’est fou le nombre de fois où un simple stand-up meeting a permis de nous débloquer une situation”

— Juliette Wagner, Designer UX/UI

Certains l’appellent le daily, d’autres le stand-up meeting. L’important est de se réunir pour échanger. Chez Kreactive, tous les matins les équipes se réunissent autour d’un Stand-Up Meeting.

La backlog review

Estimer les items du backlog

Les besoins de développement exprimés par le Product Owner sous la forme de User Stories (US) sont listés dans le backlog produit. La cérémonie de la backlog review est animée par le Product Owner qui présente à l’équipe les différentes US, qui les estiment en points de complexité ou d’effort suivant une échelle donnée. Chaque membre de l’équipe de réalisation possède une vélocité par Sprint qui est calculée en points de complexité. Chez Kreactive, nous utilisons la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21. C’est à ce moment-là que des User Stories jugées trop « grosses » sont découpées en plus petites.

Toutes les équipes de réalisation ne sont pas comparables. Chaque personne a sa propre manière de travailler et il est important de la respecter. Chaque développeur ne réalise pas le même nombre de points par Sprint. La vélocité ne doit donc pas être interprétée comme un indicateur de performance ou de travail. 

Qualifier l’état d’une User Story

La backlog review permet aussi de s’assurer que les User stories fournies possèdent tous les éléments pour que l’équipe puisse travailler en pleine autonomie sur ce qui est demandé. Si la user story remplit tous les critères, elle est alors en “ready to sprint”, prête à être intégrée dans le Sprint prochain lors du sprint planning.

Le sprint planning

Le sprint planning sert à sélectionner les items du backlog qui vont être intégrés dans le sprint.

Le Product Owner hiérarchise les différents items afin de fournir à l’équipe de réalisation une visibilité sur les priorités. Il définit un objectif de sprint et aide l’équipe de réalisation à sélectionner les items du backlog produit pour y parvenir. C’est la construction du backlog du sprint.

La vélocité est alors prise en compte pour s’assurer d’avoir une charge de travail cohérente avec les capacités de l’équipe de réalisation.

Quelle est la durée d’un sprint ? 

Un Sprint peut durer d’une semaine à un mois. En général dans une équipe de réalisation mobile, il est de 1 à 2 semaines. C’est une séquence suffisamment courte pour obtenir fréquemment des incréments produits tout en permettant à l’équipe de traiter des sujets de fond.

La rétrospective

Nous conseillons à chaque équipe de consacrer un moment à une prise de recul sur le Sprint. Il est conseillé de réaliser la rétrospective à chaque fin de Sprint. Si cette granularité est trop basse, vous pouvez aussi faire des rétrospectives moins souvent en fonction des paramètres de votre projet. 

On s’interroge ici avec bienveillance sur la façon d’organiser notre travail au sein des équipes. Que doit-on améliorer ? Quels sont nos points forts et comment capitaliser dessus ?

La rétrospective n’est pas là pour trouver des boucs-émissaires mais pour trouver des axes d’amélioration constructifs au sein de l’équipe Scrum, voire dans l’organisation globale.

Les rituels : en résumé

Il a été prouvé que les projets dans lesquels toutes les parties prenantes communiquent tous les jours fonctionnent mieux. Il en est de même pour les équipes qui se donnent des objectifs à chaque sprint pour construire un incrément produit régulièrement.

Ces meetings ne doivent pas être considérés comme des réunions mais comme un véritable dialogue dans lequel chaque personne a un droit d’expression. Les temps de réunions sont indexés selon la longueur du sprint.

Vous souhaitez mettre en place la méthodologie SCRUM dans votre équipe de développement mobile ?

Nous nous ferons un plaisir de vous aider dans cette mission !