Conduite de projets agiles

Transcription

1 Conduite de projets agiles Management alternatif dans une équipe de développement agile Julien PLÉE

2 Table des matières 1 Chapitre 1 Contexte 1. Introduction Enjeu de Talentsoft Objectifs de Talentsoft L agilité comme remède miracle Mise en place de l agile Les problématiques actuelles La solution hybride Chapitre 2 Passage à l'agile 1. Introduction Cas des dirigeants Cas des Product Owners Rôle et missions du Product Owner Caractéristiques du Product Owner Disponibilité du Product Owner Cas des architectes logiciels Cas des équipes de développement Deux types de réactions Bénéfices de l agile Collaboration avec le client Motivation des équipes Cas des managers d équipe Rôle du leader technique R&D Équilibrer la pression dans l équipe Équilibrer qualité et productivité Accompagner le changement Devenir un leader

3 2 Conduite de projets agiles Management alternatif dans une équipe de développement agile 7. Cas des clients Contractualisation des livrables Chapitre 3 Ce qu'il faut savoir pour lire la suite 1. Introduction Le manifeste agile Des individus et des interactions Des logiciels opérationnels Une collaboration avec les clients Une adaptation au changement Les méthodologies agiles Scrum Kanban Value Stream Map Limitation des travaux en cours Mesure de Lead Time En quoi Kanban peut-il aider une équipe? extreme Programming Différences entre Scrum, Kanban et XP Lean Startup Lean Canvas MVP et Build/Measure/Learn Quelle méthodologie choisir? Le sprint (ou itération) Priorités changeantes et sprint en cours Le sprint est un incrément fonctionnel Les backlogs Backlog de produit Backlog de sprint

4 Table des matières 3 6. Les personae Donner du réalisme Comment procéder pour créer le persona? Les User Stories Format des User Stories INVEST Epic Stories et taille des stories Taille des User Stories Epic Stories et fonctionnalités Visibilité des User Stories Estimation des User Stories Critères d acceptation Critères d acceptation et Definition of Done Utilisation des critères d acceptation Format des critères d acceptation Représentation des différentes Stories Les Technical Stories Dette technique et architecture d entreprise Tâches communes à plusieurs User Stories Les boards Scrum Board Kanban Board Autres boards Le Burndown Chart Intérêt du Burndown Chart Autres types de Burndown Chart

5 4 Conduite de projets agiles Management alternatif dans une équipe de développement agile Chapitre 4 Mise en place des sprints 1. Introduction Définir des processus de développement Utilité des processus Définition des processus Exemple de processus complet dans une méthodologie agile Passage d une étape à l autre : la Definition of Done Spécifier ses Definitions of Done Types de Definition of Done Exhaustivité et évolution Bénéfices de la Definition of Done Responsabilisation des développeurs Qualité Rôle des architectes logiciels Impacts des méthodes agiles sur le rôle de l architecte Architectes (du) système Architectes d entreprise Rôle du chargé de projet technique Impacts des méthodes agiles Rôle du chargé de projet Documentation des projets Gestion de la dette technique Dette technique en environnement réel Impacts sur la satisfaction client Impacts sur la gestion de projet Impacts sur la prévisibilité Gestion de la dette technique au quotidien Sensibilisation du management Dédier des ressources à la dette technique

6 Table des matières Résorber la dette technique dans tout développement Incapacité à rembourser ses dettes Durée d un sprint Chapitre 5 Méthodes utilisées 1. Introduction Communiquer Favoriser la communication Identifier les problèmes de communication Résoudre les problèmes de communication Taille d équipe Mise en situation du développeur Comprendre son projet Connaître les attentes du client Motiver en impliquant Travail en binôme Niveau 1 : répartition des tâches Niveau 2 : Pair Programming Règles de codage Référentiel de règles de codage Champ d application des règles de codage Domain-Driven Design Test-Driven Development Bénéfices du TDD TDD et dette technique Behavior-Driven Development Réduire la documentation produit Périmètre et coût

