SlideShare une entreprise Scribd logo
1  sur  5
Télécharger pour lire hors ligne
Dépasser les exigences fonctionnelles sur les projets
                  de développement Agile
Scott W. Ambler
Stratégies pour adresser les exigences non-fonctionnelles.
Scott examine les meilleurs moyens pour traiter les exigences non-fonctionnelles.
Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational.

Traduction par Emmanuel Hugonnet de l’article Beyond Functional Requirements On Agile
Projects avec l’aimable autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s
Journal.


Toutes les études, les unes après les autres, montrent que la gestion des exigences est la cause
principale d’échec pour les équipes de développement logiciel. Les développeurs agiles, en
général, se concentrent sur les exigences fonctionnelles qui décrivent un apport de valeur pour
les utilisateurs – un écran, un rapport, une fonction, ou une règle métier. Le plus souvent ces
exigences sont formalisées sous la forme d’histoires d’utilisateur (quot;user stories 1quot;) ou, encore
couramment, sous forme de cas d’utilisation ou de scénarii d’usage. Les équipes les plus
avancées en transcriront itérativement les détails sous forme de tests d’usage. Au fil des ans,
les agilistes2 ont développé plusieurs stratégies pour gérer efficacement les exigences
fonctionnelles, ce qui est probablement l’un des facteurs de la réussite des projets agiles. En
réalisant qu’il existe des exigences et des contraintes non-fonctionnelles qui doivent aussi être
prises en compte les équipes agiles et disciplinées peuvent aller plus loin,.
Les exigences non-fonctionnelles (NFRs), connues aussi sous les termes quot;exigences
techniquesquot; ou exigences de quot;qualité de servicequot; (QoS), concernent essentiellement des
caractéristiques transverses aux exigences fonctionnelles. Les NFRs les plus communément
rencontrées sont la précision, la disponibilité, les accès simultanés, les problèmes
opérationnels, la performance, la stabilité, la sécurité, le support, l‘actualisation, la facilité
d’utilisation, l’internationalisation, les services rendus, les préoccupations environnementales,
et les contraintes réglementaires.
Une contrainte introduit ou induit une restriction de la solution, par exemple lorsqu’on exige
de nous que l’on stocke toutes nos .données dans DB2 suivant le plan d’architecture de
l’entreprise, ou lorsque l’on est autorisé à utiliser uniquement des logiciels open-source (OSS)
qui respectent un certain type de licence. Ces contraintes ont souvent un impact sur vos choix
techniques : elles restreignent certains aspects de votre architecture, imposant les éléments à
réutiliser, ou même la manière d’adapter l’architecture. Bien que certains développeurs
puissent se sentir bridés, en réalité ces contraintes peuvent faciliter le travail de l’équipe au
quotidien car certaines décisions ont déjà été prises pour vous. J’aime voir cela ainsi : les
agilistes auront le courage de remettre à demain les décisions qui doivent être prise demain,
les agilistes disciplinés ont en plus l’humilité de respecter les décisions d’hier.

Bien que certaines équipes aient mis au point des techniques abouties pour gérer les exigences
fonctionnelles, la plupart sont empêtrées dans les NFRs et les contraintes. Certaines équipes

1
  NdT. : étant d’accord avec Claude Aubry j’emploierai le terme quot;histoire d’utilisateurquot; pour traduite quot;user
storyquot;.
2
  NdT : j’ai utilisé l’anglicisme ‘agiliste’ plutôt que de le traduire par manque d’un vocabulaire adapté. Une
traduction convenable aurait pu être ‘praticien agile’.
ont créé des histoires techniques pour gérer les NFRs et les contraintes de la même manière
qu’elles gèrent les exigences fonctionnelles par des histoires d’utilisateur. C’est efficace dans
un but de documentation mais cette approche ne tient pas d’un point de vue gestion et
réalisation.
La gestion agile des exigences (cf. www.agilemodeling.com/essays/changeManagement.htm)
suppose que celles-ci soient auto-suffisantes et puissent être traitées dans un délai fini, une
hypothèse qui s’avère rarement vraie dans le cas des NFRs et des contraintes.




                            Figure 1 : Le cycle de vie complet du système

La Figure 1 donne une vision générale du cycle de vie d’un système agile. Elle montre le
système dans son ensemble, comment sont gérées les activités de l’Itération -1 (cf. quot;The
Iteration Negative Onequot;, www.ddj.com/architect/209902719), le cycle complet de
développement du logiciel (Software Development LifeCycle), la phase de production durant
laquelle le système fonctionne et est maintenu, et une phase optionnelle d’arrêt pour retirer
entièrement le système de votre environnement. Le cycle de développement comprend
l’Itération 0, l’ensemble des étapes de réalisation, et l’(les) itération(s) de livraison en passant
par chacune des livraisons réussies de votre système. Au cours de l’Itération 0, aussi appelée
phase d’Introduction (Inception), vous préparez le démarrage du projet, ce qui inclut une
première modélisation et planification. Durant la réalisation, étape sur laquelle se concentrent
la plupart des méthodes agiles, vous construisez le système. Une réalisation agile et
disciplinée met en œuvre un effort de tests d’investigation indépendants (cf. quot;Agile Testing
Strategiesquot;, www.ddj.com/architect/196603549) en parallèle du développement à proprement
parler. Lors de la (les) phase(s) de livraison, que l’on appelle aussi phase de Transition, (cf.
quot;The Agile End Gamequot;, www.ddj.com/architect/198800565) vous préparez le déploiement du
système en production. Ce cycle de vie est important car il met en lumière trois des quatre
stratégies permettant d’adresser les NFRs et les contraintes sur les projets agiles :
     • Au cours de l’Itération 0, se faire une première idée de l’architecture et des exigences
         pour identifier NFRs et contraintes.
     • Un mode Juste A Temps (Just In Time) lors de la réalisation pour explorer tous les
         détails.
