Jak radzić sobie z historiami, które mają wspólną funkcjonalność

Mam dwie historie (wiem, że brakuje im części korzyści)

1. Jako użytkownik zarządzania kredytem mogę przeglądać bieżące i poprzednie różnice płac w biurach.
2. Jako użytkownik zarządzania kredytami mogę otrzymać wiadomość e-mail zawierającą plik PDF z obecnymi i poprzednimi różnicami w wynagrodzeniach dla biur.

Oba są powiązane, ponieważ będą miały te same kryteria Zapytania / Filtrowania. Jedyną różnicą jest to, że w historii „Wyświetl” wyniki są wyświetlane użytkownikowi, aw historii „E-mail” wyniki są zapisywane w pliku PDF, który jest wysyłany pocztą e-mail do użytkownika.

Walczę z oddzieleniem wspólnych aspektów tych dwóch historii, a nawet jeśli powinienem to zrobić.

Na przykład oboje będą mieli to samo zapytanie, to, co robią z wynikami, jest inne.

Czy powinienem rozdzielić zapytanie na inną, czysto techniczną historię?

Utworzenie pliku PDF i wysłanie wiadomości e-mail powinno odbywać się offline, czy powinno to stać się historią techniczną?

Widziałem dzielenie tych dwóch historii na 2 funkcjonalne i 2 techniczne.

1. Jako system mogę obliczyć różnice w bieżącej i poprzedniej liście płac dla biur.

2. Jako użytkownik zarządzania kredytem mogę zobaczyć różnice w bieżącej i poprzedniej liście płac dla biur.

3. Jako system mogę utworzyć dokument PDF dotyczący różnic w bieżącej i poprzedniej liście płac dla biur.

4. Jako użytkownik zarządzania kredytami mogę poprosić o wiadomość e-mail zawierającą plik PDF różnic w bieżącej i poprzedniej liście płac dla biur.

Problem, do którego ciągle wracam, polega na tym, że 4 historie nie są niezależne i nie „kroją ciasta”.

Nie jestem więc pewien, jak sobie z nimi poradzić.

Historie użytkowników nie są specyfikacjami systemu ani wymaganiami funkcjonalnymi. Są raczej początkiem rozmowy, która może prowadzić do takich specyfikacji lub wymagań.

W związku z tym spodziewałbym się, że wdrożenie systemu będzie się pokrywać. Historie użytkowników nie mają na celu opisania takiego nakładania się funkcji ani jego wyeliminowania. Historie użytkowników mają na celu uchwycenie oczekiwań funkcjonalnych z punktu widzenia użytkownika, a nie opisanie szczegółów implementacji.

Nie rób: spróbuj podzielić historie, zrób jedną historię, a potem drugą.

Zrób: Upewnij się, że zespół programistów zna drugą historię.

Problem z próbą zaplanowania szczegółowych zadań i stworzenia ogólnego modelu, który może obsłużyć oba w elegancki sposób, jest taki, że jest trudny.

Celem historii użytkowników jest zrobienie czegoś. Elegancki jest celem drugorzędnym i powinien zostać pozostawiony do refaktoryzacji.

Oczywiście jest to bardzo irytujące, jeśli podejmiesz to do maksimum i nie powiesz nikomu o dziesięciu innych podobnych zadaniach, które należy wykonać, ale jest również całkowicie możliwe, że drugie lub trzecie zadanie nie zostanie wymyślone, dopóki nie zostanie wykonane pierwsze. Jeśli chcesz to wszystko zaplanować, idź z wodospadem.

W brutalnej umowie z Robertem Harveyem historia użytkownika ma na celu zrozumienie, co użytkownik musi zrobić. Podczas pielęgnacji klient rozumie historię użytkownika i dba o nią, ale programiści dbają o coś więcej. Po zadaniu wystarczającej liczby pytań, aby zrozumieć i oszacować pracę, możesz utworzyć zadania wspierające je.

W tym konkretnym przypadku możesz utworzyć zadania, które umożliwią sedno obu historii użytkowników, które zostaną wykonane wraz z tym, co zrobisz jako pierwsze.

Ważne rzeczy, które należy dodać do historii użytkownika:

