Différence entre un élément du Backlog de produit et une fonctionnalité dans les types d'éléments de travail de Team Foundation

Question

J'ai une question concernant Microsoft Team Foundation. Dans Visual Studio, Team Explorer, je peux créer un nouvel élément de travail. Les types d'éléments de travail sont dictés par le modèle de processus choisi par votre équipe ; je ne sais pas exactement quel modèle de processus nous utilisons. Quoi qu'il en soit, dans Team Explorer, lorsque je souhaite créer un nouvel élément de travail, je dispose d'une liste de types d'éléments de travail à sélectionner, parmi lesquels figurent "Product Backlog Item" (élément du carnet de commandes) et "Feature" (fonctionnalité).

J'ai remarqué une différence entre les deux types d'actions en ce qui concerne la date cible de la résolution. Pour un élément du Backlog de produit, il semblerait que cette date soit dictée par la date de fin de l'itération. Pour une fonctionnalité, ce n'est pas aussi clair. Une fonctionnalité est également associée à une itération (et à une date de fin d'itération), mais elle dispose également d'un champ distinct appelé "Date cible". Le texte de la date cible au survol de la souris est "La date cible pour l'achèvement de la fonctionnalité".

Dois-je choisir "Product Backlog Item" ou "Feature" comme type d'élément de travail pour mes nouveaux éléments de travail ? Quelle est la différence entre les deux ?

Answer 1

Il semble que vous utilisiez le modèle de processus Scrum. Le site TFS a publié quelques informations très brèves sur les éléments du Backlog de produit et les fonctionnalités, ainsi que sur l'idée de créer un nouveau type d'élément de travail. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx

La différence entre les deux se résume à la granularité à laquelle vous souhaitez travailler avec vos éléments de travail :

• Les éléments du carnet de commandes du produit sont composés de tâches et sont assortis d'une estimation de l'effort.
• Les fonctionnalités sont composées d'éléments du Backlog de produit et sont assorties de dates cibles.

Je n'ai pas réussi à trouver de conseils officiels sur l'utilisation des caractéristiques par rapport aux éléments du carnet de commandes, mais j'ai créé mes propres conseils sur lesquels je base cette réponse... http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/

Faut-il créer une fonctionnalité ou un élément du carnet de commandes ?

• Si vous pensez ou espérez que le nouvel élément de travail que vous allez créer tiendra dans un seul sprint, vous devriez créer un élément du Backlog de produit et le décomposer ensuite en tâches pour votre sprint.
• Si vous pensez/savez que le nouvel élément de travail ne tiendra pas dans un seul sprint, vous devez créer une fonctionnalité et identifier tous les éléments de la taille d'un sprint qui apportent de la valeur (éléments du carnet de produits) dans lesquels la fonctionnalité peut être décomposée et les utiliser lors de la planification des sprints à venir.

[Mise à jour 2014-05-19]

Microsoft a publié plus d'informations sur la façon d'utiliser les fonctionnalités et le concept de portefeuille agile qui a été mis en œuvre dans TFS. https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx

Answer 2

Comme TFS applique une stratégie de développement agile, je pense que nous pouvons dire :

Fonctionnalité = Epic, Élément du carnet de commandes = Histoire

L'épopée contient des histoires similaires.

Answer 3

J'avais les mêmes doutes que l'OP et mes pensées se sont alignées sur la réponse de @josant, qui me semble très raisonnable.

D'autre part, j'utilise le livre de Hundhausen[1] comme référence pour l'adoption de TFS+Scrum.

Il a dit des choses comme :

Une caractéristique est une unité discrète de fonctionnalité qui apporte de la valeur à l'utilisateur ou à l'entreprise. Une IBP peut être suffisamment importante pour comporter plusieurs fonctionnalités.

et ensuite :

Une fonctionnalité peut se décomposer en plusieurs scénarios. Un scénario est un récit qui décrit un flux de travail ou une séquence d'étapes à travers la fonctionnalité qui exerce un chemin vers l'obtention d'un résultat attendu.

et continue à développer ces idées.

Pour moi, Hundhausen semble parler de cas d'utilisation[2], mais j'ai toujours l'impression que sa proposition est contre-intuitive, et il ne semble pas non plus que TFS soit le guide de cette méthode d'analyse ou que je l'ai trouvée référencée dans la littérature scrum que j'ai lue.

Il s'agit probablement de choisir une convention avec laquelle vous vous sentez plus à l'aise et d'y adhérer.

[1] http://www.amazon.es/dp/073565798X

[2] https://en.wikipedia.org/wiki/Use_case

Answer 4

Une fonctionnalité est un portefeuille du Backlog de produit.

http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx

Answer 5

L'équipe définit le travail en tant qu'initiatives de haut niveau et les décompose en fonctionnalités, qui se décomposent à leur tour et définissent le travail à effectuer en tant que "Backlog" (carnet de commandes). ref http://msdn.microsoft.com/en-us/library/dn306083.aspx ?