On 18/12/2011 11:44, Roman W wrote:
> On Dec 18, 11:04 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>
> Ja tu widze kilka praktycznych problemow:
> - co robia programisci, kiedy OSCR jest chory/poszedl na urlop i nie
> ma zastepstwa?

Możesz mieć więcej niż jednego OSCR w zespole. Jeśli np. masz jednego
rzeczywistego przedstawiciela faktycznego klienta, to drugi OSCR może
być wewnętrznie zatrudnionym BA pełniącym taką rolę - jeśli zna się na
temacie i na codzień pracuje z faktycznym przedstawicielem klienta, to
powinien mieć wystarczająco dużo informacji, żeby pociągnąć projekt
przez tydzień czy dwa (jeśli nie dłużej).

> - co sie robi w sytuacji, kiedy OSCR jest, well, glabem? jezeli mam
> problem z dokumentem (jest niekompletny, niejasny, zawiera
> sprzecznosci) moge go w miare bezpiecznie skrytykowac. Jezeli moim
> biezacym zrodlem wiedzy jest czlowiek przyslany przez klienta, to
> napisanie maila "X nie rozumie o co biega w projekcie/nie umie
> wyjasnic o co biega" jest politycznie trudniejsze niz napisanie
> "dokumentacja jest niekompletna, prosze uzupelnic", bo krytykujesz
> osobe a nie rzecz.

W przypadku dokumentu też przecież będzie tak, że jeśli w twojej krytyce
nie napiszesz "autor jest głąbem, proszę dać do napisania komuś innemu",
to dadzą dokument do poprawienia temu samemu głąbowi i on znowu napisze
nie to, czego potrzeba. Jak będziesz konsekwentnie walić krytyką, to w
momencie, w którym wymienią autora może to już w praktyce niewiele się
różnić od skrytykowania osoby.

Oczywiście zgodzę się, że takie niuanse są istotne i jeśli faktycznie
masz kulturę, gdzie trudno krytykować nawet ewidentnych głąbów, to może
rzeczywiście nie powinieneś adoptować metod opartych na bezpośśredniej
komunikacji.

Jeśli chodzi o rozwiązanie - jeśli już musisz pracować z głąbem i z
powodów politycznych nie da się z tym nic zrobić, to można go jeszcze
unieszkodliwić np. zatrudniając go do pisania dokumentacji, a do
pełnienia rzeczywistej roli OSCR-ów przyjąć ze dwóch dobrych BA.

> - bez formalnej dokumentacji jest trudniej sledzic, na jakim etapie
> kto zazyczyl sobie zmian w projekcie, kto odpowiada za dane
> rozwiazanie, itd. OSCR moze na flipczarcie narysowac programistom cos
> co mu akurat przyszlo do glowy, programisci zuzyja X roboczogodzin na
> implementacje jego fantazji, a kiedy kupka uderzy w wiatraczek, to
> OSCR sie moze wyprzec ze kiedykolwiek o tym mowil - bo przeciez nikt
> nie bedzie lazil do OSCR z dyktafonem w kieszeni, nie?

To trochę nie tak działa. Każda większa część funkcjonalności jest
dokumentowana w postaci user story i planowana na konkretną iterację.
Objaśnienia OSCR-ów w trakcie developmentu dotyczą szczegółów stories
już zaakceptowanych na daną iterację. Oczywiście podczas samego
planowania stories są tworzone, dokumentowane, i wtedy OSCR tłumaczą co
się z nimi wiąże - developerzy w tym momencie mają dowiedzieć się na
tyle, żeby ocenić złożoność implementacji. OSCR-om nie wolno w trakcie
iteracji dokładać nowych kawałków funkcjonalności. Jeśli natomiast
okazuje się, że złożoność uzgodnionej wcześniej story została poważnie
niedoszacowana, na tyle żeby zburzyć istniejący plan iteracji, to się
idzie z tym do product ownera i decyduje się, co robić. Jeśli np.
uproszczona wersja też ma sens, to można ustalić, że uproszczoną wersję
robimy teraz, a full-blown wersję zapiszemy jako osobną story. Jeśli się
tak nie da, to trzeba zmienić plan, i albo wyrzucić story do kolejnej
iteracji, albo zredukować scope aktualnej iteracji przerzucając inne
stories na kolejną. Tak czy inaczej, wszystkie stories, plany iteracji,
plany release'ów i zmiany tych planów są dokumentowane i zatwierdzane
przez odpowiednie strony.