On Dec 18, 11:18 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 18, 5:54 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > Jeśli wynotowanie sobie czegoś podczas rozmowy na kartce papieru to już
> > "dokumentacja" to się nie zrozumieliśmy.
>
> To kiedy coś jest "dokumentacją"?
> Czy napisanie czegoś na wiki się liczy?

Co za różnica?

> > Nie, nie ma żadnych N miesięcy na pisanie notetek
>
> A jak nie zdążą?

Jak nie zdążą w jeden dzień, to ewentualnie mają następny dzień, ale
to już jest sygnał, że trzeba naprawić proces. Jeśli coś, co miało być
zrobione w jeden dzień okazuje się robotą na wiele miesięcy, to się to
wycofuje z bieżącej iteracji i robi się repriorytetyzację na kolejnym
iteration planning. Jeśli coś jest robotą na wiele miesięcy, to nie
powinno być opisane jako jedna user story.

> > i nie ma wpinania
> > notatek do segregatora.
>
> A jak się rozsypią?

Jedna kartka ma się rozsypać?

> > Notatki służą do tego, żeby pomiędzy rozmową z
> > OSCR-em a zakodowaniem uzyskanej informacji rozmawiający nie zapomniał.
> > Ten czas, to bardzo rzadko więcej niż dzień, nigdy więcej niż 3-4 dni.
>
> Sorki, ale to nie działa. W 3-4 dni to sobie można okienko dialogowe
> napisać a nie określić działanie większego systemu w jakimkolwiek jego
> pionowym wycinku.

Pojedyncza user story to nie jest koniecznie kompletny kawałek
funkcjonalności. Dodatkowo, jak najbardziej można dopisać kompletną (w
sensie już użyteczną) nową funkcjonalność w 3-4 dni. Okienko dialogowe
(bez funkcjonalności) to raczej robota na minuty.

> > Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
> > piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
> > przez OSCR-ów są priorytetyzowane na początku każdej iteracji
>
> Zaraz, zaraz. Czyli OSCRy muszą *najpierw* zaproponować te user
> stories, żeby mogli je priorytetyzować.

Tak.

> Powiedzmy, że tych historyjek jest Bardzo Dużo (tm). Ile czasu trwa ich
> "zaproponowanie"?

Tyle czasu, ile się wyznaczy. Tzn. jeśli OSCR ma Bardzo Dużo
historyjek, to się go prosi o własną priorytetyzację, bo na danym
zebraniu ma tylko zaproponować te, które będą możliwe do wykonania w
ciągu jednego tygodnia. Niech przedstawi od najważniejszych do
najmniej ważnych, przy czym historyjki zależne od innych historyjek
ustawi za nimi, i niech przedstawia w takiej kolejności - dajmy na to
po pięciu minutach będzie można spokojnie powiedzieć: "wystarczy, w
tym tygodniu i tak więcej nie zrobimy".

> Czym się
> różni "zaproponowanie" dużej ilości historyjek od napisania dużej
> ilości use-casów (na przykład) w formie dokumentacji? Nadal jest to N
> miesięcy, tyle że się fajniej nazywa.

Nie ma N miesięcy, bo OSCR musi przedstawić swoje historyjki na
pierwszym zebraniu planowania iteracji, czyli powiedzmy najdalej dwa
tygodnie po rozpoczęciu projektu. Oczywiście OSCR może sobie
utrzymywac backloga tak długiego, jak chce, ale co tydzień musi i tak
określić, jakie są najważniejsze rzeczy do zrobienia _teraz_, co
wymaga w tym samym tygodniu, w którym dana historia jest
implementowana, potwierdzenia przez żywą osobę, że to jest nadal ważne
i nadal ma być zrobione tak, jak sobie to wcześniej obmyśliła.
Naturalnym jest, że w trakcie tygodnia, w którym trwa implementacja
jednych historii, następują zmiany, czy zadawane są pytania, czy
podejmowane są decyzje, które powodują, że niektóre z tych Bardzo
Wielu historyjek nigdy nie zostaną zaproponowane, albo okażą się
znacznie ważniejsze, lub mniej ważne, albo przyjmą zupełnie inną
postać, niż to zakładał OSCR, kiedy sobie pisał owe Bardzo Dużo
historyjek.

