Catégorie : Article

Dans un premier article, nous vous avons présenté quelques généralités sur la System Team, sa mission, ses responsabilités et sa composition telle que le décrit SAFe. A présent, nous aimerions vous présenter le résultat d’une réflexion que nous avons menée sur différents scénarios d’organisation des System Team (ST).

En savoir plus sur les System Team dans SAFe

Nous avons vu qu’une System Team était une équipe agile spécialisée et que sa principale raison d’être était de pouvoir apporter un soutien aux autres équipes agiles dans le cadre de la réalisation de leurs travaux, en leur fournissant un environnement de développement agile.

En termes d’organisation, SAFe ne préconise rien de bien précis sur les System Team, et plusieurs scénarios peuvent être envisagés.

·        Scénario 1 : Il y a une équipe système par Agile Release Train (ART) qui coordonne l’intégration et la validation de la solution

·        Scénario 2 : Il existe une seule équipe système pour l’ensemble des trains de la solution (Solution Train), qui peut assumer ces responsabilités pour tous les ART

·        Scénario 3 : Il existe des équipes système pour les ART et pour le Solution Train

D’autres scénarios peuvent être imaginés comme par exemple la mise en place de compétences OPS directement dans les équipes de réalisation… l’imagination humaine est sans limite ! Cependant, nous nous intéresserons ici uniquement à des scénarios prônant l’existence de System Team en tant qu’équipe agile.

Quid des System Architect / System Engineering ?

Avant de présenter plus en détails les scénarios, il est utile de revenir sur les rôles de System Architect (SA) et de System Engineering (SE) en quelques mots. Dans sa version 5, SAFe ne fait pas trop de différence entre les deux appellations et à tendance à les unir en permanence. SAFe parle de SA / SE comme un rôle de personne en charge de définir et communiquer une vision technique et architecturale commune pour un ART pour s’assurer que le système ou la Solution en voie de développement est adapté à l’usage auquel il est destiné.

Nous aimons introduire une différence entre SA et SE en précisant que le SE se positionne plus sur la définition et la communication sur la manière de réaliser le système ou la solution. C’est le SE qui précise le cadre de réalisation ; les principes et les règles de fabrication, les frameworks à utiliser… Quant à lui, le SA se concentre plus sur l’architecture du produit ou de la Solution en cours de développement.

Dans les scénarios retenus, nous pouvons choisir que les System Architects et les System Engineers font soit  partie de la System Team, soit n’en font pas partie. Arrêtons-nous quelques instants sur ces deux options possibles, sur leurs avantages et leurs inconvénients.

• Option avec les SA/SE dans la System Team

Cette option offre l’avantage d’une proximité forte entre les profils architectes et les profils OPS, ce qui favorise la diffusion de l’information et améliore le traitement des sujets de type MCO (Maintien en Condition Opérationnelle) qui représentent une part importante des travaux à mener par la ST. Dans ce cas, les informations sont mieux communiquées, plus rapidement et avec moins d’ambiguïtés et d’incompréhensions au sein de l’équipe. Les architectes travaillant souvent en avance de phase, le transfert de connaissances est grandement facilité pendant toutes les cérémonies de l’équipe. Du fait de la nature des activités d’architecture et d’opération pouvant être différente entre les membres de l’équipe, le principal inconvénient réside dans le fait que deux sous-groupes peuvent se former au sein de l’équipe, avec d’un côté les architectes et de l’autre les OPS. Cela nécessite alors souvent de mettre en place des points spécifiques d’échanges et de synchronisation, et des « boards » particuliers.

• Option avec les SA/SE en dehors de la System Team

Lorsque que les System Architects et les System Engineers ne font pas partie de l’équipe System Team, ils constituent alors un pool de compétences au sein du train, au même niveau que le Program Management. Le regroupement des SA et SE n’est pas considéré comme une équipe agile en tant que telle, avec un PO et un SM. Les principaux avantages de cette situation, c’est qu’il existe une meilleure émulation entre les architectes du train et les architectes de la Solution, et une meilleure visibilité sur le traitement de bout-en-bout des sujets techniques. Dans ce cas, la ST se concentre plutôt sur la construction et le maintien de la pipeline CI/CD et le support opérationnel auprès des équipes agiles de réalisation. A l’inverse, les SA / SE ne faisant pas partie de la ST, la transmission de l’information et le suivi de la réalisation des tâches techniques peuvent être plus compliqués.

