– Méthode Agile

Les méthodes Agiles privilégient :

  • Les individus et les interactions plutôt que les processus et les outils : le mode de travail de ces méthodes reposent avant tout sur le groupe d’individu, d’où le nom d’une des méthodes « Scrum » laquelle est avant tout un travail collectif qui permet d’atteindre l’objectif. La responsabilité devient donc collective, et de plus motivante.
  • Le produit opérationnel plutôt que la documentation exhaustive : La visibilité donnée au produit via les « sprint » (un sprint = un cycle de développement) qui délivrent sur des sessions un produit opérationnel à l’utilisateur. Voir et utiliser le produit rapidement est donc une source de motivation pour le client et l’équipe à poursuivre le projet. Cela permet d’être rassuré sur le travail effectué et sa qualité, de corriger les erreurs s’il y en a.
  • Collaboration avec le client plutôt que négociation : le client, dans une méthode prédictive est essentiellement présent lors du contrat, de la rédaction des spécifications et ensuite de la recette. Dans une méthode agile il occupe la place de « Product Owner ». Présent lors de chaque « sprint » il est celui qui définit les fonctionnalités prioritaires en fonction de leur valeur ajoutée (ROI) et tranche si besoin. Il devient ainsi membre à part entière de l’équipe tout au long du projet, son rôle est quotidien, il doit donc être capable de s’isoler du quotidien pour que la qualité du projet soit au rendez-vous. De même le « SCRUM Master », autre personnage clé, n’est pas un chef de projet mais un facilitateur qui veille au respect de la charte projet et vérifie que les équipes aient les moyens de leurs engagements pris pour chaque sprint.
  • Répondre au changement plutôt que suivre un plan : C’est le pilier conceptuel des méthodes agiles. Seuls les « sprint » dont la durée varie de 2 à 4 semaines en moyenne sont figés, avant, après les changements sont acceptés ! Quel soulagement pour un responsable métier qui a tant besoin de souplesse de la part de son équipe IT.

La logique est donc celle d’une amélioration permanente sprint après sprint pour arriver à un produit fini de qualité en adéquation avec le besoin utilisateur.
Une méthode qui implique des changements dans l’organisation quotidienne des projets.

Au quotidien, ces méthodes ont des implications sur l’organisation pratique des équipes.
Elles nécessitent par exemple:

  • Une équipe réunie physiquement au même endroit.
  • Une réunion ultra courte (15 min) mais quotidienne le « stand up meeting » (fini les discussions sur « c’est quand la prochaine réunion ? ») pour un point de partage sur le sprint en cours.
  • Un espace d’affichage partagé et visible qui permet la transparence sur les tâches à accomplir, celles réalisées et de visualiser le reste à faire ou « burndown chart ».
  • La standardisation de certaines tâches à basse valeur ajoutée pour l’équipe, par exemple l’intégration qui devient continue, ainsi que la systématisation des tests à plusieurs niveaux : en testant plus et différemment, l’anticipation des problèmes est plus rapide, la correction plus facilement réalisable: fini les recettes interminables pour les utilisateurs et les listes de bugs et d’évolutions infinies.

Beaucoup d’outils disponibles, personnellement, j’ai l’habitude d’utiliser la suite Atlassian, à savoir, jira pour la pour la gestion des demandes/évolutions et tickets/bugs, Confluence pour la gestion de contenu/documentation et surtout GreenHopper pour l’agilité.