Partager!

Prenons les choses étape par étape, être agile ne change rien ou presque à la nécessité de documenter les exigences. Peu importe le nom ou la structure que nous utilisons. Nous les appelons épopées, user stories ou exigences. Nous les utilisons dans le cadre d'opérations, de projets ou d'innovations. Documenter ces structures, nos besoins ou la manière dont nous allons exploiter les opportunités que nous identifions est fondamental pour toute initiative. Et je n'entends pas par là le seul but de communiquer aux autres ce que nous pensons, j'inclus également le processus de documentation pour l'avenir. La documentation est un processus qui consiste à envisager l'écriture et, ce faisant, nous structurons souvent mieux nos pensées, sans le vouloir.

Un peu d'histoire pour commencer. Le développement de logiciels est aujourd'hui, et a toujours été, un grand défi de communication entre les personnes. Depuis l'époque des cartes perforées, les programmeurs, ceux qui sont capables de créer des programmes pour les ordinateurs, et les concepteurs, ceux qui sont incapables de créer des programmes, mais qui ont de bonnes idées pour exploiter la puissance de calcul des machines, ont eu du mal à "s'entendre".

Exigences

De nombreux outils ont été créés pour résoudre ce problème de communication, et le concept de base qui le sous-tend est connu sous le nom d'"exigence" logicielle.

Dans l'ingénierie du développement des systèmes, un exigence est une exigence documentée concernant le contenu, la forme ou la fonctionnalité d'un produit ou d'un service. Il est utilisé dans un sens formel dans le ingénierie des systèmesingénierie logicielle e ingénierie des exigences.

Wikipedia (avril 2020) - https://es.wikipedia.org/wiki/Requisito_(sistemas)

Pourquoi est-il si difficile de rédiger des exigences ?

Il existe de nombreuses théories sur la complexité des exigences. Toutefois, pour illustrer mon propos, je veux utiliser un concept que j'ai toujours trouvé fabuleux : intégrité conceptuelle de Fred Brooks. Il s'agit de la capacité d'une personne ou d'un très petit groupe de personnes à contenir l'ensemble de la conception d'un système, d'un produit ou d'un modèle.

Dans un de ses livres - la conception de la conception - soulève l'intégrité conceptuelle à l'aide d'un exemple : réfléchissez un instant à qui a inventé l'ampoule électrique, le téléphone, le télégraphe ou l'avion. Dans tous ces exemples, il est facile d'identifier l'inventeur. Cependant, lorsque la complexité du système à concevoir augmente considérablement, il est presque impossible pour une seule personne d'avoir le détail de tous les composants dans sa tête. À ce stade, le maintien de l'intégrité conceptuelle est un véritable défi.

Si le problème n'est toujours pas clair, pensez à un livre que vous avez lu et dont vous avez discuté avec quelqu'un d'autre : quelle est la probabilité que votre image mentale des personnages et des motivations de l'autre soit exactement la même que celle de l'autre personne ? AUCUNE ! Et nous parlons de livres qui font des centaines de pages.

Un étudiant m'a dit un jour en classe alors que nous examinions ce concept : "le problème [de l'intégrité conceptuelle] est que d'autres personnes sont amenées à penser". Bien que je comprenne votre motivation personnelle et la frustration que peut générer le fait que les différentes interprétations ne concordent en aucune façon, nous ne pouvons pas prôner l'idée de "cesser de penser". Ce que nous recherchons est précisément le contraire, nous voulons que chaque membre de l'équipe réfléchisse.

Collaboration ou jeu des reproches

Un autre aspect à prendre en compte pour déterminer les outils à utiliser pour faciliter la communication entre "ceux qui ont les idées" et "ceux qui peuvent les réaliser" est l'étendue de cette collaboration. En d'autres termes, le degré de collaboration et de confiance entre les membres d'une équipe et au sein d'une organisation.

La confiance exige la sécurité psychologique au sein des membres de l'équipe et d'une organisation ou d'une entreprise. La sécurité psychologique est un terme inventé par Amy C. Edmondson, professeur à la Harvard Business School. Edmondson, professeur à la Harvard Business School, qui influe sur notre façon de communiquer et - en particulier - de le faire pendant les processus créatifs ou la construction de nouvelles solutions.

Dans un environnement à faible sécurité psychologique, les membres d'une équipe ou d'un groupe de travail ne se font pas confiance. Lorsqu'une menace se présente, qu'il s'agisse d'un problème, d'une erreur ou d'une mauvaise interprétation, les individus cherchent à se "décharger de la responsabilité" sur les autres. Si cette situation se produit régulièrement, les exigences deviennent le "contrat" qui régit la relation. Le résultat est que les documents qui modèrent la conversation entre les parties deviennent plus détaillés et explicatifs. Comme essayer de "documenter" à qui revient la faute si quelque chose ne va pas.

