Strona główna Kontakt Jogger

Bazylowy Jogg

O makach, życiu i innych pierdołach

(Fr)Agile

Ostatnio coraz częściej zderzam się z ludźmi wierzącymi, że mają doskonałe pojęcie czym jest Agile. Zaglądam nawet na wikipedię i zwyczajnie oczom nie wierzę.

Agile zrobił się modny. Wszyscy chcą go używać i jednocześnie wszyscy doskonale wiedzą czym on jest. Problem w tym, że każdy sądzi podłóg siebie, definiując czym jest Agile po swojemu. Takie budowanie wielkiej teorii z niczego. Znajomy podsumował, że konstruują śmierdzącą kupę, pakują ją w celofan i ziu...

To był może niesmaczny cytat, ale jakże trafny.

Odkąd zacząłem pracę w Wielkiej Brytanii, każda firma, dla której pracowałem chwaliła się tym, że Agile wprowadza do swoich procesów biznesowych. Przywykłem nazywać te mutanty Fragile, bo dokładnie tym są. Wielką, śmierdzącą kupą, robiącą więcej zamieszania niż pożytku.

Ponieważ jednak - tak samo jak inni - mam swoją własną teorię na temat jak to działa, a co gorsze - używałem tego z powodzeniem w dużej firmie, może podzielę się swoimi spostrzeżeniami na ten temat.

Agile NIE JEST procesem tworzenia oprogramowania. Jest jedynie WSPARCIEM istniejącego procesu. Teoria głosi kilka podstawowych zasad:

  • Programista nie ma pojęcia w ile jest w stanie wykonać dane zadanie
  • Manager kocha się rządzić i nie znosi słuchać, że coś jest trudne albo zajmie więcej czasu, niż on sobie wymyślił
  • Zmiany last-minute są zawsze do dupy i zawsze psują smaczek pracy w tym zawodzie

Agile nie robi nic innego jak stara się rozwiązać te trzy podstawowe problemy. Z powodzeniem rozwiązuje dwa z nich. Trzeci traktuje troszkę po macoszemu.

Podstawową jednostką pracy w Agile jest SCRUM Team. Zespół ludzi pracujący nad danym fragmentem, bądź też całością kodu. W takim zespole wyróżnia się dwie nietypowe postaci. SCRUM Master ma za zadanie pilnować, żeby ludzie nie skakali sobie do gardeł. Pilnuje, żeby trzymać się reguł, ale nie posiada decyzyjności jako takiej. Product Owner jest przedstawicielem managementu, który chce wszystko i na wczoraj. Licytuje się z resztą zespołu co i na kiedy może być zrobione.

Podstawową jednostką czasu wykonania grupy zadań jest Sprint. Różne firmy, w zależności od natury projektu, wielkości zespołu itp. definiją sprint jako różne okresy. Ogólnie przyjęty jest miesiąc. Początkujące zespoły powinny jednak skracać go do dwóch tygodni. Czemu - wyjaśnimy sobie zaraz.

Przed rozpoczęciem sprintu, zespół licytuje się z Product Ownerem co ma być wykonane w danej jednostce czasu. Product Owner przedstawia żądania. Zespół funkcjonalności do zaimplementowania. Zespół, z pomocą SCRUM Mastera dzieli podane grupy funkcjonalności (backlog items) na pojedyncze zadania (backlog tasks). Podział powinien być dośc drobny, ale nie ZA drobny. Żeby jasno definiował jak coś będzie wykonywane.

W tak zwanym międzyczasie, Product Owner definiuje priorytety grup (backlog items). Zespół natomiast definiuje czasochłonność, mając na uwadze ile jest do wklepania i na ile trudne/skomplikowane jest to zadanie. Obciąża zadania (backlog tasks) liczbą wykonywalności (story points). Najczęściej używaną sekwencją liczb, są liczby Fibonacciego. Banalniackie zadanie - 1, proste - 2... Później 3,5,8,13... czasem używane jest 21, ale to już BARDZO rzadko.

Kiedy zespół dopiero obywa się z Agile, przyjęło się wybierać najprostrze zadanie z listy (backlog) i obciążać go wartością 2. Każdy kolejny krok przydziału ma referencję do innego prostego zadania. 1nki zdarzają się niezmiernie rzadko. Tak samo jak 21nki... 13 zazwyczaj określane jest jako - szalenie skomplikowane, ale wiemy co robimy. 21 natomiast jako nie mam bladego pojęcia. 21 to taka czerwona lampka, że zadanie powinno zostać podzielone na mniejsze dla jasności i teoretycznie (w praktyce w sumie również) nie powinno mieć miejsca.

