Erläutern des Unterschieds zwischen Product Backlog Item und einer Aufgabe
Ich bin ein paar Mal auf diese Herausforderung gestoßen und hoffe, dass jemand Referenzen, Schulungen oder Ratschläge zur Erklärung des Unterschieds zwischen einem Product Backlog-Element und einer Aufgabe in TFS geben kann.
Ich verstehe und habe erklärt, dass ein Product Backlog-Element das "Was" und die Aufgabe das "Wie" ist. Ich habe auch erklärt, dass der PBI die Anforderung ist und die Aufgabe ist, wie die Anforderung erfüllt wird.
Ich werde wiederholt mit leeren Blicken und Kopfkratzern konfrontiert, wenn ich das erkläre. Es scheint, dass die Software-Ingenieure, denen ich dies erkläre, die Unterscheidung nicht treffen können. Es ist ihnen egal.
Ich glaube, meine andere Herausforderung besteht darin, dass ich nicht effektiv veranschaulichen kann, warum es wichtig ist, die Unterscheidung zu treffen.
Das "Product Backlog Item" ist in der Tat das What, die Funktionalität, die erstellt werden muss. Die Aufgabe beschreibt die Schritte, die unternommen werden müssen, um dorthin zu gelangen.
Viele Teams sind nicht daran gewöhnt, sich in Aufgaben zu zerlegen, sondern bauen nur das auf, was in der Spezifikation angegeben ist. Für diese Menschen ist es schwer, sie als zwei getrennte Dinge zu sehen.
Vielleicht würde eine einfache Anekdote helfen:
Sehen Sie sich die Product Backlog-Artikel als Artikel auf ihrer Einkaufsliste für ihren Urlaub an. Vielleicht ein "Zelt", eine "Angelrute", ein "Auto für die Reise vorbereiten".
Die Aufgaben für den Artikel "Zelt" lauten "Zeltanforderungen beschreiben", "Zelte online vergleichen", "Ratschläge von Freunden mit Outdoor-Erfahrung einholen", "Zum Outdoor-Shop gehen", "Zelt kaufen", "Zelt im Hinterhof aufbauen" Vollständigkeit überprüfen "," Zelt für die Reise packen "
Die Aufgaben für Angelruten werden sehr ähnlich sein, aber die Aufgaben für "Auto für die Reise vorbereiten" sind wahrscheinlich sehr unterschiedlich: "Anforderungen für Staaten/Länder auf der gewünschten Route prüfen", "Sicherheitsweste kaufen", "abgelaufene Inhalte aus der Ersten Hilfe ersetzen" Kit "," Ersatzreifen prüfen "," Termin mit Garage vereinbaren, um den Motor überprüfen zu lassen "," In die Garage gehen, um den Motor überprüfen zu lassen "," Zur staatlichen Behörde gehen, um einen Autobahnpass zu kaufen "," Autoversicherung prüfen "
Dies trennt klar die Frage, was der Product Owner will, von dem, was er tun muss. Es sei denn natürlich, der Product Owner hat sich bereits in umsetzbare Elemente im Product Backlog zerlegt. In diesem Fall müssen Sie auch mit ihnen sprechen.
Wie ich bereits sagte, denken viele Entwickler, dass sie bereits über genügend Informationen verfügen und wissen, was zu tun ist. Sie möchten die Schritte Was in Wie nicht zerlegen. Sie werden dort ankommen, wenn sie dort ankommen. Wenn Sie mit ihnen über die Verfolgung des Sprintfortschritts, die Verbesserung von Schätzungen, die Verfolgung von Arbeiten, die bei der Sprintplanung vergessen wurden, und andere Dinge, die mit professionellen Verbesserungen zu tun haben, sprechen, fragen Sie sie, wie sie und ihr Team wissen, wo sie sich verbessern können und wie sie Ich weiß, dass sie wirklich fertig sind. Wenn sie ein System entwickeln können, das funktioniert, ohne Aufgaben zu erstellen, und das funktioniert, ist das in Ordnung, aber die Chancen stehen sehr gering, dass sie es tatsächlich können.
Bevor Sie versuchen, mit TFS und den agilen Tools zu arbeiten, muss Ihr Team verstehen, wie dies alles funktioniert. Der beste Weg ist, sie mit einem Karton arbeiten zu lassen, der auf dem Arbeitsboden für alle sichtbar ist. Später, wenn der Prozess besser verstanden wird, hilft es, zu den Tools zu wechseln. Ohne das Verständnis werden die Werkzeuge nicht viel nützen und auf viel Widerstand stoßen.
Ich denke, Jesse hat eine großartige Antwort gegeben. Ich werde einfach versuchen, es einfacher zu machen (wenn möglich) :) Das Product Backlog Item (oder User Story, wenn Sie es vorziehen) ist normalerweise so geschrieben:
Als Neukunde möchte ich meine Daten registrieren, damit ich über neue Produktversionen informiert werde
In einem Entwicklerkopf kann dies bedeuten:
- Erstellen Sie ein Registrierungsformular
- Schreiben Sie Registrierungsdaten in die Datenbank
- Senden Sie eine E-Mail an den neuen Kunden, um dessen Registrierung zu bestätigen
Diese drei Punkte sind die Aufgaben.
Ich hoffe, das hilft.
- Mach es so einfach wie möglich, aber nicht einfacher (Einstein)
So rollen wir:
Der PBI:
- ist das Anforderung aka "das was"
- ist das, worüber Sie mit einem Kunden sprechen.
- Dies wird im Daily Project Update (DPU) für den Sprint angezeigt ..... erneut, da die DPU dem Kunden zugewandt ist.
- Darüber wird der Kunde in Bezug auf Schätzungen und Budget sprechen und darauf verweisen.
- Könnte eine oder mehrere Aufgaben umfassen.
- Ist geschäftsorientiert und in einer vom Kunden verstandenen geschäftsorientierten Sprache/Domain-Sprache beschrieben.
- Wird in User Acceptance Testing (UAT) getestet und akzeptiert?
Die Aufgabe:
- Ist eine Arbeit erforderlich, um die PBI zu materialisieren (Anforderung)
- Nicht etwas, worüber Sie mit einem Kunden sprechen
- Wird auf der DPU nicht angezeigt, da Sie nicht mit Kunden darüber sprechen
- Wird geschätzt, hat aber seine Schätzungen in den PBI aufgerollt
- Ist ein Kind zu einer und nur einer Anforderung.
- Kann (und wird oft) mit Fachjargon beschrieben werden
- Intern getestet und durch Test abgemeldet
- Vom Kunden nicht isoliert akzeptiert oder getestet (er weiß nicht, dass es ihn gibt)