Agile czyli jak zrobić z życia programisty piekło

in #polish6 years ago (edited)

codecode.jpg
W dawnych, prehistorycznych czasach gdy jeszcze dinozaury chodziły po ziemi, firmy IT zbierały wymagania od klienta a później w zależności od stopnia skomplikowania, po kilku czy po kilkudziesięciu miesiącach wypluwały gotowy produkt. Proces produkcji oprogramowania składał się z jasno określonych, sztywnych faz takich jak planowanie oraz analiza systemu, implementacja, testowanie oraz wdrożenie i pielęgnacja. I to było dobre, ale dla programistów, architektów i wszelkiej maści specjalistów. Nie było to jednak dobre dla klienta. Klient bardzo rzadko wie czego tak naprawdę chce, często ma również problemy z przekazaniem swojej wizji w jasny, klarowny sposób więc zdarzały się sytuacje gdy otrzymana aplikacja rozmijała się z jego oczekiwaniami. Słabo.

Agile czyli panaceum na głupotę klienta

A co gdyby wciągnąć klienta do procesu wytwarzania oprogramowania, pokazywać mu regularnie efekty swojej pracy a on decydowałby czy to co robimy odpowiada jego wymaganiom czy nie, i na podstawie tego dynamicznie kształtować produkt? Brzmi to naprawdę dobrze i pozwala zminimalizować ryzyko nietrafionych wymagań oraz żwawiej reagować na zmiany rynku. Taki styl produkcji oprogramowania nazwano zwinnym. Manifest brzmi następująco;

Bardziej cenić:
Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
http://agilemanifesto.org/iso/pl/manifesto.html

Upierdliwy klient

Agile nie rozwiązuje jednak w żaden sposób problemu z komunikacją z klientem. Sprawia jedynie, że programiści są zmuszani do wiecznego protypowania funkcjonalności by odbiorca mógł je "wymacać" a później na tym kruchym fundamencie rozwijać dalej aplikacje. Nie ma mowy o zaoraniu prototypu i przepisaniu go poprawnie od zera bo to dla klienta "niepotrzebny" koszt.

Ciągłe zmiany wymagań oczywiście bardzo negatywnie odbijają się na samym oprogramowaniu. Gdyby jakiś klient podszedł do inżyniera budownictwa i powiedział mu "Przerób mi ten dom jednorodzinny na wieżowiec a i chce by jeszcze w środku było centrum handlowe" to inżynier popukałby się w czoło i delikatnie zasugerowałby mu, że albo niech zmieni wymagania albo niech spierdala. W świecie IT takie żądania to norma i klasyk.

Płaska struktura

Firmy IT pracujące w Agile'u lubią się przechwalać płaską strukturą i elastycznością. Co to oznacza w praktyce dla programisty? Odbieranie telefonów i komunikacja mailowa z klientem, prowadzenie dla niego szkoleń, dyżury po pracy (czyli bycie pod telefonem i reagowanie na pożary), zajmowanie się architekturą systemu oraz na samym końcu nareszcie programowanie. Programista w tym modelu jest wołem na który zakłada się homąto i orze nim pole. Wszyscy są zadowoleni poza nim; klient bo otrzymuje support i może w każdej chwili wymusić zmianę, management bo zamiast 4-5 ekspertów, których trzeba było opłacać mamy powiedzmy dwóch, którzy robią wszystko. Programista jako najniższe ogniwo w firmie jest zasobem, który jak się wypali to wymienia się go na kolejnego zapaleńca, pasjonate bez życia.

Mikrozarządzanie

Agile'a bardzo często sprowadza się również do mikrozarządzania programistami. Codzienne standupy, raporty, wieczne zmieniające się nierealistyczne deadline'y, przerywanie pracy bo wpadło coś ważniejszego to klasyk. A no i openspace'y czyli pokoje wypełnione gadającymi ludźmi tak głośno, że bez słuchawek nie da się normalnie pracować. W takich warunkach nie ma miejsca na kreatywność, na dobrą architekturę, na dobrze otestowany kod. Klientowi i managmentowi nigdy nie będzie zależało na jakości oprogramowania bo zawsze jest coś do zrealizowania na wczoraj.

Wypalony programista

Programiści wpadają w pułapkę dobrych zarobków. Dobra, zarabiam 10 tysięcy ale nienawidzę swojej firmy i programowanie nie sprawia mi już frajdy. Co mam zrobić skoro mam kredyt, rodzinę przyzwyczają do życia na dobrym poziomie? Przecież nie mogę pozwolić sobie na przebranżowienie i zarabanie przez długi czas słabych pieniędzy. I tak właśnie łańcuch u nogi kolejnego kuca się zacisnął.

Ostateczne konsekwencje

Najbardziej cierpią jednak nie programiści a zwykli użytkownicy oprogramowania. Użytkownicy którzy muszą mierzyć się z słabo napisanym, gównianym oprogramowaniem, wiecznym prototypem, który często nie jest przyzwoicie zabezpieczony. Stali się beta testerami i nie zapowiada się na to by ten stan rzeczy się zmienił. Może dopiero gdy ludzie zaczną umierać przez źle napisane oprogramowanie zrobione w Agile'u? Zobaczymy.

Sort:  

Myślę że problemem nie jest sam Agile, bo Waterfall też nie gwarantuje przyjemnej pracy i udanego produktu.

Według mnie główną przyczyną większości problemów które wymieniłeś jest brak kompetencji wśród pracowników IT, zarówno koderów jak i managementu (głównie). Agile jest reklamowany jako panaceum na wszystkie problemy i cześć osób decyzyjnych to łyka. Zamiast naprawić to co rzeczywiście jest problemem (zanim wystąpi) to zasłaniają problemy "metodykami zwinnymi" w których z definicji wszystko jest bardziej rozmyte i można dalej niczym się nie martwić. A co dalej? - jak się coś wyjebie to zadziałamy doraźnie i reakcyjnie - (przy)zgasimy pożar i wszyscy będę happy (oczywiście nie wyciągniemy z tego wniosków bo wtedy trzeba byłoby coś zrobić).

A co z tym zrobić? Jest ogromne ssanie na rynku i każdy dobry programista bez problemu coś sobie znajdzie. Trzeba szukać lepszego świata :)

Cóż pracowałem w kilku projektach prowadzonych scrumem - w mniejszym lub większym stopniu. Muszę powiedzieć że może jest jakaś drobna poprawa jakości. Ale to nie jest coś co rozwiąże wszystkie problemy. Jeśli zespół jest źle prowadzony żaden metodyka nie pomoże. Scrum czy czy inne zwinne metodyki to tylko narzędzia.

Scrum moim zdaniem jest sprzeczny z manifestem agile'a:

Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.

Scurm ma sztywny "proces"

Agile'a jest dla mnie słabą metodyką pracy z tego względu, że działa dobrze jeśli masz ogarniętego klienta i naprawdę dobry zespół. W takich warunkach jednak prawie wszystko działa dobrze. Gdy klient jest głupi a zespół programistów średni to pracowanie w agile'u jest piekłem a finalny produkt jest gównem. Dobry proces nie powinien wymagać best case scenario moim zdaniem.
Agile w warunkach polskich to często jeden, dwóch programistów, którzy muszą się użerać z bucowatym klientem

Już mniejsza z tym czy scrum jest zgodny z manifestem czy nie. Ale chodzi mi bardziej o to że przez to że się zespół nie zyska nowych skilli, przez samą zmianę metodologi. Czy też klient się nie ogarnie.

Grunt do dobra komunikacja w zespole i z klientem. Czasem pomaga ją poprawić Agile - czasem nie.