On 18/12/2011 13:03, Roman W wrote:
> On Dec 18, 12:49 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
> [snip]
>
> Sumaryczna odpowiedz:
>
> 1. Koniecznosc zatrudnienia OSCR fizycznie dostepnego dla programistow
> moze byc kosztem nie do zaakceptowania.

Może tak być. No i trudno - XP w ogóle ma wiele wymagań upfron które
trzeba spełnić, bo inaczej prawodopodobnie nie da się sensownie zastosować.

> Jjezeli ten koles ma byc
> podstawowym zrodlem informacji dla programistow, to musi byc dla nich
> caly czas dostepny, czyli bedzie siedzial w biurze programistow i sie
> nudzil kiedy programisci akurat nie beda mieli do niego pytan -- ergo,
> klient oddeleguje do programistow najmniej uzyteczna osobe, czyli
> jakiegos glaba.

Po pierwsze należy klientowi delikatnie uświadomić, że jeśli oddeleguje
głąba, to znacząco redukuje swoje szanse dostania dobrego produktu w
dobrym czasie.

Po drugie OSCR, w momencie kiedy nie odpowiada na pytania programistów,
jest bardzo dobrze usytuowanym żeby wykonywać exploratory testing -
siedzieć na maszynie, na której zainstalowane jest ostatnie demo, i
próbować go używać.

Poza tym obowiązkiem OSCR jest również wymyślanie kolejnych user stories
i zastanawianie się nad ich wartością - co prawdopodobnie też się będzie
wiązać z kontaktowaniem się z odpowiednimi ludźmi w macierzystej
organizacji i omawianiem z nimi tych problemów - być może w postaci
tworzenia i przesyłania dokumentacji.

W końcu - oprócz odpowiadania i tłumaczenia, OSCR może/powinien brać
też udział w tworzeniu acceptance tests.

> Natomiast dokumentacje moze napisac najlepszy spec po
> stronie klienta, oddac ja programistom, zajac sie czym innym a od
> czasu do czasu odpowiadac na ich pytania, ew. umowic sie na spotkanie.
> Programisci, majac dobra dokumentacje, nie musza miec pod reka
> fizycznej osoby 40h/tygodniu. IMHO pisemna dokumentacja to bardziej
> efektywne wykorzystanie czasu ludzi, ktorzy najlepiej wiedza co
> projekt ma dostarczyc.

IMHO z taką dokumentacją jest cały szereg problemów, poczynając od tego,
że jeśli osoba znająca się na czymś dobrze pisze dokument, który będzie
czytać ktoś, kto się na tym zna słabo lub wcale, to jest gigantyczny
potencjał, żeby czytelnik źle zrozumiał dokument, i w związku z tym
zaimplementował funkcjonalność, która w jego mniemaniu jest zgodna z
dokumentem, natomiast jest w mniejszym lub większym stopniu niegodna z
intencją autora dokumentu. Moim zdaniem interaktywne przedstawianie tej
wiedzy, w połączeniu ze względnie krótkimi cyklami
tłumaczenie-implementacja-tłumaczenie-implementacja w dużej mierze
niwelują ten problem.

Czy marnowanie czasu na implementowanie błędnej funkcjonalności i potem
na znajdowanie i poprawianie tych błędów jest mnie lub bardziej
nieefektywne od trzymania najlepszego speca od strony klienta on site
40h/tygodniu - tego nie wiem. Moim zdaniem, również w świetle tego, co
napisałem powyżej o roli OSCR-a to bardziej się opłaca mieć tego speca
na miejscu - ale to może zależeć od specyfiki projektu, klienta, wielu
innych rzeczy. Dodatkowo pomiędzy głąbem a najlepszym specem można
jeszcze rozważyć OSCR-a pośredniego, który nie jest głąbem i zna się na
temacie, a dodatkowo ma gorącą linię do najlepszego speca i kilka godzin
tygodniowo poświęca na omawianie z nim tego, co jest i będzie robione,
jak to powinno być robione i tak dalej. Taki OSCR jak dla mnie jest
zdecydowanie bardziej wartościowy niż dokumentacja napisana przez
najlepszego speca.

> 2. Zawsze latwiej jest krytykowac efekt czyjejs pracy niz besposrednio
> autora.

Nawet jeśli, to nie zawsze najlepiej zrobić to, co zrobić najłatwiej.

Poza tym w przypadku OSCR-a też krytykujesz efekty pracy: "pan Iskiński
próbuje nam wytłumaczyć, co jak program ma się zachowywać, ale efekty
jego pracy są mizerne, bo to, co mówi nie trzyma się kupy" :)