Czy skrzynki powinny zostać ponownie otwarte na błędy, czy też powinny zostać otwarte jako nowe skrzynki?

Obecnie w moim miejscu pracy używamy FogBugz do zarządzania wszystkimi naszymi funkcjami i błędami w różnych aplikacjach internetowych.

Kiedy nowa funkcja ma zostać dodana do jednej z naszych aplikacji internetowych, tworzona jest nowa sprawa. Na przykład „Utwórz formularz przesyłania CSV”.

Następnie pracuję nad skrzynką, rejestrując ilość czasu, który na nią spędziłem. Po zakończeniu tej sprawy rozwiązuję ją i zostaje ona ponownie przypisana do otwieracza skrzynek (zwykle kierownika projektu), który następnie zamyka skrzynkę.

Jeśli są jakieś błędy w tej funkcji, mój Project Manager ponownie otwiera skrzynkę i przypisuje ją z powrotem z listą błędów.

Moim zdaniem uważam, że te błędy punktowe powinny być otwierane jako pojedyncze przypadki błędów, aby można je było łatwiej śledzić i aby nie były zaśmiecone oryginalnymi notatkami dotyczącymi funkcji.

Moi menedżerowie nie zgadzają się ze mną stwierdzając, że łatwiej jest obliczyć całkowity czas spędzony na tej funkcji, jeśli wszystko jest w jednym przypadku.

Ponadto uważają, że jest to mniej mylące dla naszych klientów, ponieważ mają tylko 1 numer referencyjny tej funkcji. Chciałbym jednak podkreślić, że błędy powinny być traktowane jako osobne przypadki, ponieważ jest to po ukończeniu pierwotnej sprawy.

Czy mam rację stwierdzając, że błędy powinny zostać ponownie otwarte jako nowa sprawa? A jakie są zalety / wady każdego sposobu zarządzania tym?

Zarówno ty, jak i menedżer macie dobry powód, aby postępować tak, jak każdy z was preferuje, i nie ma prawdziwej potrzeby kompromisu. Istnieje rozwiązanie, które działa dla mnie i rozwiązuje oba problemy.

W przypadkach takich jak Twoja stosuję podejście do zadań wysokiego poziomu / zadań podrzędnych niskiego poziomu (koncepcja, którą wybrałem z JIRA , nie mogę stwierdzić, czy FogBugz wyraźnie ^{to obsługuje} ). W ten sposób wypunktowane listy „skierowane do klienta” przechodzą do zadań wysokiego poziomu, a „iteracje programistów”, które są dla mnie ważne, znajdują odzwierciedlenie w pod zadaniach.

Kiedy zadanie na wysokim poziomie zostanie „ponownie otwarte”, tworzę nowe pod-zadanie, aby śledzić dodatkowy wysiłek dla siebie .

W ten sposób programiści mogą wyraźnie odzwierciedlić wszystkie permutacje, perwersje i zwroty akcji, które przeszły przez specyfikację funkcji, wciąż pozwalając menedżerowi prezentować je klientom jako idealnie. Nawiasem mówiąc, doskonała prezentacja ma dla mnie jako programisty wartość, ponieważ łatwiejsza lektura dla klientów pomaga uzyskać dokładniejsze poprawki.

Pozwala to oczywiście mieć jasne uzasadnienie w przypadkach, gdy wdrożenie funkcji zajmuje znacznie więcej czasu niż pierwotnie oczekiwano.

_{Jeśli chodzi o śledzenie czasu dla każdego zadania lub zadania podrzędnego - ponieważ JIRA pozwala na włączenie śledzenia zadań podrzędnych do podsumowania wyższego poziomu, menedżer może śledzić czas w zadaniach podrzędnych. Jednak nawet gdyby tak nie było, mógłbym żyć z formalnym śledzeniem czasu w zadaniu „nadrzędnym” - w tym przypadku używałbym tylko komentarzy pod zadaniami, aby określić, ile czasu poświęcono na określoną iterację.}

Jeśli to wszystko dzieje się przed udostępnieniem tej funkcji klientowi, wystarczy mieć tylko jedną walizkę. Argument polega na tym, że sprawa nie jest naprawdę zakończona, dopóki nie przejdzie kontroli jakości i nie będzie gotowa do wydania. Inne korzyści - jeden numer sprawy dla fakturowania i odniesienia do użytkowników końcowych są ważne i ważne.

