Introduction à Scrum: le backlog

Backlog board

Image by drewgstephens via Flickr

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.

Ces histoires sont assemblées dans ce que l’on appelle le backlog, que je traduit personnellement par journal de bord. C’est ce sujet que nous abordons dans ce billet.

Journal de bord

Le journal de bord, donc, est la liste de toutes les demandes de fonctionnalités, inscrites au fur et à mesure qu’elles sont suggérées par le Product Owner, le Scrum Master ou même par l’équipe de développement.  Un fait particulier et très important à noter est que cette liste n’est pas en ordre de date, n’est pas nécessairement classée par type de demande et encore moins par ordre de  personne ou d’équipe qui en a fait la demande. En fait, l’orde de cette liste va varier beaucoup tout au long du cycle de développement du produit.

Typiquement, les histoires sont triées par ordre d’importance, avec les histoires les plus importantes en haut et les moins importantes en bas de la liste. On a vu lors du précédent billet qu’au début d’une itération, le Product Owner détermine les histoires qui seront livrées au cours de cette itération. Pour ce faire il révise la valeur qu’il accorde à chaque histoire, en prenant comme donnée l’estimé de temps que l’équipe de développement lui a fournie. Le Product Owner changera donc l’ordre d’affichage du backlog à chaque itération.

Mais attention. Les histoires ne sont pas nécessairement complétées en ordre du plus important au moins important, bien qu’en général il y ait une nette tendance en ce sens. Lors de la réunion de début d’itération, un choix doit être fait sur les histoires du backlog qui seront livrées. Or, il peut survenir (assez fréquemment en fait), qu’une histoire qui a beaucoup de valeur aux yeux du Product Owner soit si complexe qu’elle pourrait prendre à elle seule beaucoup trop de ressource en une seule itération. Le Product Owner choisiera parfois de laisser de côté cette histoire le temps d’une itération ou deux, pour donner le temps à l’équipe de livrer plusieurs autres histoires de moindre importance.

Une meilleure option, à mon avis, lorsqu’une histoire requiert trop de ressource, est de la scinder en plusieurs petites histoires. Cela stimule aussi la créativité de l’équipe, en cherchant à déterminer quels sont les désirs réels recherchés par cette demande, et à suggérer parfois des compromis satisfaisants. Nettement plus agile comme procédé.

À ses yeux donc, la valeur de l’histoire change donc, parce qu’elle est mise en contexte, dans le backlog, avec les autres histoires ‘actives’. Une histoire ‘active’ est une histoire qui n’a pas déjà été livrée.

Comment maintenir son backlog en santé

Vous l’aurez deviné, le backlog peut devenir très long au fur et à mesure de l’avancement des itérations. Il est cependant nécessaire de conserver toutes les histoires dans le backlog. Celui-ci devient alors à la fois votre carnet de réalisation et votre guide de tous les jours pour savoir ce qui est sur votre table de travail et ce qui risque d’y être prochainement. Ceci dit, la liste peut devenir assez difficile à gérer. J’y vais donc de quelques unes de mes recommendations, basées sur mon expérience personnelle.

  1. N’hésitez pas à effacer les histoires jugées « abandonnées ». La tentation peut être grande de garder une histoire « en suspend ». Les chances qu’elle y reste à tout jamais dans cet état sont très grandes. Cela ne fera que poluer votre backlog. S’il y a consensus, détruisez simplement l’histoire et ne regardez plus en arrière.
  2. Gardez vos histoires concises. Souvenez-vous que vos histoire doivent simplement exprimer un besoin à combler pour un groupe de personnes cibles. Le backlog n’est l’endroit où l’on doit justifier/expliquer/détailler les aboutissants techniques ou moraux relatifs à l’histoire.
  3. Nommez un éditeur. Un seul des membres de l’équipe devrait pouvoir contrôller le backlog. Ce qui n’empêche pas de mettre en place un mécanisme de suggestion et de révision des histoires. Mais la modification du backlog final, officiel, devrait être restreint.
  4. Avant d’ajouter une histoire, recherchez d’abord les histoires complétées pour vous assurer de ne pas créer un duplicata d’une demande passée.
  5. Votre système de notation des histoires (tableau, feuille, logiciel, etc..) doit permettre d’attribuer des ‘tags’ (ou catégories) à vos histoires. Cela vous permettra de filtrer votre backlog en prévision du personnel à votre disposition et de ses connaissances/compétence.
  6. Votre système de notation doit posséder un mécanisme pour afficher différemment les histoires qui sont terminée et celles qui font partie d’une itération en cours ou à venir.
  7. Votre système doit permettre de reclasser les différentes histoire de façon à ce que l’histoire ayant la plus grande valeur aux yeux du Product Owner soit en haut, et celle avec le moins de valeur en bas.
On voit bien que de garder un backlog en santé dépend beaucoup du système utilisé. Au fil des derniers mois j’ai testé, essayé, recherché, re-testé des dizaines de façons de faire, de logiciels et de méthodes. Voici un cours résumé du résultat de mon enquête.

Outils de backlog

1. Excel, Google Doc, Libre Office Calc, ou autre classeur similaire.