•   Des tests d’investigation indépendants tout au long de la réalisation pour vérifier .que
       le système prend bien en compte NFRs et contraintes.
   •   Une formation des développeurs pour qu’ils comprennent les impacts architecturaux
       des exigences.


Agile Modeling Strategies
L’un des éléments essentiel de l’Itération 0 est la vision globale du projet en termes
d’architecture et d’exigences, car c’est à ce moment là que vous aller obtenir les informations
critiques pour la réussite du projet. Par exemple, peu d’entreprises vont financer un projet si
l’équipe n’est pas capable d’indiquer à quel problème elle s’attaque, comment elle va le
résoudre, et de fournir une grossière estimation des coûts et des délais. L’équipe a besoin
d’avoir une vision haut niveau des exigences et d’une stratégie technique raisonnable
(cohérente) ; d’où cette nécessité de se faire une première idée du projet. J’ai récemment
sondé la communauté agile à ce sujet (les résultats sont disponibles sur
www.ambysoft.com/surveys/practicesPrinciples2008.html) et j’ai découvert que 83% des
équipes ont défini très souvent, souvent ou parfois, cette vision globale des exigences, et que
81% ont mis au point une architecture générale au même moment. Contrairement à ce que
l’on pense habituellement, les agilistes commencent par modéliser.
C’est lorsque vous vous forgez cette première idée des exigences que vous allez identifier les
exigences fonctionnelles de haut-niveau, les NFRs et les contraintes. Toutes les formes
d’exigences vont piloter vos réflexions architecturales, de manière itérative au fur et à mesure
que vous vous faites votre vision des exigences. Cette première idée se fait à haut-niveau,
‘objectif étant de modéliser pour prendre les premières décisions sur votre projet en ayant
suffisamment d’informations. Le but ici n’est donc pas d’avoir des spécifications détaillées ce
qui augmenterait, dans les faits, les risques et les coûts de votre projet.
Bien que vous preniez en compte les NFRs et les contraintes en vous faisant votre propre idée
du projet, vous allez vous apercevoir que probablement vous n’avez pas tous les éléments
pour les adresser. Ces détails sont obtenus dans un mode JIT pendant la réalisation du projet
au cours de sessions de modélisation avec les clients. Par exemple, vous allez prendre une
exigence fonctionnelle au sommet de la pile qui décrit la modification d’un écran existant et
de la fonctionnalité associée. En creusant les détails de cette exigence fonctionnelle, en mode
JIT, avec vos clients vous allez aussi creuser les NFRs et contraintes transverses qui s’y
appliquent. La conséquence de tout ça est que non seulement les développeurs doivent
connaitre les NFRs et les contraintes, ce qui devrait être le cas au travers de la vision globale
du projet, mais ils doivent être suffisamment compétents pour les prendre en compte. J’y
reviendrai par la suite.


Des tests indépendants
Les modèles, particulièrement ceux écrits tôt dans le cycle de vie du projet, sont au mieux des
hypothèses sur ce que vous pensez réaliser et comment vous allez procéder. Les spéculations
c’est déjà bien, mais la validation de celles-ci c’est encore mieux. Bien que de nombreux
agilistes aient adopté le développement piloté par les tests (TDD) ou l’écriture des tests en
premier (test-first), une pratique vraiment excellente, il s’agit au mieux d’une approche par
des tests de confirmation comme je l’ai écrit dans quot;Scaling Test-Driven Developmentquot;
(www.ddj.com/architect/205207998). L’approche par des tests de confirmation valide que
vous avez construit le système selon votre compréhension des exigences. Le développement
piloté par les tests (TDD) est l’équivalent agile des tests selon les spécifications, mais cela
suppose que les exigences soient bien identifiées et bien comprises. Mais attention, si vous ne
pratiquez pas le TDD c’est encore bien pire.
L’idée ici est que le TDD est un très bon point de départ mais qu’il n’est pas suffisant.
Comme le montre la Figure 1, une équipe agile disciplinée fournit un effort de tests
indépendants en parallèle du développement. L’idée de base est que l’équipe agile déploiera,
régulièrement et au moins une fois par itération, une version opérationnelle du système pour
une équipe de testeurs indépendants afin que ces derniers puissent réaliser des tests
d’investigation ainsi que d’autres formes de tests de haut-niveau. Cet effort de tests
indépendants permet d’adresser les problèmes habituellement adressés en fin de cycle, durant
la phase de tests, par les équipes traditionnelles. En effectuant ces tests en même temps que la
réalisation et en remontant les problèmes rencontrés rapidement à l’équipe de développement,
vous réduisez le coût de correction des défauts et le temps total de réalisation du projet.
L’équipe de développement prend en compte les défauts comme des exigences potentielles
qui sont ajoutées à leur pile de tâches à effectuer, et devant être réalisées par TDD.
L’équipe de test est petite, environ un testeur pour 10 membres de l’équipe de développement,
car l’équipe de développement doit s’occuper des tests de confirmation (ce qui représente la
plus grosse part des tests). Les testeurs indépendants sont des spécialistes des tests, ils
devraient faire partie des 5 – 10% du top des testeurs, et ont accès à des outils de tests
sophistiqués. Ils utiliseront leurs outils pour essayer de mettre le système en erreur, et souvent
cela tourne autour des problèmes adressés par les NFRs et les contraintes.


