exigences

Le cas des cas d'utilisation

Un lecteur de mon livre m’interpelle à propos des use-cases. En effet dans le chapitre 13 “De la vision aux stories”, après avoir présenté la démarche pour arriver aux stories, j’ai écrit un paragraphe sur les use-cases (qui ne font pas partie de la démarche) pour rappeler qu’ils sont différents des user stories, et moins bien adaptés au développement agile. Christophe, mon lecteur, argumente pour défendre l’intérêt des use-cases. Coïncidence, j’ai rencontré ces derniers jours des utilisateurs de la technique des use-cases.

Exigences non fonctionnelles revisitées

Des exigences de localisation ou d’utilisabilité représentent des contraintes qui portent sur plusieurs user stories. J’alimente le backlog de produit d’IceScrum pour la nouvelle release. J’y mets donc des features et des user stories, qui représentent l’aspect fonctionnel. Pour avoir un produit de qualité, je réfléchis aussi aux exigences non fonctionnelles. J’avais fait un billet “que faire avec les exigences non fonctionnelles ?" il y a quelque temps en disant qu’elles devaient aussi aller dans le backlog.

Vocabulaire imprécis

Entrer dans le domaine de l’Agilité implique d’acquérir un nouveau vocabulaire. C’est vrai en particulier avec Scrum et ses métaphores sportives (sprint, mêlée). Comme la plupart des termes viennent de l’anglais, le vocabulaire subit les aléas liés à la traduction. Ou à la non traduction si on garde le mot anglais. Pour ne pas ajouter à ces difficultés de communication, il convient d’utiliser le bon vocabulaire. Lors de présentations ou de discussions, j’ai relevé des mots ou des expressions, qu’à mon avis, il vaudrait mieux éviter.

Changement de contexte

Je conseille aux organisations de développement d’éviter le multitâches en faisant en sorte qu’une personne soit affectée dans la mesure du possible à plein temps sur un projet. Ce n’est pas un conseil que je peux appliquer moi-même sur mes activités : je travaille sur plusieurs projets en même temps. En général j’arrive quand même à consacrer une journée ou une demi-journée à un seul sujet. Mais en ce moment particulièrement j’ai à changer de contexte très souvent pour passer d’un projet à un autre.

Exigences et tests, tests et exigences : un ruban de Möbius

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences. L’article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob. La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.

Collecte du feedback pendant un sprint

Sur 2 projets Scrum que je coache actuellement nous avons eu à peu près le même besoin, lié à la collecte du feedback. Au cours du sprint, bien avant la fin, l’équipe a produit un build, permettant de passer des tests d’acceptation. Le product owner (ou un testeur) a du temps pour tester ce build. Le problème, c’est qu’il n’est pas physiquement proche des développeurs quand il utilise le build et passe ces tests.

Deux entrées dans le backlog pour une exigence d'utilisabilité

Pour les droits des utilisateurs au feed-back Dans les applications Web, il existe souvent un rôle secondaire qui a accès à des informations seulement en lecture et qui a besoin d’une ergonomie particulière, soit parce que les personnes qui jouent le rôle ne sont pas expertes dans l’utilisation de l’outil informatique, soit parce que les informations doivent constituer un tableau de bord facilement lisible et permettre d’avoir une vue synthétique. L’ergonomie est essentielle et fait que ces exigences ne sont pas des histoires comme les autres.

Que faire avec les exigences non fonctionnelles ?

Les mettre dans le backlog, comme tout le monde ! Dans le backlog de produit, on met des user stories. La technique des user stories permet d’identifier les exigences fonctionnelles. Mais il y a d’autres exigences[1], qualifiées de non fonctionnelles, parfois d’exigences techniques. Dans OpenUp c’est le terme Supporting Requirements qui est utilisé et c’est mieux que le Supplementary Requirements du RUP. Cela concerne : les qualités d’exécution comme l’usabilité, la fiabilité, la performance.
Priorités définies avec des critères pondérés

Priorités définies avec des critères pondérés

Une technique pour définir les priorités entre les fonctions d’une application Les éléments du backlog sont organisés par priorité. Une séance de Priority Poker permet de définir les priorités de façon collective. Mais il n’est pas toujours possible de l’organiser avec les bonnes personnes. Une technique plus classique, que Mike Cohn appelle Theme Scoring, consiste à comparer la satisfaction de critères, en donnant un poids à chaque critère. La démarche est la suivante :

Un nouvel exemple d'agilité à grande échelle

L’application d’une méthode de développement agile pour toute une organisation Par Dean Leffingwell, l’auteur du livre Scaling Software Agility: Best Practices for Large Entreprises, les sceptiques [1] trouveront des données quantitatives (SLIM Analysis Shows Agile Development Can Bring Positive Results for both Developers and the Bottom Line) qui montrent encore[2] un exemple d’application de l’agilité au niveau de l’entreprise. L’exemple de BMC est intéressant, notamment pour la façon dont l’ingénierie des exigences a été abordée, avec la création d’un rôle Requirements Architect et la mise en place d’une pratique appelée Requirements Runway ayant pour objectif d’élaborer les exigences juste à temps[3].

Features, themes, epics et stories

Comment s’y retrouver ? Que met-on dans le backlog ? Pour une fois je vais utiliser les termes anglais[1]. Puisque vous fréquentez ce blog, vous devez savoir ce qu’est une story et ce qu’est un backlog (de produit), deux éléments de base dans l’application des méthodes agiles. Mais il y a d’autres termes utilisés couramment dans la gestion agile des exigences. Feature L’élaboration de la vision du produit passe par l’identification des features.

Les rôles impliqués dans les histoires d'utilisateur

Il n’y a pas que l’utilisateur et l’administrateur … La découverte des histoires d’utilisateur[1], comme d’ailleurs celle des cas d’utilisation ou de toute autre technique, se fait en réfléchissant à ce qu’attendent les utilisateurs du logiciel. Il faut donc commencer par identifier ces utilisateurs,au sens large, du logiciel. Les cas d’utilisation utilisent le terme acteur, pour les histoires d’utilisateur on parle de rôle ou de type de rôle ou encore de rôle d’utilisateur.

Emergence progressive des exigences

Plutôt que d’essayer de tout figer au début mieux vaut décider au dernier moment possible. Il est impossible de connaître toutes les exigences[1] dès le début d’un projet. Depuis 20 ans j’ai participé à de nombreuses définitions et spécifications d’exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d’imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d’exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l’avance.