Scénario 1 – Une équipe ST par train

Ce scénario est assez fréquent et fait appel au bon sens puisqu’il met en œuvre une équipe ST spécialisée par train. Les besoins d’intégration et de support des équipes sont importants et nécessitent l’appui d’une ST au niveau du train.

Avantages : L’équipe ST offre un support au plus près des équipes de réalisation avec un fort niveau de réactivité. L’équipe ST est considérée comme une équipe agile faisant partie intégrante du train et par conséquent, elle participe au PI Planning et gère son propre « board » d’équipe. Le PO et le SM de l’équipe participent à l’ART Sync. L’équipe est en charge de fournir le meilleur environnement de développement aux équipes de réalisation et travaille sur ses propres sujets (MCO internes et amélioration continue). Les sujets de l’équipe ST doivent être maturés au même titre que les autres sujets des équipes et intégrés au « board » du niveau Program sous forme d’Enablers.

Inconvénients : L’équipe ST est vu comme une équipe « services » et cela peut engendrer des tensions avec les équipes de réalisation qui ont souvent des attentes fortes, en particulier sur la disponibilité des environnements. L’organisation bascule souvent vers un système de « ticketing » qui peut sembler contraignant par les équipes[1] [2] . Il y a un risque d’isolement de l’équipe ST de par la nature des activités très différentes qu’elle exerce. Les membres de la ST peuvent avoir le sentiment d’être simplement des exécutants.

Pour que ce scénario fonctionne, il faut que la ST soit considérée à part entière comme une équipe agile, avec la présence d’un PO qui gère le backlog de l’équipe et d’un SM comme facilitateur et protecteur de l’équipe. Il y a nécessité de bien définir le mode de fonctionnement et les interactions entre les équipes de réalisation et la ST au sein du train, et de bien délimiter les zones de responsabilité de chacune d’elles.

Scénario 2 – Une seule équipe ST pour l’ensemble des trains de la Solution

Ce scénario propose la création d’une seule équipe System Team pour l’ensemble de la Solution. Le Solution Train est le concept organisationnel utilisé pour construire des solutions grandes et complexes qui requièrent la coordination de plusieurs Agile Release Trains (ART), ainsi que les contributions de fournisseurs (Suppliers).

Avantages : Il n’y a qu’une seule équipe ST à gérer, ce qui semble être plus simple, mais attention à ce que cette équipe reste de taille acceptable pour une équipe agile. Les compétences OPS sont concentrées au sein d’une seule équipe ce qui favorise les échanges et les partages des bonnes pratiques, ainsi qu’une certaine émulation et une homogénéité dans les manières de faire. Ce qui nous fait dire aussi que ce scénario convient bien lorsque les trains ont des problématiques très similaires en termes d’intégration et de déploiement. L’équipe peut également travailler sur des sujets et préoccupations transverses à tous les trains de la Solution.

Inconvénients : Il y a un risque que les membres de l’équipe se spécialisent sur un train en particulier, en délaissant les autres trains. L’équipe peut paraître plus éloignées des préoccupations spécifiques à certains trains et à des équipes en particulier. Le niveau Program d’un train peut avoir des difficultés dans l’activité de maturation de ses propres sujets techniques.

Pour que ce scénario fonctionne, il faut que les trains aient les mêmes besoins dans leur recherche d’autonomie. L’équipe System Team ne pourra pas (ou peu) répondre efficacement à des sollicitations d’un train en particulier. Et il y aura peut-être la nécessité de positionner quelques compétences OPS dans les équipes de réalisation afin de combler les lacunes ou les vides pouvant être engendre par l’existence d’une seule équipe ST au niveau de la Solution.

Scénario 3 – Une coexistence entre des équipes ST au niveau des trains et une équipe ST au niveau de la Solution

Ce scénario peut paraître luxueux, mais pourquoi pas ? Si les trains ont à la fois besoin de compétences OPS mutualisées au niveau de la Solution, tout en offrant une possibilité de satisfaire des demandes spécifiques, cette approche peut être intéressante.

Avantages : Les équipes ST au niveau des trains ont des périmètres plus réduits, ce qui favorise la réactivité et la maîtrise des connaissances et compétences nécessaires à chaque train.

