Comment fonctionne la gestion des exigences sur le long terme avec les projets Agile?

La gestion des exigences à court terme pour les projets Agile me semble être un problème résolu.

Sous l'angle Scrum, de nouvelles exigences ou des modifications apportées aux exigences existantes sont fournies via User Stories. Et les histoires d'utilisateurs regroupées sous une épopée ou une fonctionnalité facilitent la livraison d'exigences plus complexes et plus importantes.

Bien sûr, une User Story n'est pas techniquement un document d'exigences. Il s'agit d'un regroupement gérable de travaux qui correspond à ce que l'on appelle souvent une tranche verticale de fonctionnalités. Et la portée de ces histoires peut être définie sans ambiguïté grâce à l'utilisation des critères d'acceptation (AC).

Ainsi, bien que les User Stories ne soient pas des exigences formelles, leur navigation peut vous donner une idée assez claire de leurs exigences sous-jacentes. À court terme.

Je dis à court terme car, au fur et à mesure de l'avancement d'un projet, le nombre de User Stories augmente. Ainsi, parcourir une liste sans cesse croissante d'histoires pour trouver une exigence devient de moins en moins efficace au fil du temps.

Ce problème est aggravé lorsque vous envisagez des histoires d'utilisateurs qui se développent, remplacent ou annulent même les histoires précédentes.

Imaginez maintenant un écart de 2 ans entre les itérations de développement d'un projet (stable en production). L'équipe d'origine a disparu, tout comme toutes leurs connaissances.

Si l'équipe d'origine savait que cela allait se produire (par exemple, c'est la nature de l'entreprise), quelles mesures pourraient-elles prendre pour aider les équipes suivantes?

Bien sûr, l'arriéré fournira des informations, mais ce n'est guère sous une forme facilement consultable.

Alors, que peut-on faire pour aider les équipes suivantes à comprendre l'état du projet, y compris pourquoi et comment il y est arrivé?

D'après mon expérience, les choses suivantes ne fonctionnent pas:

• Préparation du backlog pour supprimer ou mettre à jour les user stories précédentes afin que le backlog puisse être lu comme un document d'exigences.
• Documentation Sprints où les membres de l'équipe sont chargés de documenter l'état actuel du système.
• Documentation via des tests de comportement . Cette approche est la seule que j'ai vue proche de fonctionner. Malheureusement, les tests de comportement codé sont victimes du problème de dénomination. Bien que les tests puissent documenter correctement le système, il est presque impossible d'obtenir une équipe fluctuante de développeurs pour écrire leurs tests en suivant la même terminologie, formulation et style de domaine.

Donc, pour réitérer:

Comment gérer à long terme les exigences d'un projet Agile?

Cela me semble être l'éléphant tacite dans la pièce avec les projets Agile: comment les empêcher d'évoluer en chaos?

Regardons le Manifeste Agile un instant. Désirs agiles:

1. Livraison précoce et continue
2. Adopter des exigences changeantes
3. Fournir fréquemment des logiciels fonctionnels
4. Les développeurs et les acteurs commerciaux travaillent ensemble quotidiennement
5. Construire des projets autour d'individus motivés, leur donner l'environnement et le soutien dont ils ont besoin et leur faire confiance pour faire le travail
6. La conversation en face à face comme principal mode de communication
7. Un logiciel de travail comme principale mesure de progrès
8. le développement durable
9. Une attention continue à l'excellence technique et à une bonne conception
10. Simplicité - Maximiser le travail que vous n'avez pas à faire
11. À intervalles réguliers, l'équipe réfléchit à la façon de devenir plus efficace, puis ajuste et ajuste son comportement en conséquence

J'ai mis en évidence les quatre derniers. Pourquoi? Parce que ce sont eux qui empêcheront le projet de s'effondrer sous son propre poids.

Le développement durable signifie que vous (espérons-le) avez quelqu'un qui supervise le processus de développement global, quelqu'un qui peut diriger le navire au-delà de la croissance du logiciel un peu à la fois, quelqu'un qui a une vision globale de l'ensemble du projet, quelqu'un avec une connaissance approfondie d'architecture logicielle, de conception de système, de principes de logique métier et d'ergonomie de l'interface utilisateur. Un architecte, en d'autres termes.

L'architecte est celui qui dit: "Je sais que vous l'avez demandé, mais si nous construisons cette autre chose, nous pouvons éviter ces trois autres fonctionnalités qui sont tout simplement déroutantes et nous concentrer sur l'exigence de base." C'est lui qui donne le temps à l'équipe de réduire sa dette technique. C'est lui qui apporte une structure et une organisation globales au projet. C'est lui qui appelle les réunions où l'équipe se réunit et demande "Comment pouvons-nous faire mieux?"

Et c'est lui qui gère le document des exigences principales.

Dans le livre Mastering the Requirements Process , les auteurs soutiennent qu'il existe trois types de clients, trois types de projets logiciels: Rabbits, Horses et Elephants. Les lapins sont les petits projets logiciels qui n'ont besoin que d'exigences informelles; vous travaillez directement avec le client en petits sprints, la portée du projet est raisonnablement limitée, et le logiciel se fait dans un délai relativement court. Les éléphants sont ces projets gigantesques qui nécessitent beaucoup de planification initiale, une énorme quantité de documentation et un horizon à long terme. Ils ne sont sans doute pas agiles, bien que vous puissiez les diviser en projets plus petits qui peuvent être construits en utilisant Agile.

