Un lecteur de mon livre Scrum 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.
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. Mais ça ne marche pas avec toutes.
Ne pas utiliser les mots corrects augmente le risque d'être mal compris
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.
La première est le sprint0 (ou itération zéro).
Faites ce que je dis pas ce que je fais
Spécification par l'exemple
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.
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. C’est dommage mais that’s life.
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.
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.
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 :
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.
