Le concept de « développement Agile » peut revêtir différentes significations selon la personne à qui vous vous adressez. Pour certains, il s’agit d’adopter une approche de livraison plus pragmatique et de se détacher de la rigueur traditionnelle dans la planification. Pour d’autres, il s’agit plutôt une rigueur d’un autre genre qui est mise en place pour s’attaquer au carnet de produit plus efficacement; et de façon plus générale pour faire face aux constants changements des besoins d’affaires. Par ailleurs, l’un n’empêche pas l’autre.

Une chose est certaine : tout le monde s’entend sur le caractère changeant des besoins d’affaires. Dans l’univers du développement logiciel, il est devenu exceptionnel de ne pas subir une pression constante pour lancer de nouvelles versions et répondre aux demandes de changement de plus en plus rapidement.

Les utilisateurs et les parties prenantes sont changeants, ils présument certaines choses puis changent d’avis lorsqu’on leur livre ce qui a été demandé. Ce n’est pas systématique mais c’est très fréquent. Et finalement, est-ce vraiment leur faute? Il semble de plus en plus difficile pour un utilisateur final de déterminer ses besoins. Et c’est particulièrement vrai dans le cas d’applications dont les interfaces client s’insèrent dans un marché en constante et rapide évolution. Le virage numérique que connaissent de nombreuses industries rend dorénavant cette volatilité plus normale qu’exceptionnelle.

Laisser place à l’erreur

L’Agilité met de l’avant que c’est une des raisons pour lesquelles il faut adopter une approche plus itérative qui laisse place à l’erreur, une approche pour laquelle il n’est pas nécessaire de tout connaître pour amorcer le travail. Mais pour ce faire, il est tout de même fondamental de gérer les exigences efficacement. Lorsque ces exigences sont en constante évolution, il faut mettre en place des mécanismes pour faire face à cette incertitude.

Il existe divers outils qui permettent de gérer les exigences et les demandes de changement et de bien communiquer les dépendances, mais il est encore plus essentiel est de s’assurer qu’il n’y a pas d’ambiguïté dans ces exigences, même si elles sont appelées à changer. C’est un des principaux facteurs qui influencera la qualité et l’efficacité du logiciel livré.

Le caractère changeant des besoins ne justifie en rien que les développeurs fassent face à des demandes imprécises. Il est impératif qu’ils puissent concevoir et planifier leur développement minimalement, il en va de la viabilité du processus global.

Nous pourrions même dire que la capacité à capturer ce qu’on attend des développeurs (le problème que leur produit doit résoudre et comment il doit le faire) est le facteur le plus déterminant quant au succès du projet logiciel dans son ensemble.

Un des principaux objectifs de l’Agilité étant de permettre aux entreprises et à leurs équipes de développement de mieux servir les besoins de leurs clients, notamment en livrant des logiciels fonctionnels le plus rapidement possible. La gestion des exigences est donc centrale pour n’importe quel projet Agile.

À lire aussi : Le droit à l’erreur

Gestion des exigences

Une phase initiale permettant d’appréhender et dresser un portrait des exigences est essentielle. À cette étape, il n’est pas question d’établir le fonctionnement détaillé du produit final, mais plutôt de définir la portée du projet, ce qui permettra d’estimer la durée et le coût. On cherche à avoir une compréhension des objectifs d’affaires et de ce dont on a globalement besoin pour les atteindre.

Une fois que l’on a une bonne estimation globale des objectifs, des délais et des coûts et que l’on s’entend minimalement sur celle-ci, on peut passer à la mise en place d’une gestion Agile des exigences.

La première étape consiste à créer un carnet d’exigences (requirements backlog) qui regroupe notamment des scénarios utilisateurs permettant en quelques phrases simples de décrire comment l’utilisateur s’attend à ce que le logiciel fonctionne dans certaines circonstances. Le carnet peut également comporter des représentations visuelles, des diagrammes UML, des exigences fonctionnelles, etc.

En second lieu, on cherche à planifier et prioriser les exigences. Pour ce faire, on les met en relation avec la stratégie et les objectifs d’affaires pour estimer leur importance et l’effort requis pour les accomplir.

Finalement, on décompose ces exigences générales pour créer le carnet de produit (product backlog). C’est lors de cette étape que les exigences sont en quelque sorte traduites en véritables fonctionnalités et en tâches que les développeurs pourront entreprendre. Ces derniers doivent être directement impliqués afin qu’ils puissent comprendre ce qu’ils font et pourquoi ils le font.

Je terminerais en mentionnant qu’à travers tout ce processus, il demeure important d’inclure le client, l’utilisateur final. Une interaction avec celui-ci permet de toujours maintenir une compréhension de ses besoins fondamentaux. Évidemment, ces conseils ne sont qu’un aperçu de tout ce que la gestion des exigences peut impliquer et je vous invite à en apprendre plus en consultant les liens suivants :

http://webarchive.nationalarchives.gov.uk/20090127171527/http://www.ogc.gov.uk/delivery_lifecycle_requirements_management.asp

https://www2.cdc.gov/cdcup/library/practices_guides/CDC_UP_Requirements_Management_Practices_Guide.pdf

https://link.springer.com/chapter/10.1007/978-3-319-16101-3_6

gabriel bélanger

Billet précédent

Tension dans les équipes Agiles : Introduction

Billet suivant

Les conflits au service de votre succès

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.