Unterschied zwischen Product Backlog-Element und Feature in Team Foundation-Arbeitselementtypen


111

Ich habe eine Frage zu Microsoft Team Foundation. In Visual Studio, Team Explorer, kann ich ein neues Arbeitselement erstellen. Die hier verwendeten Arbeitselementtypen werden von der von Ihrem Team ausgewählten Prozessvorlage bestimmt. Ich bin nicht sicher, welche Prozessvorlage wir verwenden. In jedem Fall erhalte ich im Team Explorer beim Erstellen eines neuen Arbeitselements eine Liste mit Arbeitselementtypen zur Auswahl, darunter "Product Backlog Item" und "Feature".

Ich bemerkte einen Unterschied zwischen den beiden Typen in Bezug auf das Datum der Zielauflösung. Bei einem Product Backlog-Element scheint dies durch das Enddatum der Iteration vorgegeben zu sein. Für ein Feature ist es nicht so klar. Ein Feature ist auch einer Iteration (und einem Iterationsenddatum) zugeordnet. Das Feature verfügt jedoch auch über ein separates Feld mit dem Namen "Zieldatum". Der Mauszeigertext für das Zieldatum lautet "Das Zieldatum für die Fertigstellung der Funktion".

Sollte ich "Product Backlog Item" oder "Feature" als Workitem-Typ für meine neuen Workitems auswählen? Was ist der Unterschied zwischen den beiden?

Geben Sie hier die Bildbeschreibung ein


2
Für mich geht es bei der Funktion um das "Was" und das Backlog-Element um das "Wie".
Oli

Antworten:


131

Es sieht so aus, als würden Sie die Scrum-Prozessvorlage verwenden. Auf der TFS-Site wurden einige sehr kurze Informationen zu Product Backlog-Elementen und -Funktionen sowie die Idee zum Erstellen eines neuen Workitem-Typs veröffentlicht. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx

Der Unterschied zwischen den beiden besteht darin, mit welcher Granularität Sie mit Ihren Arbeitselementen arbeiten möchten:

  • Product Backlog-Elemente bestehen aus Aufgaben und haben einen geschätzten Aufwand.
  • Die Funktionen bestehen aus Product Backlog-Elementen und haben Zieldaten.

Ich konnte keine offizielle Anleitung zur Verwendung von Funktionen im Vergleich zu Product Backlog-Elementen finden, habe jedoch meine eigene Anleitung erstellt, auf deren Grundlage ich diese Antwort stütze ... http://www.nsilverbullet.net/2013/06/ 04 / Features-Hilfe-uns-Plan-Arbeit-besser-im-Team-Foundation-Service-Scrum-Prozess /

Sollten Sie ein Feature oder ein Product Backlog-Element erstellen?

  • Wenn Sie glauben, dass das neue Arbeitselement, das Sie erstellen möchten, in einen einzelnen Sprint passt, sollten Sie ein Product Backlog-Element erstellen und es dann in Aufgaben für Ihren Sprint aufteilen.
  • Wenn Sie der Meinung sind / wissen, dass das neue Arbeitselement nicht in einen einzelnen Sprint passt, sollten Sie ein Feature erstellen und alle wertschöpfenden Elemente in Sprintgröße (Product Backlog Items) identifizieren, in die das Feature unterteilt werden kann, und diese verwenden, wenn zukünftige Sprints planen.

[Update 19.05.2014]

Microsoft hat weitere Informationen zur Verwendung von Funktionen und zum in TFS implementierten agilen Portfolio-Konzept veröffentlicht: https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx


