On 21/12/2011 23:03, Maciej Sobczak wrote:
> On Dec 21, 6:03 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>> Powód nazywa się natura ludzka. Jeśli nie ma aktywnej weryfikacji
>> aktualności wymagań w czasie, to fakt, że cośtam, co się zmieniło albo
>> okazało powoduje, że cośtam, co kilka miesięcy wcześniej zostało
>> zapisane w dokumencie jest nieaktualne i powinno zostać usunięte lub
>> zrewidowane, może łatwo umknąć uwadze.
>
> Nic nie umyka uwadze, bo jest DDD. Nie siadasz do kodu, dopóki nowej
> wiedzy (albo zupełnie nowej albo zmian do istniejącej) nie przelałeś
> na papier.

Ale samo przelanie na papier nie zabezpieczy cię przed otrzymaniem w
końcu dokumentacji zawierającej nieaktualne informacje. Co więcej,
możesz mieć w takiej dokumentacji sprzeczne informacje, z których część
jest aktualna, a część nie.

>>> Uwaga: trwa to dokładnie tyle samo, ile pisanie notatki.
>>
>> No więc niekoniecznie. Na przykład notatka, którą teraz mam przed
>> oczami brzmi tak: "załączniki!"
>> Wpisane do dokumentacji byłoby to bezużyteczne, ale dla mnie w
>> aktualnej sytuacji jest wystarczające.
>
> Nie życzę źle, ale co by było, gdybyś dziś wieczorem wpadł pod
> przysłowiowy autobus?

Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
notatka dotyczyła. Sama notatka jest już w śmietniku. Oczywiście nie
zawsze tak będzie, w tej chwili na biurku zostawiłem trochę notatek, z
których ciężko byłoby skorzystać, gdybym dzisiaj wpadł pod autobus. Ale
ponieważ właśnie dzisiaj rozmawiałem z kilkoma osobami na ten temat, to
prawdopodobnie nie byłoby tragedii - razem przypominając sobie, co było
powiedziane, oraz przeglądając notatki byliby prawdopodobnie w stanie
zrekonstruować ich treść.

Problem jest taki: gdybym zamiast każdej z tych notatek, które powstały
w mniej niż minutę, chciał zapisać w postaci dokumentu, który ktokolwiek
mógłby przeczytać i zrozumieć, to prawdopodobnie zajęłoby to wiele
godzin. Biorąc pod uwagę prawdopodobieństwo wpadnięcia pod autobus
(pewnie mniej niż jeden na milion), jaka jest ekonomia takiego działania?

Powiem więcej: gdybym dzisiaj wpadł pod autobus, to prawdopodobnie firma
by trochę ucierpiała, bo jestem w tej chwili jedynym implementatorem
dość krytycznego projektu. Być może koszta by były rzędu nawet zw dwóch
osobomiesięcy (chociaż to jest szacunek na wyrost). Ale to nie przez te
notatki, tylko przez to, że pracując nad tym, nad czym pracuję, zdobyłem
pewną wiedzę w temacie, którą przejmująca temat osoba musiałaby w dużej
mierze zdobyć od nowa. Ale przede wszystkim dlatego, że samo opóźnienie
spowodowałoby problemy organizacyjne zaburzające pracę wielu innych
ludzi. Oczywiście gdybym wszystko, czego się dowiaduję, dokładnie
dokumentował, to potencjalna osoba przejmująca moją pracę po moim
potencjalnym wypadku z autobusem miałaby łatwiej, ale samo pisanie
takiego dokumentu trwałoby z miesiąc, przez co po pierwsze problemy
związane z opóźnieniem miałbym za darmo, a po drugie kosztowałoby to
firmę dodatkowy roboczomiesiąc mojej pracy, i to wszystko, żeby uniknąć
dwóch roboczomiesięcy na wypadek zdarzenia, którego prawdopodobieństwo
jest jeden na milion.

> Albo gdybyś jutro na skutek chwilowej niedyspozycji jednak uznał, że
> ta notatka jest za krótka i poszedłbyś ponownie do OSCRa a to on wpadł
> pod autobus?

W tym przypadku to mało prawdopodobne (żebym uznał, abstrahując już od
prawdopodobieństwa wpadnięcia pod), ale nawet gdyby coś takiego zdarzyło
się z inną notatką, to mój OSCR nie jest jedyną osobą, która posiada
odpowiednią wiedzę. Nawet jeśli uzyskanie tej wiedzy byłoby przez chwilę
trudniejsze, to byłoby to co najwyżej kilkudniowe opóźnienie.

> Agile zbyt mocno polega na tym, że "będzie dobrze".

Właśnie agile tak w ogóle to jest głównie zabezpieczanie się przed tym,
że może być niedobrze.

W szczególności np. XP ma wiele praktyk zabezpieczających przed
scenariuszami "wpadł pod autobus" - zaczyna się od przelania wiedzy o
wymaganiach i projekcie na testy, jest programowanie parami, collective
code ownership, regularne spotkania na których jest obecny cały zespół,
i na których się mówi o tym, nad czym aktualnie się pracuje, z czym są
problemy (release planning, iteration planning, daily stand-up) i co tam
jeszcze.

> Ja nie mam nic przeciwko spontanicznemu byciu agile, jeśli tak ma się
> nazywać stan, w którym szybko reaguję na zmiany wymagań. Natomiast to,
> co odrzucam w agile i w każdej innej metodologii to stan
> fetyszyzowania i wystawiania procesu przed projekt.

Wręcz przeciwnie, fetyszyzowanie procesu jest sprzeczne z Agile. Nawet
pierwszy value o tym jest. :)

> Mam tu na myśli
> narzucanie jakiejś formy na wszystkie okazje - np. reguły, że OSCR
> jest jeden,

Nie ma takiej reguły. OSRC-ów jak najbardziej może być kilku.

> pisanie notatki ma trwać co najwyżej 15 minut

To był żart przecież, chodziło o to, że w związku z tym, że przyswajanie
dużej ilości informacji na raz wiąże się z tym, że część się zapomina,
należy przyswajać ją w małych kawałkach i starać się robić jedną rzecz
na raz.

> a iteracja
> ma mieć dokładnie tydzień. Dupatam - rozmawiać trzeba z tyloma ludźmi
> ile potrzeba, pisanie notatki (pardon: dokumentacji) ma trwać tyle,
> ile potrzeba żeby ją zapisać a iteracja ma trwać tyle, ile potrzeba,
> że zrobić etap. Czasem to może być pół dnia a czasem 3 miesiące.
> Wciskanie 3-miesięcznego etapu w tygodniową iterację jest głupie -
> widziałem to i słabo było.

Iteracje nie są po to, żeby w coś w nie wciskać, tylko żeby mieć
regularny odstęp czasu do planowania kolejnych priorytetów i do
planowania. Twój "etap" spokojnie może się mieścić w wielu iteracjach.

Poza tym: niektórzy zalecają inną długość iteracji lub też mówią, żeby
ustalić długość na 1 do 3 tygodni. Owszem, tydzień jest zalecany, i
reguła mówi, że iteracje mają być równej długości. Tylko powiedz
realnie, na czym polega twoja potrzeba, żeby iteracja była dłuższa? Bo
wydaje mi się, że jakoś źle tych iteracji używasz. To nie są inaczej
nazwane "etapy".