Inconvénients : Il y aura mathématiquement un nombre d’équipes ST plus importants et des effectifs proportionnellement plus importants. Il y a un risque de zone de flou entre les périmètres des équipes au niveau des trains et de celle au niveau de la Solution. La multiplicité des équipes nécessite des synchronisations et des partages de connaissances plus fréquents entre les membres des différents équipes et apporte une certaine lourdeur à l’organisation.

Pour que ce scénario fonctionne, il faut une bonne répartition des responsabilités entre les équipes System Team.

En conclusion

En fonction du contexte et de la maturité de l’organisation, en fonction du type de produits et de solutions réalisés, nous voyons qu’il n’y a pas une seule manière de faire. La voie empruntée par les organisations est souvent un mix de scénarios, et la feuille de route est souvent ponctuée par des objectifs nécessitant la mise en place de transitions entre des scénarios.

Nous aurions pu évoquer également d’autres scénarios. Nous pensons en particulier à un scénario mixant à la fois des compétences OPS dans les équipes de réalisation, en charge d’une partie du processus d’intégration et de déploiement, et une équipe System Team en soutien sur des activités d’expertise ou d’appoint.

L’objectif ultime doit être toujours de rendre les équipes agiles les plus autonomes possible, et de faire en sorte qu’elles construisent et déploient en continu.

Lorsque l’agilité se déploie à l’échelle, une difficulté réside dans le fait de pouvoir faire travailler ensemble des équipes agiles et être en capacité d’intégrer les différents éléments d’un système produits par ces dernières. Autant l’agilité à petite échelle, c’est-à-dire au niveau d’une équipe, est bien maîtrisée aujourd’hui, autant la mise à échelle nécessite une organisation rigoureuse et une attention particulière. 

La System Team, un support aux équipes de réalisation

Ce que dit SAFe

Dans SAFe (le “framework” d’agilité à l’échelle le plus répandu), les équipes agiles ne sont pas des unités totalement autonomes. Au lieu de cela, elles font partie d’un ensemble que l’on appelle un Agile Release Train (ART). Ce train est responsable collectivement de la fourniture d’un système complet et d’une valeur de solution plus importants. Les pratiques de qualité intégrées nécessitent généralement un travail d’infrastructure supplémentaire pour créer, intégrer, déployer et publier des artefacts de solution plus fréquemment et en continu à travers plusieurs étapes d’une chaîne que l’on appelle pipeline. 

Pour soutenir cela, une ou plusieurs équipes systèmes spécialisées sont souvent formées, appelées System Team (ST). Concrètement, en tant que type d’équipe agile « habilitante », les System Team aident à créer les environnements et à intégrer le système et la solution. Les ST peuvent aussi accélérer les vitesses des équipes agiles en effectuant certains des tests les plus lents, de bout en bout et non fonctionnels (NFR). Elles aident également à faire la démonstration de la solution au fur et à mesure de son évolution.

Une mission claire, des responsabilités et des activités diverses et variées

Mission et responsabilités d’une System Team (toujours selon SAFe)

La mission d’une ST est d’aider à créer et à prendre en charge l’environnement de développement agile. Principalement, elle réalise le développement et la maintenance de la chaîne d’outils qui constitue le “pipeline de livraison continue”. Si besoin, elle prend en charge l’intégration des actifs des équipes agiles, effectue des tests de solution de bout en bout si nécessaire et aide au déploiement et à la publication des fonctionnalités à la demande (Deploy and Release). 

Sur l’intégration de l’infrastructure de développement agile, l’équipe doit créer et maintenir la chaîne d’outils du pipeline de livraison continue, y compris l’intégration continue, les builds automatisés, les tests de vérification de build automatisés et le déploiement automatisé. Elle doit créer des plates-formes et des environnements pour le développement, les démonstrations de solutions et les tests d’acceptation utilisateurs. Enfin, elle doit faciliter les aspects techniques de la collaboration avec des tiers, tels que les fournisseurs de données ou de services et les installations d’hébergement.

Sur l’intégration de la solution, l’équipe doit participer au PI Planning et aux événements pré et post-PI Planning dans la Large Solution SAFe et au raffinement du backlog pour définir l’intégration et tester les éléments du backlog. Elle doit déterminer et aider à maintenir les décisions et les politiques pour la gestion des versions. Elle doit exécuter des scripts de génération et d’intégration au niveau de la solution ou intégrer manuellement là où l’automatisation n’existe pas encore. Enfin, elle doit se tenir informée de l’avancement pour soutenir les activités quotidiennes des autres équipes.

