Auteur : SSW Europe

Scrum est plus simple qu'il n'y paraît et peut être résumé en 8 étapes principales.

💡Conseil : Imprimez le PDF "SSW - les 8 étapes de Scrum" réalisé par SSW et affichez-le dans votre salle de réunion afin que tout le monde puisse s’y référer facilement.

Note : Scrum recommande de ne pas traduire la terminologie spécifique Scrum. Nous avons donc fait le choix de suivre cette recommandation et d’utiliser la terminologie anglaise (ex : Initial Meeting, Product Owner, etc.). Cependant, le plus important et d’avoir un langage commun au sein d’une équipe, quelle que soit la langue.

1. Initial Meeting 

Lors de l’Initial Meeting, le Product Owner explique la vision globale du produit. Les Developers réfléchissent à l'architecture nécessaire et au temps dont ils auront besoin pour établir une estimation.

2. Construction du Backlog 

L’étape suivante est la construction du Backlog, également connue sous le nom de Specification Review. Les développeurs proposent une architecture logicielle globale et une liste de tâches, appelée "Product Backlog”. Chaque élément du Product Backlog est appelé un Product Backlog Item (PBI).

Les PBIs sont estimés en termes de temps nécessaire ; puis une marge est ajoutée pour les tâches génériques telles que la partie DevOps, les tests, la résolution de bugs, la gestion de projet, etc.

C'est également à ce moment que le Product Owner définit pour la première fois le Product Goal (le "pourquoi" du projet). A noter que ce dernier peut – et devrait - être affiné tout au long du projet.

N️B - une équipe Scrum est constituée uniquement de 3 rôles : le Product Owner (décideur), le Scrum Master (sorte de chef de projet) et les Developers.

3. Sprint Planning 

Durant le Sprint Planning, les Developers vont se concentrer sur un groupe de PBIs provenant du Product Backlog qu'ils estiment pouvoir achever lors du prochain Sprint (le plus souvent sur une période de 2 semaines).

Le Product Owner classe les PBIs par ordre de priorité et s'assure que les premiers de la liste disposent des informations nécessaires pour être démarrés. Les Developers sélectionnent ensuite les PBIs qu’ils estiment pouvoir livrer lors du prochain Sprint, par ordre de priorité décroissante.

Pour finir, Les développeurs et le Product Owner définissent ensemble le Sprint Goal (le "pourquoi" du Sprint).

4. Sprint 

Durant le Sprint, les Developers travaillent sur les PBIs par ordre de priorité. De plus, ils participent aux Daily Scrum Meetings et envoient des Done emails pour chaque PBI une fois qu’il respecte la Definition of Done. Au cours de ce processus, l'équipe affine également les éléments du Product Backlog pour s'assurer qu'ils sont conformes à la Definition of Ready. Pour gérer le Sprint, un tableau de suivi des tâches est souvent utilisé.

5. Product Increment 

Chaque Sprint a pour but d’aboutir à un Product Increment, potentiellement livrable. Idéalement, si les bonnes pratiques de DevOps, d’automatisation du déploiement et de tests sont utilisées, chaque PBI devrait également aboutir à un Product Increment.

Cela signifie qu’en théorie chaque fonctionnalité peut être déployée en production dès qu'elle est terminée.

6. Feedback 

Lorsqu’un PBI est livré, les retours arrivent très rapidement. S’il s’agit de bugs ou de petites modifications, ceux-ci peuvent être ajoutés au Sprint actuel. Les suggestions plus complexes doivent être approuvées par le Product Owner, puis ajoutées au Product Backlog.

7. Sprint Review 

À la fin du Sprint, la Sprint Review permet aux Developers de présenter leurs PBIs terminés, par le biais d’une démonstration en temps réel et/ou en vidéo. L'objectif est que le Product Owner comprenne le Product Increment et discute des retours pour améliorer le produit. C'est la seule véritable mesure du succès du Sprint.

8. Rétrospective 

La Sprint Retrospective est généralement la cérémonie préférée de l’équipe Scrum. Elle permet à l’équipe de discuter des points positifs, négatifs et à améliorer, dans une démarche d'évaluation et d’adaptation constante où chaque nouveau Sprint améliore les suivants.

