Comprendre l’intérêt de la méthode Agile

La méthode Agile, ou « approche », pour les puristes, est une méthode d’optimisation du travail de groupe, destinée à pouvoir résoudre n’importe quel projet complexe, et basée sur des cycles de tâches faites conjointement par un groupe de personnes.

Cet article n’a pas vocation à décrire les fondements de l’approche, ou en expliquer tous les aspects, des centaines de livres existent à ce sujet. Nous venons simplement vous en décrire notre vision, et notre façon de l’appliquer.

La méthode Agile, c’est quoi ?

Ce sont les développeurs qui sont chargés d’écrire en langage informatique tout ce qui se rapporte au site internet et aux applications. L’architecture du site doit être décomposée et sa construction distribuée entre les différents développeurs chargés de la construction du site.

Pour achever une mission de manière efficace, des développeurs on voulu penser une méthode où chacun agit de manière concertée, évalue son temps de travail nécessaire et met à jour ses tâches au fur et à mesure de la mission.

Il n’y a pas de perte de temps dans les prises de décisions et les échanges de mails, et la mission se passe sans ralentissements liés aux problèmes de communication.

La méthode Agile, c’est donc une méthode d’organisation, pour venir à bout de n’importe quel sujet complexe. C’est une méthode de concertation efficace que nous utilisons chez 69pixl, et qui nous permet de nous adapter au mieux aux besoins du client.

Qu’est-ce que ça change pour moi ?

La méthode Agile peut être définie comme une méthode de travail basée sur trois piliers essentiels : la flexibilité, le produit, et le besoin client.

Elle permet de développer votre projet par étapes, au lieu d’utiliser la méthode traditionnelle du cahier des charges. Cette dernière ne permet pas au client de revenir sur les premières indications au fur et à mesure de l’avancement du projet.

Avec la méthode traditionnelle, le client donne son cahier des charges, le produit est développé, et si le produit ne correspond pas totalement aux désirs du client, rien ne peut être fait.

Au contraire, avec la méthode Agile, notre cahier des charges s’adapte au fur et à mesure à la mission.

Pour vous, ça change tout : nous sommes au plus proche de vos besoins.

Comment se déroule une prestation basée sur la méthode Agile ?

Pour construire un site Internet, ou développer une application, on imagine d’abord quelle forme il aura (c’est le client, donc vous, qui décidez), et les développeurs se chargeront par la suite de lui donner corps.

Vous allez présenter des idées à votre agence de conseil en stratégie digitale, qui seront la plupart du temps sous cette forme :

“Je voudrais une plateforme, sous forme d’application web et mobile, qui permettrait à des photographes de s’inscrire pour être ensuite contactés par des personnes intéressés par leur clichés. Ces clients les trouveraient en fonction de leur zone géographique, de leurs intérêts, de leur spécialité, de leur portfolio et avis clients. Ils pourraient alors commander en ligne des missions qu’ils règleraient d’avance”, etc.

C’est ce qu’on appelle le récit utilisateur, et c’est en substance le type de demande qu’on nous formule, en langage humain.

Des mots clairs et des phrases construites qui expriment vos besoins, afin que l’agence digitale à laquelle vous allez faire appel puisse comprendre votre projet.

Attribution des tâches et définition des sprint

Une fois que vous nous avez livré votre récit utilisateur, c’est l’équipe Agile qui entre en action.

Une équipe Agile est composée de trois rôles différents : un product owner, un scrum master et une équipe de développement.

Leur importance et leur périmètre de participation sont clairement définis par la méthode, de telle sorte que le travail soit efficace.

Le product owner est le représentant du client auprès de l’équipe de développement. Il est responsable du succès du produit, et doit faire en sorte qu’il s’adapte au mieux aux besoins du client. Cependant, il n’est pas le supérieur hiérarchique de l’équipe de développement.

Le product owner va transcrire le récit utilisateur en tâches simples appelées backlogs, établies d’après le modèle « En tant que »; « Je souhaite »; « Afin de ».

Par exemple :

dans le récit utilisateur → “je voudrais mettre à disposition une foire aux questions sur la plateforme pour rassurer et informer les membres”

devient dans le backlog → “en tant qu’Administrateur, je souhaite pouvoir modifier le contenu de ma page FAQ afin de répondre aux questions les plus courantes ».

