Agilisons ! – L’agilité en sous-marin

Comment transformer de l’intérieur un projet « traditionnel » en y mettant de l’agilité, encore plus d’agilité, toujours plus d’agilité !

Vous avez lu de nombreux articles sur le sujet, sur des sites, des blogs, dans des magazines. Vous avez acheté des livres, vous les avez même lus jusqu’au bout ! Vous avez assisté à des conférences, peut-être suivi une formation, obtenu une certification… C’est bon, vous êtes parés, vous connaissez le manifeste Agile par cœur, Scrum et XP n’ont plus aucun secret pour vous, cette fois, c’est dit, votre prochain projet sera Agile !

Oui mais…

Oui mais voilà, ça ne passe pas. Le client est frileux, il trouve que c’est trop d’engagement de sa part. La hiérarchie ne veut pas suivre, si ça n’a pas 30 ans d’ancienneté, ça n’a pas fait ses preuves. La MOA n’y croit pas, encore une idée de la MOE pour ne pas faire son travail.

Alors que faire ? Laisser tomber, et repartir dans un énième projet en cycle en V, ses effets tunnels, et son pourcentage d’insatisfaction indécent ? Peut-être pas…

En effet, les pratiques utilisées dans les méthodologies Agiles peuvent être classées (pour simplifier) en deux groupes : celles définissant l’organisation du projet, et celles définissant l’organisation de l’équipe de développement.  Et en tant que chef de projet, rien ne vous empêche de mettre en place de nombreux éléments de cette deuxième catégorie, pour améliorer la motivation et le travail de votre équipe, et peut être, à terme, basculer réellement en mode Agile.

Dans une première partie, nous nous intéresserons à un ensemble d’éléments pouvant être mis en œuvre facilement, et indépendamment les uns des autres. Dans une deuxième partie, nous étudierons une démarche progressive visant à convaincre le client des avantages de l’agilité. Ces divers éléments sont du ressort de l’organisation interne de l’équipe, et de ce fait peuvent être mis en place sans accord explicite de la part de la hiérarchie, du client ou de la MOA. Il faudra toutefois s’assurer l’adhésion de l’équipe.

Première partie – Agilisons l’équipe

Le but est ici, en appliquant différentes pratiques issues des méthodologies Agile, indépendantes les unes des autres, d’augmenter l’efficacité, l’implication et la qualité du travail de l’équipe.

L’ensemble de ces pratiques est bien connu de ceux ayant déjà quelques connaissances dans les méthodologies Agile. Nous ne les présenterons pas en détails, et nous bornerons à expliquer la manière dont elles peuvent être intégrées à des équipes « classiques ».

Double casquette

Dans ce qui suit, nous allons principalement faire référence à une des méthodologies Agile les plus répandues, Scrum. Un des rôles définis en Scrum est celui de Scrum Master. Si dans un projet Agile, ce rôle peut être tenu par n’importe quel membre de l’équipe, dans notre exercice, il sera plus simple que le chef de projet porte cette casquette. Plus simple, et surtout moins perturbant que ce soit pour l’équipe, si cette dernière n’est pas familiarisée avec la méthodologie, ou pour les autres intervenants qui pourraient être amenés à interagir avec vous durant le projet.

Il vous faudra donc faire preuve d’un peu de schizophrénie, en agissant comme un Scrum Master au sein de votre équipe, et en présentant un visage de chef de projet au reste du monde.

Protéger l’équipe

Une des tâches du Scrum Master est de protéger l’équipe de développement des perturbations extérieures. Il vous incombe donc d’assumer ce rôle. Ainsi, charge à vous de canaliser les communications entrantes, de servir d’interface avec le monde extérieur, d’empêcher que le client vienne directement demander à tel ou tel développeur une modification de dernière minute.

Le but du jeu n’est bien évidemment pas de centraliser une quelconque forme de pouvoir décisionnaire, mais de protéger au maximum les développeurs pour les laisser faire leur travail sans perturbation extérieure, sans qu’ils soient obligés de passer continuellement d’une tâche à une autre, et sans qu’ils soient forcés de se débattre entre des sollicitations contradictoires et non priorisées.

Stand-up meeting

On ne dira jamais assez les bienfaits que peut présenter une simple réunion quotidienne de 15 minutes. Cette réunion est très facile à mettre en place, et apporte de nombreux avantages en terme de partage d’informations et de cohésion d’équipe.

Attention cependant, sous son apparente facilité de mise en œuvre, il faut prendre garde à certains pièges, pour éviter que cette réunion ait un effet contre-productif. Il est donc primordial de bien expliquer l’esprit et le but du stand-up meeting, plus que sa forme, surtout pour une équipe sans expérience dans l’agilité. Insistez bien sur le fait qu’il ne s’agit pas d’un « flicage », et que l’on doit s’adresser à l’ensemble de l’équipe.