La formation des développeurs
La quatrième stratégie pour gérer les NFRs et les contraintes dans une équipe agile, ou dans
une équipe traditionnelle d’ailleurs, consiste à former les développeurs à ces problèmes. Il est
facile de dire que vous aller identifier et valider des NFRs qui concernent la facilité
d’utilisation, la sécurité et l’environnement, mais si vos développeurs n’ont pas la moindre
idée de ce dont il s’agit comment peuvent ils le traiter correctement? Je ne dis pas que tout le
monde devrait devenir un expert en sécurité mais au moins en maitriser les fondamentaux.
De nombreuses organisations sont réticentes à l’idée de former leurs développeurs sur ces
points, une décision incroyablement à court-terme. Effectivement, prévoir des formations de
deux jours sur 20 ou 30 sujets pour chaque membre de l’équipe constitue un certain budget.
Mais lorsque vous amortissez ces coûts sur une carrière de 30 ans, cela devient tout de suite
plus raisonnable. Si on regarde la totalité de la valeur apportée par l’amélioration des
compétences et des connaissances, souvent c’est un excellent investissement. Si vous couplez
votre effort de formation à des pratiques de développement en groupe comme la
programmation en paire ou la modélisation en groupe, vous en tirerez rapidement les
bénéfices.

Les quatre stratégies pour adresser les exigences non-fonctionnelles et les contraintes sur les
projets agiles vont main dans la main. Tout d’abord vous devez identifier ces problèmes en
vous faisant une première idée du projet et formuler une stratégie techniquement viable au
travers de l’ébauche d’architecture générale obtenue à l’Itération 0. Les détails sont traités en
mode juste à temps (JIT) au cours de la réalisation et validés par des tests indépendants en
parallèle. Finalement, pour que chacun comprenne bien les impacts de ces problèmes, votre
organisation doit investir dans la formation professionnelle, ainsi les collaborateurs auront des
compétences au-delà de leur domaine de prédilection, la technologie, ce qui améliorera leur
productivité tout au long de leur carrière.
Les agilistes disciplinés dépassent la simple gestion des exigences par une pile priorisée et
adoptent une approche plus globale qui traite les exigences fonctionnelles mais aussi les
contraintes et les exigences non-fonctionnelles.

DDJ

Contenu connexe

Tendances

Le couple MOA-MOE dans le projet informatique
Le couple MOA-MOE dans le projet informatique Le couple MOA-MOE dans le projet informatique
Le couple MOA-MOE dans le projet informatique Moez SAAIDIA
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)David VALLAT
 
Lexique du management de projet
Lexique du management de projetLexique du management de projet
Lexique du management de projetMichel Estève
 
Introduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationIntroduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationSanae BEKKAR
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 
BPMN : Business Process Modelling Notation
BPMN : Business Process Modelling NotationBPMN : Business Process Modelling Notation
BPMN : Business Process Modelling NotationKhaled Fayala
 
Perspectives des tableaux de bord
Perspectives des  tableaux de bordPerspectives des  tableaux de bord
Perspectives des tableaux de bordnodesway
 
comment rédiger une expression de besoins
comment rédiger une expression de besoinscomment rédiger une expression de besoins
comment rédiger une expression de besoinsAlexandre Zermati
 
IIBA Initiation au Business Analysis Book of Knowledge V2
IIBA Initiation au Business Analysis Book of Knowledge V2IIBA Initiation au Business Analysis Book of Knowledge V2
IIBA Initiation au Business Analysis Book of Knowledge V2COMPETENSIS
 
SOD Segregation Of Duties - Séparation de Droits et Responsabilités
SOD Segregation Of Duties - Séparation de Droits et ResponsabilitésSOD Segregation Of Duties - Séparation de Droits et Responsabilités
SOD Segregation Of Duties - Séparation de Droits et ResponsabilitésCOMPETENSIS
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPSarah
 