Po wydaniu tej funkcji i znalezieniu błędów należy je zgłaszać jako nowe problemy w oprogramowaniu do śledzenia problemów.

Całkowicie się z tobą zgadzam, podobnie jak FogBugz - dlatego definiuje różne kategorie błędów i funkcji. FogBugz nie został zaprojektowany jako narzędzie do śledzenia wykorzystania czasu; jest to przypadkowy produkt uboczny wprowadzenia harmonogramu opartego na dowodach.

Błędy dotyczące ukończonej funkcji można połączyć z głównym przypadkiem tej funkcji (w FogBugz, przy użyciu nazwy znacznika lub odsyłacza lub poprzez utworzenie ich podelementów). Widzę, że jest to nieco więcej pracy dla twojego PM na konsolidację informacji w kilku przypadkach, ale często sensowne jest również oddzielenie czasu poświęconego na pierwotne prace rozwojowe od czasu poświęconego na konserwację, szczególnie w przypadku umów o stałej cenie, oraz tracisz możliwość zrobienia tego, jeśli umieścisz wszystko w jednej skrzynce.

Moim zdaniem po zamknięciu biletu powinien on pozostać zamknięty, a moduł śledzenia błędów powinien być w stanie połączyć się z innymi sprawami. Chciałbym wskazać, że tworzenie nowych błędów i łączenie ich z oryginalną skrzynką zapewnia lepsze korzyści niż opisywana metoda.

• klienci nadal mogą mieć jeden numer referencyjny, który zawiera łącza do każdego błędu.
• status każdego błędu można śledzić indywidualnie, co pozwala na lepsze ustalanie priorytetów i raportowanie statusu.
• posiadanie osobnych błędów pozwoli menedżerowi rozłożyć czas poświęcony na błędy w porównaniu do czasu poświęconego na rozwijanie nowych funkcji i powinno to być jedynie minimalny dodatkowy wysiłek, aby uzyskać całkowitą liczbę wszystkich błędów związanych ze zmianą i rozwojem tej zmiany.
• Oddzielanie błędów znacznie ułatwia menadżerowi gromadzenie innych danych, takich jak łączna liczba błędów, średni czas na naprawę błędu, proporcje zamkniętych / w toku / naprawionych błędów.
• osobne przypadki dla każdego błędu pozwalają lepiej podzielić zadania między wszystkich programistów i pociągają każdego do odpowiedzialności za własną pracę, lub pozwalają na taką możliwość, jeśli więcej programistów zostanie zatrudnionych w późniejszym terminie.

Jedyną zaletą obecnej konfiguracji jest to, że jest ona niezwykle prosta dla osób, które nie są głównymi użytkownikami systemu. Celem narzędzia do śledzenia błędów jest, aby programista miał miejsce do zgłaszania wszystkiego o błędzie w jednym miejscu, które okazuje się być wystarczająco przyjazne, aby inni mogli zobaczyć postęp, a obecny system wydaje się podważać prawie każdą jego część.

Czy błędy zostały wykryte przed lub po „wysłaniu / wydaniu” produktu klientom?

Jeśli jest to przed wydaniem, błędy powinny być śledzone na podstawie oryginalnego biletu.

Jeśli nastąpi to po wydaniu, każdy błąd powinien być własnym biletem.

Tam, gdzie pracuję, tylko pracownicy QA mogą zamknąć sprawę. Mamy pola wyboru Kod sprawdzony, Testowany przez inżyniera i Wersja demonstracyjna dla interesariuszy (w Twoim przypadku Project Manager). Jeśli zespół kontroli jakości zobaczy sprawę oznaczoną jako „Gotowe”, która nie ma zaznaczonych wszystkich tych pól, oznaczy ją jako cofniętą i odeśle do nas.

Gdy sprawa minie wszystkie te fazy, a kontrola jakości ją zamknie, wszelkie znalezione przez nią nowe problemy są rejestrowane jako błędy.

Ten system wydaje się nam dobrze działać.

Myślę, że możesz argumentować na dwa sposoby. Spróbuję usiąść z premierem i wyjaśnić, dlaczego uważasz, że dyskretne problemy mogą ci pomóc. Osobiście chcę, aby każdy przedmiot do zrobienia był własnym biletem, ale rozumiem, dlaczego on chce go w ten sposób.