Wymagania dotyczące śledzenia wielu projektów za pomocą JIRA (lub innych narzędzi)

Question

Moja firma używa JIRA jako narzędzia do śledzenia wymagań, a także do śledzenia błędów i pracowała całkiem dobrze, podczas gdy pracowaliśmy nad jednym projektem w czas.

Mamy teraz scenariusz, w którym mamy trzy różne propozycje projektów, których wymagania częściowo się pokrywają (np. Wymaganie 1 dotyczy projektów A i B, wymóg 2 dotyczy projektów B i C itp.). Chciałbym mieć możliwość wprowadzenia pojedynczego wydania JIRA dla każdego wymagania, ale nie wydaje się to możliwe, ponieważ emisje JIRA i projekty mają relację jeden-do-jednego.

Czy ktoś znalazł sposób, aby to zrobić w JIRA, a może z innym narzędziem, które integruje się z JIRA?

Answer 1

Chociaż nie ma jednej prawidłowej odpowiedzi, mogę zaproponować pomysł. Nie mam wystarczających informacji o twoim procesie pracy, ale wspominasz, że masz propozycje projektów. Zakładam więc, że projekty A, B i C są na wczesnym etapie. Zbieranie wymagań i takie, jeszcze żadnych błędów.

Skonfiguruj pojedynczy projekt JIRA, na przykład "Wczesne wymagania". Wprowadź wszystkie wymagania dla projektów A, B i C do projektu JIRA. Aby umożliwić relację wiele do wielu między wymaganiami a prawdziwymi projektami, skonfiguruj niestandardowe pole typu "wiele pól wyboru" lub równoważne i skonfiguruj "projekt A", "projekt B" i "projekt C" jako wartości. Dla każdego wymagania możesz sprawdzić, do którego projektu się odnosi.

Teraz - i tutaj robię więcej założeń - załóżmy, że niektóre propozycje idą dalej, a niektóre wymierają. Będziesz potrzebował procesu, aby: a) wyodrębnić wszystkie wymagania dla prawdziwego projektu A do nowo utworzonego projektu JIRA dla A - można to zrobić poprzez przeszukanie numeru seryjnego w trybie wyszukiwania &; b) usuń wszystkie wymagania, które nie mają powiązanego z nimi projektu na żywo - wyszukaj zbiorczy usuń.

Ostrzeżenia: jeśli chcesz podzielić się wymaganiami z różnymi klientami, będzie to trudne. Uprawnienia są konfigurowane dla każdego typu projektu JIRA: &.

Powiedziawszy to wszystko, JIRA nie ma cech zapewniających godne zarządzanie wymaganiami, takich jak linie bazowe i identyfikowalność. Ale może być ok dla gromadzenia danych do dalszej pracy.

Answer 2

Używamy funkcji "duplikaty" lub "odnosi się do" jiry.

Podnoszenie problemu w każdym projekcie, ale wiążesz je ze sobą. W ten sposób możesz mieć jeden problem "posiadany" przez projekt i możesz zamknąć wszystkie powiązane projekty po przetestowaniu zmian na każdym z nich.

Można nawet użyć zależności, jeśli ma to sens w konfiguracji projektu.

Answer 3

W tym przypadku prawdopodobnie lepiej jest używać przecięcia oprócz jiry.

Skorzystaj z Jiry, do czego jest najlepsza, i użyj Confluence do wszystkiego innego.

Podziel swoje różne projekty na wspólne "podmoduły", jeśli uważasz, że jest to przydatne, jednak byłbym skłonny zasugerować użycie Jiry głównie do śledzenia rzeczywistej implementacji i powiązanych błędów.

Answer 4

Innym podejściem jest utworzenie niestandardowego pola wyboru z hiperwłączami (np. "XYZ-123") do problemów jako opcji.

Answer 5

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.

Answer 6

Lepszym sposobem jest rozróżnienie problemów używanych do śledzenia rozwoju i wymagań, które często są takie same na poziomie 80% dla wszystkich projektów.

Rozwiązanie istnieje: Rmsis a JIRA plugin: