W firmie, nad którą obecnie pracuję, zauważyliśmy, że czasami niektóre historie są ze sobą powiązane (jak w zbyt połączonych). Może być tak, że należą one do tej samej ogólnej funkcji lub że są to różne funkcje, ale niektóre z nich należy najpierw ukończyć, aby przejść do następnych itp.
Jak radzisz sobie z tymi sprawami, nie przerywając przepływu pracy iteracji? Czy robimy coś złego?
Odpowiedzi:
To świetne pytanie. Teoria mówi, że historie użytkowników powinny być niezależne, ale nigdy nie byłem w stanie tego w pełni osiągnąć.
Moim zdaniem najważniejsze jest przekazanie zależności, aby zarówno zespół, jak i właściciel produktu byli tego świadomi. Zmusi to właściciela produktu do przedefiniowania historii użytkownika, aby usunąć zależność (na przykład poprzez scalenie historii użytkownika) lub do odpowiedniego zdefiniowania priorytetu biznesowego, aby historia użytkownika głównego została najpierw wdrożona.
W oparciu o decyzję o priorytecie i PO zaimplementujesz oba w tym samym sprincie lub zależny zostanie wdrożony później bez żadnego problemu, ponieważ zlecenie zostanie już wykonane.
W najgorszym przypadku A jest zależne od B, a B jest zależne od A. W takim przypadku historie użytkowników są najprawdopodobniej niepoprawnie zdefiniowane i powinny zostać przepisane do A i B (głównie niezależne lub zależne tylko w jednym kierunku), a C zależne od A i B.
Zaplanuj je odpowiednio.
Umieść je w tym samym sprincie, a ponieważ historie użytkowników mają również priorytet w zaległościach sprintu, nie będziesz mieć problemu.
Ponieważ twój zespół bierze w tym udział, zdają sobie sprawę z zależności, więc nie powinieneś się niczego obawiać. Są to osoby dorosłe i jeśli wyjaśnisz im zależności (zazwyczaj wyjaśnią ci to), wszystko pójdzie gładko.
W Agile, podobnie jak w Waterfall, możesz robić tylko jedną rzecz na raz. I zwykle robisz A przed B, jeśli B potrzebuje A. To zdrowy rozsądek.
Zależności mogą być zapachem, że przecinasz swoje historie poziomo zamiast pionowo przez system. Opracowanie konkretnej funkcji powinno obejmować wszystko, od modyfikacji projektu bazy danych po interfejs użytkownika. Jeśli okaże się, że cały wysiłek poświęcasz historii użytkownika na jakimś niższym poziomie struktury systemu, na przykład pisząc procedury obsługi dla wyszukiwania w bazie danych, wówczas bardziej prawdopodobne jest tworzenie zależności między historiami. I prawdopodobnie źle piszesz historie użytkowników.
Najlepszym rozwiązaniem jest podzielenie historii niezależnych użytkowników na mniejsze części, które mogą stać się możliwie najbardziej niezależne. Powinieneś zająć się historiami, od których najbardziej zależą pierwsze (jak powiedziałeś: te, które trzeba ukończyć jako pierwsze, aby kontynuować pozostałe). Utwórz coś w rodzaju indeksu zależności: jeśli w historii 3 jest więcej osób zależnych niż w historii 1, najpierw powinieneś przypiąć ją do historii 3.
Jeśli twoje zależności powodują zbyt wiele przestojów, dobrym pomysłem może być całkowite zaprzestanie pracy (tak w trakcie bieżącego sprintu) i ponowna ocena historii użytkowników priorytetowych i rozwiązanie ich w pierwszej kolejności