Sur les tests de bout-en-bout de la solution, elle participe aux activités de test comme la création de nouveaux scénarios de tests automatisés, l’organisation des cas de test conçus par les équipes individuelles en suites ordonnées, l’exécution de certains tests manuels et des tests automatisés pour les nouvelles fonctionnalités, l’aide aux équipes dans la création de « smoke tests » ou de suites de tests réduits qui pourront être exécutés rapidement et indépendamment pour les versions des développeurs, le test des performances de la solution par rapport aux NFR (Non Functionnal Requirements) et le support aux System Architect (SA) et System Engineering (SE) du train et de la solution dans l’identification des lacunes et des goulots d’étranglement du système.

Sur la démonstration au niveau système et au niveau solution, l’équipe doit aider à préparer les environnements techniques pour une démonstration la plus fiable possible de la nouvelle fonctionnalité.

Sur la livraison de la solution, l’équipe doit soutenir l’ART ou le Solution Train pour préparer, packager et déployer une solution dans le cadre des activités DevOps et du pipeline de livraison continue.

La System Team, une équipe à géométrie variable

Nos retours d’expérience montrent que les System Team sont à géométrie variable en termes d’activités. Des équipes peuvent être plus ou moins engagées dans la réalisation des tâches d’intégration de la solution, la mise en oeuvre des tests de bout-en-bout ou les gestion des environnements de production et hors-production.

Composition et organisation d’une System Team

Une ST est une équipe agile spécialisée. Agile, cela veut dire qu’elle doit comprendre et appliquer le cadre de travail agile en mettant en œuvre les pratiques adéquates. Pour cela la présence d’un coach pour l’équipe est fortement conseillée en tant que garant et facilitateur. L’équipe System Team travaille sur le pipeline d’intégration continue (CI) et de déploiement continu (CD). Elle est en étroite collaboration avec les System Architect (SA) et les System Engineering (SE) du train. Agile, cela veut dire aussi qu’une personne de l’équipe doit jouer le rôle de « owner » pour définir la vision du produit de l’équipe (le pipeline CI/CD en l’occurrence) et sa feuille de route, gérer le backlog de l’équipe (maturation des sujets, priorisation des sujets en fonction de la valeur, …) et participer aux cérémonies de l’équipe et du train.

La System Team, des compétences d’OPS, mais pas uniquement !

SAFe n’impose pas de rôle particulier dans la ST, mais nous voyons bien que pour fonctionner correctement, cette équipe doit rassembler a minima des compétences d’OPS agissant sur l’infrastructure du système et des compétences d’architecture œuvrant sur la conception du système et l’environnement de développement agile. SAFe indique que des System Architect/ System Engineering peuvent faire partie de cette équipe mais cela ne revêt pas de caractère obligatoire. Il peut être intéressant que l’équipe dispose de compétences dans le développement avec des profils LeadDEV ou les techniques avec des LeadTECH.

Différentes configurations possibles dans l’organisation SAFe

Une ST aide un ou plusieurs ART à créer et à utiliser l’infrastructure de l’environnement de développement agile. SAFe laisse le choix du nombre et du positionnement des ST dans l’organisation agile. 

Plusieurs scénarios peuvent être envisagés :

• Scénario 1 : Il y a une équipe système par ART qui coordonne l’intégration et la validation de la solution
• Scénario 2 : Il existe une seule équipe système pour l’ensemble du train de solutions, qui peut assumer ces responsabilités pour tous les ART
• Scénario 3 : Il existe des équipes système pour les ART et le train de solutions

En fonction du contexte et de la maturité de l’organisation, en fonction du type de produits et de solutions réalisés, nous voyons qu’il n’y a pas une seule manière de faire. Il est fortement recommandé que l’organisation soit accompagnée par un coach agile ou le LACE dans SAFe.

Nous verrons dans un prochain article les avantages et les inconvénients de ces différents scénarios et nous décrirons plus précisément le fonctionnement d’une System Team aux travers des rôles et des activités de ses membres.

Article extrait de la série publiée par Modern Product Agility, dans la rubrique "ÉCLAIRAGE SUR L'AGILITÉ"

