Skip to main content

Utilisation de la méthode agile dans le cadre de projets non logiciels

Objectifs de formation

Après avoir terminé ce module, vous pourrez :

  • Décrire les valeurs et les principes des méthodologies agiles
  • Expliquer comment appliquer les valeurs et principes agiles à des projets non logiciels

Recherche de la bonne recette pour réussir votre projet

Cheffe de projet en train de cuisiner, avec des atomes de différentes tailles qui s’échappent de sa poêle en flottant

Crédit de l’image : Sergey Nivens/Adobe Stock

Si vous préparez un dîner, vous apprécierez peut-être de pouvoir vous appuyer sur une recette bien rédigée. Elle présente les ingrédients, les instructions et les conseils dont vous avez besoin. Cependant, il peut exister de multiples recettes pour un même plat. Par exemple, si vous cherchez sur Internet une recette de lasagnes, vous trouverez des centaines, voire des milliers de variantes. 

Qu’est-ce qui explique cela ? Cela est dû à des différences en matière d’expériences, de préférences et de circonstances. Si vous êtes un cuisinier expérimenté, vous préférerez peut-être la recette que vous utilisez depuis des années. Vous pouvez également préférer une recette qui demande moins d’efforts ou qu’il est plus rapide de suivre. En outre, il se peut que l’un de vos convives soit intolérant aux produits laitiers. L’expérience, les préférences et les circonstances jouent souvent un rôle déterminant dans le processus de préparation.  

La Walden University nous explique que les méthodologies et les approches de gestion de projet ressemblent à bien des égards à des recettes de cuisine. Elles comportent des étapes, des directives et des conseils nécessaires pour assurer la réussite du projet. Bien que les chefs de projet expérimentés puissent choisir une approche en fonction de leur expérience ou de leurs préférences, il est également important de prendre en compte les caractéristiques du projet et les circonstances dans lesquelles celui-ci s’inscrit. Cela se révèle particulièrement vrai dans le cadre de la gestion de projet agile.

Livre de recettes agile : le Manifeste agile

Un groupe de 17 développeurs de logiciels expérimentés a créé en 2001 le Manifeste agile comme moyen de résoudre les problèmes liés aux méthodes de développement de logiciels traditionnelles, en particulier le taux très élevé d’échec des projets de développement de logiciels. Ils ont défini quatre valeurs et 12 principes directeurs qui servent de fondement aux pratiques agiles. 

Valeurs agiles

À l’image des V2MOM de Salesforce, ces valeurs guident la manière dont les plans agiles sont développés et indiquent quels aspects doivent être prioritaires pour quiconque suit la méthodologie.

Des fiches de recettes présentant les quatre valeurs agiles répertoriées dans le module

  • Accorder plus d’intérêt aux individus et aux interactions qu’aux processus et aux outils
  • Accorder plus d’intérêt à la collaboration avec les clients qu’à la négociation de contrats
  • Accorder plus d’intérêt à l’adaptation au changement qu’au suivi d’un plan
  • Accorder plus d’intérêt à la création de logiciels efficaces qu’à la rédaction de documents détaillés

Principes agiles

  1. Notre priorité absolue est de satisfaire le client grâce à la livraison rapide et continue de logiciels porteurs de valeur.
  2. Accueillez à bras ouverts les changements d’exigences, même lorsque ceux-ci interviennent tardivement dans le développement. Les processus agiles tirent parti du changement pour renforcer l’avantage concurrentiel du client.
  3. Produisez sur une base régulière des logiciels efficaces, toutes les quelques semaines ou tous les quelques mois (de préférence selon un calendrier resserré).
  4. Les commerciaux et les développeurs doivent travailler de concert au quotidien tout au long du projet.
  5. Créez des projets autour d’individus motivés. Donnez-leur l’environnement et le soutien dont ils ont besoin et ayez confiance en leur capacité à mener les tâches à bien.
  6. La méthode la plus efficace pour communiquer des informations à une équipe de développement et favoriser les échanges en son sein est la conversation en face à face.
  7. L’efficacité des logiciels est la principale méthode d’évaluation des progrès.
  8. Les processus agiles promeuvent des pratiques de développement pérennes. Les commanditaires, les développeurs et les utilisateurs doivent pouvoir maintenir indéfiniment un rythme de travail constant.
  9. Le fait d’accorder une attention continue à l’excellence technique et à la qualité de conception améliore l’agilité.
  10. La simplicité (à savoir l’art de maximiser la quantité de travail qui n’est pas à faire) est essentielle.
  11. Les meilleures architectures, exigences et conceptions sont l’œuvre d’équipes qui s’organisent en autonomie.
  12. L’équipe doit réfléchir à intervalles réguliers à la manière de devenir plus efficace, puis ajuster son comportement en conséquence.

Bien que conçue à l’origine pour améliorer le développement de logiciels, la méthode agile convient à de nombreux environnements. Les entreprises adoptent de plus en plus cette méthode pour améliorer la productivité et les performances dans l’ensemble de leur structure. 

Examinons un exemple de projet dont les résultats diffèrent selon qu’il est géré selon la méthode traditionnelle et la méthode agile.

Surprise !

Votre organisation organise une journée portes ouvertes pour présenter son nouvel immeuble de bureaux. Les employés sont très enthousiastes à l’idée de voir ce nouveau bâtiment dont ils entendent parler depuis plusieurs années. D’après ce qu’ils ont entendu, les espaces de travail sont modernes et ont une conception flexible qui peut être facilement modifiée pour favoriser une plus grande collaboration entre les équipes. Les dirigeants de l’entreprise étaient particulièrement fiers de la conception de l’espace nommé « avenue des responsables », où toutes les portes demeurent ouvertes pour garantir une meilleure communication entre les responsables et les employés.

