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

> Agile mówi mniej więcej tyle, że należy pisać testy, które sprawdzają,
> czy program działa. To, jakie dokładnie te testy mają być i co
> obejmować pozostawia się do decydowania odpowiednim członkom zespołu.
>
> 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.
Czyli nie róbmy fetyszu z narzędzi.

> Osobiście też nie jestem przekonany, czy pełna widoczność procesu jest
> zawsze dobrym rozwiązaniem, być może jest tak, że czasem słuszniejszym
> podejściem jest "nikt nie chce wiedzieć, jak się robi kiełbasę".

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.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com