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

9

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?

sbi
źródło
2
Wydaje się, że to zbyt duży narzut dyplomatyczny, aby dodać funkcję do biblioteki lib. W naszej firmie złożonej z 50 programistów (oprogramowanie medyczne) nadal pozwalamy programistom na wysyłanie kodu do każdej z naszych bibliotek wewnętrznych, jeśli uznają to za stosowne. Oczywiście później sprawdzone. Możesz rozważyć pracę z przepływem żądań, ale spotkanie? Nie. To nigdy nie zadziała.
Teimpz
@Teimpz: Oczywiście wszyscy będą naciskać na biblioteki wewnętrzne i oczywiście każdy kod jest sprawdzany. Jednak o kolejności rozwiązywania podstawowych problemów (które nie są konieczne w przypadku niektórych bieżących projektów) decydują wszystkie zespoły. To działa całkiem dobrze, tylko Jira nie wydaje się dobrze wspierać.
sbi
Narzut wygląda na całkiem sporo, ale biorąc pod uwagę, że rdzeń jest tak szeroko używany, chętnie zaakceptuję trochę narzutów, aby upewnić się, że nic nie pójdzie źle. Spotkanie wydaje się jednak dużo. Widziałbym to jak każde inne zadanie, ale dodatkowa komunikacja - recenzje, rozmowy - byłaby ważna.
Erdrik Ironrose,

Odpowiedzi:

2

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.

Erdrik Ironrose
źródło
To wydaje się kłopotliwe, ale tak, zadziałałoby. Więc +1ode mnie.
sbi
0

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.

Stare konto
źródło
-2

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

Ewan
źródło
To wydaje się dziwne. Na początek: Jak myślisz, jaka jest różnica między tym, co nazywasz „bibliotekami z określonym małym zestawem logicznie pogrupowanych funkcji”, a tym, co nazywamy „bibliotekami podstawowymi”? (BTW: Wygląda na to, że przegapiłem powiadomienie o tej odpowiedzi. Przepraszam, że odpowiedziałem tak późno.)
sbi 12.12.16
Myślę, że to dla mnie wyjątkowy cytat: „napisany przez siebie fragment kodu jest bardziej interesujący i powinien zostać wyodrębniony do biblioteki podstawowej”. Jeśli współdzielone projekty są pełnymi „bibliotekami”, nigdy nie trzeba do nich dodawać funkcji.
Ewan,
Nie rozumiem twojego argumentu. Dlaczego jakikolwiek kod nie skorzystałby z konserwacji? Czy Twoi klienci nigdy nie żądają nowych funkcji, co prowadzi do napisania nowego kodu? A skąd wiesz, że kod jest przedmiotem wspólnego zainteresowania, poza tym, że przydzielono mu inny projekt z wymaganym już zainteresowaniem?
sbi,
Powiedzmy, że twoja biblioteka to Json.Net. ma jeden cel serializować obiekty do JSON i odwrócić. na pewno będziesz musiał naprawić błąd lub dodać obsługę ogólnych, ale ogólny zestaw funkcji nigdy się nie zmienia. Nigdy nie jesteś w sytuacji, w której na przykład klient prosi Cię o wdrożenie „możliwości anulowania zamówień” lub cokolwiek innego i myślisz: „Dodam to do Json.Net”
Ewan,