Cinq idées reçues sur la méthode Agile

Publié le 04/11/2019 par Caroline Rousseau et Ankita Singh

Partager cet article

De nombreux mythes entourent les processus de gestion de projet agile. Ils peuvent rebuter certaines équipes et les empêcher d’adopter de nouvelles méthodes. Il peut être utile de démentir ces idées reçues afin que les collaborateurs travaillent plus efficacement et soient plus ouverts au changement. Sans cela, les projets agiles risquent d’échouer et d’avoir un impact négatif sur la productivité des équipes et, plus globalement, les bénéfices.

Header : les idées reçues sur la méthode Agile

Dans cet article, nous tordons le cou à cinq mythes qui empêchent généralement les équipes d’adopter la méthode agile en toute sérénité. Vous pourrez ainsi envisager le processus de gestion de projet agile dans sa globalité et comprendre les avantages du passage à l’agilité.

Cinq mythes répandus sur la méthode Agile

Infographie sur les mythes de la méthode agile

Idée reçue n° 1 : la gestion de projet agile n’implique pas de planification

Réalité : le modèle en cascade implique une planification en tout début de processus tandis que l’approche agile exige une planification constante tout au long du cycle de vie d’un projet. Les sprints sont programmés avant le lancement du projet. Un sprint correspond à une période donnée au terme de laquelle une activité ou une tâche doit être accomplie et révisée. L’équipe projet fixe la durée de chaque sprint et discute du travail à accomplir lors de chaque réunion de planification de sprint. De cette manière, tout le monde s’accorde sur le temps et le budget nécessaires ainsi que sur l’ampleur de l’activité afin d’éviter les malentendus.

Notre conseil : en bout de sprint, comparez les résultats atteints aux critères définis au départ (ampleur, temps, qualité) pour déterminer si le sprint est une réussite ou un échec. En cours de route, modifiez les sprints pour atteindre vos objectifs. Planifiez aussi la dette technique du projet (coût de la qualité du code) pour éviter de dépasser votre budget.

Idée reçue n° 2 : l’agilité ne convient ni aux grands projets ni aux travailleurs à distance

Réalité : la collaboration continue est un fondement de la gestion de projet agile. L’approche agile est aussi avantageuse pour les petits projets que pour les grands à condition que la communication soit fluide. Quelle que soit leur importance, les projets agiles sont menés par de petites équipes chargées de différents types de tâches qui collaborent tout au long du cycle de vie du projet. Ces équipes doivent collaborer fréquemment, ce qui n’implique pas forcément qu’elles se trouvent toutes au même endroit. Elles peuvent échanger et coopérer à distance grâce à des outils de collaboration et de gestion de projet.

Notre conseil : organisez une réunion scrum pour discuter de tous les scrums suivants et évaluer les équipes scrum. Vous pourrez ainsi mieux gérer les projets d’envergure et tenir tous les participants informés (en interne ou à distance).

Cela vous donnera aussi l’occasion de discuter des recoupements et des intégrations entre des projets plus larges. Si vous ne pouvez pas organiser de réunion en personne, retrouvez vos collaborateurs en ligne via des outils de communication équipés de fonctionnalités de partage d’écran et de visioconférence.

Idée reçue n° 3 : l’agilité est la solution à tous les problèmes

Réalité : la méthode Agile consiste en un ensemble de valeurs et de principes (dont la collaboration, le feedback rapide et la qualité) qui définissent la conduite fondamentale du processus de développement logiciel. Elle vous permet de déceler les problèmes avant qu’ils n’apparaissent. Vous pouvez ainsi prévoir des solutions et éviter les soucis de communication entre les personnes concernées.

Pour autant, la gestion de projet agile n’est pas la réponse à tous les problèmes de développement logiciel et elle ne convient pas aux projets nécessitant des itérations plus courtes. Parfois, les projets agiles échouent en raison de l’incapacité des participants à adopter une approche incrémentale.

Notre conseil : consignez les problèmes que votre projet agile rencontre tout au long de son cycle de vie ainsi que les solutions que vous y avez apportées. Votre équipe pourra se référer à ces archives (p. ex. études de cas) pour résoudre de futurs problèmes. Tentez d’associer approches agiles et non agiles pour obtenir des résultats plutôt que de submerger immédiatement votre équipe dans une nouvelle méthode radicale.

Idée reçue n° 4 : l’agilité est une question de rapidité

Réalité : L’objectif de la gestion de projet agile est de développer aussi rapidement que possible des produits satisfaisants pour les clients. La qualité et la rapidité des itérations sont donc essentielles. Les itérations courtes, ou sprints, assurent que chaque étape du développement de produit est planifiée, révisée et testée. L’approche agile n’est donc pas seulement une affaire de rapidité, mais aussi une question de qualité.

Notre conseil : tenez un journal pendant toute la durée du projet et prenez des notes sur les coûts, le temps et la qualité des activités et des résultats. Vous encouragez ainsi votre équipe à s’améliorer lors de chaque sprint et, avec le temps, vos collaborateurs apprendront à fournir constamment un travail de qualité tout en livrant plus rapidement. Continuez à les motiver pour vous assurer qu’ils apprennent petit à petit à travailler rapidement tout en atteignant le niveau de qualité requis.

Idée reçue n° 5 : les projets agiles n’impliquent pas de documentation

Réalité : les projets agiles ont besoin de documentation, mais sous la forme de courts récits utilisateurs sur les processus projet, les problèmes et les solutions. Dans l’approche agile, les équipes livrent rapidement et suivent des cycles de feedback courts qui mènent à des itérations et des modifications continues. Pour que personne ne prenne de retard ou ne rate une information essentielle, il faut une documentation conséquente.

