Ingénierie des exigences dans un contexte agile 02 2016
1. Ingénierie des exigences
dans un contexte agile
Comment mettre en œuvre une démarche d’ingénierie
adaptée aux spécificités de l’agilité ?
Stéphane Badreau
Consultant & Formateur
06 60 53 54 42
stephane.badreau@compliance-consulting.fr
www.compliance-consulting.fr
2016-02 1
2. Ingénierie des Exigences
Démarche méthodologique qui consiste à construire un
référentiel d’exigences et à le maintenir à jour en présence
d’évolutions
Ensemble d’activités, de techniques et d’outils permettant de
développer et de gérer les exigences
Plusieurs principes d’ingénierie basés sur une collaboration
et une communication efficientes entre les parties prenantes
2016-02 2
3. Principes de l’Ingénierie des Exigences
Séparation du domaine du problème (du client) et du domaine
de la solution (du fournisseur)
Collaboration à plusieurs niveaux
Construction itérative et incrémentale d’un référentiel
d’exigences structuré
Communication des exigences à l’aide du langage naturel et
de la modélisation
Réduction progressive de l’espace de la solution
2016-02 3
4. Manifeste Agile – Valeurs
2016-02 4
La collaboration avec les clients
Plus que la négociation contractuelle
Les individus et leurs interactions
Plus que les processus & les outils
L’adaptation au changement
Plus que le suivi d’un plan
Des logiciels opérationnels
Plus qu’une documentation exhaustive
5. Pourquoi l’agilité ?
Faire face à un marché en constante évolution et à des
besoins des utilisateurs changeants rapidement
Pouvoir livrer périodiquement et fréquemment un produit
opérationnel afin de s’assurer qu’il répond bien aux besoins des
utilisateurs
Pouvoir recueillir un feedback de la part des utilisateurs du
produit
Améliorer la collaboration et la communication entre les
équipes assurant la définition et la réalisation du produit
2016-02 5
6. Spécificités de l’ingénierie des exigences
dans un contexte agile
Ce qui est différent d’une approche classique :
Le périmètre du produit va évoluer très souvent pendant toute la
durée du projet, seuls le budget et le délai sont fixés
Les activités d’ingénierie ne sont pas menées avec la même
intensité
Les techniques sont plus orientées vers la créativité et les jeux
Les outils utilisés ne sont pas identiques
Les rôles des acteurs du projet sont différents ; le « chef de
projet » et l’« analyste des exigences » disparaissent au profit du
Product Owner dans Scrum
2016-02 6
7. Les points d’attention
La capitalisation autour du référentiel d’exigences, si celle-ci
est nécessaire, doit être abordée de manière différente.
La traçabilité entre les exigences et les différents artefacts doit
être gérée de manière spécifique.
Les exigences non fonctionnelles ne doivent pas être
oubliées du fait de l’approche orientée utilisateur, qui va
privilégier l’aspect fonctionnel.
L’accostage avec d’autres projets ou d’autres organisation qui
ne sont pas forcément en mode agile.
2016-02 7
8. Ebauche d’une démarche
Définition de la vision du produit
Identification des parties prenantes et de leurs objectifs
Identification des usages et des features
Construction d’une feuille de route (Story Map)
Construction du Backlog du produit contenant des features
Construction du Backlog d’itération contenant des User Stories
Priorisation des User Stories
Estimation des User Stories et sélection des US pour les itérations
A la fin de chaque itération, mise à jour du Backlog d’itération en
fonction des User Stories terminées
A la fin de chaque version, mise à jour du Backlog du produit en
fonction des features livrées
2016-02 8
9. Capitalisation
Deux approches possibles, en fonction de la nécessité de
capitaliser ou non sur les exigences
2016-02 9
1. Pas de capitalisation
– La User Story est considérée comme une exigence
pendant la durée d’une itération
– À la fin d’une itération, la US reste dans le Backlog et peut
être « oubliée » en tant qu’exigence
2. Capitalisation nécessaire
– La User Story est considérée comme un conteneur et n’est
plus considérée comme une exigence
– Les exigences sont constituées d’autres types d’artefacts
et structurées dans un référentiel
Backlog
Référentiel
d’exigences
Backlog
Maintenance
& Réutilisation
10. Traçabilité
Une traçabilité entre la User Story et les autres artefacts (conception,
développement, test) doit être assurée pour une itération
Sachant que les US ont une durée de vie théoriquement limitée à une
itération, que deviennent les liens de traçabilité établis ?
⇒ Il faut maintenir la cohérence de la traçabilité avec autre chose que
les US
Une solution est d’établir des liens plus pérennes avec d’autres types
d’exigences comme les Cas d’Utilisation et les Scénarios
2016-02 10
USUS USUS
Artefacts
???
Itération CU
Scénarios
Référentiel d’exigences
Traçabilité
11. Un déploiement réussi !
Les points clés :
Sensibilisation de l’ensemble des
équipes à l’ingénierie des exigences
et à l’agilité
Définition collaborative d’une
démarche d’ingénierie
Formation des équipes
Coaching & Accompagnement
des équipes
Amélioration continue de la
démarche
2016-02 11
Une mise en œuvre réussie de
l’agilité repose sur une maîtrise
des processus d’ingénierie de
base (exigences,
configuration…) et sur une
industrialisation des activités
(analyse, conception, test…)
12. En savoir plus… vous investir !
Formation « IE dans un contexte agile »
– Formation inter et intra (1 jour)
– Objectif : Mieux appréhender les problématiques de développement et de
gestion des exigences dans un contexte agile, commencer à mettre en
œuvre une démarche d’ingénierie adaptée aux spécificités de l’agilité
– A qui s’adresse la formation ?
Analyste métier/fonctionnel, Business Analyst, Analyste système,
Responsable de produit, Product Owner, Chef de projet, Ingénieur
méthodes, …
– Pré-requis : Avoir une connaissance des fondamentaux de l’ingénierie des
exigences
– Contenu : Théorie et pratique (exercices et mises en situation)
SPECIEF : Société pour la Promotion Et la Certification en
Ingénierie des Exigences en langue Française
– Groupe de Travail n°6 : IE dans un contexte agile
– JIE : jeudi 26 mai 2016
2016-02 12