On May 26, 1:36 pm, Maciej Sobczak <s...@g...com> wrote:
> On 25 Maj, 14:59, Andrzej Jarzabek <a...@g...com> wrote:
>
> > Pół żartem mogę
> > powiedzieć, że masz tak dużo, bo nie stosujesz TDD.
>
> > Z tego co rozumiem, to w S&W przez większość czasu powinienes nie mieć
> > żadnych bugów w ogóle (o których wiesz).
>
> I właśnie tak jest. Ale w ciągu całego czasu użytkowania systemu tych
> bugów może się nazbierać - otwartych jest zwykle 0 lub 1, ale
> zamkniętych stale przybywa.

SIę gadza i o tym pisałem: ewidencjonowanie zamkniętych bugów to inna
sprawa. Nie wiem jakie masz w tym względnie doświadczenia, ale ja jak
rpacowałem nad jakimś projektem to praktyka była zwykle taka, że
otwartych bugów było dużo i w związku z tym utrzymywało się bazę
bugów, która służyła się do orientowania jakie bugi są jeszcze do
naprawienia, kto ma to zrobić, jaki jest priorytet plus jakieś traile
dotyczące tego
kiedy , przez kogo i w jakich okolicznościach zostały wykryte,
ewentualnych klientów, którym dany bug przeszkadza itd.

> A oprócz bugów są też feature requesty, których może być kilka(naście/
> dziesiąt) otwartych na raz. Czy jest sens używać osobnych systemów do
> różnych typów zadań? Nie, bo różnica pomiędzy bugiem a feature
> requestem jest jedynie *umowna*

Mimo to w używanych przeze mnie systemach do śledzenia bugów i
poprawek zwykle jest pozycja defect/enhancement.

> - czasami feature request potrafi mieć
> wyższą wartość dodaną dla użytkownika, niż poprawka buga, więc nawet
> nie ma sensu mówić, że bugi są ważniejsze.

A dla mnie jest z kolei sensowna sugestia, że w rozpoznanych tego typu
sytuacjach waga naprawy buga jest często niedoceniana.

Jakbym miał się określić jak należy w takiej sytuacji postępować, to
bym powiedział: jeśli się nie da szybko naprawić, to trzeba szybko
przerobi na feature. Poważnie - polegałoby to na tym, żeby w miarę
możliwości wyciąć kawałek funkcjonalności wokół tego buga,
poinformować klienta i dopisać dodanie z powrotem tej funkcjonalności
na listę stories/feature requests, do spriorytetyzowania w trakcie
następnej iteracji.