Une des caractéristiques des projets agiles, dits itératifs, incrémentaux et adaptatifs, est la réduction des cycles de développement et le découpage en itérations. Dans ce contexte, les équipes sont focalisées sur le court terme, et oublient souvent le moyen et le long terme.

Nul besoin de vous rappeler qu’il serait dangereux de se lancer sur un train d’itérations sans avoir défini de vision du produit et établi une feuille de route.

Lors de mes interventions, j’utilise souvent le Story Map pour préparer le projet et avoir une idée du périmètre macroscopique à adresser.

Avantages du Story Map

Le Story Map (ou carte d’histoires) est une technique qui permet la construction d’une feuille de route et offre de nombreux avantages.

Le Story Map donne :

• une meilleure explication de ce que doit faire le produit,
• de la visibilité en mettant en perspective les choses macroscopiques à faire dans le projet,
• une vue de l’avancement du projet, sur ce qui a été fait et sur ce qui reste à faire.

Le Story Map permet :

• une organisation et une priorisation à haut niveau des choses à faire dans le projet,
• une planification des versions du produit,
• une initialisation du Backlog Produit.

Construction du Story Map

Un Story Map est toujours constitué de deux dimensions.

• Une dimension temps ; axe horizontal
• Une dimension contenu ; axe vertical

Construction de l’axe horizontal

Sur l’axe horizontal, il y a plusieurs approches possibles pour la projection dans le temps :

• Soit par liste des macro fonctionnalités du produit, les « usages » (souvent celle que j’utilise)
• Soit par liste des caractéristiques du produit, les « features »
• Soit par liste des profils utilisateurs, les « rôles »

Une combinaison d’approches peut être réalisée sur cet axe.

Construction de l’axe vertical

Sur l’axe vertical, le contenu est déduit de la liste des items de l’axe horizontal par décomposition (il existe de nombreuses stratégies de raffinage que je ne présenterais pas ici). Le contenu est alors priorisé en fonction de la valeur métier.

Dans l’exemple ci-dessous, les macro-fonctionnalités (usages) ont été décomposées en histoires utilisateur.

Avec cette représentation, il est aisé de déplacer une colonne soit vers la droite, soit vers la gauche. Le déplacement d’une colonne sur l’axe horizontal implique automatiquement le déplacement de tout le contenu de l’axe vertical.

Introduction de la notion de version

Le découpage précédent avec des histoires utilisateur permet d’envisager la construction des versions du produit. Une version étant un regroupement de plusieurs itérations.

Il suffit de créer des lignes horizontales qui vont délimiter le périmètre de chacune des versions.

De même, avec cette représentation, il sera facile de modifier le contenu des versions en déplaçant les histoires d’une version à une autre sur l’axe vertical.

Initialisation du Backlog Produit

Avec cette carte d’histoires, vous avez obtenu en réalité votre première version du Backlog Produit. Il est alors très facile de construire les premiers items de votre Backlog et de les raffiner ensuite.

Voilà, vous savez presque tout sur cette technique !

N’hésitez pas à laisser vos commentaires et réactions.

Stéphane

Trop souvent, que ce soit dans le cadre de mes interventions ou lors de la lecture de différents articles trouvés çà et là sur le web, je constate que le terme exigence est utilisé de manière trop restrictive et uniquement pour représenter une condition ou une capacité que doit posséder un produit. Aléatoirement, les termes « besoin » et « exigence » sont employés pour désigner vaguement quelque chose exprimé par l’utilisateur d’un produit.

C’est oublier qu’une exigence, c’est aussi l’expression d’une condition ou d’une capacité qu’un utilisateur a besoin pour atteindre un objectif ou résoudre un problème.

Pour commencer à répondre à la question ci-dessus, il convient de revenir sur les définitions de ces deux mots.

Besoin

La définition du terme « besoin » dans le dictionnaire Larousse ne nous aide pas trop sur ce point et apporte même de la confusion puisque le terme « besoin » est défini en utilisant le mot « exigence ». Ainsi on y trouve la définition suivante « un besoin est une exigence née d’un sentiment de manque, de privation de quelque chose qui est nécessaire à la vie organique », ou bien « un besoin est une chose considérée comme nécessaire à l’existence ».

Dans la norme AFNOR X50-150, il est précisé qu’un besoin est une nécessité, un désir, un manque ou une insatisfaction éprouvé par un utilisateur, un client…, par ce que l’on appelle une partie prenante. Ce qui fait la spécificité d’un besoin, et cela constitue une différence majeure avec l’exigence, c’est qu’il n’est pas toujours exprimé !

