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