Ce sont les projets Horse qui sont quelque peu déroutants d'un point de vue agile. Ils peuvent toujours être construits de manière itérative, vous pouvez toujours utiliser des sprints courts, mais sans une certaine discipline dans les processus de collecte et de planification des exigences, ils peuvent facilement dérailler. Ce sont les projets qui peuvent bénéficier d'un processus discipliné de collecte des exigences, puis d'une adaptation et d'une modification minutieuses de ces exigences au fur et à mesure que le projet se développe, tout en conservant une vision globale pour l'ensemble du projet.

D'un point de vue personnel, je travaille avec une petite équipe d'une dizaine de développeurs. À tout moment, nous pourrions travailler sur trois projets logiciels en même temps, allant de quelques milliers de lignes de code à plus de 100 000. Notre client pense que c'est un lapin, mais c'est vraiment un cheval. Le client est engagé, mais pas au quotidien.

De loin, notre domaine le plus faible est la collecte d'exigences spécifiques, testables et mesurables et la gestion des attentes du client par rapport à la portée du projet. Mais nous y travaillons.

La question n'est pas complètement claire, mais il semble que vous vous souciez de la traçabilité des exigences . D'après mon expérience, une idée qui a tendance à se perdre dans Agile est que les exigences métier sont ce que le client veut que le système fasse, tandis que les user stories sont vraiment des exigences fonctionnelles qui indiquent comment le système fonctionne. "En tant qu'utilisateur, je veux pouvoir X." Mais cela est fait pour satisfaire une exigence, qui peut être perdue dans la user story.

Ce qui fonctionne bien dans mon expérience, c'est de lier les exigences de l'entreprise et les histoires d'utilisateurs dans les deux sens. Le BR # 1 peut être réalisé par les histoires A et B. L'histoire C pourrait couvrir les BR # 2 et # 3. Mettez cela dans votre outil de suivi de projet, dans votre feuille de calcul, quoi que vous utilisiez.

À long terme, cela permet de relier ce que le client demande (BR) à ce que le système fait (histoires) pour répondre à ces exigences. Il devrait s'agir d'une documentation assez minimale qui n'est pas trop lourde à maintenir, conformément à la mentalité Agile de ne pas produire de documentation dont personne n'a besoin et est une corvée à tenir à jour.

Il fournit également un moyen pour les nouveaux membres du projet d'accélérer car ils ont quelque chose à examiner pour obtenir l'historique des raisons pour lesquelles le logiciel fait ce qu'il fait.

Je travaille actuellement sur un projet de maintenance kanban d'une grande boutique en ligne où les développeurs originaux ne sont plus disponibles.

chaque utilisateur / exigence / correction de bogue a un numéro de ticket et chaque changement de code source est lié à un numéro de ticket dans le champ de commentaire de contrôle de source.

sourcecontrol-checkin-s (svn) met à jour automatiquement le ticket correspondant afin que dans le ticket j'ai un lien vers tous les sets de modifications sourceconrtol.

Si un module / fonction est nouvellement implémenté, il y a aussi des numéros de ticket dans le code source.

Dans le système de tickets (redmine), les tickets sont liés entre eux comme (est en double, est un bug, est un raffinement de, ....)

afin que vous puissiez suivre les tickets et voir les modifications des exigences au fil du temps.

Exemple: je dois modifier quelque chose dans la "page Web orderConfirmation". Dans le code source de la page, je vois un commentaire: 'créé pour "# 4711"' afin que je puisse lier mon nouveau ticket à l'ancien ticket "4711" ou à l'un de ses successeurs.

Personnellement, je rejette les user stories comme source de documentation sur ce que le système peut faire. À moins que des mesures actives n'aient été prises pour créer de la documentation (ce que nous avons fait pour certains de nos clients plus traditionnels), la base d'application est vraiment la meilleure documentation qui soit.

Mais ce n'est pas nouveau.

Si vous utilisez une version plus évoluée d'Agile (comme évoluée SAFe ), vous aurez d'autres backlogs qui ne sont pas le backlog d'implémentation. Cela ressemble à ceci:

1. Portefeuille en attente (planification stratégique des épopées et des budgets)
2. Programme / Release Backlog (Fonctionnalités et Epics)
3. Carnet de projet / équipe (histoires, pics, bugs)

Je ne recommanderais pas de documenter au niveau du backlog d'équipe. C'est trop granulaire et personne ne veut rarement aller à ce niveau de détail. Sans oublier qu'il peut y avoir des histoires dans une version qui contredisent les histoires précédentes dans le carnet de commandes de l'équipe.

Au lieu de cela, je recommanderais de travailler au niveau de votre Backlog de version pour fournir une documentation au niveau de la version. Ces histoires explosent rarement une fois affectées à une version particulière, et peuvent être un moyen stable et rapide de revoir ce qui est en cours de travail dans une version donnée.