Introduction à Scrum: les histoires

Scrum meeting in progress

Scrum Meeting / Image by star5112 via Flickr

Ce billet est le second d’une courte série dédiée à l’introduction à la méthodologie Scrum. Dans le premier billet, nous avons vu ce que sont les itérations et l’importance qu’elles jouent dans la méthodologie. Aujourd’hui j’aimerais vous parler d’une autre caractéristique de la méthodologie Scrum qui m’a plu dès le début: les histoires. 

Histoires

Dans notre méthodologie Scrum, chaque demande de fonctionnalité est inscrite dans le journal de bord (backlog) sous forme de petite histoire. Il ne s’agit pas ici de laisser aller nos élans créatifs de poète. Une histoire décrit de façon naturelle une demande exprimée par le client pour en tirer un bénéfice. Voyons l’exemple simple suivant. Le client désire avoir un moteur de recherche pour retrouver un texte dans son logiciel. Un programmeur pourrait prendre note de cette demande de la façon suivante:

Ajouter function publique search_document() dans le construct du template de présentation des docs

Cette demande de fonctionnalité a tout à fait du sens dans le contexte propre du programmeur qui l’a pris en note. Mais en soi, cette demande de fonctionnalité n’explique pas, à priori, ce que cet ajout fera dans le logiciel, ni pourquoi cette demande a été faite. La même demande, exprimée sous forme d’histoire, deviendra

L’utilisateur souhaite avoir une façon de rechercher facilement les documents présent dans la base de données, afin de sauver du temps lorsqu’il souhaite modifier un texte existant.

Exprimée ainsi, l’histoire spécifie trois éléments essentiels pour la compréhension du contexte associé à cette demande:

  1. Qui a fait la demande (C’est le end-user qui l’a fait, pas l’équipe de développement)
  2. Qu’est-ce que l’utilisateur cherche à faire exactement
  3. Pourquoi est-ce important pour lui.

J’aimerais mettre l’emphase sur les points 2 et 3. Lorsque j’ai commencé à changer ma façon de faire pour devenir agile dans mes méthodes de travail, j’avais de la difficulté à bien exprimer les exigences techniques sous forme d’histoire. Le fait d’être une équipe d’une seule personne n’a sans doute pas aider. Dans mon cas, le client était mon patron, et agissait à titre de gestionnaire du projet. Mais en me forçant à réécrire ce que je prenais en note presque par réflexe, et en essayant de l’écrire en me glissant dans la peau du client, j’ai pu renverser mon réflexe de programmeur. Presqu’un an plus tard, chaque fois que je prends en note une recommandation pour le développement de notre produit, une petite histoire s’ajoute à notre backlog.

L’avantage de rédiger ces histoires réside dans le fait qu’elles sont facilement compréhensibles tant par l’équipe de développement que par le client lui-même. Cela devient très important lors des rencontres avec celui-ci; l’on veut lui montrer ce qui est sur la table à dessin, mais dans un langage non-technique qu’il comprendra immédiatement. Cela ouvre aussi la possibilité, entre les développeurs, de discuter sur la meilleure façon de livrer cette valeur ajoutée pour le client. Comme la demande de fonctionnalité n’est pas exprimée par rapport à un langage ou à une façon spécifique de l’implanter, l’équipe peut prendre un certain recul face à la demande et trouver la meilleure façon de la livrer rapidement.

Changement de mentalité

Le fait de se forcer à exprimer chaque demande sous forme d’une histoire nous permet également d’humaniser notre relation avec le  projet et les utilisateurs qui en sont le moteur. Tranquillement, travailler chaque semaine avec des histoires plutôt qu’une simple liste de ‘to-do’ aide à mieux cerner les enjeux du produit développé. Ce qui auparavant pouvait être une source de distraction, d’embêtement ( « Oh non.. pas encore un  autre changement…  » 😦 ) prends soudainement un sens à nos yeux. La valeur accordée par le client à sa demande tempère parfois la première impression que l’on a de celui-ci et de ce que nous qualifions parfois de « caprice », auparavant.

Un autre bonus à l’utilité des histoire est que du coup,  notre créativité devient multidirectionnelle, au lieu d’être encarcannée dans une seule direction linéaire. Comme l’on connaît le contexte de l’histoire, cela peut nous emmener sur des pistes différentes, puisque l’on comprends l’objectif réellement visé. Ainsi, il arrive que le client ne sache tout simplement pas que ce qu’il veut accomplir est déjà possible. Un simple petit appel de quelques minutes peut le satisfaire. Il peut ainsi être agréablement surpris de voir notre efficacité à l’aider dans son utilisation du logiciel.

Évaluation des histoires

À chaque début d’itération (Sprint), l’équipe s’assoit donc, de préférence avec le chargé de projet (Scrum Master) et le client  (Product Owner) , afin d’établir la liste des histoires qui seront développées, testés puis livrées pendant ce Sprint. C’est à ce moment qu’entre en jeu l’équipe de développement qui aura pour tâche d’évaluer chacune des histoires qui aux yeux du client sont prioritaires. Le processus d’évaluation des histoires et de classement de celles-ci dans le backlog par ordre de priorité pourrait remplir un billet en entier, ce qui déborde de l’objectif de cet article. Aussi, qu’il suffise de savoir pour le moment que les développeur donnent au client un estimé du nombre d’unité de travail (une unité de travail étant généralement une demi-journée) pour chaque histoire. Ensemble, donc, suite à cette évaluation, la liste des histoires qui pourront   être livrées au cours de l’itération qui débute est établie.

En connaissant l’ampleur de la tâche pour livrer une histoire dans le produit, le client va souvent réorganiser l’ordre des priorités qu’il s’était fixé en tête. En général, le client aime bien cet exercice, car cela lui donne un contrôle sur l’évolution du produit: il décide quelles fonctionnalités il aura dans quelques jours ou semaines (à la fin du Sprint en cours).

Mon expérience personnelle m’a aussi démontrée que la valeur accordée par le client face à sa demande (son histoire) variera beaucoup au fil du temps. C’est un jeu de proportion qui se répète à chaque itération: la valeur qu’il croyait accorder à une spécification est mise en perspective du coût réel que cela lui coûtera, et il oriente ses choix avec ces nouvelles données.

Conclusion

Les histoires sont une composante essentielle à la méthodologie Scrum. Elles offrent une valeur réelle tant pour les développeurs que pour le client lui-même. La liste des histoires, grandissante avec le temps, donne après quelques mois une image très nette et très belle de l’évolution du produit, mais également de l’évolution des besoins et des désirs de l’utilisateur final. Ceci est une donnée très importante que ne peut pas nous fournir les modèle plus statiques de développement comme la méthode Waterfall.

Je vous encourage dès aujourd’hui, même si vous n’avez pas encore adopté de méthodologie agile, à commencer  à noter vos demandes et celles de vos clients sous forme de petites histoires. Vous verrez, très bientôt, votre perception changera pour le mieux!!

Publicités
Tagué , , , , , , ,

2 réflexions sur “Introduction à Scrum: les histoires

  1. […] une rencontre de planification avec le Product Owner et le Scrum Manager afin de déterminer le lot d’histoires qui seront traitées pendant cette itération. Ce choix se fait par un jeu d’estimation des […]

  2. […] Bienvenue dans ce troisième billet de ma série d’introduction sur la méthodologie Scrum. Jusqu’à présent dans cette série, nous avons vu le premier principe de base de Scrum, les itérations, et dans le second billet, l‘importance de rédiger les demandes du produit sous forme d’histoire. […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Publicités
%d blogueurs aiment cette page :