Jak modelować przygotowanie historii do problemów, które są rozwiązywane w kilku projektach

W naszej firmie kilka zespołów będzie pracować jednocześnie nad różnymi komponentami kilku projektów. Na przykład jeden zespół może tworzyć określone rodzaje oprogramowania (lub sprzętu) dla niektórych projektów, inny może tworzyć inny rodzaj oprogramowania. Używamy projektów Jira do hostowania problemów dla konkretnych projektów i tablic Jira do sprintu dla różnych zespołów.

Stajemy przed problemem unikania powielania się kodu w różnych projektach i opracowaliśmy zestaw podstawowych bibliotek, których używamy w tych projektach. Podczas pracy nad projektem niektórzy programiści zdają sobie sprawę, że napisany przez nich fragment kodu jest bardziej interesujący i powinien zostać wyodrębniony do biblioteki podstawowej, lub że część używanego przez niego kodu podstawowego zawiera błąd, potrzebuje większej parametryzacji lub nowa funkcja ... nazwij ją.

Tworzą więc podstawowy problem z biblioteką, który trafia do zaległości głównego projektu. Wszystkie te problemy są sprawdzane, uszeregowane według priorytetów i szacowane na spotkaniu w bibliotece podstawowej (raz w tygodniu) i zostaną rozwiązane zgodnie z ich priorytetem (obok problemów specyficznych dla projektu) w niektórych przyszłych sprintach.

Priorytetyzacja odbywa się poprzez sortowanie problemów, a my umieszczamy sortedetykietę na problemach posortowanych (abyśmy mogli wyszukiwać te nieposortowane). Następnie ręcznie umieszczamy jeden problem na kluczowy komponent na początku zaległości, aby zająć się nim w pierwszej kolejności. Gdy jakiś zespół wkłada taki problem do sprintu, musi ręcznie przeciągnąć inny element na szczyt zaległości.

Jest to dość podatne na błędy. Zasadniczo mamy dodatkowe statusy emisji „posortowane” i „oszacowane” między „otwartym” a „w toku”. Odzwierciedlenie tego poprzez sortedetykietę i ich pozycję na tablicy jest raczej uciążliwe i podatne na błędy. (Na przykład, jeśli ktoś porusza jakiś problem podczas jakiegoś sprintu w górę i w dół, zostanie to odzwierciedlone na płycie głównej, po cichu szyfrując kolejność problemów, o których zespół mógł zdecydować podczas obszernej dyskusji kilka tygodni wcześniej.)

Jaki byłby lepszy sposób na wdrożenie tego?

Jeśli chcesz to wyśledzić w JIRA, wykonałbym to tak, jakby to było nowe zadanie.

Na przykład:

Powiedzmy, że masz historię CORE-75: Foo the Bar .

Po podjęciu decyzji, który zespół podejmie się zadania, mogą następnie utworzyć nowe zadanie: SUPPORT-123: Foo the Bar in Core .

Następnie możesz zablokować CORE-75 za pomocą SUPPORT-123 . Po zakończeniu SUPPORT-123 możesz wrócić do CORE-75 . Możesz scalić opinie lub dwukrotnie przejrzeć kod (raz przez wyznaczony zespół, raz przez zespół bardziej specyficzny dla rdzenia).

Tak naprawdę to właśnie robisz: uważaj bibliotekę podstawową za swój własny produkt / klient, nie idź w pół drogi.

Jednym z podejść jest stworzenie przez zespół nowego problemu do sprintu, który łączy się z głównym problemem biblioteki. To trochę tak, jakbyś tworzył pod-zadanie dla zadania, ale we wszystkich tablicach / zaległościach.

Innym podejściem jest po prostu śledzenie tego osobno poza JIRA. Wyeksportuj istniejące zaległości jako CSV lub arkusz kalkulacyjny i uporządkuj je.

Oddzielając problemy od JIRA, masz swobodę definiowania priorytetu podczas spotkania planistycznego i nie musisz się martwić algorytmem sortowania JIRA na tablicach i nie będziesz musiał używać etykiet.

Na spotkaniu dotyczącym planowania priorytetów dla biblioteki podstawowej można utworzyć krótką listę zadań do wykonania dla biblioteki podstawowej, a osoba odpowiedzialna / odpowiedzialna za bibliotekę podstawową może upewnić się, że zadania te zostaną uruchomione przez różne zespoły projektowe i zakończone.

Istnieje pogląd, że biblioteki podstawowe, które zawierają wiele typowych, ale niepowiązanych funkcji, są „złą rzeczą” (tm)

Jest kilka powodów

• Pobierają zależności i kod, których nie potrzebujesz
• Ich zmiana powoduje zmiany we wszystkich aplikacjach
• Żaden pojedynczy „właściciel”

W twoim przypadku myślę, że podział zadań według aplikacji, w której wprowadzono by zmianę, jest źródłem problemu. Rodzaj odwrotnego prawa Conwaya.

Myślę, że najlepszym rozwiązaniem byłoby odejście od posiadania bibliotek „Core Libraries”. Biblioteki powinny mieć określony (mały) zestaw logicznie pogrupowanych funkcji. Powinno być możliwe ich uzupełnienie. tj. JsonParser, LogWriter itp. rzadko powinno mieć sens dodawanie nowej funkcji.

Jednak zakładając, że będzie to długie i trudne zadanie, jako drugorzędne rozwiązanie po prostu zatrzymam podstawowe zadania biblioteczne w zespole, który potrzebuje tej funkcji. to znaczy.

Zadanie: dodaj funkcję X do produktu Y

Dev: hmm część kodu dla funkcji X powinna znaleźć się w bibliotece podstawowej. Umieszczę go tam jako część tego zadania