On 23/05/2011 22:14, Maciej Sobczak wrote:
> On 23 Maj, 12:53, Andrzej Jarzabek<a...@g...com> wrote:
>
> [Większość wyciąłem, bo w sumie to się chyba zgadzamy, tylko różnie to
> nazywamy.]



>> I ja się w tym zgadzam, że _prawie_ zawsze dla każdego większego
>> programu, który będzie robiony dłużej niż 2 miesiące przez więcej niż
>> 1-2 osoby i ma szanse mieć dodawaną jakąś funkcjonalność, np. w
>> postaci kolejnych wersji, _jakieś_ testy automatyczne warto napisać.
>> Niezależnie od tego, czy się akurat stosuje agile, czy nie.
>
> No właśnie. Dlatego *jakieś* testy piszę i pomaga mi to w trzymaniu
> fasonu przy różnych zmianach. Ale nie nazywam tego "agile", bo robię
> to wybiórczo. Podobnie, *czasami* siadam do klawiatury z kimś, bo to
> sprzyja weryfikacji i dzieleniu wiedzy, ale nie nazywam tego extreme
> programming, bo to też robię wybiórczo. Itd.

To jest tak: agile to dość szerokie pojęcie, niekoniecznie określające
ilość i rodzaj testów czy żeby używać TDD. W ramach agile masz też takie
procesy jak Scrum, które mówią, że trzeba zebrać zespół w którym jest
odpowiednia ekspertyza i dać zespołowi decydować o tym, co i jak trzeba
robić, żeby wyprodukować kolejną iterację.

Z drugiej strony ja w projektach wielosobowych widzę pewną wartość w
ustaleniu pewnego procesu czy zbioru zasad, których wszyscy zgadzają się
początkowo trzymać, z zastrzeżeniem, że co jakiś czas robi się przegląd
tego, jak proces działa i podejmuje się decyzje o zmianie. Bo jednak
doświadczenia różnych ludzi są różne i oczekiwania też są różne i
czasami nawet indywidualnie jako tam słuszne decyzje bywają między sobą
niekompatybilne i rodzą problemy.

Dlatego też wydaje mi się, że ma sens opisywanie i publikowanie takich
szczegółowych metodologii jak XP i Shore&Warden w szczególności, gdzie
można kumulować doświadczenia z wielu projektów. Przy czym oczywiście
też się zgadzam, że "there is no silver bullet" i częścią dobrego opisu
powinno być szczere przyznanie gdzie dana metodologia się sprawdzi i
jakie są przeciwwskazania.

I z drugiej strony sądzę, że korzystanie z takich metodologii "as
written" (a przynajmniej próba takiego korzystania) ma sens, przy
założeniu oczywiście, że decyzję o tym podejmują ludzie z odpowiednim
doświadczeniem - najlepiej sami użytkownicy.

> Czyli nie róbmy fetyszu z narzędzi.

"[...]we have come to value individuals and interactions over processes
and tools [...]"
heh.

> Heh. Pracowałem kiedyś w Poważnym Projekcie (TM), który był widoczny i
> otwarty dla zleceniodawcy, ale tak jakoś wygodnie było mieć *dwa*
> systemy zgłaszania bugów - klient widział tylko jeden z nich, drugi
> był do użytku wewnętrznego. Powiedzmy, że ten proces dbał o zdrowie
> klienta, który widział tylko te bugi, które sam se odkrył.
> Jak to określiłeś - problem kulturowy.

No więc a propos tego, to w Shore&Warden jest interesująca sugestia,
żeby w ogóle nie utrzymywać bazy bugów.