Notre conseil : au cours du cycle de vie du projet, votre équipe devra peut-être changer pour assurer le développement fluide du logiciel et la satisfaction du client. Établissez une procédure de centralisation et de partage des documents contenant des informations à propos du produit et du projet en général.

Grâce à ce référentiel, rien ne se perdra si des membres de l’équipe tournent ou quittent le projet en cours de route et le processus restera fluide.

Méthodes de gestion de projets agiles

Après avoir dit adieu à ces quelques mythes, vous pouvez envisager d’appliquer certaines des techniques agiles suivantes

Méthode Scrum

Scrum est un modèle de gestion de projet agile allégé applicable à des projets itératifs et incrémentaux de tous types. C’est l’une des méthodes les plus répandues, puisqu’elle est utilisée par 56 % des organisations agiles (rapport en anglais).

Développement logiciel lean et Kanban

Le développement logiciel lean est une méthode agile itérative. Elle se centre sur la valeur ajoutée pour le client et sur l’efficacité de la “value stream”, soit le mécanisme qui permet d’atteindre la valeur visée.

Parmi les principes fondamentaux de la méthode lean, on peut citer l’élimination du gaspillage, l’extension de l’apprentissage, la prise de décision la plus tardive possible, la livraison la plus rapide possible, la responsabilisation de l’équipe, le développement de l’intégrité et la vision globale.

Kanban est une méthode de gestion de flux de travail très visuelle appréciée des équipes lean. Elle est basée sur trois principes : la visualisation des tâches du jour (flux de travail), la limitation de la quantité de travail engagée (le fameux “work in progress”, WIP) et l’amélioration du flux de travail.

Extreme programming (XP)

Extreme programming est une approche méthodique développée pour livrer rapidement et continuellement des logiciels de haute qualité. XP vise à renforcer la qualité des logiciels et la réactivité face aux demandes changeantes de clients.

La méthode s’appuie sur une plus grande implication des clients, un feedback rapide, un testing et une planification continus ainsi qu’un véritable travail d’équipe pour livrer des logiciels fonctionnels à intervalles réguliers (généralement en une à trois semaines).

Crystal

Les principes fondamentaux de la méthode Crystal sont le travail d’équipe, la communication, la simplicité et la réflexion. Ils permettent d’ajuster et d’améliorer fréquemment le flux de travail. Comme d’autres méthodes agiles, Crystal met l’accent sur la livraison rapide et fréquente de logiciels fonctionnels, une implication forte de l’utilisateur, l’adaptabilité et l’élimination de la paperasse et des distractions.

Dynamic systems development method (DSDM)

La méthode DSDM s’appuie sur huit principes fondamentaux : priorité aux besoins du client, livraison dans les temps, collaboration, priorité à la qualité, construction incrémentale sur des bases solides, développement par itérations, communication continue et maîtrise manifeste. Ces principes s’articulent autour des besoins et des valeurs du client, de l’implication active de l’utilisateur, de la responsabilisation des équipes, des livraisons fréquentes, du testing intégré et de la collaboration des personnes concernées.

Développement basé sur les fonctionnalités (feature-driven development, FDD)

La méthode FDD est un processus orienté modèle et axé sur des itérations courtes. Elle se base sur les meilleures pratiques du domaine du génie logiciel, dont le domain object modeling, le développement par fonctionnalités et la propriété du code. La caractéristique la plus intéressante du FDD est l’intégration de toutes ces pratiques dans une approche cohérente.

Étapes suivantes et ressources recommandées

Voici quelques mesures à prendre pour assurer l’adoption des processus agiles dans votre entreprise :

  • Personnalisez les processus pour mener à bien vos projets : appuyez-vous sur une méthode que vous comprenez et qui convient à votre PME. Vous devrez peut-être associer différentes approches pour atteindre vos objectifs. Adoptez celle qui convient à vos projets et à votre entreprise plutôt que de suivre les tendances ou dimiter vos pairs.
  • Adaptez les processus selon vos besoins : en tant que PME, centrez-vous sur les personnes plutôt que sur les procédures. Ne suivez pas aveuglément les principes agiles prescrits. Au lieu de fixer des réunions quotidiennes (stand up), retrouvez-vous deux fois par semaine quand tout se passe bien et deux fois par jour en cas de problème. Vous pouvez vous inspirer de quelques-unes des meilleures techniques agiles : planification de sprint et ditération, rétrospectives, révision de sprint et ditération ou encore itérations courtes.
  • Discutez régulièrement pour vous préparer à la disruption : testez les pratiques agiles avant de les rejeter dun bloc. Adaptez-les en fonction de votre expérience et revoyez constamment vos procédures pour livrer des résultats de qualité. Préparez-vous à de la disruption, de la discontinuité et de linconfort ; ils vont de pair avec ladoption de méthodes agiles en entreprise. Si la tâche devient trop difficile, interrogez-vous sur la valeur et les bénéfices que vous tirez de la disruption. Le jeu en vaut-il la chandelle ? Sachez que sans disruption, vous risquez dimplémenter et de suivre la méthode agile de manière incorrecte.
  • Désignez des coachs pour gérer la disruption et motiver votre équipe : gérez la disruption en organisant régulièrement des échanges au sein de vos équipes et avec lensemble de vos collaborateurs pour vous assurer de l’adhésion et de la motivation de tous. Vérifiez qu’ils comprennent bien que la disruption initiale implique une transformation radicale de tous les processus. Ils adopteront bientôt la nouvelle approche et les équipes projets s’y habitueront.

 

Partager cet article


This article may refer to products, programs or services that are not available in your country, or that may be restricted under the laws or regulations of your country. We suggest that you consult the software provider directly for information regarding product availability and compliance with local laws.