Une méthode adaptée à vos besoins !
« La méthode agile garantit trois fois plus de réussite de projets de développement de logiciel par rapport aux méthodes classiques » (unow.fr)
Depuis 2013, nous utilisons cette méthode afin de vous impliquer au maximum dans le déroulement du projet et de répondre rapidement à vos attentes.
Notre méthodologie est articulée autour de la collaboration, de la transparence et de l’engagement avec nos clients.
Pour quels projets faut-il utiliser cette méthode ?
- Besoin rapide de mise à disposition du produit
- Imprévisibilité des besoins du client
- Nécessité de changements fréquents
- Besoin de visibilité du client sur l’avancement des développements
- Présence de l’utilisateur assurant un feed-back immédiat
Dès la phase commerciale, nous expliquons aux responsables du dossier le principe de l’agilité. Le client peut ainsi saisir tous les impacts de cette méthode.
Il doit par exemple ordonner dès la signature ses priorités : budget, qualité, délais ou fonctionnalités.
Nous réalisons également lors de cette phase la charte produit. C’est elle qui définit les objectifs du logiciel. Il peut s’agir d’améliorer un processus, apporter de la satisfaction, des fonctionnalités, etc.
Le cadre du projet étant défini, nous rencontrons les (futurs) utilisateurs de l’application à développer.
Lors de cette rencontre, nous présentons un résumé de la méthode Agile SCRUM pendant 1 h environ. Cette présentation est très importante puisqu’elle va permettre à tout le monde de bien comprendre ce qu’il sera possible de faire ou non. Les avantages et les inconvénients sont présentés en toute transparence au client.
L’outil de suivi (JIRA d’Atlassian) est également présenté avec ses fonctionnalités. Des identifiants de connexion sont fournis au client pour qu’il puisse suivre l’intégralité du projet. Nous apportons des conseils de suivi autour de la gestion des e-mails de notifications. À chaque fois que de nouveaux interlocuteurs sont intégrés dans le dossier, nous faisons une nouvelle présentation de la méthode.
Des réunions d’une demi-journée à une journée sont ensuite mises en place à la fréquence de 2 semaines à 1 mois. Lors de ces réunions, nous rédigeons les Stories, nous faisons les livraisons de sprint et nous planifions les étapes. En début de projet, nous rédigeons beaucoup de stories pour avoir une réserve de travail suffisante. Un minimum d’un mois est nécessaire pour que notre organisation soit sereine en interne.
Lorsque nous avons terminé le premier cycle (stories + développement), nous travaillons à nouveau sur le développement et sur les nouvelles stories pour alimenter les sprints suivants.
En parallèle de la rédaction des stories, nous faisons leur estimation avec l’équipe technique. Cette estimation se fait pendant des séances de 2 h à 4 h avec la méthode du Poker Planning. Nous distribuons un jeu de cartes spécifiques à chaque participant. Pour chaque story, le Product Owner Doing présente les attentes du client puis tout le monde peut soulever les problématiques et poser les questions qu’il a. Chacun choisit une carte qu’il place face cachée devant lui.
Cette méthode a l’avantage de permettre à toute l’équipe de s’exprimer puisque les cartes sont révélées après que tout le monde ait voté. Nous accordons beaucoup d’importance aux avis de tous pour respecter le bien-être de chacun. Chaque estimation est alors discutée et validée par l’équipe. Nous avons alors une estimation validée par toute l’équipe technique. De plus, cela nous permet parfois de lever des difficultés non prévues ou de simplifier des tâches trop complexes. L’estimation faite, le client peut alors choisir de mettre de côté des stories, de modifier ses attentes, d’ajouter des stories.
Il prend alors entièrement la mesure de son projet et en devient un acteur primordial. À chaque fin de sprint, une livraison est effectuée. Elle se fait soit chez le client lorsque des stories sont encore à écrire, soit à distance. Cette livraison est le moment de prendre les impressions des utilisateurs et les correctifs éventuels à apporter. Ces correctifs sont alors intégrés soit en tant que bug (sans impact financier), soit via des modifications ou des adaptations.
Ici encore, la transparence avec le client est importante. Le client connait dès le début les points autorisés, les points de chaque story, il peut les classer, il voit le suivi des problèmes… Pour les projets agiles, la livraison fait partie intégrante du processus de gestion de projet, car des livrables sont réalisés lors de chaque sprint de production.