> I nadal te user stories razem
> wzięte (chyba jednak lepiej je spiąc do segregatora) to jest
> dokumentacja.

To nie jest dokumentacja. Jeśli OSCR zepnie sobie wszystkie user
stories, które ma do zaproponowania w segregator, to jest to jego
prywatny segregator, a nie dokumentacja, która kogokolwiek interesuje.

Historyjki, które są zaplanowane na kolejną iterację, oraz te, które
zostały już odhaczone,

> No, chyba że OSCRy strzelają po kilka historyjek co tydzień i tak aż
> do końca projektu. Nadal jednak będzie tego M stron i nadal ich
> napisanie zajmie N czasu, nawet jeśli się je zaraz po napisaniu
> wyrzuca do kosza.
> Dlatego nie widzę postępu.

Postęp jest taki, że w trakcie tworzenia programu zdobywa się
dodatkowe informacje o tym, co jest ważne, co jest trudne, co i jak
można uprościć itd.

> Czyli co tydzień OSCR może zmienić ogólną wizję i doprowadzić do
> stworzenia produktu, który jest zbiorem niepowiązanych ze sobą
> funkcjonalności. Coś jak odkurzacz z odtwarzaczem mp3 i ekspresem do
> kawy.
> W przypadku napisania dokumentacji z góry jest szansa to dostrzec.

Ale dlaczego nie ma szansy tego dostrzec w kolejnym tygodniu? Poza tym
poza iteracjami jest jeszcze coś takiego jak release plan, na którym
ustala się funkcjonalność potrzebną do pierwszego release. Jeśli nagle
OSCR zaczyna zgłaszać funkcjonalność, która nie jest z tym związana,
to można zweryfikować, czy faktycznie to jest koniecznie potrzebne
klientowi i czy klient rozumie, że to opóźni dostarczenie gotowego
produktu. Jeśli klient to potwierdzi, albo po otrzymaniu odkurzacza w
wersji 1.0 stanowczo potwierdzi, że wersja 1.1. ma się różnić przede
wszystkim tym, że będzie miała odtwarzacz mp3, to już jest decyzja
klienta, a nie zespołu programistycznego.

> > Przede wszystkim czas - czas życia notatki mierzony jest raczej w
> > godzinach,
>
> Nie bardzo. Wtedy nie ma szansy dostrzec, że robimy odkurzacz z mp3,
> bo przy pisaniu notatki o mp3 poprzednia historyjka o odkurzaniu jest
> już w koszu. A potem OSCR powie, że nic takiego nie mówił. I jak mu
> udowodnić, że pieprzy, skoro sami powyrzucaliśmy wszystkie notatki do
> kosza?

Ta rozmowa z OSCR-em odbywa się podczas pracy nad konkretną
historyjką. Jeśli OSCR mówi rzeczy, które nie są z tą historyjką
związane, to się mu mówi, że owszem, skoro sobie życzy, ale to
zupełnie inna historyjka, i w ogóle funkcjonalność nie przewidziana na
ten release, więc decyzja klienta, czy chce dostać jak najszybciej
release z taką funkcjonalnością, jaką zaplanowano przy planowaniu
release-u, albo czy chce zmienić plan.

> Sorki, ale nie widzę tej teorii w praktyce.

Otóż nie wiem, czy cię zaskoczę, ale to nie jest coś, co właśnie sobie
wymyśliłem, tylko coś, co jest stosowane w praktyce przez bardzo wiele
projektów i produkuje sporo działającego oprogramowania.

> Nawet nie chciałbym się w
> czymś takim znaleźć, ani jako wykonawca, ani jako klient.

Z tym nie będę polemizował.