Wyjaśnienie różnicy między pozycją rejestru produktu a zadaniem

Kilka razy spotkałem się z tym wyzwaniem i mam nadzieję, że ktoś dostarczy referencje, szkolenie lub poradę, jak wyjaśnić różnicę między pozycją rejestru produktu a zadaniem w TFS.

Rozumiem i wyjaśniłem, że pozycja Backlog produktu to „Co”, a zadaniem jest „Jak”. Wyjaśniłem również, że PBI jest wymogiem, a zadaniem jest sposób spełnienia tego wymogu.

Wielokrotnie spotykam się z pustymi spojrzeniami i drapaniem głowy, kiedy to wyjaśniam. Wygląda na to, że inżynierowie oprogramowania, którym to wyjaśniam, nie mogą tego dokonać. Dla nich wszystko jest takie samo.

Uważam, że moim drugim wyzwaniem jest to, że nie jestem w stanie skutecznie zilustrować, dlaczego tak ważne jest dokonanie tego rozróżnienia.

„Element rejestru produktu” jest rzeczywiście tym, co należy zbudować. Zadanie opisuje kroki, które należy podjąć, aby się tam dostać.

Wiele zespołów nie jest przyzwyczajonych do rozkładu na zadania, po prostu budują to, co mówi specyfikacja. Dla tych ludzi trudno jest postrzegać je jako dwie osobne rzeczy.

Może prosta anegdota pomogłaby:

Zobacz elementy rejestru produktu jako elementy na liście zakupów na wakacje. Może „namiot”, „wędka”, „przygotować samochód do podróży”.

Zadania dla pozycji „namiot” to „Opisz wymagania dotyczące namiotu”, „Porównaj namioty online”, „Uzyskaj porady od znajomych z doświadczeniem na świeżym powietrzu”, „Idź do sklepu na świeżym powietrzu”, „Kup namiot”, „Ustaw namiot w ogrodzie, aby sprawdź kompletność ”,„ spakuj namiot na podróż ”

Zadania dla wędki będą bardzo podobne, ale zadania „przygotowania samochodu do podróży” są prawdopodobnie bardzo różne: „Sprawdź wymagania dla stanów / krajów na wybranej trasie”, „kup kamizelkę bezpieczeństwa”, „wymień wygasłe treści z pierwszej pomocy zestaw ”,„ sprawdź oponę zapasową ”,„ umów się na spotkanie z garażem, aby sprawdzić silnik ”,„ idź do garażu, aby sprawdzić silnik ”,„ idź do agencji państwowej, aby kupić przepustkę ”,„ sprawdź ubezpieczenie samochodu ”

To wyraźnie oddziela pytanie, czego właściciel produktu chce od tego, co musi zrobić. O ile oczywiście właściciel produktu nie rozłożył się już na elementy w Rejestrze produktu, w takim przypadku musisz również z nimi porozmawiać.

Jak już powiedziałem, wielu programistów uważa, że ​​mają już wystarczającą ilość informacji i wiedzą, co robić, nie chcą rozkładać kroków What into How, kiedy tam dotrą. Kiedy zaczniesz rozmawiać z nimi o śledzeniu postępów sprintu, poprawianiu szacunków, śledzeniu pracy, która została zapomniana podczas planowania sprintu i innych elementach związanych z profesjonalnymi ulepszeniami, zapytaj ich, jak oni i ich zespół będą wiedzieć, gdzie mogą się poprawić i jak wiem, że są naprawdę skończone. Kiedy mogą wymyślić system, który działa bez tworzenia zadań i działa, to jest w porządku, ale szanse są bardzo małe, że faktycznie mogą.

Przed próbą pracy z TFS i zwinnymi narzędziami zespół musi zrozumieć, jak to wszystko działa. Najlepszym sposobem jest, aby pracowały z tekturą, która jest widoczna dla wszystkich na podłodze roboczej. Później, gdy proces zostanie lepiej zrozumiany, pomocne będzie przejście do narzędzi. Bez zrozumienia narzędzia nie będą miały większego zastosowania i napotkają duży opór.

Myślę, że Jesse udzielił świetnej odpowiedzi. Po prostu postaram się to zrobić, cóż, prostsze (jeśli to możliwe) :) Element Backlogu produktu (lub historia użytkownika, jeśli wolisz) jest zwykle napisana w następujący sposób:

Jako nowy klient chcę zarejestrować moje dane, aby otrzymywać informacje o nowych wersjach produktu

W głowie programisty może to przekładać się na:

1. Utwórz formularz rejestracyjny
2. Zapisz dane rejestracyjne do bazy danych
3. Wyślij wiadomość e-mail do nowego klienta, aby potwierdzić jego rejestrację

Te trzy elementy to zadania.

Mam nadzieję, że to pomaga.

- Spraw, aby było to tak proste, jak to możliwe, ale nie prostsze (Einstein)

Oto jak wykonujemy:

PBI:

• jest wymaganiem zwanym „co”
• to jest to, o czym rozmawiasz z klientem .
• To pojawia się w Daily Project Update (DPU) dla sprintu ..... ponownie, ponieważ DPU jest skierowane do klienta.
• O tym będzie mówił klient i odnieść się do niego pod względem szacunków i budżetu.
• Może obejmować jedno lub więcej zadań.
• Jest zorientowany na biznes i opisany w języku biznesowym / stylu domeny, który rozumie klient.
• To, co jest testowane i akceptowane w testach akceptacji użytkownika (UAT)

Zadanie:

• Czy praca niezbędna do zmaterializowania PBI (wymaganie)
• Nie o czym rozmawiasz z klientem
• Nie pojawia się na DPU, ponieważ nie rozmawiasz o nich z klientami
• Jest szacowany, ale ma swoje szacunki zwinięte w PBI
• Jest dzieckiem do jednego i tylko jednego wymogu.
• Można to opisać (i często jest) za pomocą technicznego żargonu
• Testowane wewnętrznie i podpisane przez test
• Klient nie przyjmuje ani nie testuje w izolacji (nie wiedzą, że istnieją)

Mam tendencję do oferowania tego na pytanie:

PBI lub Story to coś więcej niż jedna osoba może się poruszać.

Zadania to coś, co może odebrać tylko jedna osoba.