W dniu 2011-05-25 15:15, Andrzej Jarzabek pisze:
> On May 25, 1:56 pm, Paweł Kierski<n...@p...net> wrote:
>> W dniu 2011-05-25 14:16, Maciej Sobczak pisze:
>>
>>> Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
>>> lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
>>> to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
>>> końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
>>> pewno się mieści na ekranie. :-)
>>
>> Kanban postuluje m.in. to właśnie. Jeśli liczba zadań w określonym
>> stanie przekracza wartość krytyczną dla danego stanu, to cały wysiłek
>> zespołu jest skierowany na zmniejszenie liczby zadań w tym stanie.
>> W szczególności liczba zadań w stanie "bug". Wystarczy ustalić limit
>> bugów na liczba osób w zespole /2 i na jednej stronie raczej się
>> zmieści.
> [...]
>> Podejrzewam, że ideą było skrócenie maksymalnej liczby bugów do 1.
>> Fajne, ale nierealne.
>
> Shore&Warden proponują właśnie ustalenie tej liczby na 1. Co do
> realności, to twierdzą, że uzyskanie tego jest uwarunkowane
> stosowaniem odpowiednich praktyk, przede wszystkim TDD.
>
> Dlaczego ty uważasz, że jest to nierealne? (Nie mówię, że ja uważam
> inaczej, po prostu jestem ciekaw).

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

>> Dlatego w wielu wypadkach kartka i długopis oraz tablica korkowa
>> z post-itami sprawdza się najlepiej 8-)
>
> No więc oczywiście sugestia braku bazy bugów nie dotyczyła tablicy
> korkowej. Tablica korkowa to "informative workspace", a fakt, że masz
> buga to najbardziej istotna informacja, jaka może być.
>
>>> Ale też nie róbmy sobie jaj z rzetelności zawodowej.
>>> *Prosty* katalog bugów/zadań jest jak najbardziej wskazany, chyba w
>>> każdym projekcie.
>>
>> Choćby po to, żeby wiedzieć, ile ich mamy. Bez takiej wiedzy to
>> kompletny "Czy leci z nami pilot?".
>
> 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-)

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.

--
Paweł Kierski
n...@p...net