Czy historię użytkowników należy udostępniać programistom? [Zamknięte]

Często widzę historie, które mają rozwój back-end i front-end. Rozważmy na przykład duże okno dialogowe z kilkoma tabelami i niektórymi dynamicznymi kontrolkami. Zrobimy kilka historii (może jedną dla każdego stołu i drugą dla dynamicznego systemu sterowania).

Zespół deweloperów podzieli się następnie z jedną osobą z zaplecza, a drugą z przodu. Dzięki temu osoba zaplecza może po prostu martwić się strukturą warstwy SQL, podczas gdy osoba front-end skupia się na takich rzeczach, jak układ. Po uzgodnieniu początkowego interfejsu między zapleczem a interfejsem, dwaj programiści mogą skupić uwagę, aby wykonać swoją część do końca sprintu.

Potem nadchodzi chaos. Kto „jest właścicielem” jakiej historii? Co oznacza „w toku” lub „zrobione”? Czy powinniśmy stworzyć dwie osobne historie dla zaplecza i frontonu? Jeśli tak, to czy to nie łamie pomysłów na historie użytkowników oparte na funkcji? Nasz system ma pojęcie „podzadań”, co łagodzi niektóre z tych problemów. Ale zadania podrzędne powodują dodatkową złożoność. Czy jest lepszy sposób? Czy to „zły” sposób korzystania ze Scruma?

Przez kilka ostatnich lat korzystałem z jakiejś formy Agile w kilku miejscach. Nie mam jeszcze oficjalnego szkolenia, więc proszę wybaczyć niewłaściwą terminologię lub ideologię. Próbuję tylko nauczyć się praktycznych sposobów usprawnienia naszego procesu.

„Historia” jest tak nazwana, ponieważ reprezentuje kompletną, dobrze, historię z perspektywy klienta. Bez interfejsu użytkownika ani zaplecza nie ma ścieżki przypadku użycia do wykonania przez klienta.

W twoim przypadku zarówno front-end, jak i back-end powinny być pojedynczą historią. Podziel go na zadania. Deweloperzy są właścicielami różnych zadań. Zadania te można indywidualnie śledzić według ich faz - W toku, Gotowe kodowanie, Gotowe testy modułu itp.

Upewnij się, że do tej samej historii dołączasz zadania przydzielone do kontroli jakości - bez weryfikacji historia jest bezużyteczna. Kontrola jakości przetestuje kompleksową zintegrowaną historię, którą zobaczy klient. Dopiero wtedy cała historia powinna zostać oznaczona jako Gotowe. W idealnym środowisku Agile prawdziwy klient lub proxy klienta również wypróbowuje historię w uruchomionej aplikacji i zaznacza historię Zaakceptowana, jeśli spełnia uzgodnione wymagania.

Jeśli chcesz uzyskać szybsze sprzężenie zwrotne, spróbuj podzielić przypadek użycia na mniejsze funkcje end-to-end. Na przykład zamiast przypadku użycia, takiego jak „Klient może kupić rzeczy za pomocą koszyka”, podziel go na „Klient może dodać produkt do koszyka” itd. ... Następnie uzupełnij każdy mniejszy przypadek użycia od końca do końca, jak opisano powyżej.

EDYCJA: Chciałem wykonać kopię powyższych punktów w niektórych źródłach. Cechy dobrej historii użytkownika są przedstawione zwięźle za pomocą akronimu „ INVEST ”. Został stworzony przez Billa Wake'a i spopularyzowany przez ruch Scrum. Zwróć uwagę zwłaszcza na elementy opowiadań niezależnych i pionowych.

Więcej informacji tutaj i tutaj .

Kto „jest właścicielem” jakiej historii?

Ktokolwiek chwyta historię. Kluczowe z organizacyjnego punktu widzenia jest to, że za pracę odpowiada jedna osoba. Gdy zdobędziesz dwie osoby, zbyt łatwo jest przekazać złotówkę.

Czy powinniśmy stworzyć dwie osobne historie dla zaplecza i frontonu? Jeśli tak, to czy to nie łamie pomysłów na historie użytkowników oparte na funkcji?

To zależy. Widziałem, jak działają dwa sposoby. Jeśli historia jest na tyle duża, że ​​dwóch programistów pracuje nad nią w pełnym wymiarze godzin, być może należy ją podzielić. Jeśli dwaj programiści są częścią dwóch różnych zespołów, być może należy go podzielić. Jeśli dwaj programiści będą pracować nad nim podczas różnych sprintów, być może należy go podzielić.

Czy to „zły” sposób korzystania ze Scruma?