Cas d'utilisation

Ils constituent la documentation étape par étape de l'interaction d'un utilisateur avec un système d'information. La description de ce pas à pas, clic par clic et moment par moment, a fait place aux cas d'utilisation. Un UC - ou cas d'utilisation - contient des informations détaillées sur les flux d'interaction d'un type d'utilisateur (Acteur), presque toujours sous la forme d'une conversation :

  • L'utilisateur effectue une action X
  • Le système en cours de conception (SuD) effectue l'action Y
  • L'utilisateur effectue une action Z

Je pense qu'ils ont compris. A cette conversation entre l'utilisateur et le système, ils ont inclus :

  • Voies d'exception - ce qui se passe si quelque chose se passe différemment dans l'une des étapes,
  • Cas de test - discussions sur la façon de valider chacune des étapes,
  • Descriptions,
  • Images

L'un des meilleurs livres pour documenter de bons cas d'utilisation m'est venu de la main d'un grand entrepreneur... Alex Torrenegra - quand j'essayais encore de coder pour vivre : Rédaction de cas d'utilisation efficaces par Alistair Cockburn.

Pour

  • La CU est très précieuse lorsque les systèmes que nous concevons (SuD) sont extrêmement complexes.
  • Lorsque l'équipe chargée du développement ne connaît pas le fonctionnement de SuD. Par exemple, lorsque nous avons de nouveaux membres, de nouvelles équipes ou lorsque nous intégrons de nouveaux fournisseurs dans notre structure de développement.
  • Ils fournissent un niveau de détail clair sur ce qui est attendu dans les écrans, les séquences et les processus d'un système complexe.
  • Ils laissent peu de place à la créativité et à la pensée divergente.

Cons

  • Les CU ne laissent aucune place à la proposition d'améliorations, à la créativité ou à la pensée divergente en général.
  • Ils ne permettent pas de discuter ouvertement de nouvelles idées en matière de convivialité, de fonctionnalité ou de performance.
  • Les UC dépendent fortement de l'intégrité conceptuelle.

Des environnements innovants pour les récits d'utilisateurs

Dans des environnements plus incertains, où les exigences ne sont pas claires, il peut être difficile, voire impossible, d'avoir un niveau de détail précis. Par exemple, lorsqu'on travaille à la découverte ou à la conception d'un nouveau produit, la définition détaillée des exigences peut devenir un casse-tête ou être très contraignante pour l'équipe.

Histoires d'utilisateurs

Afin d'encourager la participation de tous les membres et de promouvoir la pensée divergente, de nouveaux modèles de documentation sont apparus, beaucoup plus légers et orientés vers la promotion de discussions apportant de la valeur à la solution. L'eXtreme Programming (XP), un processus de développement logiciel agile né dans les années 1990, a proposé l'utilisation de User Stories (US).

Les histoires d'utilisateurs ont le même objectif que les cas d'utilisation, mais ne sont pas les mêmes. Ils sont utilisés pour créer des estimations de temps pour la réunion de planification de la version. Ils sont également utilisés à la place d'un grand document d'exigences. Les histoires d'utilisateurs sont écrites par les clients comme des choses que le système devrait faire pour eux. Ils sont similaires aux scénarios d'utilisation, sauf qu'ils ne se limitent pas à la description d'une interface utilisateur. Ils se présentent sous la forme d'un texte d'environ trois phrases rédigé par le client dans sa terminologie, sans détails techniques.

eXtreme Programming (avril 2020) - http://www.extremeprogramming.org/rules/userstories.html

Contrairement aux cas d'utilisation, les États-Unis encouragent plusieurs choses :

  1. Se concentrer sur l'objectif (l'opportunité ou le besoin à résoudre) plutôt que sur le comment.
  2. Garder le cap sur la cible favorise les solutions innovantes
  3. simplifie le fait que les utilisateurs, les clients et les parties prenantes n'ont pas besoin de connaître le système pour proposer des idées ou demander de nouvelles fonctionnalités
  4. La conversation, la discussion et le débat sur la façon de résoudre ou de compléter un US sont les bienvenus - ce qui, dans UC, peut arriver, mais ressemble presque toujours plus à une "explication du flux" qu'à une véritable discussion d'égal à égal.

