Czym jest Agile dla programisty? Co zmienia zastosowanie zwinnego podejścia w porównaniu z klasycznym waterfall?

Klasyka

Mam za sobą kilka większych lub mniejszych projektów realizowanych klasycznie. Obserwowałem pracę programistów z różnych perspektyw. Ciekawa jest tu obserwacja jak zmienia się nastawienie pojedynczych ludzi, jak i całych zespołów do realizacji projektu. Człowiek potrafi zaadaptować się niezwykle szybko do środowiska w jakim przebywa…

W klasycznym podejściu rola programisty ogranicza się w zasadzie do ‘klepania kodu’. Powszechnie przy tym narzeka się na analityków, projektantów, a także testerów. Często nie dostrzega się klienta, czy nawet celów projektu, poza należną premią oczywiście

Jak wygląda (w uproszczeniu oczywiście) klasyczny warterfall

Miejsce programisty jest w zasadzie tylko przy etapie ‘kodowanie’. Jego rolą jest naklepanie treści do tego co wymyślił projektant… i przekazanie następnie do testera – z nadzieją aby ten nie wykrył tych drobnych obejść, które często wynikały z nieścisłego gdzieniegdzie projektu. W końcu po co zawracać sobie tym głowę – projektant widocznie tak chciał to ma.

Do takiej roli bardzo dobrze przygotowują wszelkie uczelnie. Po prostu trzeba doskonale znać narzędzia i język w którym się koduje. Działamy jak algorytm – na wejściu analiza, na wyjście dajemy działający kod. Nie ma znaczenia co gdzieś daleko za nami chciał klient, ani czego oczekuje po wdrożeniu. Jesteśmy tylko połączeniem projektanta z testerem.

Czasami rzeczywistość zaskakuje nas jak drogowców zimą Faza analizy się przedłuża i nie ma czasu na projekt Wówczas implementujemy często wynik analizy bez projektu… Jeśli przedłużyła się analiza – znaczy, że dziedzina jest trudna, pewnie implementacja też się przedłuży, więc może faza testów też jest niepotrzebna? Najważniejsze jest przecież wdrożenie… Tego chce klient (a może nie?).

W takich projektach Project Manager ma niełatwe zadanie. Ślęczy nocami nad znienawidzonym M$ Projectem, aby zgrać wszystkie etapy. Każdy próbuje zwalić winę na innego… To już temat na zupełnie osobny artykuł…
Programista podejmuje decyzje jedynie na temat tego czy użyć pętli while czy może lepiej for. Całą resztę zrzuca na projektanta lub PMa.

Agile

Jak wygląda zwinny proces rozwoju oprogramowania z punktu widzenia programisty?

Uproszczony schemat Agile

Tutaj idziemy przez całość zagadnień małymi kroczkami. Za każdym razem wykonujemy analizę, projekt implementację i integrację z całością. Za każdym razem dostajemy informację zwrotną od klienta czy to co zrobiliśmy to jest to czego oczekuje. Klient dostaje gotowe fragmenty, które może używać. Sam decyduje które fragmenty chce najszybciej.
A co robi teraz programista? Otóż niestety ma sporo więcej pracy. Przejmuje po części role analityka, projektanta, testera i wdrożeniowca… Niestety ma więcej pracy i odpowiedzialności. Ale myślę że praca ta jest dużo ciekawsza i posiada dużo większe możliwości rozwoju.

Niestety jednak, tutaj napotykamy problem. Większość absolwentów kierunków informatycznych nie jest dobrze przygotowana do przejęcia tych wszystkich ról. Nie wystarczy więc powiedzieć – od dziś pracujemy w agile. Trzeba nieustannie podnosić kwalifikacje pracowników.

Poszczególne fazy, z racji tego że nie są one w pełni formalnie osadzone, różnią się też sporo od tych znanych z podejścia klasycznego. Nie powstaje zwykle jakiś spójny dokument zwany analizą, czy projektem, który jest normalnie akceptowany i odbierany przez klienta. Za to klient akceptuje gotowa działające kawałki. Wydaje się, że ma to głębszy sens – za abstrakcyjnym dokumentem projektu nie widać zwykle gotowego systemu.

Uczelnie wypuszczają całą masę programistów. To samo w sobie nie jest złe, są oni zwykle doskonali w programowaniu… Jednak spotyka się takich którzy nie słyszeli nigdy akronimu SOLID. Podczas studiów wykonuje się niezliczone ‘projekty’ programistyczne. Niewiele z nich jednak przechodzi przez fazy analizy, projektowania, czy nawet testowania! A te umiejętności wśród programistów są niezbędne aby swobodnie realizować zwinny projekt.

Jest to jedna z trudności (i wyzwań) dla zwinnych zespołów – w klasycznym podejściu każdy ma swoją działkę w której nabywa umiejętności; w agile każdy jest specjalistą od wszystkiego Postaram się dalej pokazać, że to nie taki diabeł straszny jak go malują.

]]> http://blog.espeo.pl/2010/02/12/zwinny-projekt-okiem-programisty/feed/ 0