Embed Size (px)
Citation preview
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 BadreauConsultant & Formateur
06 60 53 54 [email protected]
www.compliance-consulting.fr
2016-02 1
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
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
Manifeste Agile – Valeurs
2016-02 4
La collaboration avec les clients Plus que la négociation contractuelle
Les individus et leurs interactionsPlus que les processus & les outils
L’adaptation au changementPlus que le suivi d’un plan
Des logiciels opérationnelsPlus qu’une documentation exhaustive
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
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ésLes 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
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
Ebauche d’une démarche
Définition de la vision du produitIdentification des parties prenantes et de leurs objectifsIdentification des usages et des featuresConstruction d’une feuille de route (Story Map)Construction du Backlog du produit contenant des featuresConstruction du Backlog d’itération contenant des User Stories
Priorisation des User StoriesEstimation 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éesA la fin de chaque version, mise à jour du Backlog du produit en fonction des features livrées
2016-02 8
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
BacklogMaintenance
& Réutilisation
Traçabilité
Une traçabilité entre la User Story et les autres artefacts (conception, développement, test) doit être assurée pour une itérationSachant 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 USUne 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
US US
Artefacts
???
Itération CU
Scénarios
Référentiel d’exigences
Traçabilité
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énierieFormation des équipesCoaching & Accompagnement
des équipesAmé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…)
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
