On Dec 19, 5:48 pm, Andrzej Jarzabek <a...@g...com>
wrote:

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

No przecież ja nie oczekuję, że cały system, który normalnie ma
kilkaset stron opisu, znajdzie się w jednym user story. Oczekuję, że
tych stories będzie np. kilkaset.
I wtedy się okaże, że ich przekazanie (oraz napisanie odpowiednich
notatek) zajmie *w sumie* tyle, ile napisanie całości. Bo chyba
wszędzie jest tak, że całość jest sumą swoich składników, i nic tu się
nie da zaoszczędzić.
Czyli jeśli zamiast spędzenia np. 1 miesiąca na pisaniu dokumentacji
mam to zrobić w czasie 160 1-godzinnych spotkań, to żadna różnica - to
nadal jest *w sumie* 160 godzin.

(W praktyce 160 1-godzinnych spotkań zajmie *znacznie* więcej, niż 160
godzin, ale nie komplikujmy rozważań, bo się zaplączemy w
złośliwościach.)

Jeszcze raz: nie podałeś jeszcze żadnego powodu, dla którego
*sumaryczny* czas spędzony na przekazywaniu wiedzy ma być w agile
mniejszy. Różnica jest taka, że ten czas jest wpleciony w czas trwania
całego projektu, ale nie ma powodu, żeby był *w sumie* krótszy.

Widziałem kiedyś prezentację nt. agile i facet na samym początku
powiedział coś takiego:

***
Wielu ludzi błędnie sądzi, że agile jest po to, żeby projekt
powstał szybciej. Jest to bzdura i bywa nawet, że trwa to dłużej.
Agile powstało po to, żeby lepiej reagować na zmieniające się
wymagania projektowe - i *to* jest właśnie powód, żeby go stosować.
***

Myślę, że to jest sedno naszego nieporozumienia. Nie mam najmniejszej
wątpliwości, że jako sposób prowadzenia projektów agile jest bardziej
odpowiedni, gdy mamy podejrzenia, że wymagania będą się zmieniać w
czasie jazdy - czy to z powodu uwarunkowań dziedzinowych, czy też z
powodu niezrównoważenia klienta, czy nawet z takiego, że cała
dziedzina ma eksploracyjny charakter i nie jest do końca poznana i
można się spodziewać, że wiele rzeczy wyjdzie dopiero w praniu.
Naprawdę - w pełni się zgadzam, że w takiej sytuacji istotna jest
ciągła współpraca między klientem a wykonawcą. W przypadku skrajnym
najlepszym rozwiązaniem jest w ogóle rezygnacja z outsource'owania
projektu i stworzenie lokalnego zespołu programistów, który będzie
temat rozwijał in-house - wtedy w ogóle nia ma sensu wyodrębniać
takiej roli jak OSCR, tylko się szkoli programistów tak, żeby sami
stali się specjalistami danej dziedziny (dodatkowo można to zrobić też
w drugą stronę - pozwolić "domenowcom" pisać kod, który się potem
integruje w całość). Właśnie w takim środowisku spędziłem ostatnie 6
lat (surprise! ;-) ) i w pełni rozumiem potrzebę ścisłej współpracy,
którą agile próbuje zrealizować przez szeroko pojęty gęsty feedback.
To ma sens.

Ale żadna metoda prowadzenia projektów nie może opierać się na
"nierobieniu" czegoś.
Dlatego naprawdę bez sensu jest twierdzić, że w agile chodzi o to,
żeby nie robić dokumentacji. O nic takiego tam nie chodzi i nie może,
z powodów fundamentalnych, czyli z nieredukowalności informacji, która
prowadzi do tego, że przekazywania wiedzy nie da się skrócić. Można
ten proces rozstrzelić i posiekać na tysiąc kawałków przemieszanych z
klepaniem kodu i można nawet ustalić limity, że jeden kawałek nie może
zająć dłużej niż dwie minuty, ale sumaryczny koszt nie zniknie - on
się rozłoży w czasie całego projektu.
Może być przez to mniej nużący. Ale nie zniknie.

Nierobienie dokumentacji jest bez sensu, podobnie jak wyrzucanie do
kosza jakichkolwiek artefaktów projektowych - również notatek.
Z biznesowego punktu widzenia nierobienie dokumentacji jest bez sensu
z kilku powodów. Raz, że wszystko może się przydać przy rozstrzyganiu
konfliktów. Dwa, że wszystko może się przydać, gdy... sprzedaje się
technologię lub całą firmę.
Wtedy lepiej jest mieć równo poukładane segregatory, bo OSCR już
poszedł do domu.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com