L'agile
Pourquoi faire de l'agile ?
Une question qu’on a souvent entendue mais à laquelle on n’a pas toujours de réponse.
Ce petit article vise à vous aider à y répondre en vous donnant les principales clefs de compréhension et un si court article ne saurait être exhaustif. Gardez à l’esprit qu’il est à destination des personnes qui ne sont pas familières avec l’agilité et qu’il représente également ma vision des choses.
Déjà, qu’est-ce que l’agilité ?
Avant tout, l’agilité est un état d’esprit.
En pensant agile, on ne se dit pas “Est-ce que le résultat de mon projet va respecter le cahier des charges”, mais plutôt “Quelle sera la valeur ajoutée pour le client ou l’utilisateur” !
Afin de remplir ce rôle, il existe différentes méthodologies et frameworks, qui sont également souvent ré-adaptés au contexte de l’équipe ou l’entreprise. Leur rôle va être de fournir un ensemble d’outils afin de justement atteindre cet objectif de valeur maximale.
Voici les principales valeurs fondatrices de l’agilité :
- Aux individus et leurs interactions plutôt qu’aux processus et aux outils ;
- A un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;
- A la collaboration avec les clients plutôt qu’à la négociation contractuelle ;
- A l’adaptation au changement plutôt qu’à l’exécution d’un plan.
Mais alors, concrètement, quels sont les gains de l’agilité ?
D’abord, une équipe agile est très souvent multidisciplinaire. Elle inclut l’ensemble des rôles nécessaires au projet. Ce qui favorise déjà grandement la communication. L’inclusion de toute l’équipe à toutes les phases permet également de rapidement lever les risques et les difficultés.
L’agilité va généralement s’articuler autour de cycles de développement courts (entre 2 et 4 semaines). Ces cycles incluront généralement toutes les étapes du build, de la rédaction du besoin (User Stories) jusqu’à la Mise En Production (MEP).
Ces cycles courts ont plusieurs avantages.
Le premier est de permettre une vision à court ou moyen terme.
Si vous spécifiez de manière détaillée toutes vos fonctionnalités pour les prochaines années, il suffit d’un changement de direction de l’entreprise, de retours clients, d’une nouvelle technologie…. et une bonne partie sera à jeter ou à revoir complètement. En ne spécifiant de manière détaillée que les mois à venir et en gardant le reste très macro, vous limitez le risque de travail inutile.
Un autre biais des cycles longs est l’Effet Tunnel. En réceptionnant un cahier des charges, vous développez l’application en ligne droite sans la remettre en question. Mais êtes-vous sûr que la direction montrée par cette spécification soit la bonne ?
Au hasard, le client pourrait mal connaître son besoin, l’avoir mal exprimé, il peut avoir changé, vous pourriez l’avoir mal compris, vous pourriez l’avoir mal exprimé dans vos propres spécifications, les développeurs pourraient l’avoir mal compris…
J’imagine que vous avez compris où je voulais en venir. Un projet, c’est beaucoup d’Humain, et, malheureusement, un humain fait des erreurs. Voir ce décalage entre le besoin et la réalisation entraînera soit un surcoût à posteriori, soit un mécontentement de la part du client.
C’est pourquoi les méthodologies agile recommandent des démos très régulières. Elles permettent de faire le point sur ce qui a été développé pour rapidement pouvoir s’adapter en cas d’inadéquation. Elles ont aussi le bon goût de rassurer votre sponsor sur l’avancement de l’équipe.
Un autre avantage de ces cycles courts avec MEP est de permettre un Time to Market très rapide. A chaque fin de sprint, les évolutions et correctifs sont déployés, et pas 6 mois plus tard.
Si (et seulement si) votre équipe à une maturité suffisante, vous pourrez même opter pour le déploiement continu, et vous ferez le plaisir de votre client.
Ce que l’agilité n’est pas !
Attention, il y a souvent une grande confusion entre Agilité et Bazar !
L’agilité demande énormément de rigueur et la capacité à dire “Oui, mais on retire quelque chose” au client.
Sauf extrême urgence, on ne change pas le contenu d’un sprint au milieu de celui-ci.
L’agilité c’est l’adaptation, mais ce n’est pas gratuit. Si le client souhaite ajouter une toute nouvelle feature dans un sprint futur, sur le principe l’équipe est ouverte, mais elle viendra prendre la place d’un autre développement. La priorisation devra être adaptée à cet ajout.
Il faut savoir expliquer au client, que l’agilité est plus une obligation de moyens que de résultat.
Si le client veut un produit précis et à une date précise, vous pourrez appliquer certains des préceptes de l’agilité, mais pas tous.
En conclusion.
Même si cet article reste à la surface des choses, j’espère vous avoir apporté quelques clefs pour comprendre l’agilité. Néanmoins, même si je suis convaincu par ses bienfaits, le plus important pour vous sera d’avoir une méthodologie projet qui fonctionne avec le contexte et le client.
CROXO Ewald
Chef de projet