Po przydziale punktów (story points) zespół licytuje się z Product Ownerem co wykonają w danym sprincie. Czasem dochodzi nawet do zmian priorytetów. Na początku ludzie mierzą ile dadzą radę zrobić w sprincie "na oko", niestety. Później to procentuje.

Po ustaleniu co zostanie wykonane, pozostajemy z kompletną listą (sprint backlog) definiującą co zostanie zrobione w danym czasie. Ta lista pozostaje niezmienna przez cały okres sprintu. W teorii. W praktyce bywa różnie, ale wtedy SCRUM Master jest naszym obrońcą. Licytuje się co z listy wyjąć, by włożyć coś innego. Zazwyczaj wyciąga się więcej niż wkłada ze względu na specyfikę pracy.

Po zakończeniu sprintu wiemy jedno. Czy się udał. Udał się jedynie wtedy jeśli wykonaliśmy plan w 100%. Jeśli wykonaliśmy 99.9% planu sprint się NIE POWIÓDŁ i należy zrediwować produktywność zespołu. Wszyscy muszą się tłumaczyć. Niepowodzenie powinno być zauważone również wcześniej. Ale o tym zaraz.

Zamknięcie sprintu pozostawia nam również informację za ile punktów udało nam się wykonać zadań w zespole. Ta wartość to wydajność zespołu (team velocity). Ze sprintu na sprint wartość ta będzie coraz stabilniejsza i da podstawy zespołowi, żeby określić ile faktycznie zadań są w stanie wykonać podczas pojedynczego sprintu. Daje to też informacje Product Ownerowi na ile wydajny jest zespół, czy może powinno się go podszkolić/zmienić?

Ostatnim istotnym elementem jest SCRUM daily meating. 15 minut dziennie, kiedy cały zespół spotyka się razem. Każdy członek zespołu jest odpytywany z tego co zrobił poprzedniego dnia, co ma zamiar robić danego dnia i czy stoją mu na przeszkodzie jakieś nieprzewidziane problemy (impediments). Zadaniem SCRUM Mastera jest rozwiązywanie tych trzecich.

Ale SCRUM Meeting to nie tylko sposób na komunikowanie problemów. To dwukierunkowa komunikacja zespół <-> management i, co najważniejsze motywator. Z czasem, jeśli podczas spotkania wszyscy mówią, że zrobili postępy, a jedna osoba nie może się pochwalić żadnymi, sam z siebie będzie robił wszystko, żeby to zmienić. Wymówką od niezrobienia czegoś jest jedynie poważny impediment, którym musi się zająć SCRUM Master.


Agile składa się oczywiście z miliona innych rzeczy, ale kwintesencja działania tego systemu została powyżej rozpisana. Czy działa? Działa znakomicie. Mogę to powiedzieć z całą pewnością, bo wdrażałem ten proces w jednej firmie i z sukcesem używałem przez długi kawałek czasu (dopóki pracy nie zmieniłem :P).

Ludzie dorabiają milion teorii do Agile. Przekombinowują, tłumacząc sobie backlogi jako minimalistyczne kodowanie. Kończy się to tym, że ludzie przepisują z iteracji na iterację cąły kod, bo nie przewidywali kolejnych kroków implementacji. BZDURA!

Jak już napisałem wcześniej - Agile to jedynie wsparcie procesu. Piramida SCRUM Teamów jest oczywista. Na górze architekci z managementem, poniżej Product Ownerzy w postaci architektów itd. To tylko wspomaganie procesów. RUP, planowanie i testowanie definiowane są gdzie indziej. Ludzie konstruują milion dokumentów na temat jak rozwiązane są powyższe problemy. Zupełnie inaczej definiują też zasady działania zespołów.

Szczerze mówiąc, włos mi się jeży na głowie, kiedy czytam te bzdury. Nie znoszę, kiedy ludzie zabierają się za filozofowanie na temat nie mając kompletnie żadnej praktyki w używaniu Agile. Szukają rozwiązań, wynajdując koło na nowo.

Ludzie! Trochę zdrowego rozsądku!

EDIT: Zamiana SCRUMM na SCRUM

Powrót do strony głównej.

rat

oho. zostalem zacytowany ;)

