Des approches SMART sont utilisées pour évaluer les exigences dans les projets en cascade, prédictifs. Elles s’appliquent aussi aux projets agiles.

SMART Requirements are Agile

http://www.bonniebiafore.com/smart-requirements-are-agile/ par Bonnie Biafore

Spécifique

Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance. Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.

Mesurable.

La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.

Atteignable

Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.

Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.

Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.

Réaliste

En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.

Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.

La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.

Temporel – contraint par le Temps

L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.