Enfin, le stand-up est le moment idéal pour encourager les développeurs à faire preuve d’initiative, ce qui nous amène directement à :

Inciter la prise d’initiative

Un des facteurs de réussite d’un projet, quelque soit son mode de gestion, est l’implication des différents participants. Dans un projet traditionnel et fortement hiérarchisé, il est habituel que le chef de projet distribue les différentes tâches aux développeurs, en fonction de leurs compétences, et parfois aussi en fonction de leurs envies. Un des leviers pour augmenter l’implication de l’équipe est de favoriser la prise d’initiative. Ainsi, les développeurs ne vont plus se voir assigner des tâches, mais vont les choisir eux-mêmes parmi les tâches définies comme prioritaires par le chef de projet. Ce choix, idéalement fait lors du stand-up meeting, peut être très motivant, le développeur s’engageant personnellement sur la réalisation d’une tâche.

Attention, il est possible (et même probable) qu’au début, il faille un peu aiguiller les membres de l’équipe, les pousser à choisir si ces derniers ont l’habitude de structures fortement hiérarchisées, mais rassurez-vous, une fois qu’ils auront compris qu’ils ont la possibilité de choisir, l’habitude prendra, et l’habitude restera !

White board

De la même manière que le stand-up meeting, le white board est un élément très facile à mettre en place. Il permet de suivre facilement l’avancée du travail de l’équipe entière, il est le lieu privilégié du stand-up (il est en effet beaucoup plus simple de tenir ce genre de réunion autour d’un white board que devant un écran, la communication en est simplifiée) et il permet l’affichage de divers indicateurs (de type « burn down chart »).

Et on ne parlera jamais assez du plaisir du développeur déplaçant sa tâche dans la colonne « Fait » !

Rétrospective

Là encore, un outil simple à mettre en œuvre. Plusieurs articles de ce blog traitant déjà de la rétrospective, je n’entrerai pas plus dans les détails, je me permettrai juste d’insister sur un point : une équipe peu au courant de ce genre de pratique pourrait considérer qu’il s’agit là d’une perte de temps. Il est donc indispensable de sortir de chaque réunion avec un plan d’action clairement défini, et d’acter, lors de la réunion suivante, que le plan d’action a bien été déroulé.

Pair programming

Débattre de la pertinence d’un projet fait intégralement en pair programming n’est pas le sujet de cet article. Il est de toute manière peu probable qu’un client, déjà peu enclin à des expérimentations méthodologiques, voit d’un bon œil l’ensemble de l’équipe travailler de cette manière. Cependant, il peut être très intéressant de favoriser ce type de pratique ponctuellement, dans de nombreux cas de figure : intégration d’un nouveau membre de l’équipe (pour par exemple, lui faire comprendre l’architecture du programme), montée en compétence d’un junior sur telle problématique technique ou fonctionnelle, programmation d’un service métier particulièrement complexe, résolution d’un bug ardu…

Le pair programming peut être un outil extrêmement efficace dans de nombreuses situations, et permet de créer du liant et de la cohésion au sein de l’équipe, et donc de l’efficacité. Il doit donc être très fortement encouragé par le chef de projet. Normalement, après quelques incitations explicites, l’équipe devrait prendre elle-même l’habitude de recourir à cette méthode.

Conclusion intermédiaire

Ces quelques pratiques empruntés à l’agilité, assez simples à mettre en place, devraient vous aider à améliorer l’implication et l’efficacité de votre équipe, et par la même, vous permettre d’envisager sereinement l’étape suivante : démontrer l’utilité de l’agilité.

Deuxième partie – Agilisons le client

Dans cette deuxième partie, nous allons être un peu plus ambitieux. Nous allons décrire un processus en 5 étapes à mettre en place par le chef de projet pour convaincre le client de l’utilité de travailler en mode agile. Les différentes actions peuvent être cependant assez complexes à mettre en œuvre. Il est tout à fait possible de ne pas utiliser l’intégralité du processus et de s’arrêter à une étape intermédiaire, le travail de l’équipe s’en trouvera de toute manière amélioré.

Triple casquette

Dans la première partie de cet article, nous avons expliqué que vous alliez devoir porter deux casquettes. Espérons que votre tête est suffisamment large, car nous allons en rajouter une troisième. En effet, en plus des rôles de chef de projet et de Scrum Master, il va falloir assumer le rôle de Product Owner. Les puristes de Scrum objecteront qu’il est impensable, dans un projet, que les rôles de Scrum Master et de Product Owner soient tenus par la même personne. Et ils auront tout à fait raison. Pour être précis, on parlera ici d’assumer une certaine partie du travail du Product Owner.