Gestion d’un projet informatique
Gestion d’un projet informatiqueGestion d’un projet informatique
Gestion d’un projet informatiqueAymen Foudhaili
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodesJean Michel
 
Design centré sur l’utilisateur et développement Agile: perspectives de réco...
Design centré sur l’utilisateur et développement  Agile: perspectives de réco...Design centré sur l’utilisateur et développement  Agile: perspectives de réco...
Design centré sur l’utilisateur et développement Agile: perspectives de réco...Geoffrey Dorne
 
La mise en œuvre d’un ERP
La mise en œuvre d’un ERPLa mise en œuvre d’un ERP
La mise en œuvre d’un ERPAyoub Minen
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Ardesi Midi-Pyrénées
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014Rémi Bachelet
 

Tendances (20)

Le couple MOA-MOE dans le projet informatique
Le couple MOA-MOE dans le projet informatique Le couple MOA-MOE dans le projet informatique
Le couple MOA-MOE dans le projet informatique
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
Lexique du management de projet
Lexique du management de projetLexique du management de projet
Lexique du management de projet
 
Introduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationIntroduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling Notation
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Methodologie projet
Methodologie projet Methodologie projet
Methodologie projet
 
BPMN : Business Process Modelling Notation
BPMN : Business Process Modelling NotationBPMN : Business Process Modelling Notation
BPMN : Business Process Modelling Notation
 
Perspectives des tableaux de bord
Perspectives des  tableaux de bordPerspectives des  tableaux de bord
Perspectives des tableaux de bord
 
comment rédiger une expression de besoins
comment rédiger une expression de besoinscomment rédiger une expression de besoins
comment rédiger une expression de besoins
 
IIBA Initiation au Business Analysis Book of Knowledge V2
IIBA Initiation au Business Analysis Book of Knowledge V2IIBA Initiation au Business Analysis Book of Knowledge V2
IIBA Initiation au Business Analysis Book of Knowledge V2
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
SOD Segregation Of Duties - Séparation de Droits et Responsabilités
SOD Segregation Of Duties - Séparation de Droits et ResponsabilitésSOD Segregation Of Duties - Séparation de Droits et Responsabilités
SOD Segregation Of Duties - Séparation de Droits et Responsabilités
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XP
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Gestion d’un projet informatique
Gestion d’un projet informatiqueGestion d’un projet informatique
Gestion d’un projet informatique
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
 
Design centré sur l’utilisateur et développement Agile: perspectives de réco...
Design centré sur l’utilisateur et développement  Agile: perspectives de réco...Design centré sur l’utilisateur et développement  Agile: perspectives de réco...
Design centré sur l’utilisateur et développement Agile: perspectives de réco...
 
La mise en œuvre d’un ERP
La mise en œuvre d’un ERPLa mise en œuvre d’un ERP
La mise en œuvre d’un ERP
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014
 

En vedette

Java Content Repository avec Jackrabbit
Java Content Repository avec JackrabbitJava Content Repository avec Jackrabbit
Java Content Repository avec JackrabbitEmmanuel Hugonnet
 
Agile Tour 2009 Coding Dojo Kata ATDD
Agile Tour 2009 Coding Dojo Kata ATDDAgile Tour 2009 Coding Dojo Kata ATDD
Agile Tour 2009 Coding Dojo Kata ATDDEmmanuel Hugonnet
 
Coding Dojo in the Alps - Retour d'expérience
Coding Dojo in the Alps - Retour d'expérienceCoding Dojo in the Alps - Retour d'expérience
Coding Dojo in the Alps - Retour d'expérienceEmmanuel Hugonnet
 
Innovations Techniques Au Service Du Test De Recette Automatisé
Innovations Techniques Au Service Du Test De Recette AutomatiséInnovations Techniques Au Service Du Test De Recette Automatisé
Innovations Techniques Au Service Du Test De Recette AutomatiséEmmanuel Hugonnet
 
Formation WordPress à Blida
Formation WordPress à BlidaFormation WordPress à Blida
Formation WordPress à BlidaGd6d
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange LabsEmmanuel Hugonnet
 
At2009 Soigner Sa Schizophrenie 1.2
At2009 Soigner Sa Schizophrenie 1.2At2009 Soigner Sa Schizophrenie 1.2
At2009 Soigner Sa Schizophrenie 1.2Emmanuel Hugonnet
 
Ddj Architecture & Design The Distributed Agile Team
Ddj   Architecture &  Design   The Distributed Agile TeamDdj   Architecture &  Design   The Distributed Agile Team
Ddj Architecture & Design The Distributed Agile TeamEmmanuel Hugonnet
 
Le modèle d’acquisition de compétences de Dreyfus
Le modèle d’acquisition de compétences de DreyfusLe modèle d’acquisition de compétences de Dreyfus
Le modèle d’acquisition de compétences de DreyfusEmmanuel Hugonnet
 
HTML5: Not Just for Breakfast
HTML5: Not Just for BreakfastHTML5: Not Just for Breakfast
HTML5: Not Just for BreakfastDave Bouwman
 
台灣趨勢報告
台灣趨勢報告台灣趨勢報告
台灣趨勢報告honan4108
 
