Jak w temacie. Czy programować (z naciskiem na PROGRAMOWAĆ) można w ogóle zespołowo? Czy jest to czynność wymagająca bezwzględnego wyizolowania się z otoczenia i skupienia na problemie?
Zobaczmy jak to wygląda z zewnątrz. Są ogólne cele (roczne, kwartalne, whatever) i mamy zespoły. Zespół spotyka się co jakiś czas by podzielić pomiędzy siebie pracę, rozbić większe problemy na mniejsze - do ogarnięcia przez jedną osobę. Jeśli wszystkie osoby reprezentują tą samą prędkość pracy to problemu nie ma.
Ale rzadko tak bywa. Zazwyczaj idzie to mocno nierówno i lider zespołu bliżej terminu zaczyna mieszać przydzielając szybszych do maruderów (albo ich zastępując). I mimo tego praca dalej zwalnia, liderzy nie potrafią ogarnąć pracy maruderów i często grzęzną w zadaniu dłużej niż gdyby miał je dokończyć oryginalny autor. A jeśli pracują w parach to zaczynają się pojawiać problemy i tarcia interpersonalne.
Czy nie jest tak że w zespołach ignoruje się indywidualne cechy każdego programisty na rzecz podejścia zrównującego (wszyscy jesteście programistami więc możecie zaprogramować rozwiązanie dla każdego problemu)? Każdemu wciskają wzorce, dobre praktyki, nawet paradygmaty - lider lubi podejście funkcyjne, język X wspiera to podejście więc będziemy kodować w tym stylu. Nieważne że reszta zespołu dalej robi proceduralne OOP.
Powiemy sobie - zły lider. I ok. Ale co z sytuacją gdy decyzja jest koncyliacyjna, podział przebiega fifty-fifty i ostatecznie wszystko zależy od głosu wypalonego gościa który już podjął decyzję o ucieczce ale że lubi poeksperymentować to czemu nie?
I tak dochodzimy do kolejnego problemu - wypalenie. Które może wynikać z powyższego. Z pracy nad problemami których nie ogarniamy, z wymuszenia stylu w którym nie czujemy się naturalnie i ciągłego powtarzania za plecami że tak robią najlepsi więc i my tak musimy a jak nie potrafimy to się nadajemy. Ale w zasadzie dlaczego?
Kod który piszemy jest obrazem naszego podejścia do zadanego problemu (nawet powiem że wyobrażenia jakie o nim posiadamy). Większość problemów może być zaatakowana z wielu stron. I jeśli maszyna go wykonuje i dostarcza akceptowalne rezultaty to co złego wynika jeśli np. całość została napisana w C/C++ z wstawkami assemblerowymi?
Jeśli ktoś podniesie zarzut o utrzymanie czegoś takiego przez innych - ok. Ale szczerze, ile w karierze widzieliście nowych projektów gdzie pierwszym odruchem nie było napalmem to!
? Albo założymy że wszyscy piszą ch*jowy kod a my jesteśmy wyjątkiem albo po prostu - styl projektu jest obcy naszym zwyczajom i przyzwyczajeniom. Mamy decyzję, możemy zostać i przekształcać to co zastaliśmy w naszym stylu albo poszukać czegoś co nam bardziej odpowiada.
Może zamiast zaklinać rzeczywistość naszej branży IT - przyznajmy po prostu: praca zespołowa w IT to mit. Programista jest samotny z problemami które rozwiązuje a styl w którym pisze implementację jest kompletnie indywidualny. Komunikacja (efektywna) pomiędzy ludźmi pracującymi nad cząstkowymi problemami czegoś większego jest niewielka i w zasadzie sprowadza się do uzgodnienia interfejsów komunikacji pomiędzy ich implementacjami.
Programista jest sam na sam z problemami które przed nim stoją. Żadne SCRUMy ani Agile tego nie zmieniają, co najwyżej ładnie zamaskują rzeczywistość.