Ecrit en juin 2010 OrganisationRôlesProduct Owner (MOA)Le Product Owner est le représentant du client, il :
Le rôle du Product Owner est assuré par un membre de la MOA avec l’aide de l’AMOA. Equipe AMOAL’équipe AMOA assiste le Product Owner et à ce titre peut intervenir dans le cadre des activités associées aux responsabilités de ce dernier. Plus concrètement, l’équipe AMOA :
ScrumMaster (MOE)Le ScrumMaster appartient à l’équipe de développement (MOE), il :
Equipe de développement (MOE)L’équipe de développement :
ProcessusRésuméLe processus itératif du projet structure le développement du produit en cycles de travail appelés « Sprints ». La durée de ces sprints a été fixée à 3 semaines dans le cadre de ce projet. L’objectif d'un Sprint consiste à présenter à l’occasion de la démonstration le produit incrémenté en fonctionnement et potentiellement livrable. Juste avant de démarrer un sprint, l’équipe de développement sélectionne les éléments de la liste priorisée des exigences (Product Backlog) et s’engage à les terminer à la fin du sprint. Au cours de ce dernier, l’AMOA, le Product Owner et l’équipe de développement collaborent étroitement pour atteindre les objectifs fixés. Chaque jour, l’équipe de développement se coordonne et mesure son avancement. A la fin du Sprint, elle présente les résultats de son travail au Product Owner accompagné de l’AMOA et d'utilisateurs sous la forme d’une démonstration des nouvelles fonctionnalités réalisées. Les feedbacks sont recueillis. Juste après le Sprint l'équipe de développement se réunit afin de tirer les leçons du sprint écoulé et étudie les moyens d'amélioration de sa productivité. S'enchaine ensuite la planification du sprint suivant, à moins que le Product Owner ai demandé une livraison. Auquel cas, quelques jours sont généralement nécessaires pour consolider et packager le produit. Processus détailléLe paragraphe suivant décrit dans l’ordre chronologique les étapes du processus. Préparation Avant le démarrage d’un Sprint, le Product Owner doit s’assurer que le Product Backlog (Liste des exigences attendues) est correctement priorisé en fonction de la valeur métier et du coût de chaque exigence. Pour les exigences dépourvues de coût, il peut solliciter l’équipe de développement afin de procéder à des séances d’estimation. Il participe à ces séances - assisté par l’AMOA - en répondant aux questions de l’équipe de développement. Il doit également s’assurer que le besoin associé aux exigences prioritaires du Product Backlog (candidates au périmètre du prochain Sprint) est suffisamment mûr (décisions métiers structurantes prises, besoin formalisé sous forme de User Stories,…). Planification de Sprint
Sprint Le sprint englobe les activités d’analyse, de conception et de développement. Au cours de ce dernier l’équipe de développement soulève des questions métiers. L’AMOA répond aux questions (se retourne vers d’autres acteurs tels que la MOA si nécessaire) et complète les User Stories associées. L’AMOA vérifie en cours de sprint la bonne conformité de la fonctionnalité développée, émet au besoin des feedbacks qui permettront d’adapter la fonctionnalité. Mêlée quotidienne L’équipe de développement se réunit chaque jour afin d’évoquer le travail réalisé la veille, celui de la journée et soulever les obstacles rencontrés. Chaque membre de l’équipe actualise son « Reste A Faire » sur ses tâches en cours de manière à actualiser le graphique d’avancement du sprint. Ce point est limité à 15 minutes, d’autres acteurs du projet peuvent être présents mais seuls les membres de l’équipe de développement ont la parole. Revue de Sprint A la fin du sprint, l’équipe de développement présente au Product Owner accompagné par l’AMOA (et autres acteurs intéressés) les nouvelles fonctionnalités produites sous la forme d’une démonstration. Le Product Owner - avec l’aide de l’AMOA - accepte ou rejette les fonctionnalités présentées. Les feedbacks sont notés. En fonction des résultats présentés, le Product Owner peut demander une livraison du produit pour réaliser des tests de l’ensemble du produit en prévision d’une mise en production. Auquel cas, quelques jours de consolidation du produit en fonction des résultats de ces tests peuvent être nécessaires. Si le Product Owner ne demande pas de livraison, une nouveau sprint est planifié (cf. paragraphe « Planification de Sprint »). Rétrospective de Sprint Après la revue du Sprint, l’équipe de développement ainsi que le Product Owner se réunissent afin d’identifier les adaptations susceptibles d’augmenter sa productivité. Les choses qui fonctionnent, celles qui ne fonctionnent pas ainsi que les améliorations à apporter, sont identifiées dans cette réunion. Elle s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit. RéunionsPlanification de sprint
Mêlée quotidienne
Revue de Sprint
Rétrospective de Sprint
ArtefactsProduct BacklogLe Product Backlog centralise la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles, défauts à corriger). Le Product Owner s’approprie ce Product Backlog et priorise ses éléments en fonction de la valeur métier et du coût estimé de chacun. L’unité de coût est le « point ». Le choix d’une telle unité permet d’éviter la confusion entre délais et coût et d’illustrer le caractère « estimatif » (imprécis). Ces estimations sont réalisées dans un premier temps à partir d’un besoin peu détaillé, il peut être révisé au cours de la planification d’itération en cas d’écart par rapport aux hypothèses établies lors de la première estimation. Sprint BacklogLe Sprint Backlog comporte la liste des tâches du Sprint (son périmètre donc) ainsi que la charge de travail associée à ces dernières. Chaque jour, le Reste A Faire de chaque tâche est actualisé par l’équipe de développement afin de tracer le graphique d’avancement de Sprint. Tableau des tâchesCe tableau comporte la liste des tâches du Sprint Backlog, il permet à l’équipe de développement de se coordonner. Il comporte généralement 4 colonnes : « A faire », « En cours », « A vérifier », « Terminé ». Il est mural et simple à interpréter, permettant à n’importe quel acteur du projet de connaître en un coup d’œil l’avancement « temps réel » du Sprint. Graphique d’avancement de SprintTout au long du Sprint, n’importe quel acteur du projet peut consulter la progression de l’équipe de développement grâce au graphique d'avancement actualisé quotidiennement. Ce graphique indique l’évolution du Reste A Faire (généralement exprimé en heures) en fonction du temps. SpécificationsIntroductionPartant des constats suivants :
L’approche du projet, concernant les spécifications, consiste à lisser le travail de rédaction des spécifications tout au long du projet et à leur accorder une valeur contractuelle faible. Privilégiant plutôt la réalisation au plus tôt d’un logiciel qui fonctionne à la fin de chaque sprint grâce à une collaboration client/fournisseur (métier/technique, MOA/MOE) étroite. ProcessusListe des besoinsLe Product Owner établit et maintient la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles ou défauts à corriger). A ce stade, le niveau de précision du besoin est faible. Chaque exigence peut se résumer à 1 à 3 phrases en moyenne. La liste des exigences vient alimenter le Product Backlog. Besoins prioritairesAvant la planification d’un nouveau Sprint, le Product Owner approfondit le besoin associé aux fonctionnalités prioritaires (en tête de liste du Product Backlog). Une bonne pratique consiste à rédiger pour chaque fonctionnalités attendue une User Story (le verso décrit le besoin et le recto énumère les tests fonctionnels permettant de vérifier la couverture du besoin). A l’issue de la réunion de planification de Sprint, le périmètre de ce dernier est fixé. Il correspond à la liste d’exigences sélectionnées par l’équipe de développement matérialisées par un ensemble de User Stories. Conception/DéveloppementUne fois le Sprint démarré, le développeur s’approprie la User Story qui servira de support de communication entre lui et le rédacteur de la User Story (Product Owner, AMOA ou utilisateur). Au fil des questions soulevées et des réponses apportées, la User Story se complètera jusqu’à la fin des développements associés. Mise à jour des spécificationsA l’issue du Sprint, l’équipe de développement, met à jour la documentation du produit. Gestion des changementsLe besoin peut changer tout au long du projet (y compris tardivement). Notamment dans les cas de figure suivants :
Principe de trocPour rappel, le Product Backlog centralise l’ensemble des exigences (ou besoins) attendues du projet. Chaque élément de ce dernier comporte une estimation de coût en points. La somme des estimations permet donc de déterminer le coût du projet (estimation). Si les contraintes de budget voir de délais du projet sont fortes ; en cas de découverte d’un nouveau besoin ou de modification d’une fonctionnalité déjà réalisée ; un nouvel éléments est ajouté au Product Backlog en échange du retrait d’un autre de même coût et de valeur métier plus faire (cf. bas de la liste). Inversement dans le cas d’une disparition d’un besoin finalement inutile, l’élément associé est retiré du Product Backlog libérant ainsi une provision pour de nouveaux besoins ou futures modifications. Changement pendant un SprintLe périmètre d’un sprint fixé à l’issue de la réunion de planification ne doit pas changer. En cas de force majeure, le Product Owner peut annuler le Sprint en cours, ce qui peut engendrer des conséquences coûteuses. Les développements en cours sont stoppés, l’équipe de développement est coupée dans son élan. Un nouveau sprint doit alors être planifié. Gestion des défautsProcessus de gestion des défautsUn défaut qui n’a pas pu être corrigé pendant le Sprint est enregistré dans le "Bug Tracker" par le testeur. L’AMOA et l’équipe de développement qualifient ensemble les défauts constatés afin de savoir si une correction et réellement nécessaire et possible en fonction des informations renseignées par le testeur. Les défauts confirmés sont ensuite priorisés par le Product Owner assisté par l’AMOA. Le Product Owner identifie la liste des défauts à corriger dans le prochain sprint. Il communiquera cette liste à l’équipe de développement lors de la réunion de planification de sprint au même titre que les exigences prioritaires à réaliser. Les défauts critiques (bloquant le travail de test AMOA ou présentant un risque majeur dans l’utilisation du produit prochainement mis en production) peuvent être ajoutés au besoin au périmètre du sprint en cours. Processus de gestion des incidents de productionLes incidents de production peuvent être pris en compte par l’équipe de développement dans le Sprint en cours. PlanningPlanning global Zoom sur un sprint Bonnes pratiquesPlanning PokerLe Planning Poker est une technique d’estimation de coût d’exigences. Cette technique se pratique en équipe et permet de procéder à des estimations rapides et aussi précises que possible selon le niveau de précision du besoin disponible. Au cours des séances d’estimation, le Product Owner (assisté de l’AMOA au besoin) soumet une à une à l’équipe de développement les exigences dont il souhaite connaître l’estimation de coût. Il répond aux questions de l’équipe de développement qui en cas d’absence de réponse (besoin encore flou) établie des hypothèses. Les estimations de coût (dont l’unité est le point) ainsi obtenues viennent alimenter le Product Backlog et aideront le Product Owner à prioriser ses exigences. La technique de Planning Poker peut également être utilisée pour estimer en équipe (Product Owner, AMOA, utilisateurs, marketing,…) la valeur métier en points des exigences du Product backlog. Pour en savoir plus : http://fr.wikipedia.org/wiki/Planning_poker User StoryLa User Story est une technique de spécification permettant de synthétiser le besoin lié à une fonctionnalité en quelques phrases courtes et simples utilisant exclusivement le vocabulaire métier (absence de connotation technique ou de description d’IHM). D’autre part, une User Story énumère les tests fonctionnels connus à date permettant de vérifier la couverture du besoin de la fonctionnalité associée. Les avantages sont nombreux :
Pour en savoir plus : http://en.wikipedia.org/wiki/User_story Pratiques de développementIntégration continueL’intégration continue a pour rôle de détecter au plus tôt les défauts d’intégrité du code (plus un défaut est corrigé tôt moins il coûte cher). Elle est matérialisée par un outillage logiciel récupérant le dernier code disponible sur le gestionnaire de version, compilant ce dernier et exécutant les tests unitaires existants. Il réalise cette tâche automatiquement à chaque modification du code soumise au gestionnaire de version ou plusieurs fois par jour. En cas de défaut détecté, une alerte est déclenchée (email, signal sonore ou visuel,…). Cet outil permet donc de renforcer la qualité des développements et de favoriser le travail indispensable de refactoring régulier du code. Pour en savoir plus : http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue Développements pilotés par les testsLe développement piloté par les tests consiste à sensibiliser le développeur sur les tests en amont de ses développements. Concrètement, la User Story associée à une fonctionnalité à développer liste les tests qui permettrons de confirmer que cette fonctionnalité couvre effectivement le besoin. Cette approche limite les erreurs d’interprétation du besoin du développeur. Programmation en binômeLa programmation en binôme consiste à rassembler deux développeurs sur un même poste de travail pour accomplir une même tâche de développement. Cette approche apporte plusieurs avantages :
Pour en savoir plus : http://fr.wikipedia.org/wiki/Programmation_en_bin%C3%B4me/ AnnexesTraduction du manifeste Agile« Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes.
Autrement dit, même si il existe de la valeur dans les éléments de droite, nous accordons plus d’importance à ceux de gauche. Nous respectons les principes suivants :
|
|
|
|
Accueil >
Organisation d'un projet Agile |