Nous avons vu les différentes vues d’un système. Même en agile, il faut les avoir pour comprendre le système et le tester (PO et testeurs : validation des « nouveautés » et de la régression).
Alors comment gérer tous ces artefacts et comment poursuivre la décomposition du système jusqu’à aboutir aux US, dont les critères INVEST sont si souvent vantés ?
Architecture d’un produit et agilité : les avantages de l’ATDD
Les avantages sont multiples :
- Le métier capitalise son savoir.
Pour lui la compréhension d’une fonctionnalité est meilleure, au lieu de multiplier des modélisations de features/epics qui ne représentent, en fait, que les nombreux éléments temporaires de développement.
- Les analyses de régression vont être facilitées
En effet, en particulier, les UC qui sont modifiés (par une tâche interne modifiée ou une tâche supprimée) doivent subir des tests pour les points qui n’ont pas de raison d’être impactés. Dans Jira si vous fermez une epic Scrum en la déclarant terminée, il vous faudra en recréer une pour des modifications ultérieures. Or ces 2 epics sont en fait deux évolutions d’une même UC (il faudra un tag par exemple pour mettre en évidence ce lien). L’ATDD vous le montre directement.
Nous pouvons donc aboutir à structurer tout système :
- En « cas d’usage » (une modélisation pour un parcours client bien clair). Ex : vente d’un produit de type X à des couples mariés ou Pacsés. En traditionnel on aurait réalisé des processus valables pour différents cas d’usage, en complexifiant l’analyse et le développement.
- En éléments pour le cas d’usage considéré : le système est un produit composé, avec de multiples sous-parties
- De manière hiérarchique : les éléments sont plus ou moins « gros »
- En montrant leurs enchaînements fonctionnels (mais sans les expliquer)
- Avec des « éléments fonctionnels stables » : ce qu’est le produit à un instant T, sans rendre compte des itérations de développement (nous verrons le lien entre fonctionnalités et artefacts agiles par la suite).
En définitive on a, par exemple :
On notera que les « UC » peuvent être réutilisés.
Un outil ATDD permet des analyses d’utilisation des éléments.
L’analyse va maintenant se poursuivre avec toute l’équipe agile.
On doit, en effet, décomposer chaque UC en “tâches” élémentaires pour l’usage du produit.
A priori lorsqu’on les définit, par analyse de décomposition des UC, ces tâches ATDD sont initialement des US ayant les critères INVEST : c’est le principe à retenir pour commencer à lier ATDD et agilité !
En résumé
3 points important à retenir :
- l’ATDD, est une spécification des tests qui utilise généralement une forme graphique de modélisation de l’enchaînement d’éléments fonctionnels, en limitant l’utilisation du système à un cas d’usage (un contexte précis de qui utilise le produit et le type de résultat attendu). On y voit en effet les dépendances entre eux, sans en comprendre les rouages, les règles qui expliquent leurs enchaînements.
- Les tâches sont les plus petits éléments, non décomposables. Ils n’ont donc pas cette forme graphique.
- Les tâches peuvent être initialement des US ayant de la valeur métier, estimable, testable (heureusement !). Nous y reviendrons plus tard, mais disons pour faire simple, INVEST, par opposition aux modifications de détail (par exemple un changement de style de police, l’ajout d’un logo, la modification de détail dans une règle de gestion, etc.).