Dans un véritable projet Agile, le rôle du Product Owner est de définir le périmètre fonctionnel du projet, de l’exprimer sous forme de User Stories et de les ordonner. Dans notre cas, le périmètre fonctionnel est déjà défini par le cadre rigide des spécifications il va donc falloir que le chef de projet traduise ces spécifications sous forme de User Stories, et fixe des priorités. C’est ce que nous allons détailler dans la suite de cet article.

Créer les User Stories

Lors d’un projet « standard », le chef de projet va avoir à sa disposition, pour pouvoir mener ses développements, un ensemble de spécifications générales ou détaillées, qu’elles soient techniques ou fonctionnelles. Pour faciliter le suivi du travail, il peut être intéressant de ne pas découper le travail en tâches techniques (coder la couche de persistance, développer l’interface graphique…), mais plutôt en User Stories, décrivant une action fonctionnelle unitaire du début à la fin. Une User Story doit de plus pouvoir être développée intégralement en une unique itération (voir plus bas).

Cette tâche, si on veut la mener à bien de manière exhaustive, est loin d’être évidente. En effet, les spécifications vont décrire un certain nombre d’écrans ou de fonctionnalités, et la relation entre ces items et les User Stories n’est pas immédiate, un item pouvant concerner plusieurs User Stories, et une User Story nécessiter la mise en œuvre de plusieurs items. Ce travail peut sembler fastidieux, il est néanmoins indispensable à la suite du processus.

Une fois le découpage fonctionnel effectué, l’ensemble de l’équipe va pouvoir déterminer la complexité de chaque User Story, dans la plus pure tradition Scrum, c’est-à-dire via le Planning Poker. Cette étape est aussi intéressante dans le sens où elle va potentiellement permettre d’identifier les manques ou les imprécisions dans les spécifications, à remonter au plus tôt au client. Il est aussi possible, lors de cette étape, de remarquer des incohérences dans le chiffrage (ce qui peut aussi être détecté lors de la définition des itérations, cf. plus bas). Quelque soit le problème identifié, il ne faut jamais hésiter à le remonter. Un des grands principes inhérents à l’Agilité est la transparence, et votre honnêteté et votre volonté à ne pas cacher les problèmes jouera en votre faveur quand vous demanderez à votre client de s’investir dans les étapes ultérieures.

Les User Stories définies, le chef de projet va pourvoir identifier des priorités, ce qui nous amène directement à :

Identifier les priorités

En s’aidant de sa connaissance du projet, de son bon sens, et en se renseignant éventuellement auprès du client, le chef de projet devrait être à même de classer les User Stories par ordre de priorité. Cette priorité n’a aucune valeur engageante auprès du client. Il va juste être question de pouvoir séquencer les tâches au sein du long tunnel que propose le cycle en V.

Attention cependant si vous décidez de solliciter le client pour établir les priorités : vous risquez d’obtenir une réponse du type « tout est prioritaire ». En effet, de nombreuses personnes ont pour réaction instinctive de penser que ce qui n’est pas en haute priorité ne sera jamais fait. Donc, d’une part l’information que vous récupérerez risque de ne pas être pertinente, et d’autre part, vous risquez de semer le doute et la crainte dans l’esprit du client, ce qui n’est clairement pas le but que nous recherchons. Toute sollicitation du client à ce stade devra donc être effectuée avec la plus grande prudence, et dépendra de votre client, de sa maturité et de la nature de la relation que vous entretenez avec lui.

N’oubliez pas non plus qu’il peut y avoir des dépendances entre les User Stories, ce qui doit bien évidemment jouer dans l’établissement des priorités. D’autre part, gardez à l’esprit que l’objectif va être de proposer des livrables intermédiaires, ce qui devrait vous inciter à regrouper les User Stories pouvant interagir les unes avec les autres à des niveaux de priorité équivalents, pour garantir la livraison d’un produit partiel, mais cohérent et utilisable.

Si nous avons des User Stories, et qu’elles sont priorisées les unes par rapport aux autres, alors il ne nous reste plus qu’une chose à faire :

Travailler en mode itératif

Nous avons une liste de User Stories. Nous avons des priorités. Nous avons une estimation faite par l’équipe, en terme de complexité, des différentes User Stories. Nous avons donc tous les éléments à notre disposition pour travailler en itérations.
Le travail en itérations est très structurant pour l’équipe. Il permet d’éviter un effet assez commun quand la deadline est très distante, qui est de travailler en sous capacité en début de projet, pour terminer en journées infernales, la fin du projet approchant. Le mode itératif permet de répartir de manière régulière la charge de travail et d’éviter (ou d’amoindrir) l’effet « rush » de fin de projet, connu aussi sous le nom de syndrome de l’étudiant.

Le but d’un travail itératif n’est pas de maintenir une pression constante sur l’équipe, mais de pouvoir répartir la charge de manière équitable, en permettant à l’équipe de travailler en permanence de manière soutenue mais supportable et ce, sur une durée indéterminée.

