Strategia komponentu JIRA

Question

Niedawno przełączyłem się na JIRA z innego systemu śledzenia błędów, a wcześniej nie korzystaliśmy z pola "komponent". Projekt był dość mały, więc wydawało się, że nie jest potrzebny w tym czasie. Ponieważ projekt robi się coraz większy, stwierdzam, że pole komponentu może się przydać, ale nie jestem do końca pewien, jak podzielić komponenty.

Załóżmy na przykład, że mam aplikację bankową i dodaję funkcję przesyłania pieniędzy między kontami. Ta funkcja może być sklasyfikowana jako komponent "Konta", ale ma również wpływ na interfejs użytkownika, a także może mieć pewne problemy z bezpieczeństwem. Wydaje się, że wiele spraw będzie miało ten przekrojowy charakter.

Czy istnieje najlepsza praktyka określania sposobu podziału projektu na komponenty? Czy rzeczy takie jak "Interfejs użytkownika" i "Bezpieczeństwo" są zbyt szerokie?

nie jestem pewien, że to pytanie ma jedną poprawną odpowiedź, więc może to powinien być przeniesiony do wiki społeczności, ale jakieś ludzie mogą zapewnić wgląd byłoby pomocne tutaj.

Answer 1

Komponenty są najbardziej przydatne, jeśli mają oczywiste domyślne cesjonariusze dla każdego z nich (przewody komponentowe). Innym podejściem jest odczekać chwilę i użyć etykiet. Sprawdź, czy są popularne etykiety, których Twoi użytkownicy lubią używać, a następnie utwórz komponenty w ciągu kilku tygodni w przypadku tych etykiet.

~ Matt

Answer 2

Użytkownik, który utworzył błąd, może dodać wiele składników podczas zgłaszania problemu. Mogli więc wybrać opcję Konto, przelewy i kwestię bezpieczeństwa (lub Pożyczka, Płatności i problem z bezpieczeństwem), tak jak wszystkie składniki spowodowane konkretnym błędem. Dowolną kombinację składników można połączyć, aby zespół programistów dokładnie wiedział, gdzie występuje ten błąd.

Answer 3

Używamy pole elementem w naszej firmie głównie do klastra problemy w znaczący sposób, tak że raporty do tych składników może dać ci informacje zwrotne, które część swojego rozwoju aplikacji dostaje najwięcej problemów, lub gdzie następuje najwięcej zmian (z największymi skutkami błędów). Czasami składniki odzwierciedlają organizację projektu, a następnie aspekt domyślnego cesjonariusza jest prawidłowy (w odpowiedzi @ @doar). Ale nawet wtedy najbardziej interesującym aspektem jest przegląd projektu.