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.
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
Mise en place des sprints Chapitre 4 103 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.
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 http://agilemanifesto.org/iso/fr/principles.html). 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
Mise en place des sprints Chapitre 4 105 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... 3. 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.
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