Lorsque des développeurs informatiques se sont réunis en 2001, partant du constat que le cycle de développement traditionnel des logiciels ne correspond plus aux contraintes et aux exigences des organisations en évolution rapide, ils ont rédigé le Manifeste Agile.

Ce document décrit l’état d’esprit “agile” à avoir pour travailler autrement afin d’être plus flexible et réactif face à des changements qui arriveront inévitablement.

Le document est découpé en 2 parties :

Ce document décrit la philosophie agile est à la base de toutes les méthodologies de gestion de projet dites agiles.

​​Devenir un chef de projet efficace et performant, ça t'intéresse ?

​Accède dès maintenant à ton guide GRATUIT pour devenir un chef de projet efficace et performant.

Les 12 principes de l’agilité

La philosophie agile, à la base des méthodes de gestion de projets agile, se compose de 12 principes fondateurs, articulés eux-mêmes autour de 4 piliers.

Ces 4 valeurs de l’agilité sont :

  1. Les individus et leurs interactions plus que les processus et les outils.
  2. Un logiciel fonctionnel plus qu’une documentation exhaustive.
  3. La collaboration avec les clients plus que la négociation contractuelle.
  4. L’adaptation au changement plus que l’exécution d’un plan.

Les 12 préceptes agiles ci-dessous offrent tous des exemples concrets de la manière dont l’agilité doit être implémentée en entreprise.

1 ) Satisfaire le client en priorité

Voici le principe en entier :

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

En gestion de projets classique, le produit final, le logiciel développé, est livré à la toute fin du projet, après des mois de développement. C’est seulement à ce moment-là que le client peut voir ce pour quoi il a payé, en espérant que cela corresponde à son besoin initial.

On l’a vu, les organisations sont évolutives, et cette manière de faire n’est plus adaptée à un besoin en perpétuelle évolution.

Vu qu’on ne peut pas garder un projet “ouvert” et en éternel développement (je rappelle que tout projet doit avoir une date de fin)pas le choix : il faut faire autrement !

L’agilité propose de fonctionner par itérations successives, pour délivrer par couche successive le produit aux utilisateurs. On développe fonctionnalité par fonctionnalité, on livre les bouts de produits au fur et à mesure au client, ce qui permet d’avoir les retours des utilisateurs sans attendre et de développer au fur et à mesure les corrections.

On gagne ainsi de nombreux mois et on raccourcit le temps avant utilisation des fonctionnalités.

Mon conseil : Garder des itérations courtes afin de pouvoir être réactif face aux évolutions. 1 à 2 semaines par itération est cohérent.

2 ) Accueillir favorablement les demandes de changement

Voici le principe en entier :

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Le changement n’est pas négatif, il est inévitable et est synonyme d’opportunités, afin d’apporter encore plus de valeur au client final.

D’où l’importance de procéder par itérations successives, d’obtenir du retour utilisateur (le fameux feedback), et de corriger / améliorer les fonctionnalités au fur et à mesure.

En livrant tôt une fonctionnalité, elle peut être juste passable. Mais en apportant régulièrement les modifications nécessaires selon les retours utilisateurs, à la fin du projet, on se retrouve avec une fonctionnalité correspondant exactement au besoin utilisateur.

Avec les méthodologies classiques, à la fin du projet on se retrouverait avec la même fonctionnalité d’un niveau passable. Au mieux.

Mon conseil : Si une itération est démarrée, on ne peut pas modifier son contenu, mais on peut ajouter les évolutions à traiter dans les prochaines itérations.

3 ) Livrer le plus souvent possible des versions opérationnelles de l’application

Voici le principe en entier :

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Pour les projets complexes (durée supérieure à quelques mois), on a l’habitude en gestion de projet traditionnelle de tracer ce qu’on appelle un diagramme de Gantt, pour visualiser l’enchaînement du projet, l’ordonnancement des tâches et leur planification.

Selon la philosophie agile, c’est du flanc ! ça ne sert strictement à rien, et ça voudrait dire que le plan est déjà tracé et qu’il ne peut y avoir aucun changement, aucune évolution.

Sauf qu’on embrasse le changement !

Du coup mieux vaut se concentrer sur des itérations plus courtes, d’1 à 2 semaines. De livrer à la fin de chaque itération les nouvelles fonctionnalités développées et de les faire tester aux utilisateurs. Puis d’intégrer leur retour dans les itérations suivantes.

