czwartek, 7 stycznia 2010

Nie każdy chce pracować w zwinnym zespole?

 W komentarzu do mojego posta o zwinnym szkoleniu Jacek Zawłocki napisał:
Ja w swojej naiwności sądziłem że wszyscy programiści pragną być członkiem zespołu Agile, tylko kierownictwo uważa Agile i programowanie w parach za fanaberię, hamując w rezultacie zapędy programistów. Jednak tak nie jest, co mnie bardzo zaskoczyło. Sami programiści nie wierzą, że to działa. 
I faktycznie Jacek ma rację. Z czego to wynika?

1. Świadomość czym jest zwinność
Wielu programistów "naturalnie" skupia się na procesach, procedurach, praktykach. Codziennie nimi właśnie się zajmujemy. Je tworzymy w oprogramowaniu. Do ich stosowania jesteśmy przyzwyczajeni. Trudno jest więc przyjąć, że są one tylko środkiem a nie celem.
W zwinnych metodykach podkreśla się adaptacyjność - celem jest tworzenie wartości i dostarczanie jej często. Jak to robimy jest zależne od zespołu i warunków. Nie ma więc raczej uniwersalnych praktyk. Nawet iteracyjność, która jest często utożsamiana ze zwinnością, nie jest zawsze nieodzowna (np. Kanban nie jest iteracyjny - skupia się na równomiernym przepływie).

2. U nas się nie da ...
Wielu programistów dochodzi do wniosku, że nie mogą pracować zwinnie / że ich zespół nie może być zwinny, bo ich manager nigdy nie zgodzi się na ... (tu można wstawić cokolwiek: TDD, refaktoryzację, programowanie w parach, itp.) I to może być nawet prawda. Ale zwinny zespół to ten, który dostosowuje się do warunków. Jeśli nie da się robić TDD ("od testów mamy dział testów") to tego nie róbcie. Starajcie się inaczej dbać o jakość. Skupcie się na tym co można, co się da robić, a nie na tym czego się nie da. Jeśli można spotkać się z klientem/użytkownikiem co jakiś czas by pokazać mu aplikację i otrzymać komentarze - róbcie to. Jeśli można codziennie rano poświęcić 5min na ustalenie kto co zrobił i co planuje na dziś, warto to wprowadzić.

3. Przezroczystość
Praca w zwinnym zespole wymaga założenia, że mamy wspólny cel, i że realizujemy go razem. Dlatego chcemy wprowadzić maksymalną przezroczystość procesu i pracy, by każdy zawsze wiedział "gdzie jest" i by można było szybciej i odpowiedzialniej reagować na to co się dzieje w projekcie.
Nie każdy jednak chce by mu inni zaglądali w kod, by inni dokładnie wiedzieli co robi. Szczególnie osoby przyzwyczajone do pracy ściśle indywidualnej mogą mieć opory żeby poświęcić część swojej prywatności zawodowej (skądinąd czy to czasem nie jest oksymoron?)
W zwinnych zespołach zakładamy, że nic w pracy nie jest indywidualne - ani kod, ani czas pracy nie jest własnością programisty. Odpowiedzialność i uczciwość zawodowa, ale również prędkość pracy i zaufanie w zespole i klienta względem zespołu wymagają jawności.

Wierzę, że jeśli przyjmie się takie proaktywne, pozytywne nastawienie dużo łatwiej o zwinność.

1 komentarz:

  1. Poruszyłeś dobrą kwestie agile. "Ale zwinny zespół to ten, który dostosowuje się do warunków". Gdzieś przeczytałem coś w stylu: "jeśli od dwóch tygodni pracujesz z agile i nadal robisz to tak samo jak na początku to nie jesteś agile". I to jest dużo prawdy. Mówisz agile i wszyscy myślą, że piszesz testy, codziennie się spotykasz z zespołem, co dwa tygodniem z klietami itp. A jak powiesz, że zespół nie spotyka się codziennie to mówią, że to już nie jest agile.

    OdpowiedzUsuń