En tant que chef de projet responsable de la conception et du développement de l’avenue des responsables, vous étiez impatient de voir leurs réactions. Vous vous attendiez à des félicitations pour cette conception innovante. Vous n’étiez pas prêt, cependant, à voir le groupe de responsables observer les lieux en silence, laissant apparaître leur déception.  

Que s'est-il passé ? Vous et l’équipe de projet avez travaillé en étroite collaboration avec un architecte et un entrepreneur en bâtiment pour planifier le projet. Ils disposaient d’un plan de projet complet qui a été suivi étape par étape. Chaque tâche a été effectuée, le projet s’est terminé dans les délais et le budget a été respecté. Cela signifie que le projet a été une réussite, n’est-ce pas ? Malheureusement, non.

Examinons la situation dans un contexte de gestion de projet traditionnel.

Série d’icônes représentant les phases du cycle de vie de la gestion de projet : Lancement (fusée), Élaboration du plan (porte-bloc), Exécution (pelleteuse), Surveillance et contrôle (dessin de tête avec un engrenage) et Clôture (cadenas). Le titre de l’image est Cycle de vie du projet.

La gestion de projet traditionnelle s’appuie fortement sur une documentation exhaustive. Il est présupposé que toutes les exigences du projet sont connues et définies avant le début des travaux. Le client ou l’utilisateur final est impliqué dans la phase de planification pour définir les exigences. Il peut recevoir des rapports sur l’état et les performances du projet, mais il ne voit le résultat définitif que lorsque celui-ci prend fin. Surprise ! 

En matière de satisfaction client, ce projet n’a pas répondu aux attentes.

Application de la méthode agile

Avec la méthode agile, au contraire, les processus d’échange de commentaires intégrés permettent une collaboration étroite avec le client et donnent la possibilité d’intégrer des changements rapidement et facilement sans impact sur les délais et les coûts.

Série de trois icônes de boucle intitulées Cycle 1, Cycle 2 et Cycle 3 représentant la nature itérative du processus de gestion de projet agile. Elles sont chacune accompagnées d’opportunités d’examen et de création.

En quoi le résultat du projet de conception d’espaces de travail aurait-il été différent si une approche agile avait été utilisée ? Examinons un exemple.

Cycle 1

Le premier cycle implique l’équipe de projet, les responsables qui occuperont le nouvel espace, l’architecte qui concevra l’espace et l’entrepreneur en bâtiment. Le livrable attendu de ce cycle est un prototype dessiné du nouvel espace qui répond aux exigences du client. 

Les responsables font part de leurs besoins. L’architecte recueille les exigences dans le logiciel de conception et présente à l’équipe un prototype dessiné de la conception. L’entrepreneur en bâtiment fournit des informations concernant le respect du code de la construction qui doivent impérativement être prises en compte. L’architecte modifie la conception pour se conformer au code de la construction. À la fin de la session, tous les intervenants s’accordent pour dire que le résultat attendu a bien été atteint.

Cycle 2

Le même groupe se retrouve pour le deuxième cycle. Cette session a pour objectif que l’entrepreneur en bâtiment puisse proposer un modèle 3D de l’espace de travail. L’architecte fournit le dessin le plus récent de l’espace. L’entrepreneur en bâtiment apporte un modèle préliminaire. Après examen de ce modèle, les responsables remarquent immédiatement un problème.

Les espaces avec portes ouvertes destinés aux responsables ne permettront aucune intimité. Les responsables doivent pouvoir parler avec les employés en privé, et le fait de les obliger à trouver une salle de réunion pour mener de telles discussions pose problème. L’architecte et le constructeur proposent une conception modifiée. Le modèle 3D est mis à jour, et tous s’accordent sur la nouvelle conception.

Cycle 3

Lors du troisième cycle, l’entrepreneur en bâtiment fait intervenir une équipe chargée de construire partiellement le nouvel espace. Pendant que les ouvriers procèdent aux travaux, l’entrepreneur en bâtiment examine le modèle 3D avec l’équipe de projet et y intègre quelques petites modifications demandées par les responsables. L’équipe de construction obtient le feu vert pour continuer. 

L’équipe de projet a maintenant la possibilité de voir l’espace et de donner une dernière fois son avis avant que la phase finale de construction débute. Les responsables sont satisfaits du résultat, car leurs commentaires ont été pris en compte et leurs exigences sont satisfaites. 

En changeant votre « recette » de gestion, vous avez réduit le risque d’avoir une mauvaise surprise le jour de l’ouverture. Ouf !

Votre projet est servi

Il n’existe pas de recette unique qui fonctionne pour tout le monde, car l’expérience, les préférences et les circonstances varient. Pour ces mêmes raisons, il n’existe pas d’approche de gestion unique qui fonctionne pour chaque projet. Dans le cadre de projets qui peuvent bénéficier d’une approche itérative faisant la part belle au changement et axée sur la création de valeur pour le client, il peut s’avérer intéressant d’avoir recours à la méthode agile. Malgré le fait qu’il s’agisse d’une approche initialement dédiée au développement de logiciels, de nombreuses organisations trouvent les avantages de la méthode agile tout simplement trop attrayants pour être ignorés.

Grâce à la Walden University, vous connaissez maintenant le cycle de vie des projets et les différentes méthodologies que vous pouvez appliquer pour les gérer. Dans l’unité suivante, vous allez consolider ces acquis en apprenant comment vous pouvez vous assurer que votre projet est porteur de valeur pour votre organisation.

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires