Ddj Architecture & Design Beyond Functional Requirements On Agile Projects

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

Ddj Architecture & Design Beyond Functional Requirements On Agile Projects

by Emmanuel Hugonnet on Oct 06, 2008

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 7

Statistics

Ddj Architecture & Design Beyond Functional Requirements On Agile Projects — Document Transcript