On May 25, 1:16 pm, Maciej Sobczak <s...@g...com> wrote:
> On 24 Maj, 23:45, Andrzej Jarzabek <a...@g...com> wrote:
>
> > Nie no, oczywiście że nie postulują, żeby informacji nie było. Chodzi
> > raczej o to, że infrastruktura mająca na celu katalogowanie i
> > zarządzaniu dużą ilością otwartych bugów na raz jest uważana za
> > demoralizującą. Że w momencie, kiedy ilość otwartych bugów staje się tak
> > duża, że pojawia się potrzeba bazy typu JIRA, to znaczy, że robisz za
> > dużo bugów i zamiast zakładać bazę powinieneś zlikwidować przyczynę.
>
> 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. :-)

No więc oni uważają, że to zdecydowanie za dużo. 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). Jeśli masz regularnie więcej
niż jednego otwartego buga, to powinieneś najpierw poprawić wszystkie
bugi, potem zlikwidować przyczynę bugów, a potem dopiero dokładać nową
funkcjonalność.

Przy czym jeszcze raz przypomnę, że to jest metodologia dostosowana do
małych zespołów i się nie skaluje.

> > Jak wspommiałem, pomysł ten kwalifikuję jako "interesujący".
>
> A ja go kwalifikuję jako farmazon i utwierdzam się w przekonaniu, że
> agile to próba kreowania nowych buzzwordów bez istotnej wartości
> dodanej - zwłaszcza, jeśli większość tych haseł to pomysły, czego nie
> robić. Takie budowanie bez betoniarki...

Po pierwsze to jednak nieprawda, że większość to pomysły, czego nie
robić. W konkretnych metodologiach jest bardzo dużo o tym, co właśnie
należy robić i jak: planowanie, customer involvement, TDD, coding
standards, refaktoryzacja, programowanie parami, continuous
integration, informative workspace, root cause analysis, retrospektywy
itd. itp.

Jeśli chodzi o to, czy to buzzwordy, to może to tak wyglądać w
dyskusji usenetowej, ale przecież nie będę przepisywał książki. Piszę
np. TDD bez wyjasniania o co chodzi, bo zakładam, że dyskutant wie, a
jak nie wie, to sobie wygugla. Ale oczywiście samo TDD to temat na
osobną książkę, i też niejedna została napisana - mam właśnie w ręku
"Growing Object-Oriented Software Guided by Teses" Steve'a Freemana i
Nata Pryce'a.