On 19/02/2012 14:33, Bronek Kozicki wrote:
> On 19/02/2012 12:31, Andrzej Jarzabek wrote:
>>
>> Druga sprawa jest taka, że to, co opisujesz jest tylko możliwe wtedy,
>> kiedy masz innych członków zespołu pracujących nad tym samym, co ty. A
>> to ma te same wady, które są przypisywane programowaniu parami.
>
> różnica polega na tym, że każdy z członków zespołu może w danym momencie
> pracować nad innym zadaniem, i tylko okazjonalnie poświęcić swoją uwagę
> zadaniom kolegów.

W takiej sytuacji jest kilka problemów:

Skoro kolega zajmuje się czymś innym, to niekonieczenie ma orientację w
tym, co robisz, żeby jakkolwiek pomóc. Więc musi się wdrożyć w tematem,
potem musi się zastanowić nad twoim problemem, potem ci powiedzieć, co
wymyślił. To wszystko też zajmuje czas, a zanim to się stanie, to ty
możesz co najwyżej samemu się zastanawiać nad rozwiązaniem swojego
problemu. W końcu jeśli wymyślisz lepsze rozwiązanie, to jego czas
został zmarnowany, jeśli jego rozwiązanie jest lepsze, a ty, czekając na
niego zacząłeś już implementować swoje, gorsze, to musisz pozmieniać to,
co właśnie zrobiłeś.

Kolejną istotną sprawą jest czas przestawienia się, zmiany kontekstu.
Jeśli twój kolega pracuje nad czymś innym, ale odrywa się od swojej
pracy, żeby tobie pomóc, to powrót do stanu wysokiej produktywności przy
tym, co robił wcześniej, zajmie mu sporo czasu. Szacuje się, że
każdorazowy "context switching" to strata kilku roboczogodzin. Żeby nie
było, że to tylko moje zdanie, to odsyłam znowu do "Peopleware".

> A to że nad jednym projektem pracuje więcej niż jedna
> osoba, nie ma żadnego związku z programowanie parami (zdarzało mi się to
> drugie też) tylko to zdrowy rozsądek.

Problem jest taki, że w jednym projekcie jest zwykle wiele oderwanych od
siebie tematów i zadań. To, że ktoś pracuje nad modelem GUI do tego
samego produktu, nie znaczy, że będzie miał cokolwiek do powiedzenia w
temacie zrównoleglenia obliczeń.