Vendre SCRUM à une équipe qui pratique le cycle en V
Un article de ODcWiki.
 Auteur : llaslaz.
|
Passer en mode SCRUM une équipe de développement de logiciel qui applique une méthode classique (de type cycle en V) est un challenge en vue d'une bien meilleure efficacité, mais nécessite de grands changements organisationnels et une remise en question des pratiques de l'équipe. Nous présentons dans cet article un bref résumé de la méthode, ses avantages, ses difficultés, et quelques recettes simples pour aider à franchir le pas.
Avant tout, quelques rappels essentiels liés aux spécificités du métier du développement de logiciel
- Chaque logiciel est unique tant d'un point de vue technique que fonctionnel. Pour répondre à un même besoin, il est possible d'utiliser des solutions très différentes.
- La méthode de travail doit être adaptée à la réalisation d’un nouveau produit complexe pour lequel il n'est pas possible de faire des spécifications fonctionnelles et techniques détaillées et exhaustives. Les tâches sont découvertes progressivement, les changements sont la norme et doivent être considérés comme une opportunité : un besoin, une solution technique qui n’ont pas été identifiés lors du lancement du projet, mais qui sont pertinents, doivent être pris en compte. A l’inverse, un choix non adapté doit être remis en question et retiré si nécessaire.
Ainsi, il importe que la méthode de travail permette à l’équipe de s’adapter aux changements et imprévus, qu’ils soient techniques, fonctionnels ou organisationnels (par exemple un changement de la constitution de l’équipe). Il est donc nécessaire d’utiliser des outils et une organisation qui permettent :
- D’optimiser le travail de l’équipe : faire ce qui est nécessaire et suffisant pour l’utilisateur, favoriser le partage des savoirs et des compétences et mettre en avant les compétences de chacun.
- D’établir un dialogue de qualité avec l’utilisateur: comprendre ce qu’il dit, parler un langage qu’il comprend et l’impliquer dans la réussite du projet.
- De s’organiser en s’appuyant sur des estimations fiables: un plan précis, mais faux, est plus qu’inutile : il est dangereux ! Il est important d’estimer la qualité de l’information dont on dispose.
Les méthodes de travail qui respectent ce besoin de grande réactivité sont appelées les méthodes agiles. Le « manifeste agile » formalise la notion d’agilité en la déclinant sous la forme de 4 valeurs et de 12 principes. Il est intéressant de présenter et parcourir avec les membres de l’équipe ces valeurs et principes afin de les sensibiliser sur les enjeux et réalités pratiques auxquels il est nécessaire de faire face dans le cadre du développement de logiciel.
Plusieurs méthodes agiles répondent à ce besoin d'agilité. SCRUM est l'une d'entre elles, particulièrement efficace et en fort essor à l'heure actuelle.
Quels sont les principes de SCRUM ?
Ils sont simples !
Les personnes qui interviennent sur le projet sont réparties en seulement 3 rôles :
- Le Product Owner ou directeur de produit : il représente les utilisateurs, définit et priorise les demandes produit.
- L’équipe SCRUM : équipe de moins de 7 personnes regroupant tous les rôles traditionnels : architecte, développeur, testeur, administrateur. Cette équipe développe le produit et se gère en toute autonomie.
- Le Scrum Master, qui n’est pas le chef de projet mais qui a un rôle de coach : sa mission est de tout mettre en œuvre pour que l'équipe travaille dans de bonnes conditions et se concentre sur l'objectif du projet.
Le Product BackLog liste les besoins produits. Il est géré par le Product Owner mais est partagé avec l’ensemble de l’équipe. Les besoins sont priorisés et l’accent est mis sur les besoins les plus prioritaires et devant être adressés à court terme. Ils sont associés à des critères d’acceptance qui permettent de définir, sans ambiguïté, les critères qui permettront de considérer que le besoin est couvert.
Le Sprint BackLog contient les tâches à réaliser durant une itération appelée Sprint.
Les Burndown Charts sont des graphiques permettant de suivre visuellement l’avancement du Sprint et de la Release (composée de plusieurs Sprints).
Les Sprints ont une durée fixe et se déroulent de la façon suivante :
- Chaque sprint commence par une réunion de planification appelée Sprint planning. A l’issue de cette réunion, l’ensemble de l’équipe connaît et comprend l’objectif du Sprint et chaque besoin, qui doit être adressé dans le Sprint, est décomposé en tâches.
- Durant le sprint, chaque membre de l’équipe prend une et une seule tâche dans le pool de tâches les plus prioritaires et effectue celle-ci.
- A heure fixe, un Daily Scrum (mêlée quotidienne) est effectué debout. Chaque membre de l’équipe prend la parole à tour de rôle pour indiquer ce qu’il a fait, ce qu’il va faire et les problèmes qu’il a rencontrés. L’objet de ce meeting est de faire un statut mais pas de résoudre les problèmes.
- En fin de Sprint, les besoins réalisés durant le Sprint sont montrés à travers l’utilisation du logiciel.
- La réunion de rétrospective est faite après la démonstration. Cette réunion a pour objet de lister les points qui ont bien fonctionné, ceux qui peuvent être améliorés et de convenir d’un ou 2 axes d’amélioration pour le prochain Sprint.
Qu'est ce qui différencie SCRUM des autres méthodes agiles ?
A la différence des méthodes UP ou XP, SCRUM met l'accent sur l'implication de chaque membre de l'équipe pour atteindre un objectif et non pas sur des pratiques de développement de logiciel.
Le Product Owner est fortement impliqué : il revoit les priorités et besoins à chaque Sprint et se focalise sur leurs valeurs business. L’équipe Scrum travaille de façon incrémentale avec des itérations time boxées. Ainsi, SCRUM permet de satisfaire le client en livrant tôt et régulièrement des logiciels utiles et de qualité (puisque composés de fonctionnalités terminées).
On retrouve dans SCRUM l'importance de la cohésion de l'équipe pour faire face aux difficultés qui vont être rencontrées tout au long de la vie du projet. Dans l'équipe Scrum, chaque membre de l’équipe est impliqué et a sa place dans le projet : les compétences, connaissances et avis de chacun sont importants et complémentaires. Cette organisation permet à chaque membre de l’équipe non seulement de remonter des besoins qui n’ont pas forcément été identifiés mais également de mieux comprendre les besoins et difficultés des autres membres de l’équipe. Par exemple, l’implication d’une personne en charge de l’exploitation de l’application permet à l’équipe de mieux comprendre et appréhender les besoins de monitoring ou de déploiement de l’application.
La responsabilité n'incombe plus à une seule et même personne mais est partagée entre le Product Owner, l'équipe Scrum et le Scrum Master.
Quel est l'intérêt de cette approche ?
L'équipe est très efficace !
Les membres de l'équipe sont impliqués donc amenés à collaborer ensemble, ce qui permet de partager la connaissance et d'éviter ainsi que l'équipe ne devienne trop dépendante d'une seule personne. Plusieurs personnes sont en mesure de prendre une tâche hautement prioritaire et sont ainsi capables de terminer une fonctionnalité.
Les livraisons régulières motivent l’équipe et l'impliquent dans la réussite du projet.
L'équipe travaille dans de bonnes conditions puisque le Scrum Master fait en sorte qu'elle ne soit pas perturbée par des éléments extérieurs au projet.
L'équipe livre régulièrement des fonctionnalités terminées ce qui permet :
- D'utiliser le logiciel en l'état.
- De mesurer la capacité de production (appelée vélocité) de l'équipe et ainsi d'ajuster la planification des fonctionnalités qu'il reste à implémenter.
Comment passer en mode SCRUM ?
Former l'équipe à SCRUM.
Rassembler l'équipe projet dans une seule et même pièce si cela est possible.
Mettre en place des outils et pratiques pour travailler efficacement en mode incrémental. SCRUM ne précise pas les techniques d'ingénierie du logiciel à utiliser. Une bonne pratique consiste à utiliser celles préconisées par XP notamment l'utilisation d'une plateforme d'intégration continue et le Test Driven Development (TDD).
Initialiser un Product BackLog en se concentrant sur les besoins les plus prioritaires. Mettre l'accent sur les critères d'acceptance de chaque besoin. Le découpage est un exercice difficile et pour lequel il est important de consacrer du temps puisque c'est à partir de ce découpage que l'équipe va travailler.
Se poser la question de la nécessité d'opérations faites habituellement en mode cycle en V tant d'un point de vue technique qu'organisationnel : nécessité d'un rapport, d'un document, etc.
Si le projet est en cours et a commencé en mode cycle en V : arrêter toutes les nouvelles tâches de développement et de spécifications et terminer en testant et intégrant les fonctionnalités commencées.
Les difficultés qui peuvent être rencontrées lors de la mise en place de SCRUM
La mise en place de SCRUM nécessite des changements et remises en questions. Il est important que l'équipe adhère aux choix qui sont faits et se les approprie.
SCRUM remet en question :
La façon de travailler de l’équipe :
- Les fonctionnalités sont priorisées et doivent être exprimées sous forme de besoins qui ont de la valeur pour l’utilisateur et qui sont adressables en un Sprint : trouver le bon niveau de granularité et le bon découpage demande de la pratique.
- L'équipe doit être capable de délivrer des fonctionnalités avec un coût de tests, de packaging et de déploiement acceptables. La mise en place de l'outillage peut nécessiter un effort important pour des projets existants ayant peu ou pas de tests automatisés ou des procédures de déploiement manuelles et fastidieuses.
- Des critères d'acceptance doivent être définis avant d'adresser le besoin. L'équipe doit s'habituer à terminer (en accord avec les critères d'acceptance définis) les fonctionnalités adressées avant d'en commencer d'autres.
L'organisation de l'équipe :
- Il faut faire accepter aux personnes la nouveauté. Elles ne travaillent pas exclusivement sur leur domaine de compétence ou selon leurs aspirations : par exemple, un développeur va être amené à contribuer aux tests pour atteindre l'objectif du Sprint. Son rôle ne se limite donc plus simplement à produire du code.
- Chaque membre n'a pas une liste de tâches affectées mais prend des tâches parmi les plus prioritaires tout au long du Sprint. Toutefois, il existe des limites puisque certaines tâches sont liées à un certain corps de métier et ne peuvent être réalisées par n’importe quel membre de l’équipe. C’est le cas, par exemple, des tâches de déploiements en production.
- Les membres de l'équipe qui avaient un rôle décisionnel (notamment le chef de projet) ou qui avaient obtenu un « titre » convoité depuis longtemps peuvent ressentir un sentiment de frustration.
- A l'inverse, les personnes qui ne sont pas habituées à se prononcer auront besoin d'une phase d'adaptation.
De ce fait, du temps et de l'adaptation à plusieurs niveaux peuvent être nécessaires pour obtenir une cohésion optimale de l'équipe. Pour passer outre ces difficultés, le rôle du Scrum Master est essentiel. Il doit pour cela :
- Etre à l'écoute de l'équipe et attentif aux obstacles rencontrés qui peuvent être de nature très variée (conflits internes, problèmes d'infrastructure, administratifs, etc.
- Faire appliquer les valeurs et les pratiques de SCRUM,
- Superviser l’activité de l’équipe,
- Communiquer au client l'avancement et les problèmes,
- Protéger l’équipe de tous les éléments perturbateurs externes,
- Encourager la coopération entre les personnes,
- Aider le Product Owner à sélectionner les fonctionnalités qui ont la plus-value maximale.
Quelles solutions peuvent être mises en place ?
Il peut être nécessaire de procéder par étapes, notamment lorsque l'équipe a un historique de cycle en V. Par exemple, la non affectation de tâches lors du Sprint Planning est sujet à discussion. Si, malgré une explication, la majorité de l'équipe n'est pas convaincue de l'intérêt de cette approche, il est possible dans un premier temps d'affecter les tâches lors du Sprint Planning. On démontre ainsi à l'équipe qu'en se focalisant sur les objectifs du Sprint, le turn-over des tâches est souvent tel qu'il n'y a pas d'intérêt à les assigner. Après quelques Sprints, il est plus facile de convaincre l'équipe d'essayer (et d'adopter :-) le fait de ne pas affecter les tâches.
Il est important que l'équipe essaye de nouvelles pratiques et se fasse un jugement après les avoir essayées : l'utilisation du tableau Scrum (qui contient l'objectif du Sprint, les tâches à faire, en cours et terminées) et du Planning Poker pour faire des estimations font partie des pratiques les plus courantes pour appliquer rapidement les valeurs et règles de SCRUM.
Pour conclure, bien que la méthode SCRUM réponde à des règles relativement précises, il est important de bien garder à l’esprit que chaque équipe, chaque projet et chaque contexte sont différents. La solution retenue sur un projet n’est pas forcément celle qui doit être appliquée sur tout autre projet. Le cadre de SCRUM est suffisamment large pour permettre à chaque équipe de trouver l'organisation et les solutions adéquates.