• Kryteria przyjęcia
• Założenia

Ściśle mówiąc, Historie użytkowników są obietnicą rozmowy, która pozwoli zrozumieć wymagany wynik.

Na przykład biorąc swoją drugą historię użytkownika

Jako użytkownik zarządzania kredytami mogę otrzymać wiadomość e-mail zawierającą plik PDF z obecnymi i poprzednimi różnicami w wynagrodzeniach dla biur.

Pomyśl o następujących kwestiach:

• Czego potrzebuje użytkownik, który kieruje tym wymogiem? (Czy plik PDF w wiadomości e-mail jako rozwiązanie pochodzi od nich? Może to nie zaspokajać potrzeby, a Twój zespół może zaproponować lepsze rozwiązanie)
• Jaki jest minimalny wycinek, który może zaspokoić tę potrzebę użytkownika i zweryfikować twoje rozwiązanie? Krótkie pętle zwrotne są cenne.

Zbliżając się do dzielenia historii, pamiętaj o swoich kryteriach INVEST, jeśli to możliwe.

1. Jestem niezależny
2. Nie do zaakceptowania
3. V aluable
4. E stymulowalny
5. Centrum handlowe S.
6. T estable

W porządku są historie, które mają naturalny porządek. Weź to pod uwagę - zazwyczaj pierwsza historia jest większa, ponieważ wprowadza wymaganą funkcjonalność, a druga opiera się na niej.

Zakwestionowałbym historie „techniczne”, ponieważ generalnie najprawdopodobniej są to zadania mające na celu wsparcie w implementacji historii zorientowanych na wyniki użytkownika.

TL; DR

Zakładając, że obie historie użytkowników są objęte zakresem tej samej iteracji, zadaniem zespołu jest rozkład historii na plan wdrożenia i związane z nim zadania. Historie użytkowników zapewniają kontekst i zakres; nie są implementacjami, specyfikacjami ani elementami listy dziurkowania.

Historie powinny być rozkładane na zadania iteracyjne

Bez względu na to, czy stosujesz Scrum, czy inną zwinną metodologię, częstym błędem jest pomijanie fazy planowania iteracji. W Scrumie, gdy element Backlogu produktu (ściśle mówiąc, nie musi to być historia użytkownika) jest wciągany do bieżącego Sprint, zespół powinien następnie użyć części Planowania Sprintu, aby rozliczyć podobieństwa między elementami pracy, zidentyfikować zależności i następnie opracuj dziennik sprintu, aby przechwycić pracę na poziomie zadania.

Jak zauważyłeś w swoim poście, zwinna iteracja zawiera ściśle powiązane historie użytkowników (nie jest niczym niezwykłym (a wręcz pożądanym)). W Scrumie jest to możliwe dzięki wykorzystaniu celu sprintu. Poza ramami Scruma często sensowne jest pobieranie powiązanych historii ze względu na ich wspólne cele lub wspólne zależności. Wyodrębniając współdzielone zależności, a następnie pracując nad nimi w ramach pojedynczej iteracji, zespoły często mogą uniknąć konieczności refaktoryzacji lub iteracji kodu w celu uzyskania podobnych, ale nie identycznych funkcji w przyszłości.

Zadania Wdrażanie historii

Oto inny sposób myślenia o planowaniu zależności dla historii użytkowników. Ogólnie:

1. Epicki / motyw jest używany do długoterminowego planowania lub grupowania w zaległościach.
2. Historia użytkownika służy do komunikowania celów, kontekstu i zakresu.
3. Planowanie just-in-time służy do opracowania implementacji pasującej do jednej iteracji.
4. Zadania wdrażają plan dokładnie na czas, który spełnia definicję ukończenia dla jednej lub więcej historii użytkowników.

Traktowanie historii użytkowników jako planu wdrożenia lub listy zadań jest uważane przez większość praktyków za zwinny anty-wzorzec. Bez względu na to, jak to nazwiesz, nie pomiń fazy planowania w odpowiednim czasie swojego zwinnego frameworka i upewnij się, że śledzisz zależności i współużytkujesz szczegóły implementacji gdzieś w procesie zespołu.