extrême [XP 99].
On pourra également utiliser des outils simples pour les éditer, les trier ou les manipuler ([Rees
02], [Dwitam…20]).
Figure 2: Exemple de Story Card, hormis l’histoire et les conditions d’acceptation, on indiquera
l’importance et une première estimation de la charge de travail des fonctions décrites dans l’histoire (tirée
de [Link]
Chaque élément du backlog produit (voir Figure 3) a une courte description, une priorité vue de la base client,
une liste de clients importants demandant le changement, un effort estimé (EE) de développement, une valeur
perçue (VP) auprès des clients (ici, haute, moyenne, ou faible). Les éléments du backlog sont ordonnés par
priorités commerciales déterminées par le gardien du produit avec l’aide de l’équipe marketing, et plus tard,
parfois seulement dans le backlog de sprint, par niveaux de sévérité techniques déterminées par les équipes de
développement. Les dépendances techniques entre différentes parties du code sont également analysées car elles
sont sources de difficultés de développement (surtout quand les interfaces ne sont pas conçues pour ces
nouveaux éléments) et également sources de régressions. Nous voyons bien que plus VP sera élevé et EE bas
plus haute sera la priorité. C’est le cas de l’exemple de la Figure 3 où le premier élément du tableau est
clairement moins prioritaire que le second puisqu’à la fois il coute plus cher en développement (EE) et rapporte
moins en valeur perçue (VP) que le second élément.
Customer
Product Level of Bugzilla Requested Customers
Priority Perceived Release Item Name Status Entry Feature Description
Area Effort ID By Affected
Value
Is there any way in which the
nurses can have a repository
Print Preview of the letters (in Read only
P2 LETTERS LOW 1W 3.4.2 1243 EOS All OPEN 5/12/08
Repository format) where they can go to
view the letters prior to
printing them?
The ability to include a digital
P1 LETTERS MEDIUM 2D 3.4.2 1162 Signatures EOS All OPEN 6/6/08
signature in a letter
Figure 3: Deux éléments du backlog produit d’une de nos jeunes pousses. Il est stocké dans une base de
données spécialisée (ici Bugzilla). De nombreux champs sont identiques à la base de données contenant les
bugs du produit.
Le backlog de sprint est un extrait du backlog produit. Dans nos expériences, il a été défini lors de réunion entre
l’équipe de développement et le gardien du produit. Chaque élément est cette fois assigné à un développeur de
l’équipe. L’estimé de temps de développement est affiné et donné en jours de travail. La somme de ces estimés
va permettre de calibrer le sprint et d’initialiser le tableur de calcul de la charge de travail. La méthode
recommande de calibrer le sprint à 30 jours de travail ce que nous n’avons pas trouvé toujours possible.
5
Le gel du backlog de sprint, c’est-à-dire sa stabilisation une fois qu’il est défini, a toujours été un point important
de la méthode, particulièrement difficile à respecter en milieu de jeune pousse. D’une part, les « chickens » vont
constamment chercher à influencer et changer la définition du plan de développement. Enfin, (le mieux étant
parfois l’ennemi du bien) tout développeur se rend compte régulièrement que son code a des faiblesses et est
tenté de s’arrêter et de recommencer pour faire nettement mieux, plus élégant et plus maintenable. Chacun a
rencontré ce double phénomène dangereux et source de divergences pour lequel nous n’avons pas de solution
simple si ce n’est de revenir au strict respect des délais. À moment donné, il faut se décider à arrêter toute
fluctuation dans la définition de la livraison produit et remettre toute nouvelle proposition à la version qui suivra.
C’est un point délicat : il faut se souvenir du point 2 de la méthode Agile demandant de savoir accueillir tout
changement même tard dans le développement.
4.2 Intégrations des backlogs dans un environnement de livraison produit
Il y a un backlog produit par produit dans l’entreprise, mais il peut y avoir plusieurs backlogs de sprint pour
chaque nouvelle version produit. Ces deux catégories de backlog ne doivent pas rester isolées et sont en relation
avec d’autres artefacts de la ligne produit (voir le schema synthétique Figure 4). L’un des plus importants est la
vision technique du produit venant du bureau du directeur technique. Elle pourra contenir des évolutions de
l’architecture du produit ou encore des évaluations de composants logiciels qui sont candidats à une intégration
future, ou encore des nouveaux algorithmes en préparation. Surtout le backlog produit et backlog de sprint ont
une structure de données similaire à celle de la base de défauts ouverte à tous les membres de l’entreprise tout
particulièrement les équipes support et les équipes de tests favorisant des mouvements de l’un vers l’autre, par
exemple lors du triage (voir un extrait de backlog produit Figure 3). Dans nos expériences la vision marketing
est directement entrée dans le backlog par le gardien du produit ; elle n’a donc pas d’artefact spécifique sur la
description technique du produit à partager.
Technical Release :
Product Sprint Code &
Vision Product Backlog
Documents
…
Backlog
Release
Bug Release
Sprint
Database Notes
Backlog
TRIAGE
TESTS
Bug Database
Figure 4: Le backlog produit et les backlogs de sprint doivent s’intégrer aux autres artéfacts produit :
database de bugs, vision technologique du produit, code et documentations (technique et utilisateur).
Un premier point d’intégration est de mettre en relation le backlog produit avec les travaux de l’équipe
d’assurance qualité. Dans nos deux expériences cette équipe était chargée de construire une suite de tests
(incluant des tests provenant des utilisateurs pour une des expériences) et de tester en continu le développement
produit courant. Les tests unitaires quant à eux relevaient de la responsabilité des développeurs, ils étaient
obligatoires et certains étaient engendrés automatiquement. L’équipe d’assurance qualité reporte et décrit
soigneusement tout problème rencontré lors des tests dans la base de données de défauts de manière à ce que le
problème soit aussi aisément que possible reproductible. Les réunions de triage peuvent après tout être
considérées comme des réunions remplaçant celles de scrum de scrums puisque c’est le lieu où se rencontrent en
particulier le gardien du produit, tous les maîtres de scrum, un représentant de l’architecte produit ou du directeur