SCRUM est une méthodologie de gestion de projet basée sur la théorie empirique du contrôle des processus, qui est cohérente avec les valeurs du manifeste Agile (2001). Il ne s'agit pas d'une méthodologie de travail restrictive, mais plutôt d'un cadre qui permet de fournir un logiciel sans avoir d'emblée une vision de la forme finale. Les principaux avantages de la méthodologie SCRUM sont de minimiser le coût des changements d'exigences et de fournir rapidement des fonctionnalités potentiellement prêtes à l'emploi.
Comment cela fonctionne-t-il ?
En pratique, cela signifie que l'ensemble du processus est constamment optimisé et adapté aux besoins de l'entreprise. équipe et le produit pendant toute la durée des travaux de la projet. Responsabilité de la gestion développement de produits est réparti entre le propriétaire du produit (PO) et l'équipe de conception. Le PO est la personne chargée de prendre les décisions relatives à l'orientation du développement du produit et a une "vision" globale de ce que le produit est appelé à devenir. La gestion des tâches est basée sur le tableau Kanban (en conjonction avec l'outil sprint appelé tableau SCRUM). Chaque participant au processus peut ajouter des tâches au carnet de commandes, mais c'est au PO qu'il incombe de fixer les priorités. L'équipe de projet est chargée de "transformer" les idées du PO en tâches spécifiques et de planifier leur mise en œuvre.
Déroulement du cycle
Le processus est divisé en itérations (sprints). Dans le cadre d'un sprint d'une durée d'environ 2 semaines, l'équipe de projet met en œuvre et teste la partie de la fonctionnalité planifiée précédemment.
Le sprint commence par la "planification", au cours de laquelle l'équipe discute et prépare les tâches qui ont été préalablement préparées et placées par le PO en haut du backlog. Ensuite, la difficulté de ces tâches est estimée et des points leur sont attribués en fonction de cette difficulté. La composition de l'équipe et les conditions de travail étant relativement constantes, le nombre de points attribués au cours de chaque sprint est reproductible et permet de planifier le travail futur. À la fin de la réunion de planification, les tâches ayant un nombre total de points à réaliser au cours d'un sprint sont sélectionnées, et un nouveau sprint commence.
Au milieu du sprint, le toilettage a lieu. Il s'agit d'une réunion au cours de laquelle le PO présente à l'équipe ses nouvelles attentes et idées, tandis que l'équipe de projet les analyse, les décompose en tâches plus petites et lui présente d'éventuelles suggestions. Lors de la planification des tâches futures, le PO consulte les analystes, les utilisateurs, les concepteurs UX et les concepteurs graphiques. Des analyses supplémentaires (marché (recherche et science des données) sont souvent nécessaires à ce stade. Ce n'est qu'après avoir analysé et formulé le récit de l'utilisateur que le PO publiera ces récits dans un carnet de commandes. Le récit de l'utilisateur doit contenir des informations sur ce que le PO attend d'une tâche ou d'un groupe de tâches donné et sur les critères à utiliser pour déterminer si la tâche est achevée.
Au cours du sprint, des réunions dites "Daily standup meeting" sont organisées quotidiennement. Lors de ces réunions, chaque développeur explique au reste de l'équipe ce qu'il a fait au cours de la journée écoulée et signale éventuellement les problèmes ou blocages qui entravent la poursuite de son travail. Grâce à cet échange d'informations sur l'état d'avancement du projet, il est possible de détecter beaucoup plus rapidement les conflits potentiels entre les différentes tâches et d'éviter que le développeur ne reste bloqué sur un problème et ne puisse plus progresser. L'hypothèse du standup quotidien doit être aussi courte que possible, tout en remplissant son rôle. La formule permanente de la réunion encourage l'équipe à faire en sorte qu'elle soit la plus courte possible.
Pendant le sprint, les tâches sont déplacées sur le tableau SCRUM en fonction de leur statut actuel. Le choix des colonnes correspond généralement au système de travail des entreprises ou de l'équipe et est associé au système de contrôle des versions et à la fréquence des versions. Pour nous, c'est le suivant :
- À faire - tâches en attente d'achèvement
- En cours - tâches en cours
- Code révision - tâches en attente d'être vérifiées par un autre développeur
- Préparé - tâches vérifiées et acceptées par les développeurs
- Stagé - tâches situées sur une instance de staging et en attente de l'approbation du PO
- Accepté - tâches acceptées par le PO
- Done - tâches prêtes situées sur l'instance de production
Après le sprint, une rétrospective a lieu. Il s'agit d'une réunion consacrée à l'optimisation du travail. Toute l'équipe discute de ce qui s'est bien passé au cours du dernier sprint et de ce qui doit être amélioré. Nous nous référons également souvent à la rétrospective précédente et vérifions si nous avons pu mettre en œuvre toutes les idées visant à améliorer le travail. Les problèmes abordés lors de la rétrospective peuvent concerner les outils de développement, la pression, la difficulté des tâches ou les problèmes de communication (tant entre les développeurs et l'équipe qu'avec le PO).
Responsabilités du maître SCRUM
La personne responsable du bon déroulement du processus SCRUM est le maître SCRUM. C'est souvent le rôle le plus incompréhensible de l'équipe. Le maître SCRUM n'a aucun pouvoir de décision. Les décisions sont prises conjointement par l'équipe et le PO, tandis que le rôle du SCRUM master est de lever les obstacles au bon déroulement du processus.
Les tâches du maître SCRUM sont les suivantes :
- Conduite des réunions SCRUM, y compris la planification, le toilettage, la réunion quotidienne et la rétrospective.
- S'assurer que les tâches sur le tableau SCRUM sont régulièrement toilettées par l'équipe et priorisées par le PO.
- Fonctionner comme un lien entre l'équipe et le PO ; par conséquent, c'est souvent le maître SCRUM qui a un rôle difficile à jouer en traduisant le langage des programmeurs dans le langage de l'entreprise, et vice versa. Cela est dû au fait que, dans notre entreprise, le maître SCRUM est un développeur, donc une personne technique. Le cadre général du travail du maître SCRUM ne l'exige pas.
- Empêcher l'équipe de s'écarter du sujet et veiller au respect de l'ordre du jour lors des réunions
- Veiller à l'ambiance au sein de l'équipe - principalement lors des réunions.
- Résoudre les conflits s'ils surviennent.
Lire aussi :