Exigence

Pour le terme « exigence, et toujours dans le domaine normatif (ISO, IEEE, CMMi), il est souvent fait référence à deux niveaux d’exigences :

• L’exigence de niveau utilisateur ; qui exprime une attente ou un problème à résoudre de la part d’une partie prenante. Cette partie prenante peut être soit un utilisateur, un client ou une maîtrise d’ouvrage. L’exigence de niveau utilisateur appartient au domaine du problème et est exprimée dans le langage de la partie prenante considérée (ie. le client).
• L’exigence de niveau système ; qui exprime une condition ou une capacité que doit posséder un produit ou un composant de produit pour satisfaire un contrat, une norme, une spécification ou tout autre document imposé formellement. L’exigence de niveau système appartient au domaine de la solution et est exprimée dans le langage du fournisseur.

L’exigence de niveau utilisateur est donc bien un énoncé qui traduit un besoin de l’utilisateur. C’est une transformation du besoin en quelque chose. A la différence du besoin, ce quelque chose va respecter des critères qualité comme la concision, la non ambiguïté, la clarté, la précision…

On le voit, il y a donc une différence importante entre les deux notions…

Nous connaissons tous les valeurs agiles promues dans le Manifeste Agile pour le développement de logiciel de 2001 (http://agilemanifesto.org/) et reprises ci-dessous :

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan

Les signataires de ce Manifeste ont mis en avant l’équipe, le produit, la collaboration et le changement, mais ils n’ont pas oublié de mentionner la chose suivante : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. ».

Alors que l’ingénierie des exigences est une discipline qui commence à être reconnue par les organisations qui définissent et conçoivent des systèmes complexes, nous assistons dans le même temps à la montée en puissance de la gestion de projet agile.

Dans ce nouveau contexte organisationnel, nous ne pouvons pas nous empêcher de nous poser les questions suivantes : Retrouvons-nous les quatre valeurs de l’agilité en ingénierie des exigences ? Si oui sous quelle forme les trouve-t-on ? Et comment peuvent-elles être déclinées ?

L’équipe – Les individus et leurs interactions

En ingénierie des exigences, les parties prenantes constituent la source principale des exigences. Un objectif fondamental de l’ingénierie des exigences est de comprendre les désirs et les besoins des parties prenantes et d’en extraire des exigences. Les utilisateurs d’un produit, d’un système ou d’un logiciel sont également des parties prenantes et leurs exigences représentent des conditions ou des capacités requises pour résoudre un problème ou atteindre un objectif.

Le processus qui produit les exigences est un processus itératif et incrémental. Ce processus que l’on appelle couramment « processus de développement des exigences » est un processus cognitif qui repose sur une communication intensive et sur l’action réciproque entre les parties prenantes et l’équipe en charge de la définition et de la réalisation du produit. Les processus et les outils sont importants pour manipuler le contenu souvent complexe et soutenir ce processus cognitif.

Néanmoins, cette première valeur de l’agilité insiste sur le fait que les processus et les outils ne sont pas une fin en soi ; ils doivent être introduits de façon raisonnable et avec discernement, et doivent être utilisés avec soin et pragmatisme.

Le produit – Des logiciels opérationnels

L’ingénierie des exigences est la base de la compréhension des besoins des utilisateurs et de l’appropriation par l’équipe de développement de leurs exigences, afin qu’elle puisse construire le bon produit. La valeur principale de la discipline et le facteur principal de la réussite d’un projet résident dans la connaissance des besoins des parties prenantes. L’interaction avec et entre les membres de l’équipe partageant la connaissance est une façon de préserver cette connaissance.

L’agilité met en avant le logiciel opérationnel au détriment de la documentation et considère que la documentation n’est pas une fin en soi. Contrairement aux idées reçues, cela ne veut pas dire qu’il n’y a pas de documentation dans un projet agile, mais que cette documentation sera réalisée avec parcimonie et en particulier, en fonction de la nécessité ou non de capitaliser sur la connaissance.

Par définition, une exigence est une représentation documentée d’une condition ou d’une capacité. Aussi, en agilité, la documentation des User Stories dans le Backlog du produit est déjà une première étape de la documentation des exigences. C’est le « contrat » minimal entre le Product Owner et l’équipe en charge de la réalisation du produit.

N’oublions pas que dans certains domaines spécifiques tels que le médical, l’automobile ou l’aéronautique, la conformité et les contraintes réglementaires définissent des normes sous forme de spécification, ce qui exige l’existence d’une documentation écrite par rapport aux exigences.

La collaboration – La collaboration avec les clients 

Le socle des connaissances en ingénierie des exigences aborde le sujet de la collaboration avec le client dans les activités d’élucidation et de négociation des exigences. Les objectifs de ces activités couvrent des principes importants de l’agilité et les éléments utilisés dans les projets agiles, tels que la communication directe, les personas, les techniques de créativité, l’enquête contextuelle, les User Stories, … font partie des techniques et des outils de l’ingénierie des exigences.

Afin de faire adhérer l’équipe à l’idée de collaboration, il est important de disposer d’un référentiel unique de l’information. Ce référentiel devra être partagé entre toutes les équipes, unique et centralisé, organisé et structuré… Une partie de ce référentiel sera constituée d’exigences.

Avec son schéma de certification, l’IREB(*) offre un module de niveau avancé traitant de l’élucidation et de la consolidation des exigences avec les parties prenantes et les utilisateurs. Ce module de niveau avancé met l’accent sur les valeurs agiles et la collaboration entre les équipes.

Le changement – L’adaptation au changement

Les démarches agiles comme Scrum ou Kanban fournissent une réponse aux changements comme principe de base des valeurs agiles au travers de méthodes spécifiques, de techniques et de bonnes pratiques. Les modèles de cycle de vie agiles donnent des conseils sur comment et quand appliquer ces méthodes, techniques et bonnes pratiques.

Le fait de répondre au changement n’est pas une spécificité de l’agilité. A sa manière, la discipline de l’ingénierie des exigences au travers des activités de gestion des exigences (traçabilité, analyse d’impact, versionnement des exigences…) répond à cette nécessité. L’ingénierie des exigences offre également des méthodes spécifiques et des techniques qui soutiennent cette prise en compte du changement.

En conclusion, nous pouvons affirmer que l’ingénierie des exigences et la gestion de projet agile ne sont pas incompatibles. Le socle des connaissances en ingénierie des exigences est tout aussi important et pertinent dans le modèle de cycle de vie en cascade ou en V que dans l’agile. Les aspects collaboration et communication sont très présents dans l’un et l’autre, et la satisfaction des utilisateurs constitue un objectif commun. Des adaptations sont néanmoins nécessaires et se traduisent par des activités d’ingénierie menées avec des intensités variables, des techniques et des outils différents, des rôles des acteurs redéfinis.

Article inspiré du document IREB(*) « Ingénierie des exigences et développement agile ».

(*) IREB = International Requirements Engineering Board (www.ireb.org)

C’est une question qui se pose naturellement lorsqu’une organisation souhaite mettre en place l’agilité dans ses projets. Pour y répondre, il convient de revenir aux fondamentaux de l’ingénierie des exigences.

Revenons à la notion d’exigence. L’exigence est une « caractéristique observable de l’extérieur d’une entité souhaitée » (Alan Davis). C’est donc une vue « boîte noire » d’un produit. Une exigence ne doit pas décrire l’intérieur de la boîte mais uniquement ce qui est visible de l’extérieur. Par conséquent, une exigence n’est pas et ne doit pas être une description d’une solution concrète. Partant de cette définition, et compte tenu qu’un produit (un système) est souvent décomposer en sous-systèmes, nous constatons que plusieurs niveau d’exigences peuvent coexister, tout va dépendre de l’endroit où se porte l’attention.

L’exigence représente le QUOI. Elle doit être justifiée et doit par conséquent être reliée à un objectif de haut niveau d’une partie prenante, le POURQUOI. L’exigence ne décrit pas le COMMENT. Le COMMENT doit être décrit dans les spécifications de conception, d’architecture, de tests…

POURQUOI ? (pour quelle raison)            objectifs

QUOI ?                                                            exigences

COMMENT ?                                                  spécifications

Les normes internationales (IEEE, CMMi, ISO) ont défini le terme exigence en utilisant trois définitions complémentaires :

1. Une exigence est une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.
2. Une exigence est une condition ou une capacité que doit posséder un produit (ou un composant de produit) pour remplir un contrat, se conformer à une norme ou tout autre document imposé formellement.
3. Une exigence est une représentation documentée d’une condition ou d’une capacité du cas 1 ou du cas 2.

Cela montre clairement qu’il y a deux niveaux d’exigences à considérer pour un produit. En ingénierie des exigences, nous avons l’habitude de distinguer les « exigences utilisateur » (dans le cas 1) et les « exigences système » (dans le cas 2).

Les « exigences utilisateur » traduisent le problème à résoudre, l’opportunité à saisir pour un utilisateur, c’est le domaine du problème. Elles doivent être reliées à des objectifs de haut niveau que nous appelons des « buts ». Les exigences de haut niveau (les buts) sont décomposées en exigences plus fines par un mécanisme de scénarisation. La scénarisation permet d’envisager les différentes manières d’atteindre le but de haut niveau.

Selon l’IREB, les exigences utilisateurs peuvent être décrites sous la forme de buts et de scénarios. Les scénarios peuvent être regroupés en cas d’utilisation. Le niveau de granularité des exigences utilisateurs les plus fines peut être obtenu au niveau d’une étape d’un scénario.

Les « exigences système » sont une réponse aux « exigences utilisateur », c’est le domaine de la solution. On dit généralement que les « exigences système » satisfont les « exigences utilisateur ». Les deux niveaux d’exigences représentent toujours une vue « boîte noire » de notre système.

Dans une approche agile, le focus est mis sur les exigences de l’utilisateur et la valeur délivrée. La notion de User Story est très souvent employée pour décrire ce que souhaite l’utilisateur d’un produit. Elle s’exprime sous la forme :

« En tant que <utilisateur>, je souhaite <faire cela> afin de <atteindre un objectif>. »

Nous voyons que dans l’expression d’une User Story, un parallèle assez évident peut être fait entre le besoin de l’utilisateur <faire cela> et l’exigence utilisateur (le cas 1 défini plus haut), et <atteindre un objectif> avec un but de haut niveau.

Lors de l’identification des User Stories, il arrive très souvent que le souhait de l’utilisateur soit exprimé de manière très macroscopique, comme par exemple « En tant que conseiller de clientèle, je souhaite simuler un crédit à la consommation afin de proposer une offre à mon client. ». Cette User Story est trop « grosse » pour être réalisée dans une seule itération, il va donc être nécessaire de la découper en User Stories plus petites, c’est ce que l’on appelle le « grooming ». Ces User Stories macroscopiques sont souvent appelées soit des Thèmes, soit des Epics. Les Thèmes et les Epics peuvent être considérés comme des buts de haut niveau pour l’utilisateur. Lors du raffinage des Thèmes & Epics en User Stories, une démarche de type « scénarisation » doit être utilisée.

Dans Scrum, la décomposition des Thèmes & Epics en User Stories est réalisée en collaboration entre un Product Owner et l’équipe de réalisation.

J’ai un produit complexe à concevoir, quelles sont les questions essentielles à se poser ?

• quel problème dois-je résoudre ? quel est l’objectif à atteindre ?
• pourquoi dois-je concevoir ce produit ? quelle est sa justification ?
• que doit faire le produit pour atteindre l’objectif ? comment doit-il se comporter ?
• comment savoir si l’objectif est atteint ?
• quel risque vais-je prendre pour atteindre l’objectif ?
• comment vais-je le réaliser ?
• combien la réalisation du produit va-t-elle me coûter ?
• quand et sous quelle forme vais-je pouvoir livrer le produit ?

Lorsque la User Story est dimensionnée pour pouvoir être réalisée dans une itération, l’équipe de développement réalise une décomposition en tâches. Les tâches vont permettre la réalisation des US. Il est important à ce stade de se concentrer sur ce que doit faire le système pour satisfaire la US et comment il doit se comporter. C’est à ce niveau qu’apparaissent alors les exigences système. Les exigences système décrivent les fonctions et les interfaces du futur système. Les tâches étant en réalité la manière de réaliser les exigences système.

Cette notion d’exigence système dans un projet agile est très importante et souvent sous-estimée car c’est sur la définition de ces exigences que sera réalisé le futur système. Le référentiel d’exigences système constituera une référence pour les demandes de changements et l’analyse d’impact des modifications qui ne manqueront pas d’arriver sur le projet. Le référentiel d’exigences système est également le point de départ pour la capitalisation et la réutilisation des exigences.