Cachotterie

Bazyl, z całym szacunkiem, ale to Ty piszesz bzdury. Agile != Scrum (właśnie SCRUM, nie SCRUMM). Scrum jest tylko jakąś tam „implementacją” założeń wszelkich metodologii agile. Agile to dużo wyższy poziom abstrakcji, Scrum jest bardzo konkretnym rozwiązaniem, które na dodatek nie w każdych warunkach się sprawdza (masz szczęście jeśli w Twojej firmie tak). Równie dobrze mógłbyś sprowadzić całe agile do praktyk z eXtreme Programming – równie całościowe podejście jak równanie agile ze Scrumem. Słyszałeś kiedyś o czymś takim jak XP, Crystal, Feature Driven Development? To wszystko też Agile.
Polecam http://agilemanifesto.org/ i odradzam redefiniowanie dość dobrze już ugruntowanych pojęć i definicji. Można robić świetny Agile development i nawet się nie otrzeć o Scruma (choć przyznaję, że ze wszystkich istniejących podejść akurat Scrum bardzo mi się podoba).

Człowieku, trochę szacunku do tych „filozofujących” którzy mają lata świetlne więcej doświadczeń niż Ty (mówię tu o Becku, Cockburnie, Fowlerze i reszcie tej ekipy).

bazyl

Niestety nie mam szacunku do tych filozofujących. Bo w większości przypadków (nie wszystkich oczywiście) rozdrabniają gówno na atomy bladego pojęcia nie mając o czym piszą. A SCRUM czy SCRUMM jest jedyną implementacją Agile, która cieszy się sukcesem jakimkolwiek. O pozostałych implementacjach wdrożonych w firmy słyszałaś?

Zresztą, dlatego napisałem, że ja też dorzucę swoje trzy grosze. Nie wiem o sprawie wszystkiego. Ja tylko rzucam konkretami, zamiast filozofować i popieram sprawę wdrożeniem, które działa. XP powstało przed Agile. FDD i TDD również. Agile teoretyczny starał się to wszystko uogólnić robiąc tylko jeszcze większą kupę.

Jesteśmy programistami! Trzeba nam konkretów, a nie banialuków.

Cachotterie

Bazyl, śmiem twierdzić że oni dużo bardziej mają pojęcie o czym piszą niż Ty w tej chwil. Nie chce mi się z Tobą kłócić, może za jakiś czas samo do Ciebie dotrze, że sam Scrum nie jest panaceum na wszelkie bolączki, jeśli nie ma za tym głębszej ideologii – a dokładnie tym jest agile manifesto. Powiem Ci tylko tyle – sam czysty Scrum, który jest w zasadzie głównie zbiorem zasad zarządzania i planowania i równie dobrze mógłby być stosowany w innych branżach niż software, bez praktyk XP (TDD, pair programming, refactoring, code reviews, continuous delivery etc. ) produkuje w warstwie kodu właśnie kupę g… o której wspominasz. Kod działa, jest dostarczany na czas, można przewidzieć ile dostarczymy – etc. etc. etc. – niestety jest kupą g. i spaghetti code, bo nigdzie w Scrumie nie jest napisane JAK dokładnie masz programować i jakie praktyki w tej kwestii wprowadzać.

bazyl

Dokładnie. Bo SCRUM nie jest procesem, a wsparciem procesu. I z tym należy się liczyć. Też o tym napisałem. SCRUM nie jest lekarstwem na wszystkie bolączki bo nie zawsze warto go wdrażać.

Powtarzam raz kolejny – konkretyzacja zamiast pieprzenia o pogodzie ma sens. Budowanie wspaniałych teorii Agile również. Tak długo jak traktowane jest to poważnie, a nie – tak jak teraz – trĘdi.

Jest trĘdi, więc będziemy używać. W końcu jest takie doskonałem.

I PLUF, nagle nie działa nic i nikt nie wie dlaczego.

Największa głupota niestety mieści się w managemencie. Oni lubią brak konkretów. Dlatego używają Agile, a nie SCRUM czy innej implementacji. Bawią się w coś, co zwykłem nazywać FILOZOWANIEM.

Jajcuś

