Placer le client au centre des démarches et des personnes. C’est l'objectif des méthodes de développement dites "Agiles".

De quoi s’agit-il ? Et surtout quels en sont les avantages et y a-t-il des inconvénients ou des risques d'échecs ?

Le manifeste Agile débute par 4 valeurs générales.
Ces 4 valeurs agiles sont transposables dans d'autres métiers que le développement informatique.

  1. Les individus et leurs interactions plus que les processus et les outils.
  2. Du logiciel qui fonctionne plus qu’une documentation exhaustive.
  3. La collaboration avec les clients__ plus que la négociation contractuelle.
  4. L’adaptation au changement plus que le suivi d’un plan.

Les 12 principes à suivre pour devenir une entreprise agile

Principe 1 : la satisfaction client avant tout

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ». Ce premier principe doit inspirer l’entreprise qui souhaite devenir agile en ajoutant au retour sur investissement classique la notion de valeur. En clair, même si une fonctionnalité ne fait pas gagner beaucoup de clients s’il elle a un impact sur son image c’est positif pour l’organisation.

Principe 2 : L’adaptation au changement, un avantage compétitif

« 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 ». Les équipes doivent pouvoir s’adapter rapidement aux demandes parfois contradictoires de ses clients ou de ses exigences du marché qui évolue de plus en plus vite. Dans ce contexte, le rôle de l’organisation est d’aider les équipes à adopter la culture de l’adaptation, plutôt que de les figer dans des process trop rigides.

Principe 3 : questionner régulièrement le positionnement de l’entreprise

« Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts », conseille Goji qui identifie 3 axes de vigilance : veiller à ce que les stratégies des collaborateurs soit bien en phase avec celle de l’entreprise, analyser régulièrement les besoins en compétences et faire remonter les points de blocage dans les déploiement des projets.

Principe 4 : mener les projets sur un mode collaboratif

« Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet ». C’est une condition sine qua non de réussite d’un projet. L’ère des managers ou des cadres qui décident seuls de la conduite à tenir est terminée. Il faut associer aux projets toutes les parties prenantes (y compris le client final) pour qu’une décision soit réellement applicable. Et les collaborateurs ont souvent le point de vue le plus éclairé sur les bons choix à faire sur un produit.

Principe 5 : impliquer les salariés

« 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 ». Pour impliquer les salariés, il est nécessaire de les écouter, les connaître et surtout, de leur faire confiance. L’engagement des salariés est facilité lorsqu’ils ont le sentiment d’être associés aux décisions et de faire partie d’un projet collectif.

Principe 6 : privilégier les échanges en face-à-face

« La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et au sein de celle-ci est le dialogue en face à face ». La surabondance de mails noie les collaborateurs dans un océan d’infobésité. Pour garantir une bonne communication interne, Goji propose une règle très simple : « au-delà de 3 e-mails, on se rencontre… »

Principe 7 : le plus important c’est que le produit fonctionne

« Un logiciel opérationnel est la principale mesure d’avancement ». Qu’importe les process ou les modalités de prise de décision, la meilleure mesure d’avancement d’un projet c’est de voir ses progrès opérationnels.

Principe 8 : savoir où on va

« Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant ». Plus facile à dire qu’à faire… A ce niveau, il est indispensable de rester maître du projet et d’avoir conscience de la charge de travail nécessaire pour atteindre ses objectifs. Ces derniers doivent aussi être atteignables, sous peine d’épuiser vainement les équipes.

Principe 9 : de la qualité et du sur-mesure

« Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité ». Le client est roi, ce n’est pas nouveau… la qualité du produit est essentielle, de même que la qualité de la relation avec le client. Il faut être proactif pour lui proposer du sur-mesure.

Principe 10 : faire simple

« La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle ». Combien de projets sont tombés à l’eau en raison de process abscons ? La méthode agile, à travers par exemple des scrums quotidiens, permet de contourner les blocages et supprimer des étapes superflues.

