03 listopada 2009

(wady) Agile - Dyskusja

Najwyraźniej ostatnia Warsjawa 2009 (patrz moja relacja Wrażenia z sobotniej, zwinnej Warsjawy 2009) pokazała niedosyt "lekkich" tematów o Scrumie/Agile podczas spotkań i konferencji organizowanych przez Warszawa JUG, bądź też w samej Warszawie. Na forum grupy rozgorzała dyskusja [warszawa-jug] (wady) Agile - Dyskusja, w której moim faworytem stał się nieznany mi wcześniej Adam Lider (nota bene, nazwisko mówi samo za siebie), który napisał (cytuję za pozwoleniem Adama w całości):

Po kilku latach doswiadczenia z lekkimi metodykami jestem sceptycznie nastawiony do Scruma. Uwazam ze jest to metoda, ktora moze nawet wyrzadzic krzywde filozofii Agile. Wytwarzanie oprogramowania jest rzemioslem trudnym, wymagajacym wiedzy, doswiadczenia, a przede wszystkim dyscypliny. Aby dojsc do "mistrzostwa" trzeba po prostu duzo pracy. Natomiast Scrum jest czesto widziany jako rozwiazanie dla zespolow, ktore sobie nie radza. Niestety zdecydowana wiekszosc tych zespolow zbudowana jest z malo lub srednio doswiadczonych ludzi i Scrum moze im niewiele pomoc a nawet zaszkodzic, poprzez koncepcje samoorganizujacego sie zespolu. Jak ja moge wiedziec co jest dla mnie dobre skoro malo jeszcze doswiadczylem? Najczesciej nie wiem. Co wiecej wprowadzenie Scruma do takich zespolow wprowadza rodzaj sztucznego uporzadkowania, w ktorym czesto wieksza wage przewiazuje sie do pielegnacji Scruma niz projektu. Tam gdzie Scrum dziala to najczesniej zespoly zbudowane z bardzo dobrych ludzi, a Scrum jest tylko (bardzo waznym) smarem dla dobrego mechanizmu.Dla zespolow mniej doswiadczonych zdecydowanie bardziej polecam XP. Dla mnie glowna roznica w stosunku do Scruma to zdecyowanie wiekszy nacisk na czysto techniczne praktyki tj. TDD, No bugs, Done Done z podkresleniem, ze musisz stosowac wszystko i nie jutro, ale dzisiaj. Praktykowanie TDD nie jest latwe i wiekszosc mniej doswiadczoncyh zespolow pracujacych pod etykieta Scrum (lub bez) po prostu odklada w czasie zastosowanie tej (lub innych rownie wymagajacych) praktyki (w koncu sami sie organizujemy i skoro to dla nas trudne, mozemy to zaczac pozniej). Jak sie ma kiepskich rzemieslnikow to Scrum niewiele pomoze. To troche tak jak z nasza reprezentacja pilki noznej - czy wierzycie ze z super taktyka super trenera nasi kopacze zdobyliby puchar w 2012? Moze i zagraliby lepiej, a moze wrecz przeciwnie bo np. kluczem dla taktyki bylaby gra z pierwszej pilki, a to trzeba umiec.

Moj glowny zarzut dla tej metody to proba wmowienia, ze wytwarzanie oprogramowania moze byc efektywne i dosc latwe (ze Scrumem), z niedostateczny podkresleniem wagi rzemiosla zespolu i jego czlonkow.


Ta wypowiedź dokładnie wyraża mój pogląd na temat lekkich metodyk, które mimo swojej nazwy nie są wcale lekkimi we wdrożeniu, bo ich lekkość jest zauważalna dopiero, kiedy zespół jest doświadczony, aby pozwolić sobie na samoorganizowanie i dyscyplinę pracy. Skąd niby członkowie młodych zespołów (doświadczeniem nie wiekiem) mieliby wiedzieć, czego chcą, jeśli ich jedyną potrzebą jest skończyć projekt (nic nadzwyczajnego, normalka) w technologi, którą dopiero poznają, bo wszyscy wkoło mówili, że fajna?! Przejaskrawiam z tą nową technologią, ale traktuję go jedynie jako przykład i możnaby tutaj podstawić wszystko inne, które kojarzy nam się z fantazją młodych zespołów. Tutaj podkreślam, że zwykle w takich zespołach panuje przekonanie, że fajna technologia będzie panaceum na brak doświadczenia zespołu oraz skróci czas, tak że projekt nie tylko, że zakończy się w założonym czasie, ale i budżecie (!) Marzenia ściętej głowy, co? Powiedziałbym, że zwinny zespół można budować z osób, które samodzielnie również potrafiliby poprowadzić ten projekt tyle, że zajęłoby im to więcej czasu. Siła doświadczonych inżynierów wynika z ich pragmatycznego podejścia do tematu i świadomości, że po ciekawym poranku z kawką i eclipsową wtyczką do pudelka (ukłon w stronę Mateusza) przyjdzie im ciężko popracować przy zadaniu. Jeśli do tej ciężkiej pracy dodamy niezwykle wyrafinowany funkcjonalnie superszkielet aplikacyjny, to mamy dwa podejścia, idziemy z nim w szranki i konkury, aby go poznać, a wtedy wdrażamy, albo po prostu zarzucamy, bo z naszych obliczeń wynika, że albo on albo my. To nazywam pragmatycznym podejściem. Mamy świadomość, że nie wszystko teraz i zaraz, że niektóre superrozwiązania jeszcze na nas poczekają. Takiej świadomości nie możemy oczekiwać od niedoświadczonych członków zespołu.

A Ty jak uważasz? Pewnie nie tylko ja jestem zainteresowany Twoim zdaniem, więc podejmij temat i wyraź swoją opinię na forum w wątku [warszawa-jug] (wady) Agile - Dyskusja.