Mnie też się nie wydaje, żeby Bazyl pisał o agile. SCRUM/SCRUMM nie znam, możliwe, że to dobrze opisał. Ale to nie jest agile. Najwyżej jedna z „implementacji” agile software development.
Agile nie określa organizacji firmy developerskiej czy sposobu zarządzania. Określa podejście do projektu, jako rozwijanego tworu, a nie tylko jakiegoś odległego, chociaż konkretnie określonego produktu końcowego (bo to praktycznie nigdy nie wychodzi). W Agile bardziej chodzi o relację developer<>użytkownik niż programista<>manager.

bazyl

Jajcuś: Piszę jako praktyk, nie filozof. W tym rzecz. Nie znoszę teorii. Wolę konkrety. Konkretna implementacja, konkretne wsparcie, konkretne rezultaty. Agile jest trędi, bo jest jak religia. Wierzysz, albo nie.

Wolę dowody.

Cachotterie

Nawet za tym Twoim konkretnym ubóstwianym Scrumem stoi jakaś teoria – zbiór zasad choćby i czemu one będą działać. Agile też ma konkretne rezultaty – to że Ty ich dotąd nie doświadczyłeś nie znaczy że jest tylko filozofowaniem.

bazyl

Agile to generalizacja konkretnych procesów z przeszłości i dokładane szuflą nowe teorie. Z racji samej definicji nie może mieć żadnych rezultatów. Jedynie jego implementacje mają takie szanse.

SCRUMa nie ubóstwiam. Ale używałem.
Dlatego wypowiadam się tylko na temat tego, co wiem, że działa.

Filozowanie zostawiam tym, którym się nudzi. Filozowanie, nie filozofowanie. Bo niestety, jak w każdej społeczności, ludzi pracujących nad lub z Agile definiuje ta przeważająca grupa pieniaczy, a nie prawdziwi specjaliści, których jest garstka.

Agile jest trędi. EMO też jest trędi. Może więc poużalamy się trochę? :P

rat

to ja ! to ja chce byc pierwszy do uzalania sie !
kawa mi sie w kubku skonczyla !

Cachotterie

Cóż bazyl, Twój wybór, ja też się wypowiadam na temat tego co działa, a w każdym razie MOŻE działać jeśli jest stosowane prawidłowo. Ty niestety wylewasz dziecko z kąpielą. Praktyki/zalecenia/ideały (jakkolwiek to nazwać) agile mogą być wdrożone poprawnie albo może to być jeden wielki bullshit i czcze gadanie – tyle że dokładnie to samo występuje dla Scruma. Akurat u Ciebie podziałało – fajnie. Znam tzw. wdrożenie Scruma które ze scrumem ma wspólne poranne meetingi (rzadko trwające tylko 15 min) i to że się pracuje w iteracjach. Nie skreślam Scruma tylko dlatego, że akurat w tym przypadku wyszła z niego jakaś parodia. Może sobie tego nie wyobrażasz, ale całkiem sporo „filozofii” agile również działa, tyle że mogłeś tego nie widzieć. Wydaje Ci się, że agile to filozowanie, bo nie widziałeś nigdy żeby działało. Tyle że jest kupa ludzi, którzy widzieli i dla nich agile to nie tylko filozowanie.
A bycie bądź nie trędi nie ma tu nic do rzeczy, Scrum też jest trędi i czy to go skreśla?

bazyl

Oczywiście, że wylewam. Wychodzę niestety z założenia, że większość managerów to idioci. Też poparte doświadczeniem. Dla nich zbyt wiele teorii buduje krzywy ideał. Stąd problem teorii bez implementacji.

Natomiast złe wdrożenie SCRUMa jest już winą jedynie techników, którzy pomylili głowę z dupą, kiedy wdrażali cały system.

A nie managerów, którzy z założenia nie znają się na rzeczy.

Cachotterie

Zawsze wszystko wiesz najlepiej, co? To wyobraź sobie Scruma, w którym management nie potrafi wyznaczyć jednego Product Ownera i jeden zespół Scrum ma 5 osób, które potencjalnie są Product Ownerami i każdy z nich ma inne priorytety. Ale oczywiście koniecznie chcą mieć Scruma (tu się zgodzę: bo jest trendi). Nadal twierdzisz że to wina techników, czy też może ci technicy robią co mogą (iteracje, poranne spotkania) a problem leży w managemencie właśnie?

bazyl

Jasne, że nie zawsze. Pomyliłem SCRUMM ze SCRUMem i nie docierało do mnie, że to jedynie implementacja Agile, a nie Agile sam w sobie.

A problem z budową SCRUM teamów to problem techniczny. Zawsze da się zbudować odpowiednie zespoły. Nawet jeśli na siłę. Więc definitywnie jest to błąd techniczny.