avantages:

  • À peu près tout le monde sait s’en servir
  • Sa structure de grille semble toute indiquée pour séparer intuitivement les caractéristiques d’une entrée au backlog: histoire, catégorie, statuts, no. de l’itération, etc..
  • Facilement partageable sur Google Doc.
  • Dans Excel, la séparation par onglet permet de conserver un historique, de séparer dans le même fichier le backlog lui-même ainsi que les wish list et autres informations pertinentes.
dangers:
  • Devient rapidement très fastidieux à utiliser quand le backlog s’allonge. Notamment si au cours d’une réunion ont veut déplacer des histoires parce qu’on modifie leur « valeur » (donc leur priorité).
  • Il est trop facile de poluer le backlog avec plein d’autres trucs qui n’ont rien à voir (wish list, distribution du travail, etc.).
2. Tableau de liège et cartes d’index.
avantages:
  • Aucun besoin technologique
  • Très dynamique, rends les réunions de Sprint plus intéressantes
  • Plusieurs Gurus de la méthode Scrum ou Kanban préconisent cette approche, parce qu’elle permet de mettre de l’avant la théorie de la chambre des joueurs (the locker room theory).
  • Permet une mise à jour ultra-rapide du backlog
  • Excellente façon de s’introduire aux méthodologies agile
dangers:
  • Aucunement pratique pour les équipe distribuées
  • L’écriture à la main peut devenir un fardeau pour la personne faisant office d’éditeur ainsi que pour les lecteurs
  • Aucune portabilité. Très difficile de consulter le backlog.
3. Logiciels spécialisés
Les solutions de gestion de projet agiles en ligne pleuvent litéralement. Certaines sont gratuites et mal conçues, d’autres sont gratuite pour l’essais ou pour les petites équipes, ou payant pour plus de sérieux.
avantages:
  • Ces solutions sont pensées et conçue pour la gestion de projet agiles.
  • Elles peuvent vous aider à vous organiser rapidement, vous dirigeant pas à pas vers ‘leur’ processus (workflow)
  • Les solutions en lignes sont idéales pour les équipes distribuées
dangers:
  • Le coût associé à certaines de ces solutions rebutera les petite firmes qui sont incertaines ou hésitantes à adopter les méthodologie agiles à y aller de l’avant. Cela peut même avoir un effet décourageant si vous êtes celui qui tente d’implanter Scrum dans votre équipe de développement.
  • Je ne suis pas un maniaque du 100% agile-by-the-book. J’ai trouvé que la grande majorité de ces solutions sont beaucoup trop complexes pour les besoins que nous avions. En début d’implantation, cela a ajouté un surplus de travail que je juge inutile.
  • Côté sécurité et propriété intellectuelle, lorsque vous utilisez une solution en ligne, le contenu de vos backlogs sont hébergés sur des serveurs que vous ne contrôlez pas nécessairement. Cela peut causer des problèmes éventuels, d’ordre juridiques.
Parmi les logiciels que j’ai testé, il y en a deux qui se distinguent vraiment du lot. iceScrum et VersionOne. iceScrum a l’avantage de vous laisser héberger vous-même la solution et est openSource. VersionOne quant à lui est d’une simplicité élémentaire mais offre en même temps tout ce que vous pouvez souhaitez pour gérer vos projet dans une méthodologie agile.

4. Outils non-agiles

Au cours de ma recherche, je suis tombé sur plusieurs outils qui à priori n’ont rien à voir avec les méthodologies agiles, mais qui offrent tout de même des fonctionnalité intéressantes qui peuvent être utilisées dans l’optique du backlog. Qu’il s’agisse de liste de to-do en ligne ou de partage de document, il y en a une panoplie. Cherchez un peu et vous pourrez trouver des solutions intéressantes, hébergée ou open-source.
Parmi celle que j’ai essayé, il y en a une qui m’a vraiment impressionné. Il s’agit du site thoughtbox.es. Le principe est simple, c’est un gestionnaire de to-do vraiment réinventé. Vous inscrivez vos idées (histoires) dans des boites auxquelles vous associer une couleur et un titre. L’interface est super intuitive, facile et agréable à utiliser. Des fonctionnalités déplacer-déposer permettent de déplacer les histoire et de les reclassez de façon très naturelle. En bonus, l’utilisation des boites vous permet d’avoir une boite principal (votre backlog) et d’autres boites qui peuvent faire office de ‘wish list’ ou de notes temporaire. Définitivement un outil à vérifier surtout si vous débutez dans Scrum.

Conclusion

Le backlog est un peu comme la colonne vertébrale de votre gestion de projet Scrum. Un backlog bien entretenu, alimenté par des histoire bien définies vous permettra de construire une belle vision de votre produit au fil des itérations. Plus vous avancerez plus vous verrez ‘the big picture’ de votre projet. Le Product Owner (client) appréciera égalemet d’avoir une vision aussi transparente sur ce qui se passe avec son produit.

Un dernier conseil: ne tardez pas à trouver l’outil de prédilection pour votre équipe, à y adhérer et à ne plus le changer. Il n’y a rien de pire que de briser le rythme en changeant le support du backlog.

Lors du prochain billet de cette série, nous regarderons les mesure de calcul de la vélocité, un élément essentiel pour évaluer l’efficacité de votre équipe.

Publicités
Tagué , , , , ,

Une réflexion sur “Introduction à Scrum: le backlog

  1. […] et le choix de celle-ci est basé sur les histoires. Finalement, le tout est confiné dans le backlog de […]

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 :