Assignment1_2
Assignment1_2Assignment1_2
Assignment1_2saihingne
 
2007 Bpc Conference Summary 080827
2007 Bpc Conference Summary 0808272007 Bpc Conference Summary 080827
2007 Bpc Conference Summary 080827admin_BPC
 
Commerciële productontwikkeling voor hoteliers
Commerciële productontwikkeling voor hoteliersCommerciële productontwikkeling voor hoteliers
Commerciële productontwikkeling voor hoteliersXavier Debeerst
 
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)responsabilitate_sociala
 

En vedette (20)

At2009 Coding Dojo ATDD
At2009 Coding Dojo ATDDAt2009 Coding Dojo ATDD
At2009 Coding Dojo ATDD
 
Java Content Repository avec Jackrabbit
Java Content Repository avec JackrabbitJava Content Repository avec Jackrabbit
Java Content Repository avec Jackrabbit
 
Agile Tour 2009 Coding Dojo Kata ATDD
Agile Tour 2009 Coding Dojo Kata ATDDAgile Tour 2009 Coding Dojo Kata ATDD
Agile Tour 2009 Coding Dojo Kata ATDD
 
Soigner Sa Schizophrénie
Soigner Sa SchizophrénieSoigner Sa Schizophrénie
Soigner Sa Schizophrénie
 
Coding Dojo in the Alps - Retour d'expérience
Coding Dojo in the Alps - Retour d'expérienceCoding Dojo in the Alps - Retour d'expérience
Coding Dojo in the Alps - Retour d'expérience
 
Innovations Techniques Au Service Du Test De Recette Automatisé
Innovations Techniques Au Service Du Test De Recette AutomatiséInnovations Techniques Au Service Du Test De Recette Automatisé
Innovations Techniques Au Service Du Test De Recette Automatisé
 
Formation WordPress à Blida
Formation WordPress à BlidaFormation WordPress à Blida
Formation WordPress à Blida
 
J2EE m’a tuer
J2EE m’a tuerJ2EE m’a tuer
J2EE m’a tuer
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
 
At2009 Soigner Sa Schizophrenie 1.2
At2009 Soigner Sa Schizophrenie 1.2At2009 Soigner Sa Schizophrenie 1.2
At2009 Soigner Sa Schizophrenie 1.2
 
Ddj Architecture & Design The Distributed Agile Team
Ddj   Architecture &  Design   The Distributed Agile TeamDdj   Architecture &  Design   The Distributed Agile Team
Ddj Architecture & Design The Distributed Agile Team
 
Le modèle d’acquisition de compétences de Dreyfus
Le modèle d’acquisition de compétences de DreyfusLe modèle d’acquisition de compétences de Dreyfus
Le modèle d’acquisition de compétences de Dreyfus
 
ACON's International work
ACON's International workACON's International work
ACON's International work
 
HTML5: Not Just for Breakfast
HTML5: Not Just for BreakfastHTML5: Not Just for Breakfast
HTML5: Not Just for Breakfast
 
台灣趨勢報告
台灣趨勢報告台灣趨勢報告
台灣趨勢報告
 
Assignment1_2
Assignment1_2Assignment1_2
Assignment1_2
 
2007 Bpc Conference Summary 080827
2007 Bpc Conference Summary 0808272007 Bpc Conference Summary 080827
2007 Bpc Conference Summary 080827
 
Commerciële productontwikkeling voor hoteliers
Commerciële productontwikkeling voor hoteliersCommerciële productontwikkeling voor hoteliers
Commerciële productontwikkeling voor hoteliers
 
La Vida no me enseñó
La Vida no me enseñóLa Vida no me enseñó
La Vida no me enseñó
 
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)
Proiect de renovare a dispensarului din comuna Ciuruleasa (jud. Alba)
 

Similaire à Ddj Architecture & Design Beyond Functional Requirements On Agile Projects

Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSISébastien Bourguignon
 
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...BPMSinfo
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SINouhaila ALAMI
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Pyxis Technologies
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesEchoesLabs
 
Webinar erp : 7 points clés pour un cahier des charges réussi
Webinar erp : 7 points clés pour un cahier des charges réussiWebinar erp : 7 points clés pour un cahier des charges réussi
Webinar erp : 7 points clés pour un cahier des charges réussiAxelor
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
Etude de cadrage clef de la réussite d'un upgrade oracle people soft busine...
Etude de cadrage clef de la réussite d'un upgrade oracle people soft   busine...Etude de cadrage clef de la réussite d'un upgrade oracle people soft   busine...
Etude de cadrage clef de la réussite d'un upgrade oracle people soft busine...Business At Work
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2David VALLAT
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logicielMajid CHADAD
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfimenhamada17
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
Les Schémas Directeurs SI par la pratique - IAE Paris - 10 septembre 2013
Les Schémas Directeurs SI par la pratique -  IAE Paris - 10 septembre 2013Les Schémas Directeurs SI par la pratique -  IAE Paris - 10 septembre 2013
Les Schémas Directeurs SI par la pratique - IAE Paris - 10 septembre 2013ArielleMeffre
 