Nie umniejszam jednak kretynizmu idiotów z managementów, którzy za wszelką cenę chcą swoją kupę pakować właśnie w ten celofan.

Cachotterie

Nie da się zbudować zespołu faktycznie implementującego Scruma bez współpracy managementu, tych z władzą decyzyjną co zespół ma robić. W prawdziwym Scrumie iteracja jest świętością, umawiasz się „zrobię to, to i to” i do końca iteracji masz spokój, nic nie ma prawa Ci przeszkadzać. Dlatego Scrum działa – dlatego możesz estymować, możesz mieć commitment na zrobienie czegoś, obiecywać coś odpowiedzialnie. Bo wiesz, że w tym krótkim zakresie czasu – 2 tygodnie czy miesiąc, różne są szkoły – masz wolną rękę i nic na Ciebie nie wpływa.
W momencie kiedy iteracja może zostać przerwana przez management i jakieś jedno story (najczęściej już zaczęte) jest zamieniane innym, albo zakres jakiegoś story jest zmieniany – to to już nie jest Scrum i w tyłek możesz sobie wsadzić swoje planowanie, estymowanie i inne reguły.
Co Ci zostaje ze Scruma, jeśli naruszysz jedną z jego podstawowych reguł – że Sprint trwa, zespół podjął zobowiązania i nikt zespołowi nie ma prawa przeszkadzać? Co Ci zostaje ze Scruma, jeśli masz nieustanne mieszanie w pracy „świnek” przez „kurczaki”? Co „technicy” mogą wtedy niby zrobić, żeby to był Scrum? Powiedzieć „nie wstanę, tak będę leżał, nie zrobimy tego story” ?

bazyl

Management jest częścią układanki. Jeśli nie potrafią się przystosować, powinni zostać zwolnieni, bo nie nadają się do swojej pracy.

Jeśli jest to natomiast właściciel, to sama powinnaś uciekać. To problem firmy, nie systemu :)

Cachotterie

Hehe, no niestety trafiłeś ;) Trudno powiedzieć kto bardziej się nie nadaje – klient, management klienta, tak czy owak mimo szkolenia na Scrum Mastera niewiele się zmieniło, więc obawiam się że niewiele do nich dotarło z tego, co mówiła bardzo fajna kobitka odnośnie konieczności posiadania 1nego product ownera, odnośnie nieingerowania w iteracje etc.
Tak czy siak, zgadzam się z tezą o ucieczce – niestety ;)

bazyl

Ja byłem do tego zmuszony w mojej poprzedniej firmie. Zwiałem do obecnej, bo nic już nie szło zrobić. A teraz widzę, że mój szefcio zaczyna robić sajgon teraz tutaj, więc znów będę musiał zwiewać.

Powodzenia w poszukiwaniach nowej pracy. BTW: U nas szukają j2ee’owców :P

Tylko nie wiem czy polecać :P

Cachotterie

Na 3 miesiące chcesz zwiewać? Czy jednak Polska nie we wrześniu? :)
Raczej nie poleca się w firmy z której samemu się chce uciekać ? ;)

bazyl

Żartuję. Szefcio ma zapędy, ale sam jest byłym programistą, więc bałaganu nie narobi ;P

Chciałem jakoś usprawiedliwić mój powrót do PL :P

Moarc/J-23

Wow, przeczytałem, że ścierasz się z ludźmi wierzącymi, którzy twierdzą, że wiedzą, co to Agile i pomyślałem, że Agile to jakaś sekta :D

Tomek

Zawsze mnie bawi jak szefostwo po jakiejs prezentacji doznaje objawienia, wprowadza nowy agile-owy proces, nowe agile-owe narzedia i przybija szyld „jestesmy agile”. Po jakims czasie okazuje sie ze to jednak nie dziala i nikt nie wie dlaczego. Nikt tez nie zauwaza, ze mialo byc „Individuals and interactions over processes and tools” itd. a wyszlo po staremu ;)

Jak masz troche czasy polecam:

http://accu.org/index.php/conferences/accu_conference_2008/accu2008_sessions#Five%20practical%20solutions%20to%20Agile%20myths

http://accu.org/index.php/conferences/accu_conference_2008/accu2008_sessions#Organizational%20Patterns:%20The%20Foundations%20of%20Agile

Tomek

Skomentuj:

Nick
URI
Kod: code