Gestion des exigences avec Microsoft Azure DevOps

Notre exemple de scénario se concentrera sur le développement d'une solution de mobilité que nous sommes en train de développer en tant qu'éditeurs de logiciels. L'objectif du projet est de développer une plateforme de mobilité permettant à nos clients d'améliorer leur expérience de voyage courte durée et de la combiner avec d'autres moyens de transport tout au long de la chaîne du voyage. Au cours de la première année du déploiement, au moins 200 trottinettes devraient être disponibles dans les villes pilotes, aucune perte ne devrait être enregistrée et au moins deux autres moyens de transport devraient être intégrés. L'accent est mis ici sur l'intégration transparente entre plusieurs fournisseurs et sur la facilité de manipulation des applications pour maximiser l'expérience client.

Avant de nous lancer dans la gestion des exigences avec Azure DevOps, nous créons un environnement de projet dans Azure DevOps en commençant par la page d’accueil du projet. Celle-ci offre une vue d'ensemble du projet et de son organisation à toutes les parties prenantes. Azure DevOps permet de créer des pages Wiki et de les utiliser pour créer des sites projets, qui peuvent être utilisés par exemple pour la description du projet, les objectifs, les personnes à contacter et les détails techniques des environnements. Pour notre projet « Seamless Mobility », nous avons créé le site projet suivant :

L'étape suivante consiste à concrétiser les objectifs du projet sous forme d'« Epics » (épopée), « Features » (fonctionnalités) et les premiers brouillons de « User Stories » (histoires utilisateur). Les epics, en particulier, établiront un lien direct avec les objectifs du projet. Par conséquent, il est recommandé de passer du plus simple (les objectifs du projet formulés sous la forme d'epics) au plus détaillé (les fonctionnalités attribuées et les user stories). Cette approche présente l'avantage que même les exigences à petite échelle peuvent toujours être attribuées à la vision du projet.

Dans notre exemple de projet, nous avons défini les epics suivantes :

• E-Scooter Provisioning (tout ce qui concerne la collaboration contractuelle avec un fabricant de trottinettes électriques, c'est-à-dire l'infrastructure générale)
• E-Scooter Booking App (l'application avec laquelle la trottinette électrique peut être réservée et avec laquelle des réservations combinées ultérieures peuvent également être effectuées, par exemple en combinaison avec un billet de train)
• Intégration d'autres prestataires (intégration technique avec d'autres plateformes de réservation telles que la SNCF ou Car2Go App)

Ci-dessous vous pouvez voir une structure possible basée sur les epics définies, qui sont affinées étape par étape dans les fonctionnalités et ensuite dans les user stories.

Lors de la description des exigences, nous recommandons que l'équipe projet maintienne une structure cohérente pour la saisie des données. Ceci permet de s'assurer que les exigences soient décrites de manière complète à tous les niveaux de détail (Epic, Feature et User Story). Les modèles tels que le modèle Epic de SAFe conviennent à cet effet. Azure DevOps offre la possibilité d'enregistrer des modèles pour faciliter l’élaboration de vos work items .

Dorénavant, si vous créez un nouvel epic, une fonctionnalité ou un autre work item, vous pouvez accéder à tout moment à vos modèles précédemment enregistrés pour le type de work item correspondant :

Sur le fond, on peut constater qu‘en plus de lier les exigences de haut niveau aux résultats des projets, il est aussi important de se concentrer sur les avantages pour le client et le produit à tous les niveaux de détail. Notre recommandation est de ne pas le faire pour tous les work items et pour tous les niveaux en détail - les raisons en sont l'assurance de la capacité de réagir aux changements dans le projet et la portée du produit ainsi que le fait d'éviter des discussions ou des chiffrages pour les user stories ou fonctionnalités qui ne pourront être réalisés du tout pendant la durée du projet. 

Une fois que les exigences ont été décrites et analysées en termes d'epics et de fonctionnalités, elles doivent être chiffrées. Comme méthode, un chiffrage d'expert ainsi que des estimations abstraites relatives (par exemple, les tailles de t-shirt) peuvent être utilisées pour comparer les epics et les fonctionnalités avec des solutions déjà mises en œuvre. Les estimations relatives ont l'avantage qu'elles peuvent souvent être effectuées beaucoup plus rapidement qu’un chiffrage classique. En utilisant des tailles abstraites, telles que les tailles de t-shirt, les détails manquants et le caractère incertain qui en découle sont pris en compte. Cependant, l'estimation est suffisante pour un premier chiffrage et une priorisation. Lorsqu'on utilise des estimations abstraites, il est important que l'équipe projet s'entende sur une compréhension commune, p. ex. S <= 4 semaines, M <= 8 semaines, L <= 16 semaines.
 
En plus d'estimer la charge, nous recommandons également d'estimer la valeur afin de comparer la charge et le bénéfice. Azure DevOps offre déjà de nombreux champs utiles pour la saisie des détails de planification. Il est facile d'ajouter un champ défini par l'utilisateur pour capturer une estimation approximative sous la forme de tailles de t-shirt. 

Une fois que les epics et les fonctionnalités clés ont été formulées, estimées et classées par ordre de priorité, elles peuvent être planifiées. Azure Marketplace offre une variété d'améliorations pour Azure DevOps (souvent gratuites). Il s'agit notamment de l'extension "Feature Timeline and Epic Roadmap", qui rend la planification de la feuille de route rapide et facile. 

Azure DevOps fournit une interface utilisateur intuitive et polyvalente pour la définition et l'analyse agile des exigences. Grâce à l'utilisation ciblée d'extensions, un grand nombre de cas d'application peuvent être réalisés rapidement et facilement, même sans un gros budget.