Agilité
Agilité https://samiadrici.com/wp-content/uploads/2022/05/samiadrici-product-agilite-introduction.jpg 800 400 Samia Drici https://samiadrici.com/wp-content/uploads/2022/05/samiadrici-product-agilite-introduction.jpgHome >> Product Management >> Agilité
L’Agilité c’est avant tout une culture, un état d’esprit, orienté sur la quête de sens, la création de valeur, la rationalisation et l’adaptabilité.
Valeurs et principes de l’Agilité
Le Manifeste pour le développement Agile de logiciels pose la base des valeurs et des principes de l’agilité dans le monde du développement de logiciels informatiques. Voici ce qu’il dit :
Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :
• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
De ces 4 valeurs découlent 12 principes parmi lesquels la satisfaction client, l’accueil positif du changement, les livraisons fréquentes et régulières, la confiance dans les équipes…
Organisation d’une équipe Agile
L’équipe Agile a pour objectif de délivrer fréquemment de la valeur aux clients et de s’adapter aux attentes des utilisateurs. Cela doit passer par des livraisons en production plus fréquentes et des services améliorés d’une livraison à l’autre.
Pour atteindre son objectif, l’équipe Agile s’appuie sur :
- Des cadres de travail : organisation en feature/ product team, auto-organisation au quotidien, affinages fréquents et réguliers des travaux en équipe, planification des travaux sur une courte durée…
- Des outils collaboratifs : management visuel, gestion de backlog, gestion de sources, intégration continue…
L’équipe doit être le plus autonome possible et à la recherche d’amélioration continue (rétrospectives).
Les rôles au sein de l’équipe Agile
Product Owner
Le Product Owner est celui qui porte et partage la vision produit. Il est au contact permanent des clients, recueille leurs besoins, les priorise et les partage à l’équipe tout au long de la vie du produit.
Scrum Master
Le Scrum Master est lse facilitateur, garant de la culture Agile au sein de l’équipe. Il est au service de l’efficacité de l’équipe et constamment dans une optique d’amélioration de la productivité, du savoir-faire et du savoir-être de l’équipe.
Dev Team
La Dev Team regroupe l’ensemble des personnes qui contribuent à la réalisation du produit, ceux sans qui rien ne serait possible : les architectes, business analysts, développeurs, testeurs…
Les cérémonies Agile
Le daily standup meeting
Comme son nom l’indique, c’est le rendez-vous quotidien de l’équipe. Il permet à la dev team de s’auto-organiser. Le “standup” ou “DSM”, se déroule devant le board d’équipe. Chaque participant y partage ce qu’il a fait la veille et ce qu’il va faire dans la journée. C’est l’occasion pour chacun de solliciter de l’aide s’il rencontre une difficulté particulière. On l’appelle “standup” car les participants se tiennent debout afin de s’assurer que le rituel ne s’éternise pas. Dans l’idéal il dure 10 à 15 minutes maximum. Le scrum master s’assure que les participants gardent le focus sur les sujets en cours et les invitent à reporter les éventuels sujets de discussion à la fin de la cérémonie. Si le Product Owner peut participer à ce rituel en tant qu’auditeur, il n’est pas indispensable.
L’affinage
L’affinage permet de préparer en équipe les stories qui pourront ensuite être embarquées dans un sprint. Durant ce rituel, le Product Owner présente les stories à la Dev Team qui s’assure qu’elle sont correctement décrites pour être comprises et réalisées. Si nécessaire, l’équipe découpe en stories plus unitaires les sujets qui peuvent être découpés. C’est également durant cette cérémonie que le Dev Team estime l’effort nécessaire à la réalisation de chaque story (story points). Il n’y a pas de récurrence prédéfinies pour les cérémonies d’affinage. Le Product Owner doit s’assurer d’avoir toujours suffisamment de stories affinées pour démarrer le sprint suivant. Toutefois, il est peu productif d’affiner à l’avance des stories qui ne pourront pas être traitées rapidement. Il faut donc adapter le rythme des affinages aux besoins.
La revue de sprint
La revue de sprint à lieu à la fin de chaque sprint (en général toutes les 2 ou 3 semaines). Préparée par la Dev Team et le Product Owner, elle permet de partager avec les parties prenantes les réalisations du sprint. On y présente un bilan des stories réalisées, les éléments marquants, les éventuelles difficultés rencontrées… C’est également l’occasion de faire des démos des nouvelles réalisations aux clients et aux autres parties prenantes qui peuvent donner des feedbacks directs à l’équipe.
La rétrospective
La rétrospective à lieu à la fin de chaque sprint. Contrairement à la revue, elle se déroule à huis clos entre les membres de l’équipe. Elle est animée par le scrum master et a pour objectif de permettre à l’équipe de s’améliorer en continu. Durant ce rituel, l’équipe échange en toute bienveillance sur ce qui a bien fonctionné et ce qui doit être amélioré. L’objectif est de proposer ensemble des axes d’amélioration en proposant des actions SMART qui seront suivie d’une rétrospective à l’autre;
Le sprint planning
Le sprint planning est la cérémonie durant laquelle le Product Owner clôture avec l’équipe le sprint en cours et démarre le suivant. En général sur un rythme de 2 ou 3 semaines. C’est l’occasion de valider en équipe ou d’ajuster le contenu du sprint. Le Product Owner a-t-il prévu trop de choses ? A-t-il oublié un sujet important et urgent pour l’équipe ? Quelle est le niveau de confiance de la Dev Team pour réaliser l’ensemble des stories prévues ?