Principe 11 : laisser les équipes s’auto-gérer

« Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées ». L’auto-organisation en mode projet permet d’associer des prestataires externes en cas de besoin. L’équipe est la mieux placée pour savoir comment faire. Les managers ne sont pas là pour contrôler leur travail, mais pour aider à maintenir la cohésion.

Principe 12 : l’équipe doit pouvoir s ‘améliorer

« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence ». Une équipe autonome n’a pas besoin de consulter sa hiérarchie pour la moindre  des décisions. Elle doit également être en mesure de questionner son fonctionnement pour l’améliorer en permanence.


La méthode Agile est aujourd'hui très répandue dans les sociétés de services ou les agences web. J'ai souvent entendu qu'un des avantages de cette méthode était qu'on pouvait prendre ce qu'on voulait dedans, mais contrairement aux idées reçues, cette méthode ne portera ses fruits que si elle est respectée à la lettre. En effet, chaque étape est importante. Nous verrons ainsi les nombreux avantages ainsi que les inconvénients ou risques éventuels à utiliser cette méthode.

Principes de fonctionnement des méthodes «Agile"
 
Le principe de base des méthodes « Agile » est qu’il est contre-productif qu’avant de développer un produit, il faille le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas frustrations et pertes de temps car les aléas surviennent fréquemment. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser. Ainsi, au lieu de fixer les objectifs lointains, le mieux serait de procéder par étapes c’est-à-dire fixer des objectifs à court terme et commencer le développement sans perdre de temps. Chaque fois que cet objectif est atteint, on passe au prochain et ainsi de suite jusqu’à atteindre le but ultime. Au niveau d’un développement de logiciel, c’est le client qui transmet à l’équipe de développeurs sa vision du produit avec la liste des fonctionnalités qu’aurait ce produit. Il communique ainsi directement avec l’équipe et ensemble ils estiment le coût de chaque fonctionnalité pour aboutir à une idée approximative du budget final. De ce fait, on raisonne plus « produit » que « projet », d’où l’utilisation du terme « gestion de produit » au lieu de « gestion de projet ».
 
L’Agile manifesto 
 
Ces méthodes « Agile » se sont beaucoup développées et on a pu en recenser une dizaine de variantes jusqu’au début des années 2000. Conscientes qu’une certaine uniformisation était devenue nécessaire, 17 grandes figures du développement logiciel s’étaient réunies aux Etats-Unis en 2001 pour déterminer les critères communs et les principes fondamentaux de ce qui allait devenir un « Manifeste Agile ». D’après ce manifesto, les méthodes « Agile » demandent une plus grande implication du client et permettent une meilleure réactivité des développeurs face à ses demandes. Ce manifeste prône 4 valeurs fondamentales inhérentes aux méthodes « Agile » : l’équipe, l’application, la collaboration et l’acceptation du changement. De ces valeurs découlent 12 principes généraux qui se basent essentiellement sur une relation privilégiée entre le client et les développeurs. La priorité est ainsi donnée à la satisfaction du client et pour y arriver, une implication totale de l’équipe est requise. Cette équipe doit être capable de réagir très vite face aux éventuels changements requis par le client ou aux modifications de la méthode de travail face à des obstacles imprévus. Elle doit également être capable de se remettre en cause et de rechercher perpétuellement à évoluer.
 
La conception d’un produit « Agile »
La première étape consiste à effectuer une première planification de l’itération ou Sprint dans le jargon des développeurs. Cette réunion fera ressortir les éléments prioritaires de la liste des exigences fonctionnelles du produit. Chaque exigence représente une user storie (US) ou "histoire utilisateur". Une US doit être rédigée dans un bon français et décrit e fonctionnement ainsi que le parcours de l'utilisateur de la fonctionnalité. Elle doit également contenir les cas de tests ainsi que les critères de validation de la fonctionnalité développée.
 