Pour ce faire, la durée de l’itération doit être suffisamment courte pour ne pas elle-même souffrir d’un mini effet tunnel. On trouvera généralement des itérations d’une durée de 2 à 4 semaines. A vous de trouver le rythme qui convient le mieux à votre équipe. Même si plusieurs durées peuvent être essayées, il est cependant important d’arriver rapidement à une durée d’itération fixe pour une meilleure structuration du travail. Pour un premier essai, 2 semaines est un choix pertinent, vous permettant de balayer sur un délai court toutes les étapes d’une itération, ce qui peut être intéressant pour présenter rapidement à une équipe novice la manière de fonctionner en Agile. Libre à vous ensuite d’adapter la durée de l’itération au rythme de votre équipe et de votre projet.

L’équipe va donc décider des User Stories à embarquer pour l’itération, en se servant du chiffrage en terme de complexité et des priorités. Chaque story sera découpée en tâches techniques (développer l’interface, le service métier, la couche de persistance, les tests…), toujours par l’équipe, tâches qui pourront, éventuellement, être chiffrées en terme d’heures. Cette étape récurrente peut, elle aussi, servir de système d’alarme pour remonter au plus tôt les inadéquations entre le chiffrage initial fait à partir des spécifications, et la réalité du terrain, estimée par l’équipe.

Ce sont les tâches ainsi définies qui apparaîtront sur le white board, une User Story n’étant considérée terminée que quand l’ensemble des tâches afférentes se retrouve dans la colonne « fait ».

Note : suivant la nature de votre projet, il est possible qu’une première itération, dite itération zéro, soit nécessaire pour mettre en place l’environnement technique nécessaire au développement de l’application.

Au final, le fait d’avoir découpé le projet en User Stories va permettre d’avoir, à la fin de chaque itération, un produit présentant un certain nombre d’éléments fonctionnels complets et aboutis. Et si on a, toutes les deux semaines, une application qui fonctionne, il serait dommage de la garder pour soi :

Démonstration à l’équipe

Toutes les fins d’itération, organiser une présentation à l’équipe du travail accompli va permettre là encore d’impliquer ses différents membres. La démonstration permet en effet de montrer l’avancée du projet de manière très concrète. C’est le moment pour l’équipe de se congratuler avant de partir pour une nouvelle itération. C’est aussi le moment idéal pour prendre du recul sur le l’itération écoulée et faire une rétrospective.

Mais si le logiciel est suffisamment abouti pour être présenté à l’équipe, il peut tout aussi bien être présenté à d’autres personnes.

Démonstration au client

En effet, il peut être très intéressant de convier d’autres personnes à la démonstration de fin d’itération. Suivant votre organisation, le directeur de projet, la MOA, le client, le sponsor… N’importe qui d’impliqué dans le projet, d’autant plus avec un rôle décisionnaire, devrait se voir convier à la présentation. D’une part, il est toujours gratifiant pour l’équipe de montrer le travail accompli, d’autre part, il peut être rassurant de dissiper les inquiétudes générées par le fameux effet tunnel.

Quelques précautions à prendre cependant : vos interlocuteurs ne sont pas habitués à ce type de fonctionnement, ni peut-être à s’impliquer autant sur un projet. Il est peut être préférable d’attendre quelques itérations avant la première démonstration, histoire d’avoir quelque chose d’un peu consistant à montrer. D’autre part, attention à l’effet démo. Une présentation ne s’improvise pas, elle se prépare. Et ne montrez que ce qui fonctionne à 100%, en insistant bien sur ce qui est développé, pas sur les parties manquantes. A ce stade, le moindre message d’erreur pourrait se montrer extrêmement contre-productif. Dans le même état d’esprit, ne laissez pas la souris au client : assurez vous-même la manipulation, ou faites-la effectuer par un membre de l’équipe, en ne déviant pas du scénario défini au préalable.

Et enfin, ce type de démonstration peut amener des discussions très intéressantes pour notre objectif : le produit présenté, bien que pleinement conforme aux spécifications, peut ne pas correspondre exactement aux attentes du client, la démonstration peut donner de nouvelles idées à la MOA, ouvrir de nouvelles perspectives quant à ce que devrait être le produit, ou permettre au contraire d’identifier des fonctionnalités au final inutiles.

Malheureusement, la méthodologie qui est utilisée pour gérer le projet ne va pas permettre de s’adapter facilement à tous les changements que vos démonstrations précoces auront pu susciter, le client n’étant probablement pas d’avis, dès le début du projet, de partir en réécriture de spécifications et négociations d’avenants.

Heureusement, vous avez, par le plus grand des hasards, une proposition très intéressante et structurée à faire, qui est justement pensée pour répondre à ce genre de problématique : agilisons !

Nombre de vue : 35

AJOUTER UN COMMENTAIRE