7 6 Conduite de projets agiles Management alternatif dans une équipe de développement agile 10. Revues de code Pair Review Validation technique continue Assurance qualité technique Démonstrations régulières au Product Owner Maquettage de produit Amélioration continue Intégration continue Couverture du code par les tests Analyse statique du code Automatisation des livraisons Fréquence des livraisons et déploiement continu Intégration continue et dette technique Décliner le feedback pour en profiter au maximum Early Adopters Tests A/B Utilité des réseaux sociaux Fail Fast Rétrospectives Encourager la communication % de «Free Time» Essayer ses propres idées Origine des idées Organisation du Free Time Organisation du travail Gestion du temps Distinguer Free Time et Roadmap

8 Table des matières 7 Chapitre 6 Réunions agiles 1. Introduction Backlog Refinement Meeting Utilité Déroulement de la réunion Effets potentiels sur la priorisation Sprint Planning Meeting Daily Scrum Meeting Organisation des Scrum Meetings dans une grande équipe Scrum Meetings de Scrum Meetings Revue de sprint Rétrospective de sprint Rétrospective d'anomalies (ou Post-Mortem) Présentations R&D Big Code Review One on One Meeting Synthèse des réunions Backlog Refinement Meeting Sprint Planning Meeting Daily Scrum Meeting Revue de sprint Rétrospective de sprint Rétrospective d'anomalies Présentations R&D Big Code Review One on One Meeting

9 8 Conduite de projets agiles Management alternatif dans une équipe de développement agile Chapitre 7 Gérer son projet agile 1. Introduction Gérer son équipe Organisation fonctionnelle Organisation en projets/produits Organisation matricielle Équipes et culture d entreprise Gérer son backlog de produit Prioriser son backlog de produit Prioriser son backlog de sprint Gérer son backlog d architecture Effort d architecture dans un projet Organisation des travaux d architecture Organisation des équipes d architecture Minimum Viable Product Gérer la qualité et les anomalies Développer sur un socle instable Différents cas de figure Réduire la difficulté C est l auteur de l anomalie qui la corrige Impliquer la chaîne de développement Root Cause Analysis Privilégier la qualité Estimer Unité d estimation Que représente un Story Point? Estimation en unités de temps Estimation en Story Points

10 Table des matières Définir des Stories de référence Périmètre de la référence À quel moment définir des User Stories de référence? Périmètre des User Stories Manque d informations pour estimer Découpage en tâches Taille des tâches Définir les tâches pour terminer une User Story Estimation des tâches Planifier Planification agile ou prédictive Vélocité Corriger la vélocité en fin de sprint Unifier la vélocité de plusieurs équipes Planifier à long terme avec la vélocité Ne pas convertir les points en unités de temps Donner une date de fin Métriques agiles Burndown Chart Humeur de l équipe Vélocité Vers l autogestion Chapitre 8 Outillage pour l'agilité 1. Introduction Tableur Trello Tableau de post-its

11 10 Conduite de projets agiles Management alternatif dans une équipe de développement agile 5. Outils d ALM Jira Agile Pilotage des projets Simplification des tâches quotidiennes Team Foundation Server Intégration de TFS dans l écosystème logiciel Recueil du feedback avec TFS User Story Map Chapitre 9 Retour d'expérience 1. Introduction Retour des dirigeants Retour des Product Owners Retour des architectes Retour du management Retour de l équipe de développement Index

12 101 Chapitre 4 Mise en place des sprints 1. Introduction Mise en place des sprints Afin de parvenir à une mise en place efficace de ses sprints, l équipe doit prendre en compte divers facteurs, qui vont de l utilisation de processus précis de développement, à, par exemple, la définition du rôle des architectes logiciels qui va garantir leur bonne collaboration avec les équipes agiles, en passant par la documentation des différentes fonctionnalités développées qui n est pas en option en développement agile. 2. Définir des processus de développement Les processus sont inhérents au bon déroulement de tout projet, quelle que soit la méthodologie employée pour en assurer la gestion. De manière générale, travailler avec les méthodes agiles ne signifie certainement pas travailler sans processus. La première valeur du manifeste Agile peut pourtant rapidement prêter à confusion : «Individuals and interactions over processes and tools» La page web officielle du manifeste agile donne la traduction suivante en français : «les individus et leurs interactions plus que les processus et les outils». Il faut comprendre que les individus et les interactions humaines priment et non pas qu elles effacent totalement les processus.