Similaire à Ddj Architecture & Design Beyond Functional Requirements On Agile Projects (20)

Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...
Conférence solutions bpms 2011 - Agilité du SI et agilité de l'entreprise 201...
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigences
 
Webinar erp : 7 points clés pour un cahier des charges réussi
Webinar erp : 7 points clés pour un cahier des charges réussiWebinar erp : 7 points clés pour un cahier des charges réussi
Webinar erp : 7 points clés pour un cahier des charges réussi
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Up1
Up1Up1
Up1
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Etude de cadrage clef de la réussite d'un upgrade oracle people soft busine...
Etude de cadrage clef de la réussite d'un upgrade oracle people soft   busine...Etude de cadrage clef de la réussite d'un upgrade oracle people soft   busine...
Etude de cadrage clef de la réussite d'un upgrade oracle people soft busine...
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
TOGAF.pptx
TOGAF.pptxTOGAF.pptx
TOGAF.pptx
 
Rad
RadRad
Rad
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
Les Schémas Directeurs SI par la pratique - IAE Paris - 10 septembre 2013
Les Schémas Directeurs SI par la pratique -  IAE Paris - 10 septembre 2013Les Schémas Directeurs SI par la pratique -  IAE Paris - 10 septembre 2013
Les Schémas Directeurs SI par la pratique - IAE Paris - 10 septembre 2013
 

Plus de Emmanuel Hugonnet

You're a pretty fly for a WildFly
You're a pretty fly for a WildFlyYou're a pretty fly for a WildFly
You're a pretty fly for a WildFlyEmmanuel Hugonnet
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4Emmanuel Hugonnet
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicEmmanuel Hugonnet
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicEmmanuel Hugonnet
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes PratiquesEmmanuel Hugonnet
 

Plus de Emmanuel Hugonnet (6)

You're a pretty fly for a WildFly
You're a pretty fly for a WildFlyYou're a pretty fly for a WildFly
You're a pretty fly for a WildFly
 
Coding Dojo
Coding DojoCoding Dojo
Coding Dojo
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
 

