Do mojej płyty Pivotal Tracker dodałem kilka historii użytkowników, które rozwiązują problemy techniczne. Czy powinienem uważać je za cechy (utrzymywanie poziomu prędkości) czy za obowiązki / błędy (obniżanie prędkości)? Rozumiem, że na dłuższą metę nie zrobi to żadnej różnicy, jeśli zrobię jedno lub drugie konsekwentnie, ale za każdym razem, gdy dodam historię długu technicznego, muszę podjąć decyzję.

Kilka myśli:

• W rzeczywistości nie są to robaki, niczego nie psują
• Użytkownicy nie prosili o nic, ponieważ nie ma na nich wpływu implementacja niskiego poziomu, ale ułatwi to długoterminowy rozwój
• Jeśli definiować funkcje, jak historie, które dodają wartości do użytkowników, oraz a) nie, ponieważ użytkownicy nie widać żadnych bezpośrednich korzyści, ale potem b) robią, bo robią przyszły rozwój / utrzymanie możliwie który ma wartość dodaną, tylko nie teraz

Nie decyduję, czy faktycznie wykonać pracę, ani kiedy ją zaplanować, po prostu wiem, co powinienem nazwać długiem technicznym w moim narzędziu do zarządzania projektami i dlaczego.

To jest funkcja.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

Jest zdefiniowany i zaplanowany oraz śledzony, jak każda inna funkcja.

Jeśli wdrożenie tej funkcji nie jest wystarczająco cenne (dla klienta lub dla Ciebie), aby można ją było kiedykolwiek zaplanować, jest to inny problem.

(Spłaty) dług techniczny jest imho nie jest cechą , ponieważ klient nie jest uprawniony do podejmowania decyzji o tym . Co najważniejsze klient nie może decydować, kiedy jest gotowy, a dodatkowo klient jest całkowicie zależne od Ciebie, aby wyjaśnić korzyści. To jest twój wyrok, że nie ma dług techniczny, i to do ciebie, aby zdecydować, jak go naprawić, a kiedy skończysz. Dług techniczny ma wpływ na swoją prędkość (przyszłości), a nie na percepcję klientów oprogramowania. Jeśli nie było długu, można byłoby bardziej wydajne. A prędkość zostałeś pomiaru tej pory jest błędne, ponieważ należy wziąć więcej czasu, aby zachować kod w kształcie.

I sądzę, należy powiadomić o tym z klientem, ale nie jest to coś w ich kontrolą. Można powiedzieć coś takiego: „Byliśmy biorąc kilka skrótów do tej pory, co mamy do naprawienia. Oznacza to nasza prędkość będzie zejść nieco w ciągu najbliższych kilku iteracji, ale to, aby upewnić się, że mają w utrzymaniu oprogramowania w dłuższej perspektywie.

Kontynuując prace nad funkcją klienta pomoże również zachować skupienie się na poprawie oprogramowania dla klienta, zamiast tego staje jakiś ćwiczeń akademickich, aby znaleźć idealny projekt (jest to coś, czego osobiście walczyć z czasem).

IMHO zadanie polegające na wyeliminowaniu długu technicznego zdecydowanie nie jest cechą. Mógłby zostać przeniesiony do działu „błędów”, ale rozciągałby definicję terminów, ponieważ ponownie nie powoduje zmian w zachowaniu obserwowanych przez użytkowników.

Chciałbym po prostu nazywają to zadanie utrzymanie. W każdym projekcie programistycznym istnieje wiele takich zadań, takich jak konfigurowanie środowiska programistycznego / testowego, składanie danych testowych, łączenie oddziałów w SCM itp. Żadne z nich nie jest bezpośrednio obserwowalne przez użytkowników, ale ich regularne wykonywanie nie prowadzi do zwiększenia rozwoju koszty i szybkość błąd w dłuższej perspektywie.

Nie może być jednak konieczne do obsługi ich jako odrębnych zadań (o ile nie są ogromne, i / lub jesteś pod żadnym ciśnieniem do realizacji nowych funkcji w tej chwili). Zwykle może być lepiej po prostu określić, kiedy nowa funkcja wymaga refaktoringu / pisania testów jednostkowych itp i obsługiwać je w ramach opracowywania nowej funkcji. Może to być łatwiejsze do wyjaśnienia zarówno zarządowi, jak i użytkownikom końcowym (jeśli chcą wiedzieć, na co spędzasz czas). Aktualizacja: Ponadto pomaga programistom skupić się również na wartości refaktoryzacji. Łatwo jest dać się wciągnąć w refaktoryzację ze względu na refaktoryzację, więc skupienie się na wartości dodanej, jaką konkretna refaktoryzacja przynosi z perspektywy klienta, jest użyteczne IMHO.

Nazwałbym to improvement.

Nie jest to błąd, ponieważ nic nie jest zepsute.

Ani funkcja, ponieważ refactoring nie będzie żądanie klienta. (ponieważ to działa!).

Większość systemów śledzenia wspierać typ problemu improvementdomyślnie, jeśli nie prawdopodobnie można zmieniać typy i tak.