On Feb 20, 6:15 pm, Bronek Kozicki <b...@s...net> wrote:
> On 19/02/2012 19:23, Andrzej Jarzabek wrote:
>
> >> 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,
>
> widzisz, cały zespół (mały, ale zespół) zajmuje się pielęgnacją
> *jednego* programu, jeden z celów takiej polityki jest taki że dowolny
> członek zespołu potrafi poprawić program/ocenić pracę innego/dodać nowe
> features. Oczywiście niektórzy znaję pewne miejsce programu lepiej od
> innych, ale to kwestia praktyki. GUI jest pielęgnowane przez inny zespół
> (i w innym języku).
>
> Ponadto na ten konkretny problem każdy z członków zespołu już wcześniej
> się natknął, tylko dopiero niedawno zaczęło to przeszkadzać użytkownikom.

No ale sam widzisz, masz taki konkretny problem i taką specyfikę
projektu.

W innych projektach często jest tak, że poszczególne problemy są mocno
rozstrzelone, np. jedna osoba robi interfejs do JMS, inna optymalizuje
zużycie pamięci, a inna jeszcze moduł komunikacji z bazą danych.

Nawet jeśli założenie jest takie, że każdy ma móc pracować nad
dowolnym kawałkiem programu i programiści są rotowani między
komponentami, to nadal masz ten problem: inny programista w danym
momencie zajmuje się czymś zupełnie innym; nad twoim komponentem może
kiedyś pracował, ale to mogło być wiele miesięcy temu. Musiałby sobie
przypomnieć. Poza tym nawet jak się orientuje w danym komponencie, to
nie orientuje się w tym, co ty akurat próbujesz z nim zrobić. Więc
musisz mu to wytłumaczyć - czasem będzie to proste, ale czasem sprawa
jest bardziej skomplikowana i tak jak ty poświęciłeś kilka godzin na
czytanie dokumentacji, rozmowy z analitykami itd. żeby to zrozumieć,
tak może teraz będziesz musiał poświęcić kilka godzin swojego i kolegi
czasu na wytłumaczenie mu tego.

> > Kolejną istotną sprawą jest czas przestawienia się, zmiany kontekstu.
> > Jeśli twój kolega pracuje nad czymś innym, ale odrywa się od swojej
>
> z mojego doświadczenia zmiana kontekstu jest stosunkowo tania jeżeli
> cały czas dotyczy programowania, w ramach tego samego programu.
> Spotkania za to, czy zmiana projektu .... to już inna para kaloszy.

Z mojego doświadczenia w ramach jednego projektu możesz mieć problemy
tak rozbieżne, że równie dobrze mogłyby dotyczyć zupełnie innego
projektu.