Pour

  • Les États-Unis encouragent la pensée divergente et les solutions créatives.
  • Ils permettent des propositions différentes - et certainement plus efficaces - aux problèmes ou aux besoins posés.
  • Augmenter la productivité des équipes - des équipes matures et bien coordonnées
  • Promouvoir la participation des clients - et des autres parties prenantes - en étant simples à rédiger (ce qui réduit les obstacles à la participation et à la contribution).

Cons

  • Des équipes non alignées peuvent violer des conceptions ou des architectures d'applications conçues à grande échelle - dans de grandes organisations.
  • Forcer l'utilisation de l'US peut être un véritable casse-tête - en raison du manque même de détails. Par exemple, j'ai vu une fois une équipe qui essayait d'utiliser les États-Unis pour décrire les opérations de BI et d'analyse.
  • Nombreux sont ceux qui pensent que les US ne peuvent pas coexister dans le même Backlog - une liste hiérarchisée d'exigences ou de travaux à effectuer - avec d'autres instruments tels que les tâches, les cas d'utilisation ou les exigences techniques (NFR).

Si vous voulez en savoir plus sur la façon d'écrire de bonnes histoires d'utilisateur, je vous recommande de lire le livre de Mike Cohn intitulé "Angular" User Stories : Application des User Stories. Je décerne une mention bien méritée à deux Colombiens (Lucho Salazar y Jorge Abad) qui ont fait un excellent travail avec leur publication Histoires d'utilisateurs : une vue pragmatique.

Modélisation agile

La modélisation agile fait référence à l'utilisation d'autres instruments et outils pour documenter les exigences - principalement les exigences logicielles. Ils peuvent être compris comme une sorte de "pack d'extension" à des cadres tels que XP ou Scrum. D'après mon expérience, les outils complémentaires les plus utiles à l'heure actuelle sont :

Échelle et désagrégation, au-delà des histoires d'utilisateurs

Cependant, l'utilisation d'un seul instrument dans le Backlog - ou leur description sur une même échelle - est inefficace lorsque nous avons des horizons temporels différents dans le même instrument. En d'autres termes, le Backlog comprend des exigences qui sont si claires et si importantes qu'elles doivent être exécutées et achevées dans les prochaines semaines ; il peut également inclure des éléments qui ne sont que de vagues idées.

Ces "annotations" au Backlog ressemblent plus à un "rappel" pour une discussion future - à mon avis très personnel, et peut-être influencé par les outils de gestion informatisés, on devrait toujours écrire toutes les idées et tous les concepts ayant le potentiel de devenir réalité dans le Backlog et ne pas se fier à la mémoire humaine.

Par conséquent, l'ampleur de l'effort et la complexité d'un élément du backlog peuvent prendre en compte de nombreuses exigences - sous la forme d'histoires ou de cas d'utilisation, ou de simples tâches - je m'écarte ici des puristes radicaux. Dans leur empressement à nommer différentes échelles de détail et d'ampleur, et à indiquer clairement que ces éléments doivent être décomposés, des concepts tels que les épopées, les caractéristiques et les capacités ont été créés. Épopées, Caractéristiques y Capacités.

Conseils pratiques: Utilisez les noms Epic, Trait et Ability comme bon vous semble, mais ne les intervertissez pas pour ne pas créer de confusion. Vous pouvez en utiliser un, vous pouvez en utiliser plusieurs, vous pouvez utiliser ceux-ci et d'autres encore. Ne vous compliquez pas la vie, donnez simplement à chaque terme un contexte et une utilisation spécifiques.

Epic

