Les méthodes Agile (Kanban – Scrum – Extreme programming) ont été créées afin de tenir compte de la réalité de la plupart des projets pour lesquels il est quasiment impossible de tout définir dès le début du projet.
L’une des premières méthodes répandues à travers le monde est la méthode Cascade. Une autre méthode dite classique est la méthode Cycle en V qui est une méthode d’organisation de projet imaginée afin de limiter le problème de réactivité du modèle en cascade et permet, en cas d’anomalie, de limiter le retour aux étapes précédentes. Elle est représentée par un V dont la branche descendante contient toutes les phases de conception du projet, et la branche montante toutes les étapes de tests du projet. La pointe du V représente la phase de réalisation du projet. Chaque phase de la branche descendante a un lien avec une phase de la branche montante (voir la figure ci-dessous).
Scrum permet de pallier ce problème et de s’adapter aux changements qui peuvent arriver au cours du projet, il est ainsi possible de modifier ou de donner plus de précision aux spécifications. Des ajustements peuvent être effectués régulièrement, notamment à la fin de chaque itération, appelée « Sprint ».
La méthode Scrum, qui tire son nom du terme anglais « Mêlée », en référence à la mêlée du rugby, met l’accent sur l’esprit d’équipe et sur le fait que tous les acteurs doivent avancer dans la même direction pour atteindre un même objectif. Scrum repose sur une intense collaboration de l’équipe qui se focalise sur une partie limitée et maîtrisable des fonctionnalités à réaliser.
Contrairement au Cycle en V qui se compose d’un chef de projet, un MOA et un MOE, l’équipe Scrum est répartie en 3 rôles :
- Le Product Owner : c’est le responsable du produit, il représente les clients et les utilisateurs en transcrivant leurs besoins, définit et priorise les demandes produit.
- Le Scrum Master, qui n’est pas le chef de projet mais il a pour charge de faciliter l’application de Scrum, sa mission est de tout mettre en œuvre pour que l’équipe travaille dans de bonnes conditions et se concentre sur l’objectif du projet. Il porte également une attention particulière au respect des différentes phases de Scrum.
- L’équipe Scrum : L’équipe se gère en toute autonomie et est en charge du développement du produit. Il n’y a pas de notion de hiérarchie, toutes les décisions sont prises ensemble. Elle regroupe les rôles habituellement nécessaires à un projet (architecte, concepteur, développeur, etc).
La méthode Scrum repose sur deux journaux ou « backlog » :
- Backlog de produit : liste les fonctionnalités pour le produit qui sont estimées par l’équipe. Il est géré par le Product Owner mais partagé avec l’ensemble de l’équipe. Les fonctionnalités sont priorisées et associées à des critères d’acceptation qui permettent de déterminer si le besoin est couvert.
- Backlog de Sprint : liste l’ensemble des tâches nécessaires pour répondre à l’objectif du Sprint. C’est la propriété de l’équipe, cette dernière le met régulièrement à jour et choisit les tâches sur lesquelles elle souhaite travailler.
Un projet utilisant la méthodologie Scrum se base sur des itérations appelées Sprints qui se succèdent. Un sprint dure de 2 à 4 semaines (voir la figure ci-dessous). Chaque Sprint commence par une réunion de planification appelée « Sprint planning » (appelée aussi planning poker). C’est à l’issue de cette réunion, que l’équipe découvre l’objectif du Sprint et chaque besoin qui est décomposé en plusieurs tâches.
Durant un Sprint, des réunions quotidiennes appelées « Daily meeting » (ou Stand up) de moins de 15 mn permettent à chaque membre de prendre la parole et de faire le point sur ce qu’il a fait, ce qu’il compte faire et les difficultés rencontrées.
Pendant ce Sprint, l’équipe développe l’ensemble des besoins embarqués dans ce sprint en analysant, concevant, développant, testant et intégrant les fonctionnalités.
Chaque Sprint se termine par une revue du Sprint appelée « Démonstration » durant laquelle les besoins réalisés sont évalués par le Product Owner en présence du client qui valide ou pas le produit partiel et modifie par la suite le backlog de produit.
Une réunion « Rétrospective » se fait généralement après la démonstration. Elle a pour but d’examiner ce qui a bien fonctionné, ce qui ne l’a pas été et ce qui peut être amélioré.
La méthode Scrum suit un processus itératif permettant d’obtenir un produit proche des besoins client en prenant en compte l’évolution de ces derniers et ainsi maximiser la valeur du produit livré.
Si au cours d’un Sprint, un problème survient, la responsabilité n’incombe pas à une seule personne mais elle est partagée entre le Product Owner, le Scrum Master et l’équipe Scrum.
Comparaison Scrum Vs Cycle en V :
En comparant la méthode Cycle en V et Scrum, cette dernière présente certains avantages et inconvénients que nous décrivons dans le tableau récapitulatif ci-dessous :
| Thème | Cycle en V | Scrum | Préférence |
| Cycle de vie | En V, phases séquentielles | Processus itératif | – |
| Livraison | La livraison est tardive puisqu’on attend la réalisation de toutes les fonctionnalités pour utiliser le produit | Livraison plus rapide et l’utilisation partielle du produit se fait très tôt (d’où la priorisation des besoins) | Scrum |
| Contrôle Qualité | Le contrôle qualité se fait qu’à la livraison finale (fin du cycle de développement) ce qui provoque un effet tunnel | Le contrôle qualité est très précoce puisque le client visualise le produit partiel assez tôt | Scrum |
| Spécification | La méthode s’oppose à tout changement et nécessite de revenir à la phase des spécifications, et repasser par toutes les autres phases, ce qui peut prendre un certain temps et un coût supplémentaire | Les spécifications sont beaucoup plus souples car si des fonctionnalités ne répondent pas aux besoins (même après la réalisation de la recette), il suffit d’ajouter une modification ou une nouvelle fonctionnalité dans des sprints suivants qui n’était pas prévue au départ (C’est principalement ce qui rend cette méthode Agile) | Scrum |
| Planification | Caractérisée par des plans détaillés sur la base d’exigences stables et définies tout au début du projet | Elle est adaptative avec ajustements si nécessaires au fil de l’eau en fonction des nouvelles demandes | Scrum |
| Équipe | L’équipe intervient uniquement dans la phase de développement et n’a pas de vision globale du projet | Chaque membre de l’équipe peut s’impliquer plus dans le projet en participant à des prises de décisions, en échangeant sur les difficultés rencontrées et de les supprimer au plus tôt. La productivité de l’équipe est ainsi augmentée surtout que cette dernière participe au chiffrage (sprint planning) | Scrum |
| Taille de l’équipe | Pas de limitation mais ce n’est pas pour autant un avantage car une équipe trop nombreuse peut poser certains problèmes | Limitée car l’organisation des réunions devient impossible ce qui peut remettre en cause les fondements mêmes de la méthode | – |
| Documentation | Produite en quantité importante | Réduite au strict nécessaire | Scrum |
| Demandes supplémentaires en nombre | Opposition à tout changement et demande donc théoriquement pas de dépassement de budget | Ces demandes peuvent, des fois, être contradictoires donc difficiles à gérer et causer des projets sans fin et un coût exorbitant | Cycle en V |
Conclusion :
Pour conclure, nous pouvons dire que Scrum offre plusieurs avantages avec la possibilité de s’appliquer sur un large panel de projets. Il appartient à chacun de se faire sa propre idée et de décider si la méthodologie Scrum est adaptée ou pas à un tel ou tel projet car il est important de garder à l’esprit que chaque équipe, chaque projet et chaque contexte sont différents.
Très bel article. Explication claire et limpide!
Je ne suis pas tout à fait d’accord sur la taille de l’équipe et les demandes supplémentaires en nombre. Serte une équipe SCRUM doit rester assez petite mais rien n’empêche d’avoir plusieurs équipes sur un même produit. Pour les demandes, c’est au product owner de calmer les ardeurs du client si ce dernier fait des demandes contradictoires et/ou non pertinentes.
Je n’ai pas d’expérience réel de SCRUM, juste la théorie donc je me trompe peut être.
Bel article, mais pour moi un chouillat trop partial.
La dérive du projet sans fin se vérifie quand même bien souvent, avec des impacts qui peuvent mettre en danger le projet :
– problèmes contractuels
– motivation des équipes (surtout client) qui n’en voient pas la fin
– et surtout une résistance au changement grandissante de l’utilisateur final qui voit son interface et ses processus changer tous les 15 jours. Il finira toujours par trouver des alternatives (mettant à terme en danger la crédibilité et l’efficacité du produit), car à quoi bon encore faire l’effort d’intégrer un changement qui n’en n’est que le pénultième et sûrement pas le dernier ?
« Le client », c’est celui qui paye ou délégué, qui a une vision globale, et celui qui généralement n’est pas l’opérationnel.
L’utilisateur final, lui… alors qu’AGILE le met au centre (et tant mieux), l’informatique n’est souvent pour lui qu’un outil, et de son point de vue le changement pour le changement peut devenir un dogme, d’où résistance accrue par ce type de méthode en flux tendu.
Surtout que pour tout changement au sein d’une Entreprise – qui peut donc avoir des répercussions organisationnelles et de fiche de poste-, il n’y a pas forcément que des gagnants. En faisant des mises en prod très rapprochées, vous augmentez potentiellement le troupeau des mécontents (une variation de la maxime : on se souvient toujours + des trains qui ne sont pas à l’heure).
Salut les copains, on s’est vu aux MS Experiences’17 ;).
Merci beaucoup pour cet article, cela me fait penser à un article que l’un de mes collègues a écrit. Il revisite les 12 principes du manifeste agile, on voit bien la réalité entre ce qu’il faudrait faire et ce qu’il se passe en réalité.
L’article est ici si ça vous intéresse :
http://www.softfluent.fr/blog/expertise/2017/05/17/Les-12-principes-du-manifeste-agile
Merci pour cet article qui me semble être une excellente introduction pour quelqu’un qui souhaite, comme moi, en connaitre d’avantage sur les méthodes de gestion de projet.
J’ai une question par rapport au Sprint Planning.Vous dites que « Chaque Sprint commence par une réunion de planification appelée Sprint Planning. C’est à l’issue de cette réunion que l’équipe découvre l’objectif du Sprint et chaque besoin qui est décomposé en plusieurs tâches ». Quand je lis ça, j’ai donc l’impression que les besoins intégrés dans le Sprint qui commence ont déjà été définis et chiffrés.
Or plus bas, vous dites que l’équipe de développement participe au chiffrage lors du Sprint Planning.
Mes questions sont donc les suivantes :
– Quand a lieu le chiffrage des besoins ? Lors du Sprint Planning ou avant ?
– Quand est-ce que l’on définit les besoins qui « entrent » dans le Sprint Backlog, et ceux qui restent dans le Product Backlog ? Lors du Sprint Planning ?