On 01/01/2013 20:12, Wojciech Muła wrote:
> W dniu wtorek, 1 stycznia 2013 18:13:48 UTC+1 użytkownik Andrzej Jarzabek napisał:
>>> Agile radzę omijać z daleka.
>>
>> A skoro już mamy nowy rok, to dla podtrzemania dyskusji napiszesz może
>> dlaczego?
>
> Agile skupia się na tworzeniu działającego produktu, nie dostarcza żadnych
> narzędzi dla zespołu w celu tworzenia utrzymywalnego programu. Celem jest
> działający produkt i zadowolenie klienta (tu i teraz).
>
> Mam okazję uczestniczyć w procesie SCRUMowym i nie potrafię dostrzec żadnych
> pozytywnych cech takiego postępowania. Najbardziej irytujące jest właśnie
> skupienie się na dostarczeniu "inkrementu" na review, przez co odkładane
> są prace na później. W konsekwencji kod wymaga refaktoringu w kolejnej
> iteracji/iteracjach, więc i straty czasu.
>
> Precyzyjne planowanie prac jest wykonywane w perspektywie jednego sprintu,
> przez co mamy do czynienia z podejściem "koduj najpierw, myśl później".

Trudno mi się wypowiedzieć na temat tego procesu, w którym miałeś
okazjęę uczestniczyć, ale ogólnie jeśli chodzi o techniki Agile to się
przykłada _bardzo_ dużą wagę do utrzymywalności kodu i w ramach Agile
jest całkiem sporo narzędzi do tego celu. Paradoksalnie, właśnie
wspomniana przez ciebie refaktoryzacja jest jednym z tych narzędzi.

Może ci się wydawać, że metoda "do the simplest thing" a potem
refaktoryzowania jest mniej wydajna od BDUF. Częscią problemu z takim
założeniem jest to, że często się okazuje, że to, co początkowo wydawało
się potrzebne, w końcu okazuje się niepotrzebne lub niewiele warte i
wypada z release. Drugą częścią jest to, że jeśli potrzebne okaże się
coś, czego twój projekt nie przewidział, to to wszystko, co
przewidziałeś i pod co "ugeneryczniłeś" swój projekt staje się balastem,
nawet jeśli z tej elastyczności nie korzystasz.

Tak więc jeden argument jest taki, że czas można w ten sposób nie
stracić, a zyskać. W rzeczywistości być może jest tak i tak.

Drugi argument natomiast jest psychologiczny i jako taki subiektywny,
ale wielu ludziom się w ten sposób po prostu lepiej pracuje. Działa to
chyba trochę na tej samej zasadzie co zrozumienie złożonego problemu
przez ograniczenie go do prostszego, i potem dokładanie kolejnych
komplikacji. Jeśli release'owa postać programu jest takim złożonym
problemem, to uważam, że uzyskanie działającego programu dla
uproszczonych wariantów (wraz z baterią testów oczywiście) daje znacznie
lepszą szanse na rzeczywiste zrozumienie problemu niż napisanie
dokumentu czy narysowanie diagramu - nawet jeśli trochę więcej czasu
trzeba na to poświęcić. A mój większy komfort w tym względzie przekłada
się na pozytywny wpływ na wydajność pracy, która z naddatkiem kompensuje
tę stratę.