On 17/12/2011 22:51, Maciej Sobczak wrote:
> On Dec 17, 4:58 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
>> długo, żeby zrozumieć co program ma robić,
>
> I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
> procesu.
>
> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
> krótką listą zakupów, ale dłuższe opisy mi się urywają.
>
> [*] Z obserwacji wynika, że nie tylko ja mam ten defekt. Akurat mamy
> weekend - stań przed jakimś kościołem i zapytaj wychodzących ludzi o
> czym było kazanie. Pamiętaj, że wszyscy słuchali tego samego, ale
> zapytaj kilka różnych osób.
> Dobre, nie?
>
> Pytanie: jak długa jest rozmowa z tym - jak mu tam - OSCR, żeby
> przekazać równoważnik kilkuset stron tekstu? Krócej, niż kazanie, czy
> dłużej?

Ale moment, ty to sobie wyobrażasz na zasadzie "kazanie" - programiści
siadają wszyscy w sali i klient im mówi od początku do końca jak program
ma działać, po czym bierze walizeczkę i idzie do domu?

W takiej sytuacji mogę tylko powiedzieć, że po prostu niee zrozumiałeś,
o co chodzi. On-site customer polega właśnie na tym, że pracuje razem z
zespołem, siedzi razem z zespołem w godzinach pracy i jeśli programiści
nie wiedzą jak coś konkretnie powinno działać, to idą i on im mówi. To
może równie dobrze trwać dwie minuty.

Ze szczegółowymi wymaganiami robi się tak, że rozbija się na małe
kawałki, tzw "user stories". Potem te stories się planuje i konkretni
programiści zajmujący się akurat implementacją konkretnej story
rozmawiają z OSRC na temat tego jak program ma działać we fragmencie
związanym z tą właśnie story.

>> a jeśli nie jest w stanie
>> zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
>> rozmawia z OSCR jeszcze trochę.
>
> No właśnie.
> Otóż zaletą metodologii "dokumentacyjnych" jest to, że kiedyś,
> ostatecznie, *można się rozejść*. Bo nawet jeśli się odbiorcy się
> urwał wątek, to może sobie do niego wrócić we własnym zakresie i nie
> potrzebuje "rozmawiać z OSCR jeszcze trochę".

Jak "rozejść"? Jakiemu odbiorcy? Nie bardzo rozumiem, co masz na myśli.
On-site customer representative reprezentuje twojego klienta
(zewnętrznego, wewnętrznego lub wyobrażonego). Dopóki masz klienta, to
możesz mieć osobę reprezentującą to, co klient chce.

Jeśli z "rozejściem" chodziło o to, że programiści mogą się fizycznie
oddalić od OSCR, to przecież nie chodzi o to, że oni fizycznie
rozmawiają z nim cały czas. Rozmawiają tyle, ile potrzeba żeby się
dowiedzieli, czego nie wiedzą, zrozumieli, czego nie rozumieją, a co
jest im akurat potrzebne do zaimplementowania kolejnego kawałka
funkcjonalności, zanotowali co trzeba, a potem oddalili się do
stanowiska programistycznego i przelali to, co właśnie usłyszeli do
postaci tesów i kodu.

> Możliwość rozejścia się jest kluczowa dla postępu projektu. Bez tej
> możliwości albo masz zastój (znaczy: odbiorca "rozmawia jeszcze
> trochę" w nieskończoność), albo urwaną treść. Osobiście nie widzę
> siebie w rozmowie na temat czegoś, co na papierze ma kilkaset stron.

Ale jesteś w stanie przeczytać te kilkaset stron od deski do deski i
pamiętać każdy szczegół?

> Napisanie dokumentacji służy przekazaniu wiedzy i jest to proces,
> który może być zarówno kompletny, jak i obustronnie potwierdzony.

Pisanie acceptance testów też może być takim procesem.

> Minimalizacja bugów, jeśli w ogóle występuje, jest tu procesem
> pobocznym a nie celem samym w sobie. Celem minimalizacji bugów może
> być np. zastosowanie metod formalnych. Albo unit testy. Albo voo-doo.
> Albo co tam kto umie i czemu ufa, zależnie od budżetu i lokalnej
> kultury. Jednak żadna z tych metod nie wyklucza użycia dokumentacji,
> która służy tylko (i aż!) do skompletowania procesu przekazywania
> wiedzy.
> Dlatego nie ma problemu, żeby zrobić dokumentację *oraz* unit testy
> (przykładowo).

Problem jest taki, że masz ograniczone zasoby i musisz rozwiązać problem
efektywnego ich wykorzystania. Jeśli ktoś pisze dokumentację, to nie
może w tym samym czasie odpowiadać na pytania ani pisać testów. Porządne
pisanie kodu i testów może trwać dłużej niż pisanie byle jak: do tego
stopnie, że być może będziesz chciał np. tworzyć albo adaptować DSL-e
i/lub frameworki do tego, żeby można było automatyczne testy wyrazić w
sposób maksymalnie deklaratywny i przy użyciu domain concepts.

> Problem z agile polega na tym, że przekazywanie wiedzy oparte jest na
> machaniu rękami i jest to najsłabsze ogniwo z powodów powyżej. A
> ponieważ to ogniwo jest na początku procesu, to dalej buduje się na
> gównianych fundamentach i stąd te ciągłe dema i walenie klienta po

Nie jest na początku procesu. Jest cały czas.

Natomiast problem z pisaniem dokumentacji jest taki, że jest oparte na
machaniu rękami, a ponieważ dokumentację pisze się na początku, to dalej
buduje się na gównainych fundamentach i stąd te ciągłe opóźnienia i
dostarczanie po terminie "kompletnej" funkcjonalności kompletnie nie
odpowiadającej potrzebom klientów.

> głowie niedokończonymi wersjami.
> Pominięcie dokumentacji *nie jest tańsze*. Tak przynajmniej wynika z
> moich obserwacji.

Z moich wręcz przeciwnie.