Mon conseil : Abandonne l’idée du diagramme de Gantt en gestion de projet Agile, tu vas t’arracher les cheveux après avoir atteint la version 92. Concentre-toi sur le planning de l’itération en cours, et ce que tu vas intégrer dans la suivante. Pour le reste, il y a la roadmap.

4 ) Assurer une coopération permanente entre le client et l’équipe projet

Voici le principe en entier :

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Le problème c’est que l’utilisateur parle “métier” alors que le développeur parle “technique”. Et ces deux mondes parlent rarement le même langage et considère que l’autre est ne comprend rien à rien et ne sert à rien.

C’est en partie vrai. Mais travailler de manière Agile les oblige à s’entendre et à travailler et collaborer ensemble.

Quant au fait de parler le même langage, le chef de projet joue le rôle de traducteur : il traduit les demandes métiers en besoin technique pour les développeurs, et traduit les explications techniques en terme métiers compréhensibles des utilisateurs.

Mon conseil : Toujours reformuler ce que disent les développeurs ou les utilisateurs, pour être sur d’avoir bien compris et de bien retransmettre le message.

5 ) Construire des projets autour d’individus motivés

Voici le principe en entier :

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

Gérer un projet en mode Agile implique de faire confiance par défaut. Bien sûr qu’un chef de projet doit garder un minimum de contrôle pour s’assurer que l’on ne parte pas à l’opposé du besoin initial.

Mais …

Il ne doit en aucun cas dicter aux autres quoi faire, ou vouloir forcer une organisation précise. Une équipe agile s’auto-organise : chacun sait quel rôle il a à jouer.

Pas de temps à perdre dans les conflits d’ego, ici on se concentre sur le développement et la valeur à apporter.

Mon conseil : Hors de question de faire du micro-management et de vérifier que chacun à fait la tâche qui lui incombait. C’est le résultat de l’itération qui permettra de mesurer l’avancement du projet ainsi que le succès.

6 ) Privilégier la conversation en face à face

Voici le principe en entier :

La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

,Ici le principe est simple : on réunit l’équipe (ce qui inclus le chef de projet) au même endroit. On peut réserver par exemple une salle de réunion pour la durée du projet.

Adieu les envois de mails intempestifs contenant 5 documentations à lire, et les 340 allers-retours à gérer. Exit les réunions d’équipe.

En travaillant tous au même endroit, les questions fusent, on échange en direct, on obtient ses réponses en direct, on gagne tous du temps.

Et tout le monde sait sur quoi l’autre travaille et quelles sont ses problématiques actuelles.

Mon conseil : Tous les matins, fais un point d’équipe de maximum 5 minutes pour que chacun indique ce qu’il va faire le jour même et quelles sont les problématiques rencontrées actuellement. ça permet rapidement de savoir où se concentrer le matin tout en créant une cohésion d’équipe.

7 ) Mesurer l’avancement du projet en termes de fonctionnalités de l’application

Voici le principe en entier :

Un logiciel opérationnel est la principale mesure d’avancement.

En gestion de projets classique, on mesure souvent l’avancement d’un projet au nombre de tâches traitées. Ce qui est profondément idiot.

On ne devrait pas piloter un projet au nombre de tâches traitées, mais à la qualité du travail réalisé. C’est l’essence même de ce septième principe.

L’avancement du projet se déduit par la valeur apportée aux utilisateurs. Par le taux d’utilisation des fonctionnalités livrées.

Mon conseil : Ne pas hésiter à solliciter les utilisateurs finaux pour aller chercher leur feedback, avoir leurs retours et avis sur les fonctionnalités livrées. On a tous tendance à se réveiller lorsque ça ne marche pas mais à faire les sourds-muets lorsque tout va bien.

8 ) Faire avancer le projet à un rythme soutenable et constant

Voici le principe en entier :

Les processus Agiles encouragent un rythme de développement soutenable.

En gestion de projet classique, c’est souvent le rush dans les dernières semaines pour finir le développement d’un logiciel et le livrer dans les temps.

Puis on se rend compte qu’il ne correspond pas aux besoins et il faut redévelopper les améliorations nécessaires. Avec un budget serré. Un coût serré. Donc des délais serrés. Et les développeurs sont pressés comme des citrons.

L’agilité permet d’éviter cela, en fonctionnant par itérations successives : le travail s’étale mieux dans le temps.

En plus, pouvoir livrer des fonctionnalités rapidement et avoir les retours positifs des utilisateurs alors que le développement est toujours en cours permet de garder ses équipes motivées et engagées.

