Mamy ten sam problem.W przypadku, gdy masz problem (błąd lub nową funkcję), który dotyczy wielu produktów i które mają zależności między nimi. (Jako przykład powiedzmy, że mamy serwer, api połączenia i aplikację kliencką). Jeśli istnieje jakiś nowy pomysł dotyczący rozszerzenia aplikacji klienckiej w pewien sposób, to całkiem możliwe, że także api połączenia i serwer potrzebują jakiegoś rozszerzenia. Prawdopodobnie są one opracowywane przez różne zespoły ... Nie są obsługiwane w tym samym sprincie/iteracji, ale jako właściciel produktu chcesz śledzić wszystkie te nowe funkcje jako grupę.
W rzeczywistości stworzyliśmy kilka niestandardowych pól. Pierwsze pole, które wprowadziliśmy, to "Cascading Select", jako "Program" i "Faza". Daje to właścicielom produktów możliwość grupowania problemów w ramach programu i wykonywania pewnych przybliżonych planów długoterminowych (kilka iteracji).
Następnie dodaliśmy kolejne pole (Pole tekstowe) do "Eposu" (lub "Motywu"), które obejmuje problemy związane z określonym Eposem/Motywem. Pomysł polega na użyciu "Epics" w "Programie". W przypadku większego "Programu" można prawdopodobnie podzielić go na różne części, które następnie zostaną odzwierciedlone w tych "Epikach". (Rodzaj fabuły: grupa opowiadań (które mogą się rozprzestrzeniać na wiele produktów), które dodają wartości jako otwór w serii produktów).
Oba pola sprawiają, że teraz łatwo jest odfiltrować problemy, które dotyczą wielu produktów, w oparciu o Program (z jego fazą lub bez) i Epic.
Rzeczywiście po włączeniu łączenia można teraz tworzyć zależności między różnymi problemami w różnych produktach. Jest on całkowicie oddzielony od domyślnej wersji produktu Jira. Co jest świetne, więc normalny proces uwalniania pozostaje taki, jaki jest.
Innym pomysłem, który zamierzam wprowadzić, jest pole "Iteracja". Podczas wchodzenia w sesję planowania (lub tuż po niej). To pole może zostać zaktualizowane nazwą tego sprintu (Jira jest świetna w edycji/aktualizacji wielu wersji). Dzięki temu można łatwo odfiltrować wszystkie problemy związane z tym sprintem.
Najbardziej podoba mi się używanie Jiry również jako narzędzia do planowania Scrum/śledzenia sprintu, ponieważ nie ma osobnego narzędzia do planowania i tworzenia zaległości. Błędy są bardziej widoczne. Brak podwójnego podawania błędów w narzędziu do planowania i/lub planowania elementów w narzędzie do śledzenia błędów (dla prawidłowych numerów zatwierdzeń cvs/svn/etc). Lub generowanie uwag do wydania.
Dzięki, to interesujący pomysł; Naprawdę wolałbym mieć problemy z wymaganiami w projektach, do których się odnoszą, ale zobaczę, jak działa Twoja sugestia. –