En accord avec le client, aussi appelé Product Owner, les premières livraisons devraient être effectuées à la fin de cette itération (une itération à une durée d'environ 2 à 3 semaines suivant le nombre d'US présentent dans le backlog). Le backlog est l'ensemble des US à développer durant l'itération en cours.
Une autre réunion appelée Revue de Sprint est organisée à la fin de chaque Sprint durant laquelle les développeurs présentent au client les fonctionnalités développées. Ce dernier pourra ainsi tout de suite donner son feedback, ce qui présente l’avantage de gagner beaucoup de temps et d’ajuster les fonctionnalités ou les méthodes de travail le cas échéant.
Vient ensuite une rétrospective de Sprint qui permet à tous les acteurs d’améliorer des choses et de s’améliorer également. Une autre particularité de la méthode « Agile » est la réalisation de mêlées quotidiennes qui permettent à l’équipe de développeurs de synchroniser leur travail. Appelée aussi Stand Up meeting, cette réunion qui ne dure pas plus de 15 minutes permet à chacun de déterminer ce qu’ils ont réalisé depuis la dernière mêlée, de ce qu’ils auront à terminer avant la prochaine Stand Up meeting et d’identifier les obstacles qui pourraient les bloquer. En effet, les trois questions "phares" du scrum master sont :
  1. Qu'as tu fais hier ?
  2. Que vas tu faire aujourd'hui ?
  3. As tu des points bloquants ?
Quelques  outils d’aide à la gestion d’une équipe « Agile »
 
De nombreux outils d’aide à la gestion d’une équipe « Agile » ont fait leur apparition ces dernières années. On peut en citer pêle-mêle Agilefant, IceScrum, Agilo, eXPlainPMT ou encore XPlanner. D’autres sont apparus dernièrement comme le JIRA Agile qui a l’avantage d’être facilement utilisable même pour les débutants. Il permet d’élaborer des tableaux de tâches, de créer et d’estimer les user stories (US), d’identifier l’engagement et la vélocité de l’équipe ou encore de créer divers rapports sur l’état d’avancement des projets. En outre, un outil comme PMTool offre un large choix de rapports dans une interface simple mais très complète. Ainsi, les développeurs tout comme les chefs de projet (Scrum master) dispose d'une interface simple pour saisir leur feuille de temps et rendre compte de leurs activités. Un tableau de bord personnalisable est également disponible pour permettre à l’utilisateur d’avoir sous ses yeux les principaux indicateurs pour le suivi de son projet/développement tout en prenant en compte l'itération en cours. Les questions/incidents pourront enfin être gérés de manière très aisé car cette action est centralisée et se fait en un seul clic grâce à un menu très discret qui s'affiche partout (quel que soit la rubrique en cours de consultation). 
 

Conclusion

Avantages
  • Méthode fun !
  • Excellente réactivité vis-à-vis du client (product owners => PO)
  • Qualité accrue du fait de la présence des PO
  • Favorise et facilite la communication avec les autres membres de l'équipe
  • Développements hors sujet très peu probable
Inconvénients
  • Changement radical de gestion de projet/produit : fort impact sur tous les intervenants
  • Dans les grosses sociétés : collaboration/synchronisation difficile avec les autres équipes qui n'utilisent pas cette méthode. (délais différents donc réactivité plus longues)
  • Contraignante, surtout au début le temps que tout le monde s'y habitue.
  • Bonne volonté et bonne entente de tous les participants impératif.
  • Gros travail de rédaction pour les PO => création des "users stories" + cas de tests + critères de validation de l'US
  • Les développeurs doivent accepter le changement (revenir sur du code pour le modifier voir le supprimer).
  • Les développeurs doivent être autonomes (une équipe "Agile" doit être auto gérée)
  • La sociabilité doit être une qualité de tous les intervenants (communication)

Les commentaires sont fermés.

Fil RSS des commentaires de cet article