Mon conseil : Partager et célébrer tous les retours positifs obtenus avec l’équipe. Il n’y a pas de petites victoires.

9 ) Porter une attention continue à l’excellence technique et à la conception

Voici le principe en entier :

Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

En clair, le neuvième principe demande de faire preuve de rigueur au quotidien pour fournir un produit à forte valeur ajoutée en sortie.

La rigueur doit se situer à plusieurs niveaux :

  • Déjà, en respectant scrupuleusement la méthodologie de gestion de projets choisie.
  • Ensuite dans le développement même : par exemple le code informatique doit être commenté pour être compréhensible, indenté (structurer pour plus de lisibilité), propre.
  • Enfin, les tâches à effectuer dans le cadre de l’itération doivent être respectées. Si l’itération est commencée on ne peut plus apporter de modifications à celle-ci, mais aux suivantes oui.

Mon conseil : Ne jamais faire d’écart par rapport à la méthodologie retenue, et ne pas hésiter à faire des rappels à l’ordre pour garder cette rigueur intacte au niveau de l’équipe.

10 ) Faire simple

Voici le principe en entier :

La simplicité, c’est à dire l’art de minimiser la quantité de travail inutile, est essentielle.

L’objectif est simple : simplifier au maximum tout ce qui peut l’être.

On ne traite que les tâches importantes et utiles. On garde les documentations simples. On ne fait des réunions que si c’est absolument nécessaire. On ne réinvente pas la roue non plus.

Mon conseil : Laisse l’équipe s’auto-organiser et juger des réunions nécessaires ou non.

11 ) Responsabiliser les équipes

Voici le principe en entier :

Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.

Responsabiliser ses équipes, c’est les laisser travailler en autonomie, leur laisser leur indépendance sur la manière de travailler, d’organiser les tâches entre elles. C’est leur laisser le champ libre pour prendre des initiatives en cas d’imprévus.

Mon conseil : Hors de question qu’un acteur remonte au chef de projet un problème en attendant qu’il trouve la solution et lui dise quoi faire. Chacun est responsable, chacun connaît son métier, chacun est en capacité de prendre des initiatives.

12 ) Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace

Voici le principe en entier :

A intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace.

Comme le dit si bien Ron Wallace, “une fois qu’on fait quelque chose bien, il faut recommencer du début et chercher à le faire encore mieux.”

C’est le principe même de l’amélioration continue : toujours chercher à s’améliorer, à gagner du temps, sur tous les sujets.

C’est la clé des équipes performantes.

Mon conseil : Prévoir un point d’amélioration continue 1 à 2 fois par mois pour lister les points sur lesquels s’améliorer, et travailler dessus jusqu’à la réunion suivante.

Conclusion

L’Agilité est une vraie force dans notre monde et nos organisations en perpétuel changement, en perpétuelle évolution.

Avant d’être une méthode, c’est un état d’esprit, structuré par 12 grands principes :

  1. Satisfaire le client en priorité.
  2. Accueillir favorablement les changements.
  3. Livrer le plus souvent possible les versions opérationnelles de l’application.
  4. Assurer une coopération permanente entre client et équipe projet.
  5. Construire des projets autour de personnes motivées.
  6. Privilégier la conversation aux réunions.
  7. Mesurer l’avancement du projet en terme de résultats.
  8. Faire avancer le projet à un rythme soutenable.
  9. Porter attention à la rigueur et l’excellence.
  10. Faire simple.
  11. Responsabiliser les équipes.
  12. S’améliorer continuellement.

Que penses-tu de ces principes ? Comment se passe la mise en place de l’agilité dans tes équipes et ton entreprise ? Fais-nous part de ton retour d’expérience dans les commentaires.

Thibault

​A propos de l'auteur

Chef de projet IT depuis 2008, j'ai travaillé sur des projets à plusieurs millions d'euros. J'ai décidé de dépoussiérer la gestion de projet. Exit les méthodologies complexes, exit les outils lents, lourds, complexes à utiliser. Mon objectif ? Te donner les clés pour piloter tes projets avec efficacité.

​Tu aimeras aussi :

​laisser un commentaire

​Ton adresse mail ne sera pas visible. 
​les champs marqués avec un * sont oblgiatoires.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

​Découvre les meilleures astuces pour devenir un chef de projet performant.

Transforme ton prochain projet en succès !

0 Partages
Partagez
Tweetez
Partagez
Enregistrer