13 102 Conduite de projets agiles Management alternatif dans une équipe de développement agile Un projet de développement logiciel mené en agile ne pourrait être mené à bien sans une définition précise de processus. 2.1 Utilité des processus Les processus permettent de définir, et de standardiser, les moyens et les bonnes pratiques pour réaliser des étapes dans le cycle de développement logiciel. L utilisation de processus dans l équipe de développement permet donc de normaliser les méthodes de travail pour chaque étape et les livrables produits qui leur sont relatifs. Par exemple, il est utile de définir un processus de revue de code au sein de l équipe. Cela permet de poser les règles d équipe sur la manière dont s effectuent les revues, à quelle position se trouve la personne qui revoit le code par rapport à celle qui l a codé, sur le moment où la revue s effectue... Exemple d éléments définissant le processus pour la revue de code Ci-dessous figurent deux exemples tirés de notre processus de revue de code. Le premier est relatif à la position du validateur par rapport au développeur, et le second est relatif au moment où s effectue la revue dans le cycle de développement d une User Story : «Le validateur ne doit pas faire partie du binôme qui a développé la User Story afin d éviter les biais cognitifs de conception.» «La revue s effectue à chaque fin de User Story, et non à la fin de chaque tâche technique, pour que le validateur puisse mettre en relief le design technique avec la cohérence fonctionnelle des développements.» Ce dernier exemple sur le moment auquel doit avoir lieu la validation induit aussi une définition de processus au sujet des User Stories car il induit la nécessité de disposer de User Stories avec un bon découpage, ce qui permet une revue qui a du sens. Ce afin que la validation d une User Story reste quelque chose d efficace et de facilement intelligible pour le validateur. Editions ENI - All rights reserved

14 Mise en place des sprints Chapitre Pour chaque étape du cycle de développement, il est donc nécessaire de se demander fréquemment s il ne manque pas un processus qui permettrait de fluidifier, tout du moins de dégripper un mode de fonctionnement améliorable dans l équipe. Ce questionnement introspectif sur la qualité de l organisation du travail de l équipe est à reproduire régulièrement dans une démarche d amélioration continue (cf. chapitre Méthodes utilisées - Décliner le feedback pour en profiter au maximum). La réciproque n est pas vraie : cela ne signifie pas qu il faille inclure des processus dans toutes les étapes du cycle de développement. Il peut d ailleurs s avérer dangereux et contre-productif de le faire, car cela peut par exemple impacter les bénéfices d une innovation qui pourrait être apportée par une liberté plus importante laissée sur une étape de conception. Pour saupoudrer le bon niveau de processus dans l équipe, il faut partir du principe que les processus sont des aides, et non pas des contraintes. Tout processus coercitif pour l innovation, qui fait perdre du temps en n apportant pas de bénéfice, pas de qualité supplémentaire par exemple, ou un processus de reporting (suivi des travaux) sans aucun autre bénéfice que d informer un responsable qui n en tire rien pour son propre travail, doit pouvoir être modifié ou retiré de l ensemble des processus de l équipe. 2.2 Définition des processus Afin de réduire la définition des processus à son strict essentiel dès la création de l équipe, ou de la mise en place de son projet, il faut partir d une feuille blanche. Pour rappel, une surenchère de processus conduirait inévitablement à un blocage des rouages de l agilité, donc à un échec.