Ddj Architecture & Design Beyond Functional Requirements On Agile Projects

  • 1. Dépasser les exigences fonctionnelles sur les projets de développement Agile Scott W. Ambler Stratégies pour adresser les exigences non-fonctionnelles. Scott examine les meilleurs moyens pour traiter les exigences non-fonctionnelles. Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational. Traduction par Emmanuel Hugonnet de l’article Beyond Functional Requirements On Agile Projects avec l’aimable autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s Journal. Toutes les études, les unes après les autres, montrent que la gestion des exigences est la cause principale d’échec pour les équipes de développement logiciel. Les développeurs agiles, en général, se concentrent sur les exigences fonctionnelles qui décrivent un apport de valeur pour les utilisateurs – un écran, un rapport, une fonction, ou une règle métier. Le plus souvent ces exigences sont formalisées sous la forme d’histoires d’utilisateur (quot;user stories 1quot;) ou, encore couramment, sous forme de cas d’utilisation ou de scénarii d’usage. Les équipes les plus avancées en transcriront itérativement les détails sous forme de tests d’usage. Au fil des ans, les agilistes2 ont développé plusieurs stratégies pour gérer efficacement les exigences fonctionnelles, ce qui est probablement l’un des facteurs de la réussite des projets agiles. En réalisant qu’il existe des exigences et des contraintes non-fonctionnelles qui doivent aussi être prises en compte les équipes agiles et disciplinées peuvent aller plus loin,. Les exigences non-fonctionnelles (NFRs), connues aussi sous les termes quot;exigences techniquesquot; ou exigences de quot;qualité de servicequot; (QoS), concernent essentiellement des caractéristiques transverses aux exigences fonctionnelles. Les NFRs les plus communément rencontrées sont la précision, la disponibilité, les accès simultanés, les problèmes opérationnels, la performance, la stabilité, la sécurité, le support, l‘actualisation, la facilité d’utilisation, l’internationalisation, les services rendus, les préoccupations environnementales, et les contraintes réglementaires. Une contrainte introduit ou induit une restriction de la solution, par exemple lorsqu’on exige de nous que l’on stocke toutes nos .données dans DB2 suivant le plan d’architecture de l’entreprise, ou lorsque l’on est autorisé à utiliser uniquement des logiciels open-source (OSS) qui respectent un certain type de licence. Ces contraintes ont souvent un impact sur vos choix techniques : elles restreignent certains aspects de votre architecture, imposant les éléments à réutiliser, ou même la manière d’adapter l’architecture. Bien que certains développeurs puissent se sentir bridés, en réalité ces contraintes peuvent faciliter le travail de l’équipe au quotidien car certaines décisions ont déjà été prises pour vous. J’aime voir cela ainsi : les agilistes auront le courage de remettre à demain les décisions qui doivent être prise demain, les agilistes disciplinés ont en plus l’humilité de respecter les décisions d’hier. Bien que certaines équipes aient mis au point des techniques abouties pour gérer les exigences fonctionnelles, la plupart sont empêtrées dans les NFRs et les contraintes. Certaines équipes 1 NdT. : étant d’accord avec Claude Aubry j’emploierai le terme quot;histoire d’utilisateurquot; pour traduite quot;user storyquot;. 2 NdT : j’ai utilisé l’anglicisme ‘agiliste’ plutôt que de le traduire par manque d’un vocabulaire adapté. Une traduction convenable aurait pu être ‘praticien agile’.
  • 2. ont créé des histoires techniques pour gérer les NFRs et les contraintes de la même manière qu’elles gèrent les exigences fonctionnelles par des histoires d’utilisateur. C’est efficace dans un but de documentation mais cette approche ne tient pas d’un point de vue gestion et réalisation. La gestion agile des exigences (cf. www.agilemodeling.com/essays/changeManagement.htm) suppose que celles-ci soient auto-suffisantes et puissent être traitées dans un délai fini, une hypothèse qui s’avère rarement vraie dans le cas des NFRs et des contraintes. Figure 1 : Le cycle de vie complet du système La Figure 1 donne une vision générale du cycle de vie d’un système agile. Elle montre le système dans son ensemble, comment sont gérées les activités de l’Itération -1 (cf. quot;The Iteration Negative Onequot;, www.ddj.com/architect/209902719), le cycle complet de développement du logiciel (Software Development LifeCycle), la phase de production durant laquelle le système fonctionne et est maintenu, et une phase optionnelle d’arrêt pour retirer entièrement le système de votre environnement. Le cycle de développement comprend l’Itération 0, l’ensemble des étapes de réalisation, et l’(les) itération(s) de livraison en passant par chacune des livraisons réussies de votre système. Au cours de l’Itération 0, aussi appelée phase d’Introduction (Inception), vous préparez le démarrage du projet, ce qui inclut une première modélisation et planification. Durant la réalisation, étape sur laquelle se concentrent la plupart des méthodes agiles, vous construisez le système. Une réalisation agile et disciplinée met en œuvre un effort de tests d’investigation indépendants (cf. quot;Agile Testing Strategiesquot;, www.ddj.com/architect/196603549) en parallèle du développement à proprement parler. Lors de la (les) phase(s) de livraison, que l’on appelle aussi phase de Transition, (cf. quot;The Agile End Gamequot;, www.ddj.com/architect/198800565) vous préparez le déploiement du système en production. Ce cycle de vie est important car il met en lumière trois des quatre stratégies permettant d’adresser les NFRs et les contraintes sur les projets agiles : • Au cours de l’Itération 0, se faire une première idée de l’architecture et des exigences pour identifier NFRs et contraintes. • Un mode Juste A Temps (Just In Time) lors de la réalisation pour explorer tous les détails.
  • 3. Des tests d’investigation indépendants tout au long de la réalisation pour vérifier .que le système prend bien en compte NFRs et contraintes. • Une formation des développeurs pour qu’ils comprennent les impacts architecturaux des exigences. Agile Modeling Strategies L’un des éléments essentiel de l’Itération 0 est la vision globale du projet en termes d’architecture et d’exigences, car c’est à ce moment là que vous aller obtenir les informations critiques pour la réussite du projet. Par exemple, peu d’entreprises vont financer un projet si l’équipe n’est pas capable d’indiquer à quel problème elle s’attaque, comment elle va le résoudre, et de fournir une grossière estimation des coûts et des délais. L’équipe a besoin d’avoir une vision haut niveau des exigences et d’une stratégie technique raisonnable (cohérente) ; d’où cette nécessité de se faire une première idée du projet. J’ai récemment sondé la communauté agile à ce sujet (les résultats sont disponibles sur www.ambysoft.com/surveys/practicesPrinciples2008.html) et j’ai découvert que 83% des équipes ont défini très souvent, souvent ou parfois, cette vision globale des exigences, et que 81% ont mis au point une architecture générale au même moment. Contrairement à ce que l’on pense habituellement, les agilistes commencent par modéliser. C’est lorsque vous vous forgez cette première idée des exigences que vous allez identifier les exigences fonctionnelles de haut-niveau, les NFRs et les contraintes. Toutes les formes d’exigences vont piloter vos réflexions architecturales, de manière itérative au fur et à mesure que vous vous faites votre vision des exigences. Cette première idée se fait à haut-niveau, ‘objectif étant de modéliser pour prendre les premières décisions sur votre projet en ayant suffisamment d’informations. Le but ici n’est donc pas d’avoir des spécifications détaillées ce qui augmenterait, dans les faits, les risques et les coûts de votre projet. Bien que vous preniez en compte les NFRs et les contraintes en vous faisant votre propre idée du projet, vous allez vous apercevoir que probablement vous n’avez pas tous les éléments pour les adresser. Ces détails sont obtenus dans un mode JIT pendant la réalisation du projet au cours de sessions de modélisation avec les clients. Par exemple, vous allez prendre une exigence fonctionnelle au sommet de la pile qui décrit la modification d’un écran existant et de la fonctionnalité associée. En creusant les détails de cette exigence fonctionnelle, en mode JIT, avec vos clients vous allez aussi creuser les NFRs et contraintes transverses qui s’y appliquent. La conséquence de tout ça est que non seulement les développeurs doivent connaitre les NFRs et les contraintes, ce qui devrait être le cas au travers de la vision globale du projet, mais ils doivent être suffisamment compétents pour les prendre en compte. J’y reviendrai par la suite. Des tests indépendants Les modèles, particulièrement ceux écrits tôt dans le cycle de vie du projet, sont au mieux des hypothèses sur ce que vous pensez réaliser et comment vous allez procéder. Les spéculations c’est déjà bien, mais la validation de celles-ci c’est encore mieux. Bien que de nombreux agilistes aient adopté le développement piloté par les tests (TDD) ou l’écriture des tests en premier (test-first), une pratique vraiment excellente, il s’agit au mieux d’une approche par des tests de confirmation comme je l’ai écrit dans quot;Scaling Test-Driven Developmentquot; (www.ddj.com/architect/205207998). L’approche par des tests de confirmation valide que
  • 4. vous avez construit le système selon votre compréhension des exigences. Le développement piloté par les tests (TDD) est l’équivalent agile des tests selon les spécifications, mais cela suppose que les exigences soient bien identifiées et bien comprises. Mais attention, si vous ne pratiquez pas le TDD c’est encore bien pire. L’idée ici est que le TDD est un très bon point de départ mais qu’il n’est pas suffisant. Comme le montre la Figure 1, une équipe agile disciplinée fournit un effort de tests indépendants en parallèle du développement. L’idée de base est que l’équipe agile déploiera, régulièrement et au moins une fois par itération, une version opérationnelle du système pour une équipe de testeurs indépendants afin que ces derniers puissent réaliser des tests d’investigation ainsi que d’autres formes de tests de haut-niveau. Cet effort de tests indépendants permet d’adresser les problèmes habituellement adressés en fin de cycle, durant la phase de tests, par les équipes traditionnelles. En effectuant ces tests en même temps que la réalisation et en remontant les problèmes rencontrés rapidement à l’équipe de développement, vous réduisez le coût de correction des défauts et le temps total de réalisation du projet. L’équipe de développement prend en compte les défauts comme des exigences potentielles qui sont ajoutées à leur pile de tâches à effectuer, et devant être réalisées par TDD. L’équipe de test est petite, environ un testeur pour 10 membres de l’équipe de développement, car l’équipe de développement doit s’occuper des tests de confirmation (ce qui représente la plus grosse part des tests). Les testeurs indépendants sont des spécialistes des tests, ils devraient faire partie des 5 – 10% du top des testeurs, et ont accès à des outils de tests sophistiqués. Ils utiliseront leurs outils pour essayer de mettre le système en erreur, et souvent cela tourne autour des problèmes adressés par les NFRs et les contraintes. La formation des développeurs La quatrième stratégie pour gérer les NFRs et les contraintes dans une équipe agile, ou dans une équipe traditionnelle d’ailleurs, consiste à former les développeurs à ces problèmes. Il est facile de dire que vous aller identifier et valider des NFRs qui concernent la facilité d’utilisation, la sécurité et l’environnement, mais si vos développeurs n’ont pas la moindre idée de ce dont il s’agit comment peuvent ils le traiter correctement? Je ne dis pas que tout le monde devrait devenir un expert en sécurité mais au moins en maitriser les fondamentaux. De nombreuses organisations sont réticentes à l’idée de former leurs développeurs sur ces points, une décision incroyablement à court-terme. Effectivement, prévoir des formations de deux jours sur 20 ou 30 sujets pour chaque membre de l’équipe constitue un certain budget. Mais lorsque vous amortissez ces coûts sur une carrière de 30 ans, cela devient tout de suite plus raisonnable. Si on regarde la totalité de la valeur apportée par l’amélioration des compétences et des connaissances, souvent c’est un excellent investissement. Si vous couplez votre effort de formation à des pratiques de développement en groupe comme la programmation en paire ou la modélisation en groupe, vous en tirerez rapidement les bénéfices. Les quatre stratégies pour adresser les exigences non-fonctionnelles et les contraintes sur les projets agiles vont main dans la main. Tout d’abord vous devez identifier ces problèmes en vous faisant une première idée du projet et formuler une stratégie techniquement viable au travers de l’ébauche d’architecture générale obtenue à l’Itération 0. Les détails sont traités en mode juste à temps (JIT) au cours de la réalisation et validés par des tests indépendants en parallèle. Finalement, pour que chacun comprenne bien les impacts de ces problèmes, votre organisation doit investir dans la formation professionnelle, ainsi les collaborateurs auront des
  • 5. compétences au-delà de leur domaine de prédilection, la technologie, ce qui améliorera leur productivité tout au long de leur carrière. Les agilistes disciplinés dépassent la simple gestion des exigences par une pile priorisée et adoptent une approche plus globale qui traite les exigences fonctionnelles mais aussi les contraintes et les exigences non-fonctionnelles. DDJ