Gdzie rejestrujesz techniczny dług w TFS?

Chciałbym znaleźć sposób na zapisanie technicznego długu, który ponosimy w TFS.Gdzie rejestrujesz techniczny dług w TFS?

Muszę zarejestrować każdy element poza określoną iteracją, aby zapewnić, że jest on cały czas widoczny i łatwo raportowany. Rozważałem stworzenie oddzielnego obszaru dla technicznego długu, ale nie jestem pewien, jak dobrze pasuje to pole.

Jakie są niektóre wspólne podejścia, które mogę rozważyć? Czy nawet szczerzę odpowiednie drzewo, próbując znaleźć właściwe miejsce, by je umieścić?

Źródło

2009-12-21 Phil.Wheeler

Nie jestem pewien, jak to zrobić, ale jest to świetne pytanie. Ma to sens, aby śledzić swój dług techniczny, tak jak śledzisz wymagania. Problem, który widzę, polega na identyfikacji długu. Jeśli potrafisz go dokładnie zidentyfikować, możesz zrobić przedmiot pracy, aby go spłacić. –

TFS == Team Foundation Server? Pomaga w definiowaniu akronimów. –

Niestety - tak TFS === Team Foundation Server. Próbowałem oznaczyć je pomiędzy tagami , ale nie są one obsługiwane w SO. –

Nie znalazłem potrzeby śledzenia go oddzielnie; Po prostu wpisuję to jako dodatkowe zadania. W ten sposób można je łatwo śledzić i zgłaszać.

Źródło

2009-12-21 01:42:01 RickNZ

Ale czy nadal nie musisz kojarzyć zadania z konkretną iteracją? Czy uważasz, że to podejście jest czyste i łatwe w zarządzaniu? Co robisz dla zadań, które mogą obejmować kilka iteracji? –

Zarządzam nim jak każdym innym zadaniem - więc tak, uważam, że jest czysty i łatwy w zarządzaniu. Nie uważam za użyteczne wybicie "technicznego długu" jako oddzielnego obszaru; ostatecznie to sprowadza się do większej pracy w istniejących obszarach. Czasami zadanie przechodzi do bieżącej iteracji; czasami w innym. Podobnie jak w przypadku wszystkich zadań, czasami mogą one zostać odroczone z bieżącej iteracji do następnej, ponieważ iteracja dobiega końca. W przypadku zadań, które mogą obejmować więcej niż iterację, zwykle dzielę je na wiele zadań (nawet coś tak prostego jak "faza 1" i "faza 2" ogólnie działa dobrze). – RickNZ

Podoba mi się twój punkt widzenia na temat długów technicznych, które ostatecznie mają swoją "główną przyczynę" w istniejącym obiekcie lub obszarze projektu. Słuszna uwaga. –

Uważam, że istnieje kilka rodzajów długów technicznych: Dług, o którym wiesz i który możesz śledzić do czasu naprawienia, oraz długu, który staje się oczywisty w wyniku nieoczekiwanego błędu. Lubię śledzić zaległy dług techniczny znany jako w osobnej iteracji, którą nazywam "backlogem serwisowym", w obszarze "Technical Debt". Mogę następnie powiązać istotne błędy z DOWOLNEJ iteracji z obszarem Zadłużenia Technicznego, wciąż śledząc problemy, których jeszcze nie mogę rozwiązać. Kluczem jest to, że wciąż potrzebujesz błędów związanych z iteracją, którą są znalezione i naprawione oraz powiązanymi z pochodzącymi wymaganiami dla celów raportowania, itp.

Źródło

2009-12-21 01:58:25 PortageMonkey

Dzięki. Takie podejście mnie interesowało. Ale czy uważasz, że działa dobrze? Czy w ten sposób działają inne osoby/firmy? Czy twój obszar "Zadłużenie techniczne" i iteracja "Obsługa zaległości" są na najwyższym poziomie w hierarchii? –

Dobrze działa, ponieważ zespół może podjąć proaktywne podejście, dokumentując dług techniczny, nawet jeśli nie może go naprawić w bieżącej iteracji. Mogę również łatwo opisać, jak wiele nieporozumień w pracy na cykl wynika z długu technicznego itd. W naszej okolicy działa inna firma (200 + programistów), która stosuje podobne podejście. Nie mogę mówić za szerszą społeczność, ale wydaje się, że wykorzystuje TFS w zamierzony sposób. – PortageMonkey

Gdzie rejestrujesz techniczny dług w TFS?

Odpowiedz

Powiązane problemy