On May 25, 2:27 pm, Paweł Kierski <n...@p...net> wrote:
> W dniu 2011-05-25 15:15, Andrzej Jarzabek pisze:
>
> To co napisałeś obok wyjaśnia sprawę. Realne może jest w bardzo małym
> zespole i małym projekcie. W dużym intensywność testowania i używania
> może łatwo doprowadzać do sytuacji więcej niż jednego wykrytego błędu.

No, ten pomysł jest podany w ramach bardzo konkretnej metodologii
opisanej w książce, ale wydał mi się tak radykalny, że nawet przy tych
założeniach moją pierwszą myślą było "ciekawe, czy to się w praktyce
da zrobić?"

> Niezależnie od TDD, bo tu zgadzam się Maciejem - nie da się za pomocą
> TDD zapewnić takiego odsiania błędów.

Nie no, nie jest to zależne od TDD, bo TDD jednak podobno zdecydowanie
pomaga w redukcji ilości bugów, więc teoria jest taka, że z TDD jest
to możliwe w takim małym zespole, a bez TDD nawet w małym będzie
trudne. Co generalnie (przynajmniej jeśli chodzi o drugą część tego
zdania) potwierdza moje obserwacje.

> > Jeśli zwykle nie masz bugów, czasem masz jednego, a naprawdę wyjątkowo
> > masz więcej, to chyba nie potrzebujesz "bazy bugów"?
>
> Kwestia nazewnictwa. Dzięki brakowi wyjaśnienia podstawowych pojęć (tu
> "baza bugów") wyglądało, jakbyście z Maciejem mieli różne zdanie.
> A śmiem twierdzić, że jest wręcz przeciwnie - jest miejsce, gdzie bugi
> są spisane i obaj się zgadzacie co do konieczności istnienia takiego
> miejsca. Jakkolwiek je nazwać 8-)

No więc jeszcze raz: chodziło o narzędzie do zarządzania bugami ze
szczególnym uwzględnieniem bugów w danej chwili otwartych. W
szzególności to może wyglądać też tak, że masz bazę 'user stories',
którą utrzymuejsz, bo czasem trzeba przy danej story napisać trochę
więcej, niż się zmieści na karteczce, czasem implementacja danej story
odkładana jest na kilka iteracji do przodu i głupio by było w tym
czasie zgubić kartki. Więc taka baza ma sens. Ale jak cię korci, żeby
tej bazy używać też do bugów, lub mieć drugą taką do bugów, to
powinieneś się jednak powstrzymać, bo (jak głosi metodologia) nie
będzie ci potrzebna, a co gorsza działa demoralizująco.

> Ogólnie mam wrażenie, że cała dyskusja agile vs. waterfall sprowadza się
> do takich właśnie nieporozumień. Gdyby wyraźnie powiedzieć, że np.:
>   - waterfall to proces iteracyjny z niewielką liczbą iteracji (być może
> jedną),
>   - w iteracjach agile istnieje faza analizy (być może uproszczona,
> gdzie ryzyko tego uproszczenia jest wkalkulowane w koszty)
> to okazałoby się, że mówimy o tym samym procesie różniącym się pewnymi
> parametrami.

No ale te parametry robią różnicę, jest taki moment, kiedy ilość
przechodzi w jakość - np. czy dana faza trwa dwa miesiące, czy jest
trimeboxowana na 15 minut.