On 17/02/2012 21:55, A.L. wrote:
>
> Programwoanie w parch to paranoja. Jedyna forma programwoanai w parach
> ktora znam to nie taka ze dwoch pracuje nad tym samym problemem, ale
> taka ze jeden pracuje nad dwoma problemami. Gdy koszt programisty jezt
> rzedu 200 tysiecy dolarow rocznie (nei wiem ile w Polsce) to za
> propozycje programwoania parami mozna dostac kopa w dolna czesc ciala.

Nie mam dużego doświadczenia w programowaniu w parach, ale na podstawie
tego, co piszą ludzie, którzy to praktykują i z mojego doświadczenia
wynika, że w odpowiednich warunkach i sensownie zrobione może to mieć
duży sens.

Przede wszystkim mogę zaobserwować, że fizyczne klepanie kodu zajmuje
bardzo niewielki wycineek mojego czasu. Wiele z innych czynności mogłoby
być znacznie przyspieszone przez programowanie w parach, albo jest i tak
dublowaniem tego, co bym robił programując w parze z kimś innym, tylko
mało efektywnie (transfer wiedzy).

Moje doświadczenie wskazuje na przykład, że w przypadku takich czynności
jak projektowanie albo znajdowanie problematycznych bugów, naradzenie
się z drugą osobą, która również "siedzi w temacie" jest często
wielokrotnie (więcej niż dwukrotnie, nierzadko znacznie więcej) szybsze,
niż siedzenie i głowienie się samemu. Tyle że w typowej sytuacji, w
której pracuję, w zespole nie ma takiej osoby.

Z drugiej strony wygląda to tak, że ktoś zgłasza się do mnie z prośbą o
pomoc lub wytłumaczenie czegoś. Ponieważ ja akurat robię zupełnie coś
innego, to po pierwsze sama zmiana kontekstu zaburza moją produktywność
w tym, co robię, po drugie muszę poświęcić ileśtam czasu na zrozumienie
problemu mojego kolegi, w dodatku do czasu poświęconego na samo
tłumaczenie. W końcu wszelkie problemy w komunikacji mogą powodować, że
kolega, który coś źle zrozumiał, zrobi źle, więc nie tylko część
poświęconego czasu była zmarnowana, ale to, że zrobił źle, potencjalnie
zmarnuje jeszcze więcej czasu innych ludzi. Z kolei ja, pracując nad
czymś innym, nie mam ani głowy, ani obowiązku ani konkretnej motywacji,
żeby sprawdzić, czy to, co tłumaczyłem przełożyło się na prawidłowe
wykonanie.

I skoro już o tym mowa - defekty są sporym problemem. Pomijając już
koszta związane z ich manifestacją w systemach produkcyjnych, to samo
diagnozowanie, znajdowanie i usuwanie ich pochłania wiele czasu wielu
ludzi, w tym również owych cennych programistów. Jeśli para programistów
produkuje kod z mniejszą ilością defektów niż pojedynczy programista (na
co również wskazują różne dane), to oszczędność czasu na samym tym może
znacznie przewyższać potencjalną stratę na tym, że dwóch programistów
siedzi nad jednym problemem.

W końcu jest ten subtelny psychologiczny aspekt "satysfakcji z pracy".
Oczywiście menedżment może przyjąć punkt widzenia taki, że w pracy się
nie siedzi dla przyjemności, a dla firmy są ważne zyski i straty a nie
zadowolenie pracowników - a jam sam z kolei mogę byc oskarżony o to, że
mam własny interes w tym, żeby mieć satysfakcję z pracy, nawet kosztem
zyskó pracodawcy. Ale też mam pewne wsparcie w literaturze twierdząc, że
satysfakcja pracowników (w szczególności developerów) ma bardzo
konkretne przełożenie na pieniądze: na ten przykład Tom DeMarco i
Timothy Lister "Peopleware".

Z jednej strony moje doświadczenie jest takie, że utknięcie na jakimś
problemie i niemożność obgadania go z kimś jest frustrująca. I że im
bardziej frustrująca praca, tym szybciej się ją zmienia na inną, a
programista, który cośtam potrafi nie tylko nie będzie miał z tym
problemów, ale nawet będą do niego regularnie dzwonić headhuntery i
podsuwać mu propozycje. DeMarco i Lister twierdzą, że wymiana
pracownika, nawet jeśli natychmiast znajdzie się nowego pracownika o
podobnych kwalifikacjach na jego miejsce, kosztuje mniej więcej tyle, co
półroczny koszt zatrudnienia tego pracownika - niekiedy mniej, ale
niekiedy znacznie więcej. Wydaje mi sie to sensownym oszacowaniem.

Druga strona medalu jest taka, że programowanie parami może pomagać w
integrowaniu zespołu, tym, co DeMarco i Lister nazywają "jelling".
Twierdzą oni, z czym również się zgadzam, że takie "jelled" zespoły
osiągają radykalnie lepsze rezultaty, co oczywiście też się przekłada na
pieniądze.

Oczywiście prawdziwość tego wszystkiego, a co za tym idzie skuteczność
programowania w parach zależy mocno od tego jak jest to robione i jak w
ogóle działa cały zespół. Ale też w XP wprost zakłada się, że
poszczególne praktyki działają w kontekście innych praktyk, i dlatego
programowanie parami powinno być połączone co najmniej z TDD,
rozbudowanymi coding standards, collective ownership, daily stand-up itd.

> Ja kuz mowilem o Agile. Proponuje poczytac na ten temat

Aglie jako takie jest raczej ogólnym podejściem, "duchem", niż jakąś
konkretną metodologią. Można jednak zauważyć, że:
1. XP jest uważane za metodologię agile,
2. Zespoły praktykujące agile, nawet jeśli nie stosują XP, często
programują parami,
3. Zgodnie z założeniami agile m. in. o tym, czy progrmauje się parami,
czy pojedyczno, jak również o wielu innych rzeczach, decyduje sam
zespół, a nie kierownictwo. Jeśli jest się w sytuacji, w której nie
można uprawiać programowania parami ze względu na brak zgody
kierownictwa, to nie da się również uprawiać agile, niezależnie od tego,
czy z programowaniem parami, czy bez - zespół po prostu ma za mało
autonomii.

>> Jak waszym zdaniem powinno wyglądać zapewnienie jakości?
>
> Nom na ten temat mapisano moze ksiazek i stworzono ocena metodologii,
> poczynajac od testow jednostkowych. W normalnym przemyslowym
> srodowisku programista musi napisac testy jednostkowe do wszystkiego
> co robi; w wiekscosci przypadkow to jest okolo 75% kodu ktory
> programista pisze. Te testy sa scentralizowane i wykonywan pzrez
> osobny personel. U mnie - co noc.

Personel? U nas to robi maszyna :)

> Poza tym, znow polecam Agile w kontekscie jakosci, wszczegolnocis cos
> takiego jak "test driven development". Ksiazka jest na ten temat, i to
> o ile pamietam, nie jedna

Bardzo polecam - Steve Freeman, Nat Pryce "Growing Object Oriented
Software Guided By Tests".