Story-Splitting-b-agile

więc to jest mniej więcej kwestia gustu, czy wolisz graficzny diagram przypadków użycia, czy listę (tekstowych) historii użytkownika.

pozwólcie, że podsumuję dyskusję na temat strukturyzowania wymagań w dużym: niezależnie od notacji rozkład dużego problemu na proces wyzwalany zewnętrznie jest najbardziej neutralnym sposobem osiągnięcia tego podziału. Nie opiera się na żadnej wewnętrznej strukturze systemów (Nie jego funkcji, nie jego podsystemów, Nie jego obiektów, .,,), ale wyłącznie na potrzeby środowiska.

nie oznacza to, że inne strategie dekompozycji wymienione powyżej nie działają, a jedynie sugestię, aby nie utknąć w wewnętrznych dyskusjach strukturalnych.

Dzielenie w małym

jak widać w prostym przykładzie systemu nawigacji powyżej ten proces (niezależnie od preferowanej notacji) nadal wydaje się zbyt złożony, aby można go było zaimplementować w jednej iteracji. Zdecydowanie musisz podzielić go na mniejsze kawałki. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) zasugerował wiele sposobów radzenia sobie z większymi kawałkami i dzielenia ich na historie, które są wystarczająco małe, aby umożliwić jedną iterację.

podczas gdy klasyczne metody sugerowały przede wszystkim lepsze zrozumienie złożonego procesu poprzez spojrzenie na jego sekwencję kroków, obecnie stoimy w obliczu dodatkowego problemu w świecie agile: chcemy tworzyć wartość w każdej iteracji, tj. wymyślać potencjalnie możliwe do wysyłki przyrosty produktów. Nie jest wystarczająco dobre, aby po prostu rozłożyć duży proces (przypadek użycia lub duża historia) dla lepszego zrozumienia go. Po rozłożeniu każda z części nadal powinna dostarczyć użytkownikowi pewną wartość niezależną od pozostałych części.

to hamuje podziały techniczne, takie jak dzielenie na warstwy techniczne, takie jak interfejs użytkownika, funkcjonalność domeny i warstwa trwałości, ponieważ implementacja warstwy trwałości najpierw (tj. tworzenie tabel bazy danych) nie dostarcza żadnej wartości biznesowej, dopóki nie można ich wypełnić i wyświetlić. To samo często odnosi się do czystego rozkładu procesów biznesowych na etapy: wdrożenie tylko jednego kroku 7 złożonego procesu może nie przynieść żadnej wartości, o ile nie ma kroków poprzednika i następcy.

(po prostu interesująca historyczna uwaga na temat wojen terminologicznych między metodologami: Mike Cohn skarżył się, że historie użytkowników nie są przypadkami użycia po prostu za pomocą argumentu: mogą być zbyt duże, aby zaimplementować je w jednej iteracji. Ivar Jacobson zaakceptował ten argument na temat rozmiaru, ale cofnął się twierdząc, że “plasterki przypadków użycia” są znacznie lepszym sposobem myślenia niż praca z wystarczająco małymi historiami użytkownika, ponieważ plasterki przypadków użycia dostarczają wartości end-to-end.)