Une excellente idée que l'équipe de Scaled Agile Framework a consisté à définir des objectifs spécifiques pour chaque instrument - ainsi que des objectifs dans les délais de planification et de mise en œuvre. Sans être le seul moyen, il me semble que c'est la meilleure façon (jusqu'à présent) de différencier chaque échelle.

Dans ce cadre de référence, le épique sont des instruments permettant de définir les investissements de portefeuille - pour des raisons de marketing et de distanciation par rapport au PMI, toujours à la traîne, ils ont décidé de ne pas utiliser le mot "projet". Les épopées sont alors des composantes d'un portefeuille ou d'un programme qui incluent la validation d'hypothèses techniques ou commerciales - similaires à une analyse de rentabilité Agile. Ils insistent sur le fait que les épopées et les projets ne sont pas les mêmes, mais, tout comme j'ai mes différences personnelles avec la "philosophie PMI", j'en ai aussi avec la "philosophie SAFe".

Au sein d'une Epic, nous pouvons examiner de nombreux éléments, certains visant à réduire les risques, d'autres à renforcer nos capacités organisationnelles ou techniques, et d'autres encore à atteindre les objectifs stratégiques.

Caractéristiques Caractéristiques

Cependant, une épopée définie dans ce contexte semble bien éloignée du travail que font les équipes agiles. C'est pourquoi nous avons besoin d'instruments intermédiaires qui relient l'échelle stratégique à l'exploitation et à la réalisation de cette valeur commerciale. C'est là que, à mon grand dam, ils ont utilisé des termes qui sont étroitement liés au développement de produits : le caractéristiques.

Les fonctionnalités sont deux choses, une exigence de haut niveau, quelque part entre les Epics et les Stories, et représentent donc aussi un ensemble d'éléments de Backlog qui est un instrument proche de l'équipe - bien que dans SAFe ils définissent d'autres Backlogs de haut niveau. Ce qui est intéressant, c'est la relation temporelle qu'ils essaient d'établir entre les articles et les reportages.

Capacités Capacités

Dans SAFe, il existe un outil d'agrégation supplémentaire connu sous le nom de capacitédont la différence la plus notable avec le caractéristiques est qu'il est réalisé grâce au travail de différents ARTs - un terme désignant une équipe agile à grande échelle axée sur un produit, un service ou une chaîne de valeur.

Instruments de planification

Rappelons que les éléments du backlog sont des instruments permettant d'identifier la valeur et de maintenir l'alignement entre l'objectif et la livraison - un concept qui prend de l'ampleur dans le monde qui promeut le "flux de valeur commerciale". De même, ces éléments sont très utiles pour fixer des horizons temporels et, qu'on le veuille ou non, des jalons commerciaux.

Il est très utile d'avoir des éléments qui représentent différentes échelles d'effort pour établir la cadence de livraison. Pour citer un exemple, nous pouvons examiner la proposition de Scaled Agile Framework:

  • Les itérations de deux semaines (les itérations plus longues me semblent inutiles, je préfère les itérations d'une semaine) devraient donner lieu à plusieurs témoignages d'utilisateurs.
  • Cycles de 5 ou 6 itérations ou sprints pour fournir diverses fonctionnalités et capacités (incrémentalisme du programme dans SAFe).
  • Une année pourrait permettre de livrer, de résoudre ou de traiter plusieurs Epics (portefeuille Lean).

Conclusions et considérations

Le défi est le même : maintenir l'intégrité conceptuelle entre les parties prenantes - les êtres humains merveilleux, divers et dispersés - et faciliter et promouvoir le développement des "meilleures solutions possibles" - techniques, économiques, fonctionnelles et conviviales. Il existe des instruments qui limitent la créativité et la pensée divergente - très utiles pour résoudre des problèmes complexes pour lesquels les équipes ne disposent pas de l'expertise et/ou des connaissances nécessaires, ou pour lesquels il n'est tout simplement pas pratique de proposer des solutions différentes ou de favoriser l'interprétation - comme les calculs avancés avec des données, les rapports et les processus commerciaux étroitement réglementés. Il existe des outils qui favorisent la pensée divergente et les solutions innovantes, qui contribuent à la création de nouveaux et meilleurs produits, et qui posent des mécanismes d'alignement mental - tels que les Personas agiles - pour renforcer l'intégrité conceptuelle.

Ces outils, tels que les user stories, sont également utiles en fonction des stades de maturité de l'équipe et des connaissances des membres sur le système lui-même. Imaginez un groupe de "nouveaux venus" sans expérience préalable essayant de concevoir un système au sein d'une organisation ayant de fortes contraintes de conception ou des limitations techniques - comme les systèmes existants - au moment des histoires d'utilisateurs - ce serait frustrant !

À l'inverse, imaginez un groupe expérimenté de collègues proches essayant de résoudre un défi en suivant les traces de quelqu'un qui n'est pas avec eux - ennuyeux ! - Nous devons toujours trouver un équilibre entre les compétences et les défis et ces outils peuvent être utiles à chaque étape de chaque cycle.

D'autres instruments n'existent que pour nous permettre de gérer différentes échelles d'effort et/ou de temps, comme les épopées et les caractéristiques. Ils sont utiles pour gérer des équipes multiples à un niveau élevé et pour communiquer des intentions, des buts et des objectifs valables.

En guise de conclusion, je vous laisse avec cette courte vidéo sur le concept d'intégrité conceptuelle. Rien d'aussi profond et radical que la vidéo d'Amy.

À l'avenir, nous verrons certainement apparaître de nouveaux moyens de communiquer et de documenter nos besoins, et j'espère être là pour les utiliser et en tirer le meilleur parti.

Partager!

Image par défaut
Alberto Dominguez
Diriger des équipes de la théorie à la réalisation réelle et durable de produits et services informatiques innovants.
Publications: 33

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

fr_FR