Korzystanie z oprogramowania do śledzenia błędów / śledzenia problemów w celu omawiania pytań projektowych, nowych narzędzi itp

Czy ktoś ma doświadczenie w korzystaniu z oprogramowania do śledzenia błędów / śledzenia problemów, takiego jak Bugzilla, Modliszka lub JIRA, nie tylko do zgłaszania błędów lub zadań, ale także do inicjowania i prowadzenia dyskusji, które ostatecznie prowadzą do podjęcia decyzji?

Na przykład deweloper uważa, że ​​wszystkie chronione pola powinny zostać zniesione i zmienione na prywatne z chronionymi metodami, które mają do nich dostęp. To nie jest jego wezwanie i chciałby to przedyskutować. Zazwyczaj porusza kwestię następnego spotkania programistów, pod koniec którego zapada decyzja. Zamiast tego moim pomysłem było, aby otworzył kwestię pewnego rodzaju „decyzji” i opisał swoje zamiary, tak jak normalnie można by opisać błąd lub zadanie.

Inni programiści mogą komentować, jeśli mają na to ochotę, a ostatecznie problem zostaje zamknięty jako „zaakceptowany” lub „odrzucony”.

Zalety, które widzę w tym:

• Komunikacja asynchroniczna: nikt nie jest zmuszony do wyrażenia swojej opinii na spotkaniu, gdy nie mieli jeszcze czasu na nadzorowanie wszystkich konsekwencji tej decyzji.
• Pisemny dziennik rozważań, które prowadzą do decyzji. Jeśli ktoś później podniesie to pytanie, można go skierować.
• Można nawiązać relacje z innymi kwestiami, np. Zadanie może być kontynuowane do podjęcia decyzji.
• Integracja z oprogramowaniem do kontroli wersji, np. Zatwierdzenie, można prześledzić od decyzji.

Niedogodności:

• Ciężki zapach złotego młota: oprogramowanie do śledzenia problemów zwykle służy do śledzenia przedmiotów, które można wykonać
• Narzuty organizacyjne mogą być nieproporcjonalne: zamiast małej nieformalnej rozmowy należy przekazać swoje pomysły w formie pisemnej

W naszym sposobie działania śledzenie problemów powinno śledzić wszystkie problemy. Nie wiemy, jakie problemy można rozwiązać, dopóki nie zostaną przeanalizowane. Jeśli w systemie śledzenia występują tylko problemy, które można rozwiązać, jest prawdopodobne, że są one zbyt wcześnie segregowane, co oznacza, że ​​wszelkie dyskusje i decyzje zostaną utracone. Przyjmujemy podejście, w którym każda rzecz powinna iść (w naszym przepływie pracy), ponieważ w przeciwnym razie problemy mogą być wielokrotnie podnoszone bez widoczności.

W naszej implementacji Jira mamy kategorię „Ryzyko”, dlatego używamy Jiry do śledzenia przedmiotów, których nie można wykonać, ale mogą w jakiś sposób zagrozić oprogramowaniu. Dyskusja na temat przedmiotu jest śledzona, a gdy ryzyko zniknie (lub zostanie zmniejszone) problem zostanie zamknięty. Podany przykład może łatwo przejść do kategorii Ryzyko.

Ważne jest, aby omawiać i śledzić takie sprawy, a także rejestrować decyzję. Gdy programista ponownie podnosi problem w ciągu kilku miesięcy, odpowiedź „Pytanie i odpowiedź” ma uzasadnienie.

Popraw mnie, jeśli się mylę; ale myślę, że to, o czym mówisz - „Może / Jak korzystać z systemów śledzenia błędów / śledzenia problemów, aby wykonywać także„ Śledzenie decyzji ”.

Na początku powiedziałbym, że to naprawdę świetny pomysł. Chociaż nie używamy go w dokładnie wspomniany sposób, ma sens, że używamy go do celów śledzenia. W naszym przypadku następuje długi wątek wiadomości e-mail - bardziej jako forum / lista mailingowa.

Jednak twoje pytanie w szerszym sensie dotyczy tego, jak skutecznie podejmować decyzje (i nimi zarządzać) i jak powiązać implikacje pracy z decyzjami podjętymi, co zapewnia lepszy wgląd.

Jak powiedziałem, może to być świetny pomysł, jeśli pomaga ludziom. Nie ma w tym nic złego. Ale do skutecznego podejmowania / zmieniania decyzji potrzeba kilku konkretnych rzeczy.

1. Prawdą jest, że większość decyzji powinna być podejmowana na szeroką skalę, tak aby wszystkie ważne aspekty zostały odpowiednio uwzględnione i zważone przed podjęciem decyzji. Zatem każde narzędzie, którego używasz, musi mieć przejrzysty dostęp do informacji dla wszystkich zainteresowanych. Masz rację, że asynchroniczny tryb przekazywania i gromadzenia informacji pomaga, ponieważ ludzie mogą zdążyć przed przedstawieniem sugestii. Jeśli zostaniesz poproszony o odpowiedź z góry - zazwyczaj na spotkaniach, ocena może nie być równie rozsądna w porównaniu do tej samej osoby z wystarczającą liczbą zadań domowych.

2. Nie musi to jednak oznaczać „czystej demokracji”, w której każdy głos jest równy. Ogólnie rzecz biorąc, osoba podejmująca decyzję powinna być jedną lub kilkoma osobami - i chociaż przyjęły wszystkie opinie, muszą być indywidualnie odpowiedzialne za decyzje, a nie wszystkie osoby, które wyraziły swoje opinie.

3. Większość decyzji musi być wykonalna. Może to być trudne do uniknięcia sprzeczności; ale fakt, że decyzje nie podlegają zaskarżeniu, a jedynie subiektywne, oznacza, że ​​istnieją możliwości przyszłych (błędnych) interpretacji.

4. Ważne jest, aby sklasyfikować poziom i zakres decyzji. Co najważniejsze, musimy ustalić, czy omawiamy konkretny problem projektowy czy konkretny aspekt kodu, aspekt procesów, czy te problemy związane z planowaniem i śledzeniem projektu? Dość często, gdy problemy wynikają z kodu produkcyjnego - wszystkie mają zastosowanie, ale musimy być w stanie rozróżnić wszystkie różne aspekty i niezależnie, aby móc skutecznie zarządzać tymi decyzjami.

5. Czasami mogą być podejmowane decyzje dotyczące tego, czy korzystamy z określonych systemów, czy też z ról i obowiązków poszczególnych osób; umieszczenie tych decyzji obok kodowania konkretnych decyzji na forum typu tablica ogłoszeń może być trudne.

6. Tylko dodatkowe anegdoty; każdy zespół musi traktować recenzje kodu i recenzje jako proces sam w sobie - co wyczerpująco obejmie wiele problemów, takich jak cytowany przykład. Są to decyzje, czy śledzenie decyzji dotyczy innych rzeczy, czy nie.

Dobre praktyki decyzyjne wymagają dużej dyscypliny w zbieraniu informacji i zapewnianiu, że decyzje są wdrażane z wdrażaniem we właściwym duchu.

Narzędzie może jedynie pomóc w zwiększeniu reprezentatywności informacji; ale to może być dobra pomoc, jeśli działa dla ciebie.

FogBugz jest właściwą drogą. To nie jest za darmo. Najnowsze funkcje jeszcze bardziej ułatwiają wdrożenie zwinnej metodologii.

Prostszą, darmową drogą będzie Asana.

Bez względu na to, jakiego narzędzia używasz, komunikacja zespołowa jest najważniejsza dla ułatwienia udanego projektu.