15 104 Conduite de projets agiles Management alternatif dans une équipe de développement agile Voici une méthode qui peut vous aider pour la mise en place des méthodes agiles dans votre structure : Démarrer à partir d une feuille blanche. Reprendre dans l ordre les valeurs du Manifeste agile (cf. chapitre Ce qu il faut savoir pour lire la suite - Le manifeste agile) qui constituent un défrichage des problèmes organisationnels en développement logiciel en suggérant les meilleures réponses d après ses auteurs. Pour chaque valeur, mettre en place vos méthodes en ne vous basant que sur la première partie de chaque assertion. Ces méthodes permettent de mettre en œuvre ces valeurs. Par exemple, pour «les individus et leurs interactions plus que les processus et les outils», ne garder que «les individus et leurs interactions» puis commencer à lister les méthodes de votre organisation que vous pouvez mettre en place et qui répondent à cette phrase. Ensuite, si possible transformer chacune de vos méthodes, ou ajouter de nouvelles méthodes, en prenant en compte la deuxième partie de chaque assertion (celle qui commence par «plus que...»), et donc, en n oubliant pas que cette deuxième partie est importante et qu il y a de grandes chances que vos méthodes doivent également les prendre en compte pour le bon fonctionnement de votre organisation. Étoffer au besoin les méthodes déjà trouvées en vérifiant qu elles répondent bien aux douze principes agiles découlant des quatre valeurs du manifeste (voir Enfin, lister les problèmes rencontrés par le passé dans votre organisation et vos équipes et vérifier que les méthodes définies répondent également à ces problèmes. Remarque Pour ce qui est de trouver les méthodes et les transformer afin de correspondre aux valeurs et principes du manifeste agile, connaître les méthodologies agiles comme Scrum, Kanban, extreme Programming... est un accélérateur à la mise en place de bonnes méthodes. Il peut donc être utile de se renseigner sur les principales méthodologies agiles avant d effectuer vos définitions de méthodes. Editions ENI - All rights reserved

16 Mise en place des sprints Chapitre C est ainsi que vous obtenez une méthodologie qui prend en compte les problèmes résolus par l Agile et qui sont en l occurrence, vos problèmes également. C est ainsi que j ai procédé dans la mise en place de l agilité dans les équipes de développement de mon entreprise pour obtenir finalement une méthodologie composite qui utilise le meilleur de l agilité pour notre contexte. Il est également important de ne pas oublier les avantages des méthodologies dites prédictives telles que le «cycle en V» ou la «cascade». Nous avons pris le parti d exécuter quelques rares projets dans ce mode car il convient parfois mieux (cf. chapitre Contexte - La solution hybride). L autre avantage de procéder ainsi est de mettre en pratique les principes du Manifeste agile en partant de votre expérience dans votre société. Il est plus aisé de définir un mode de fonctionnement quand on est déjà bien au fait de ses qualités et de ses limites, plutôt que de vouloir appliquer stricto sensu une méthodologie qui pourrait subir l effet de mode du moment sans savoir si elle est adaptée au contexte. L effet pernicieux est alors qu un processus peut paraître adapté au niveau «macro», c est le principe de la vulgarisation d une méthodologie, mais provoquer des blocages au niveau «micro», et rendre plus lente et ardue l adhésion de l équipe au changement de méthodologie, équipe qui aura alors la juste impression qu on lui applique un changement aux vertus difficiles à percevoir Exemple de processus complet dans une méthodologie agile Dans mes équipes de développement, nous avons mis en place un moyen simple et graphique pour que chacun puisse savoir quoi faire à chaque étape de développement d une User Story : le cycle de vie d une User Story est résumé à travers un tableau RACI (acronyme pour les rôles Responsable, Approbateur, Contributeur et Informé) qui est une matrice des responsabilités. Les colonnes représentent les différents rôles en lien avec le développement d une User Story et les lignes représentent les différentes phases du cycle de vie de la User Story. Cela permet d avoir une vision claire et rapide de ce que chacun doit faire à chaque étape de la réalisation.

17 106 Conduite de projets agiles Management alternatif dans une équipe de développement agile Cette pratique n est a priori liée à aucune méthodologie agile, c est juste un moyen pratique de partager l information. Aussi, cette matrice RACI est un moyen simple d exposer quelques-uns des processus liés à la réalisation d une User Story dans les équipes de développement. Exemple de mise en œuvre d une matrice RACI pour le cycle de vie d une User Story : Sur la capture d écran ci-dessus, extraite du tableur constituant le RACI de nos équipes, on peut voir les différentes étapes que franchit la User Story, de son écriture à la fin de sa réalisation, associées aux responsabilités des différents rôles de l équipe. Editions ENI - All rights reserved