On Dec 18, 12:49 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> 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.

IMHO to dziala w przypadku systemow ktore sa na tyle proste, ze mozesz
je wytlumaczyc czlowiekowi na tablicy, on/ona chwile popatrzy, pomysli
i bedzie mial/a w glowie pelne zrozumienie problemu. Wtedy taka
procedura ma szanse dzialac. Jezeli projektuje sie bardziej zlozony
system, to niestety ludzie musza wziac napisany dokument, zaparzyc
sobie kawy, siasc i go przetrawic w skupieniu. Inaczej nie beda
rozumieli co robia.

RW