Kluczem do zapamiętania jest to, że proces służy wam, a nie odwrotnie. Historie użytkowników są sposobem dla ludzi technicznych i nietechnicznych, aby ułatwić komunikację. Określają, co chcieliby, wszyscy negocjują, a następnie przekazujesz informacje zwrotne w historii o jego postępach.

Tak długo, jak proces działa dla Ciebie, nie może być tak źle.

Tam, gdzie wdrożyliśmy modele Scrum, doskonale oczekuje się, że wielu użytkowników może być zaangażowanych w historię jednego użytkownika. Mogą istnieć prace nad warstwą danych, integracją, front-end CSS, infrastrukturą itp. Zespół może połączyć różne zadania cząstkowe, aby stworzyć historię, która ma to zrobić.

To powiedziawszy, jedna osoba jest właścicielem tej historii i jest odpowiedzialna za aktualizowanie jej postępu i zapewnianie, że wszyscy wykonali swój kawałek i że działa razem. To dla nas osoba, która informuje, że historia jest „skończona”.

Jak sugerują inni, mój zespół dzieli również historie użytkowników na zadania. Zazwyczaj jest to łatwe, jeśli zarządzasz historiami użytkowników za pomocą oprogramowania (takiego jak JIRA lub Rally). Następnie łatwo jest powiedzieć, które części historii się poruszają.

Ale alternatywą dla zadań byłoby po prostu przeniesienie własności, gdy każda osoba kończy swoją część. Tak więc historia jest przekazywana - być może programista 1 zaczyna ją od pracy wewnętrznej bazy danych, a następnie przechodzi do programisty 2, aby wykonać interfejs użytkownika. Następnie jest przekazywany do testera kontroli jakości w celu weryfikacji. Ta metoda powinna działać dobrze w środowiskach, w których używasz rzeczywistych kart na ścianie lub jeśli twoje oprogramowanie nie śledzi zadań.

Ale w każdym razie zalecam, aby nigdy nie nazywać historii „wykonaną”, dopóki zespół nie zgodzi się na to, w tym na testowanie. W ten sposób każdy ma szansę wnieść swój wkład. A jeśli połączysz to z pomysłami na zbiorowe posiadanie kodu i recenzje kodu, każda historia i tak naprawdę będzie „własnością” zespołu. Można go „przypisać” różnym osobom po drodze, ale jeśli ktoś jest poza domem (choroba / urlop / zbyt wiele spotkań? / Inne), praca może zostać wykonana.

Mój zespół często akceptuje historie użytkowników w ramach naszego porannego spotkania stand-up / SCRUM. W ten sposób każdy może łatwo potwierdzić lub spierać się, czy jest to rzeczywiście „zrobione”. Innym razem po prostu pozwalamy naszemu inżynierowi ds. Kontroli jakości to robić - jeśli jest zadowolona z tego, że jest przetestowana i działa, a wszystkie zadania są ukończone, to nazywamy to wykonanym.

Tam, gdzie jestem dzisiaj, nazywamy ten większy projekt „epickim”. Epos składa się z wielu historii i może obejmować wiele sprintów / iteracji. Historia jest dla nas zawsze przekazywana jednemu deweloperowi i powinna mieścić się w jednym sprincie. Pojedyncza historia jest następnie dzielona na zadania. Każde z zadań jest wykonywane przez tego samego autora tej historii. Zadania mają na celu dać wgląd w przebieg historii podczas sprintu / iteracji. Po zakończeniu każdej historii, każdy deweloper, epopeja pokazuje postęp.

Celem eposu jest posiadanie większego celu, który niekoniecznie pasuje do jednego sprintu / iteracji. Z biegiem czasu wszystkie historie są ukończone, a epos zakończony. Epopeje są umieszczane w wydaniu.

Potem nadchodzi chaos. Kto „jest właścicielem” jakiej historii? Co oznacza „w toku” lub „zrobione”?

Demonstrujemy kod co dwa tygodnie, w którym historie dotyczące tego sprintu / iteracji muszą być pokazane interesariuszom i zatwierdzone. W tym kontekście „gotowe” opowiadanie oznacza, że ​​mogę pokazać Ci, co robi. Deweloper jest właścicielem swojej historii i jest odpowiedzialny za jej pokazanie (ta część jest swego rodzaju nadmiernym uproszczeniem, ale wystarczająca do tej odpowiedzi; koordynujemy nasze dema przez jedną osobę). „Gotowe” oznacza, że ​​można to z powodzeniem wykazać. „W toku” oznacza, że ​​mam zaległe zadania, a historia nie jest kompletna. Epos jest zakończony, gdy wszystkie historie z tego eposu zostały pomyślnie zademonstrowane.

Teraz jest to idealny postęp przypadku. Mamy historie i dema, które zawodzą, użytkownicy, którzy chcą czegoś innego, itp. Powyżej jest cel i w przeważającej części działa.