Dlaczego programiści nie lubią Agile? Co z nim poszło nie tak?

Ruch Agile został pierwotnie stworzony dla programistów przez programistów, czyli osoby techniczne. Z zasady wzmacniał ich pozycję i stawiał na samodzielne i kreatywne zespoły, które stale się uczą, dostosowują i samoorganizują. Z czasem jednak zboczył z wytyczonego toru i przesunął się nieoczekiwanie w stronę zarządzania projektami.

Programiści byli więc jednymi z tych, którzy dostrzegli, że tradycyjny sposób działania przy spełnianiu oczekiwań klienta, projektowanie, planowanie i kodowanie, nie działa dobrze. Czuli, że w Agile można zrobić to lepiej. Nowy system umożliwiał pisanie kodu wysokiej jakości, wokół czego obraca się idea Agile. W przeszłości nazywano to doskonałością techniczną, co oznaczało, że programista wykonał pracę, z której był dumny.

Jakość, to obok czasu i kosztów, główna zmienna Agile, która, ustalona na początku projektu, do końca jego trwania nie podlega negocjacjom. Powodem, dla którego organizacje zaakceptowały Agile, była zapowiedź, że może on tworzyć i dostarczać wartościowy produkt. Czyli wszyscy mieli te same motywy i wspólny cel.

Teoria a praktyka

Jeżeli jednak organizacje nie kładą nacisku na jakość, jest prawdopodobne, że stosowanie stylu i zasad Agile nie przyniesie nawet połowy korzyści, które oferuje. Jest jeszcze gorzej, gdy sami programiści używają zwinności bez jakości technicznej. W ciągu ostatnich lat wielu programistów wyraziło swoje obawy wobec zwinności w praktyce.

Robert C. Martin, jedna z osób, które w 2001 roku opracowały Manifest Agile, zwrócił uwagę, że jest on – nie jak pierwotnie wyobrażał go sobie Kent Beck i inni twórcy – od dawna wykorzystywany przez armię certyfikowanych mistrzów Scrum i biznesmenów, którzy nie rozumieją jego idei. Jak z kolei sugeruje Robert Garrett, problemem mogą być specyficzne metody implementacji Agile, a nie jego podstawowe wartości. Z zasady praca zwinnego ma polegać na wypracowaniu dobrej jakości czystego kodu oraz bieżącym ocenianiu i korygowaniu poszczególnych elementów produktu końcowego (nie, jak w tradycyjnych modelach – na końcu projektu).

Negatywne elementy Agile według jego twórców:

• zobowiązywanie programistów do arbitralnych szacunków i terminów uniemożliwiające dokładne przemyślenie funkcji, które tworzą; 
• tworzenie sztywnej struktury (framework) organizacyjnej, jak w Scrumie;
• nadmiar dokumentacji i biurokracji;
• ignorowanie tematu tzw. długu technicznego.

W idealnym świecie Agile, programiści powinni mieć wystarczająco dużo czasu na ulepszanie struktury istniejącego kodu (refaktoryzację) i dokładne przemyślenie funkcji, tak, aby oprogramowanie było możliwe do utrzymania w dłuższej perspektywie.

Czy Agile nie działa po stronie programistów?

Mówiąc o tym, że programiści mogą się źle czuć w Agile, należy przeanalizować sytuacje, w których uważają, że Agile nie działa po ich stronie. Podstawowe wartości i zasady Agile są wspaniałe i żadna rozsądna osoba nie może się z nimi nie zgodzić. Żaden rozsądny programista nie powiedziałby: „Nie chcę dostarczać wartościowego oprogramowania! Nie chcę zachwycać moich klientów! Nie chcę oprogramowania wysokiej jakości i niskim ryzyku!”.

Negatywne aspekty Agile według programistów:

• arbitralne cele i nierealistyczne terminy;
• biurokrację i brak miejsca na kreatywność programistów;
• popędzanie programistów w ich pracy.

Uważają, że, choć menedżer chce, by programista pracował w Agile, to sam często go nie rozumie lub nie pomaga zespołowi. Kiedy wprowadzono Agile, miał on działać oddolnie, jednak stał się podejściem odgórnym. W tej sytuacji trudno o samodzielne działania. Od programistów wymaga się, aby dawali z siebie ponad miarę, napięcie w zespole rośnie poprzez ciągłą presję z góry. Jeśli menedżer stosuje narzędzia zwinne w niewłaściwy sposób, może prowadzić do mikrozarządzania zespołem. Skutkuje to konfliktem nie w duchu zwinnego.

