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.
W mojej pierwszej (no dobra, może drugiej) pracy spotkałem się ze Scrumem. Takim z codziennymi spotkaniami, z retrospekcją na koniec, ze spotkaniem planującym sprint. Miałem szczęście, że jako ja ten niedoświadczony pracowałem z doświadczonym programistą, który z niejednego pieca ... I muszę przyznać, że największym problemem była dla mnie estymacja zadań. Wszystko inne na czele z TDD spodobało mi się tak bardzo, że teraz nie wyobrażam sobie pracy bez TDD i przeglądów kodu. Sam też uważam, że Scruma trzeba dostosować do zespołu. Nie trzeba korzystać z wszystkiego wszystkiego o czym się pisze w kontekście "agile". Jeśli coś się nie sprawdza lepiej z tego zrezygnować np. zamiast esytmacji w "story points" robić to w godzinach. Scrum w gruncie rzeczy ma wiele ram, ograniczeń, zasad, które sprawiają, że nie jest już taki leciutki.
OdpowiedzUsuńDyskusja oczywiście ląduje u mnie w ulubionych zakładach - trzeba przeczytać bo wydaje się bardzo fajna.
Ta wypowiedź Adama jest tak przedstawiona, że Scrum (który dotyczy zarządzania projektem dowolnym nie tylko programistycznym) to tylko samoorganizujący się zespół i nic więcej. To tak jak zatrudnić kilku świeżo upieczonych studentów bez doświadczenia i powiedzieć, że mają napisać system AIAX :-)
OdpowiedzUsuńKażdy zespół potrzebuje mentora, przewodnika, etc. I tego powinien zażądać zespół, powiedzieć, że to ich blokuje przed dalszą pracą i to powinien zapewnić im Scrum Master. A jeśli nie powiedzą, to i tak Scrum Master powinien to wyłapać po najbliższych trzech-czterech spotkaniach.
To co do mnie przemawia w Scrumie, to że szybko pokazuje słabości zespołu i łatwo dzięki temu usprawnić ten najważniejszy element :D
"Niestety zdecydowana wiekszosc tych zespolow zbudowana jest z malo lub srednio doswiadczonych ludzi i Scrum moze im niewiele pomoc a nawet zaszkodzic"
OdpowiedzUsuńNo, oki, ale to patologia zespołu a nie metodyki...
Taki przykład:
1. Umiem jeździć na rowerze, jest fajnie
2. Widziałem w telewizji wyścigi motorowe. Wyglądało fajnie więc kupuję nowy sprzęt
3. Rozwalam się. No bo jednak motocykl to trochę co innego niż rower
4. Wyciągam wniosek: motocykle są do bani bo się połamałem....
Nie wczytywałem się w dalsze wywody, p. Lidera, bo już samo założenie wydaje mi się błędne. Nie sądzę, by istniała metodyka, która z niedoświadczonych programistów zrobi bogów jee, ale to nie wina metodyki.
Panie Michale,
OdpowiedzUsuń>> No, oki, ale to patologia zespołu a nie metodyki
Jestem bardzo daleki od odkreslania niedoswiadczongo zespolu patologicznym. Taki zespol tez moze tworzyc calkiem dobre oprogramowanie. Nikt nie jest od razu doswiadczony. Ten etap trzeba przejsc, chociaz unikalbym tworzenia zespolu z samych poczatkujacych programistow. Ale nawet taki zespol moze tworzyc dobre oprogramowanie, ale nie powinno mu sie wmawiac, ze sam sie moze organizowac, sam decydowac jakich narzedzi/bibliotek uzyc, jaki i kiedy dostarczac oprogramowanie, jak dokumentowac, itp. Taki zespol powinien dostac wytyczne (reguly) pracy. W takim zespole potrzebna jest mala dawka http://en.wikipedia.org/wiki/Command_and_control.
Charakterystyczny dla poczatkujach jest problem z szacowaniem. Generalnie wszystkigo, a w szczegolnosci wlasnych umiejetnosci. Czesto po przeczytaniu jakiejs ksiazki i paru tutorialach oceniamy siebie na conajmniej srednio-zaawansowanego w danej dzidzinie. A tak parawde dopiero po kilku latach pracy w tej dziedzinie osiagniemy ten poziom. Oczywiscie zalezy to od osoby, dziedziny i zaangazowania.
>> Nie wczytywałem się w dalsze wywody, p. Lidera, bo już samo założenie wydaje mi się błędne.
Jednak zachecam do przeczytania. Zanim odrzuci sie teze warto spojrzec na proby dowodu.
http://groups.google.com/group/warszawa-jug/msg/8091f366d76506fe
- Adam