Ensuite l’équipe démarre un nouveau Sprint Planning (#3), et la séquence recommence jusqu’à complétion du projet.

Source : https://www.ssw.com.au/rules/8-steps-to-scrum/  

---

Les rôles de Scrum

Développeurs : Les membres de l'équipe de développement qui sont responsables de la création du produit. Ils sont auto-organisés et interviennent dans tous les aspects du travail. 

Product Owner (PO) : Membre de l'équipe (généralement le client) responsable de définir et de prioriser le travail de l'équipe de développement en fonction de ses besoins. 

Scrum Master: Membre de l'équipe chargé de la bonne application de Scrum au sein de l'équipe de développement et de supprimer les obstacles qui entravent leur progression.  

Feriez-vous construire une maison sans faire appel à un architecte au préalable pour définir un plan ? Évidemment non ! C'est la raison pour laquelle une réunion préparatoire est généralement planifiée avec le client avant de commencer tout type de projet.

Il n’est pas réaliste de pouvoir comprendre pleinement la complexité d’un projet et de donner une estimation précise pour les travaux à réaliser après une brève réunion. Dans la plupart des cas, quelques jours sont nécessaires pour obtenir et documenter les exigences des parties prenantes du projet, et par la suite, transformer ces idées en une feuille de route détaillée.

Livrables

Les livrables de la Specification Review dépendent principalement de la taille de l'application et du temps passé lors de la revue. À la fin de la Spec Review, le client recevra les livrables suivant :

Analyse des besoins

• Une feuille de route technique, ou "Roadmap", recommandant les options d'architecture adaptées à la solution.
• Une décomposition de l'application voulue en ses composants principaux, incluant par exemple le nombre approximatif de fonctionnalités principales (formulaires, rapports, etc.).
• Un plan d'intégration.
• Une stratégie de déploiement et d'hébergement.
• La définition d'un Minimum Viable Product (MVP), ainsi qu'une liste de fonctionnalités secondaires ; cette étape nécessite l'implication du client pour définir les priorités (i.e. périmètre du MVP)
• Une liste détaillée des problèmes existants ayant un impact sur le développement et la maintenance de la future solution.
• Lorsque pertinent, des recommandations logicielles (ou matérielles) - le développement sur mesure n'est pas toujours la solution optimale.
  
• Si nécessaire, des maquettes des principaux écrans.

Backlog Produit

• Un Backlog Produit, sous forme d’une liste de Product Backlog Items (“PBIs”), établi en fonction de l'analyse des exigences et de l'architecture choisie.
• Une estimation en termes de temps de développement nécessaire pour chaque PBI.

Budget Estimatif €

• Le nombre estimé de Sprints (et par conséquent de jours).
• Le nombre estimé de développeurs.
• Le coût total estimé du projet.

De la maquette au produit final

Nous produisons souvent des maquettes pendant le processus de Specification Review afin de donner un aperçu relativement fidèle des fonctionnalités et de l'apparence de la solution proposée au client.

Les maquettes sont utilisées aux différentes étapes clefs du cycle de développement de la solution.

La création et l'utilisation des maquettes suit généralement le processus suivant :

• Les développeurs discutent avec le client pour mieux comprendre ses besoins.
• Les développeurs conçoivent les maquettes pour que le client puisse les visualiser, puis les valident ensemble.
• Les maquettes servent ensuite de base de travail pour les développeurs lors de l'implémentation. 
• Les développeurs livrent le produit pour recette au client.
• Les développeurs présentent le produit final avec une "done video".

Jetons un coup d'œil à un exemple concret :

Ces maquettes ont été créées lors de la Specification Review, et ont permis d'obtenir un aperçu du nouveau moteur de recherche voulu par le client.

Elles ont ensuite été utilisées comme base de travail, conduisant au résultat final suivant :

Comme vous pouvez le constater, le produit final est relativement proche de la maquette initiale. C'est un outil formidable permettant d'entrevoir le futur d'offrir rapidement une représentation concrète du produit final.

---

Source : ssw.com.au/rules/what-is-a-spec-review