Zespoły zwinne nie muszą mieć menedżera, choć posiadanie go nie szkodzi, o ile sam stosuje zasady Agile

Agile w istocie ma na celu umożliwienie zespołom organizowanie się. W gronie zespołu Agile programiści są zdolni dostrzec problemy i być w stanie je naprawić. Zespoły zwinne nie muszą mieć menedżera, choć posiadanie go nie szkodzi, o ile sam stosuje zwinność. Dlatego wielu programistów uważa, że ich praca byłaby łatwiejsza, gdyby menedżerowie nauczyli się Agile, czy poszczególnych metod implementacji (Scrum, Kanban itp.), przyjmując tym samym na siebie odpowiedzialność techniczną. Skarżą się też, że wielu menedżerów wykorzystuje cykle do uczynienia swojego harmonogramu wygodniejszym, np. spotyka się z całym zespołem, zamiast planować oddzielne spotkania z poszczególnymi programistami, marnując czas innych. To też nie jest to w duchu Agile.

Kiedy zespoły nie stosują praktyk prostego projektowania i programowania opartego na  testach, są zmuszone do wcześniejszego dostarczenia, co prowadzi do spadku jakości. Gdy jakość spada, trudno jest cokolwiek wyprodukować w krótkim czasie. 

Iteracyjnie znaczy stopniowo

Być może istnieją inne powody, dla których programiści mogą nie lubić Agile. Na przykład myślą, że to „srebrny pocisk”. Chcą rozwiązać wszystkie problemy za pomocą jego narzędzi. Innym z powodów jest prawdopodobnie to, że rola programisty w Agile to znacznie więcej niż tylko pisanie kodu. Deweloperzy pracujący w środowisku Agile muszą wziąć na siebie znacznie większą odpowiedzialność.

Dodatkowe obowiązki programistów w Agile:

• branie odpowiedzialności za planowanie i zarządzanie własną pracą w celu pomyślnego zakończenia sprintów;
• efektywna praca poszczególnych członków zespołu, by zapewnić całemu zespołowi sukces i opracowywać dobrze zintegrowane rozwiązania;
• w niektórych metodach również bezpośrednia współpraca z klientami w celu lepszego zrozumienia i wyjaśnienia wymagań.

Niektórzy programiści cieszą się z dodatkowej odpowiedzialności i szczególnej autonomii oraz uprawnieniami, które otrzymują w środowisku Agile. Inni jednak nie będą jej chcieli.

"Zwinne" elementy, właściwe dla innych implementacji, a nie zawsze lubiane:

• codzienne spotkania, tzw. stand-upy (pochodzi ze Scruma) – mają być z zasady szybkim kontaktem i planem na cały dzień. W rzeczywistości przechodzą w długie spotkania, czyli coś, od czego chciano odejść 20 lat temu. Zabierają one cenny czas programistom, którzy woleliby przeznaczyć go na kodowanie. W efekcie czują niepotrzebną presję, by wywiązać się ze swoich zobowiązań sprinterskich;
• pair programming (pochodzi z XP) – choć wielu programistów może je lubić i uważać za produktywne, w istocie nie jest zgodne z Agile;
• formatowanie historii i spotkania dotyczące planowania iteracji.

Agile a menedżerowi

Kiedy zatrudniasz zespół programistów, dowiedz się, czy używają Agile i co o nim myślą. Może to pomóc ci zrozumieć ich podejście do jakości technicznej i tego, czy są w stanie dostarczyć wysokiej jakości projekty. Wśród doświadczonych programistów często pojawia się opinia, że menedżerowie nie dość cenią albo nie rozumieją Agile, lub używają jego narzędzi w niewłaściwy sposób.

Złe praktyki menedżerów w Agile:

• chcą sami dyktować prędkość (lub co należy zrobić) w danym cyklu;
• nie przestrzegają cyklu, naruszają go, zmieniają priorytety w trakcie jego trwania;
• ich sposób zarządzania nie pozwala programistom na samodzielność;
• nie wymagają typowej dla Agile integracji między członkami zespołu.

