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).

> 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"?