5
Microsoft hat jetzt zusätzliche Informationen zur Verwendung von Funktionen veröffentlicht. visualstudio.com/en-us/get-started/… Leider sind für Visual Studio Online-Funktionen nur Benutzer mit erweiterten Lizenzen verfügbar . :-( visualstudio.com/en-us/get-started/try-additional-features-vs Der Preis beträgt $ 60 pro Benutzer / Monat.
agilejoshua

Wo passen Bugs dazu? Sind Fehler mit Aufgaben austauschbar?
Captain Sensible

1
@DiegoDeberdt - Fehler sind nicht mit Aufgaben austauschbar. Stellen Sie sich vor, dass sie entweder auf derselben Hierarchieebene wie PBIs oder möglicherweise als untergeordnete Elemente von PBIs existieren (wenn Sie sich dafür entscheiden, diese Methode zu verfolgen, ist es normalerweise ausreichend, sie als verwandt zu belassen). Aufgaben können Kinder von Fehlern sein, um den Entwickler zu verfolgen und die Arbeit gegen ihn zu testen.
StingyJack

2
Ich kann mich anscheinend nicht auf den Ansatz "Multiple Sprint ist Feature" einigen. Es sollte als Brücke (hauptsächlich zur Verfolgung) zwischen eher technischen und weniger technischen Zwecken verwendet werden. Ich kann mir vorstellen, dass ein Feature innerhalb eines Sprints mit genügend Engagement und Ressourcen beginnt und endet. Feature ist jedoch eine einfache Möglichkeit für das Management usw., die technischen Inhalte in Beziehung zu setzen und zu verstehen.
Beytan Kurt

Es gibt eine neue Leitfadenseite für Visual Studio 2015, ALM> Arbeit>
Skalieren

20

Da TFS eine agile Entwicklungsstrategie anwendet, können wir meiner Meinung nach sagen:

Feature = Episch, Backlog item = Story

Das Epos enthält ähnliche Geschichten.


9
Ja, aber jetzt haben sie Epics hinzugefügt, die Funktionen enthalten, die Backlog-Elemente oder Fehler enthalten, die beide Aufgaben enthalten können.
Toddmo

1

Ich hatte die gleichen Zweifel wie OP und meine Gedanken stimmten mit der Antwort von @josant überein, was für mich sehr vernünftig ist.

Auf der anderen Seite verwende ich das Hundhausen-Buch [1] als Referenz für die Übernahme von TFS + Scrum.

Er sagte Dinge wie:

Eine Funktion ist eine diskrete Funktionseinheit, die dem Benutzer oder Unternehmen einen Mehrwert bietet. Ein PBI kann groß genug sein, um mehrere Funktionen zu haben.

und dann:

Eine Funktion kann in mehrere Szenarien unterteilt werden. Ein Szenario ist eine Erzählung, die einen Workflow oder eine Abfolge von Schritten durch die Funktion beschreibt, die einen Weg zum Erreichen eines erwarteten Ergebnisses ausübt.

und entwickelt diese Ideen weiter.

Für mich scheint Hundhausen über Anwendungsfälle zu sprechen [2], aber ich halte seinen Vorschlag dennoch für nicht intuitiv, und TFS scheint auch nicht zu dieser Analysemethode zu führen, auf die ich in der von mir gelesenen Scrum-Literatur verwiesen habe.

Wahrscheinlich geht es nur darum, eine Konvention zu wählen, mit der Sie sich wohler fühlen und die Sie einhalten.

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

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




1

Wie andere hier sagten:

  • Eigenschaften: Top Level
  • Rückstände: Eine Ebene unter den Funktionen (eine Funktion besteht aus Rückstandselementen)

Beachten Sie, dass Sie Arbeitselemente verknüpfen und als Baumliste anzeigen können. Sie können also ein Backlog-Element mit einem Feature verknüpfen und später eine Aufgabe mit einem Backlog-Element verknüpfen. So erhalten Sie eine schöne hierarchische Baumliste.


1

So benutze ich es. Unter den Werkzeugelementen "Arbeit" -> "Rückstände" werden sowohl "Funktionen" als auch "Rückstandselemente" aufgelistet. Ich beginne mit Funktionen, sodass zu diesem Zeitpunkt keine Rückstandselemente vorhanden sind. Ich füge die Features hinzu, indem ich Features unter der Überschrift Backlog auswähle und den Feature-Namen in das Formular einfüge, dann speichere und schließe. Links von jedem neu hinzugefügten Feature befindet sich ein grünes + Zeichen. Klicken Sie auf das Pluszeichen und die Auswahloptionen werden angezeigt. Wählen Sie "Product Backlog Items". Geben Sie beim Öffnen den Namen des Backlog-Elements wie in Features in das obere Feld ein. Wenn Sie diese Backlog-Elemente erstellen, gibt es kein Popup. Geben Sie die anderen Informationen nach Bedarf ein und speichern und schließen Sie sie. Klicken Sie nach dem Erstellen der Backlog-Elemente auf das grüne + der neu erstellten Backlog-Elemente. Geben Sie den Namen des Arbeitselements ein, wie Sie es für die Backlog-Elemente und die Funktionen getan haben. Wenn Sie die Arbeitselemente hinzufügen, fügen Sie den Sprint in das Iterationsfeld ein und sie befinden sich im Sprint, wenn Sie ihn öffnen. Nichts davon ist irgendwo dokumentiert, was ich finden könnte. Ich hoffe es ist ausreichend detailliert.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.