„Mówienie, że coś można zrobić w czasie x, kiedy to niemożliwe, mówienie, aby nie robić x przed y, kiedy x jest potrzebne jako pierwsze, mówienie zespołowi, jakie mają być ich zobowiązania, zamiast pozwalać im angażować się w to, co mogą zrobić itp.”. 

Dług techniczny przyczyną problemu?

Na jednej z konferencji Robertowi C. Martinowi zadano pytanie, czy Agile może wrócić do swojej pierwotnej misji polegającej na pokonywaniu przepaści między biznesem a programistami? „Może się to zdarzyć tylko wtedy, gdy zaczniemy zwracać uwagę na niepotrzebną biurokrację, która ma miejsce, oraz dług techniczny, który wciąż się piętrzy. Żaden rozsądny programista nie chce pisać złego, niechlujnego kodu. Jednak często są do tego zmuszani przez ludzi biznesu, którzy chcą jak najszybciej udostępnić nowe funkcje”. 

Dług techniczny (technologiczny) to zjawisko, w którym z powodu wybrania opcji pozornie łatwiejszej i tańszej do zrealizowania, całkowity koszt wyboru tej opcji staje się w dłuższej perspektywie czasu mniej opłacalny od wyboru bardziej czasochłonnego, ale obiektywnie lepszego i bardziej dopracowanego rozwiązania.

Przyczyny długu technicznego:

• nieprecyzyjne lub ewoluujące wymagania w trakcie trwania projektu;
• presja wydania oprogramowania we wcześniejszym terminie niż zakładano;
• wydawanie produktu, kiedy nie jest w pełni dokończony;
• skupienie na szybkim generowaniu zysków;
• brak dostosowania do standardów i dobrych praktyk w początkowych fazach;
• brak refaktoryzacji w początkowych fazach;
• zbyt późne zmiany wymagań.

Software Craftsmanship – Ruch Rzemiosła Oprogramowania

Czy możliwe jest połączenie programowania, postrzeganego jako profesjonalizm i techniczna perfekcja, z oczekiwaniami biznesu, który chce oprogramowanie szybko i tanio? Ruch Rzemiosła Oprogramowania próbuje wrócić do pierwotnej obietnicy Agile, która – według Kenta Becka – miała zlikwidować przepaść między biznesem a programowaniem. W 2009 roku powstał Manifest Software Craftsmanship, który rozwijał niektóre zasady Manifestu Agile. Wynika z niego potrzeba większego zaangażowania programistów w wytwarzanie oprogramowania na wielu poziomach.

Założenia Manifestu Software Craftsmanship:

• dobrze napisane oprogramowanie, a nie tylko działające;
• ciągłe dodawanie wartości, nie tylko reagowanie na zmiany;
• całą społeczność profesjonalistów, nie na poszczególne osoby i interakcje;
• produktywne partnerstwo, nie zaś jedynie współpracę z klientem.

„Projekt programistyczny nie może się udać bez współpracy z dobrymi programistami, którzy nie tylko potrafią tworzyć dobrej jakości oprogramowanie, ale również są w stanie pomóc biznesowi w osiągnięciu tego, co ten chce osiągnąć, oferując mu odpowiednie opcje, informacje zwrotne i konstruktywną krytykę”.

Idea straciła już nieco na blasku w tym sensie, że szczyt jej popularności przypadł na 2010–2011 rok. Z pewnością jednak manifest odcisnął swoje piętno na branży IT, przyczyniając się się do stworzenia etosu programisty. 

Podsumowanie

Agile nie sprawdzi się tam, gdzie jest zbyt rygorystyczny wobec zespołu projektowego i ogólnej kultury organizacyjnej. O ile zespół projektowy jest wyszkolony w zwinności, a w firmie istnieje kultura organizacyjna, to Agile niekoniecznie musi być najlepszym wyborem. Każda metoda działa, jeśli te czynniki są spełnione. Natomiast gdy metodę narzuca się przeciętnemu zespołowi projektowemu i niegotowej organizacji, Agile jest prawdopodobnie gorszy niż alternatywy, takie jak waterfall czy podejście spiralne. Bo jeśli jest wspaniały zespół i kultura, wtedy waterfall też się sprawdzi.

Szukasz efektywnej metody zarządzania w Twoim projekcie? Przeczytaj o poszczególnych metodach, które możesz wybrać: tradycyjnych i zwinnych.