Un élément de « vérification » est alors induit. C’est en effectuant cette action que l’on pourra constater que cette tâche décrite dans le backlog a été réalisée, et est fonctionnelle.

Dans notre exemple précédent, cela pourrait donc être : « Accéder depuis l’interface Admin aux blocs questions/réponses et pouvoir en ajouter, en supprimer, en modifier. Ces changements seraient visibles en ligne après validation ».

Ces tâches simples sont classées par ordre de priorité et d’importance par le product owner, et regroupées entre elles pour former des sprints.

Un sprint correspond à une période de temps au bout de laquelle tel ensemble de tâches doit avoir été réalisé. Un sprint dure en moyenne une à trois semaines.

Le fait de décomposer ainsi un ensemble de tâches complexes en étapes simples va nous permettre de mieux quantifier le travail réalisé.

Il nous donne aussi l’occasion de revenir vers vous entre deux sprints, pour voir si l’avancement du projet vous convient toujours. Cela nous permet d’être au plus proche de votre demande, et d’avancer de manière concertée.

Evaluation de la durée des tâches

Avant de commencer la mission, les membres de l’équipe Agile de votre agence de développement sont amenés à évaluer le temps nécessaire pour effectuer chaque backlog. Ainsi, chaque membre attribue un nombre de points à chaque tâche qu’il est supposé faire.

Les points sont des évaluations de temps, qui peuvent être revues à la hausse ou à la baisse au fur et à mesure de la mission.

Avec cette quantification, le product owner construit la roadmap, qui est un planning du déroulement de la mission.

Estimation des coûts de la prestation

Le prix d’une mission réalisée avec la méthode Agile ne diffère pas nécessairement de celui d’une mission traditionnelle. Seulement, l’évaluation des coûts sera beaucoup plus facile avec la méthode Agile, et surtout bien plus adaptée aux évolutions de la maquette.

Pour une mission traditionnelle, l’estimation se fait en amont de la mission, en fonction de la durée moyenne d’une mission comparable, et des coûts habituels du prestataire. Par exemple, on aura un cahier des charges avec une estimation de 50 jours de construction du site, 10 jours de gestion et 10 de tests, le prix sera donc de X euros.

En méthode Agile, l’estimation de la durée des tâches permet d’évaluer plus précisément le prix final de la prestation. En effet, comme le projet est découpé en backlogs et chaque backlog associé à des unités de temps, on peut aisément associer chaque unité de temps Y à un prix Z. Le prix final ( Y x Z ) pourra donc être ajusté en cours de prestation si la durée des backlogs ont été sous ou sur-évalués.

L’évaluation du prix de la prestation est donc plus flexible et plus précise.

Déroulement de la prestation

Après un atelier ou une étude complète de la stratégie à appliquer par le pôle conseil de votre agence web, une fois le contenu des sprints défini et le temps de la prestation évalué, la mission peut commencer. Ici, c’est le scrum master qui entre en jeu. Son rôle est de faciliter le bon déroulement des tâches de l’équipe de développement.

Ce n’est en aucun cas le supérieur hiérarchique de celle-ci (Nous insistons sur l’absence de hiérarchie, car il est important que l’équipe de développement soit auto-organisée et non soumise à des ordres venus d’en haut. C’est ce qui fait la force de la méthode). Le scrum master gère aussi les relations de l’équipe avec l’extérieur, ainsi que les éventuels problèmes administratifs.

L’équipe de développement s’occupe alors d’effectuer et de terminer chaque tâche (aussi appelée item) pour pouvoir rendre un livrable à la fin du sprint.

L’équipe de développement est constituée de 2 à 10 personnes, et elle constitue un ensemble autonome et proactif. Les item qui ont été priorisés par le product owner vous sont livrés à la fin du sprint. Cela vous permet d’avoir un livrable plus régulier de votre produit.

Selon vos besoins, vos envies ou l’évolution du marché, vous pouvez alors donner de nouvelles indications au product owner pour qu’il adapte le sprint suivant.

Cette approche étant axée en priorité sur les besoins et le rendu optimal, il était évident chez 69pixl de l’appliquer sur les projets d’envergure. Envie de sprinter avec nous ?