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?

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

Coś jak wydrukowane kazanie.

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.

Napisanie dokumentacji służy przekazaniu wiedzy i jest to proces,
który może być zarówno kompletny, jak i obustronnie potwierdzony.
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 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
głowie niedokończonymi wersjami.
Pominięcie dokumentacji *nie jest tańsze*. Tak przynajmniej wynika z
moich obserwacji.

Oczywiście, robiłem też projekty bez dokumentacji. Jak również takie
bez testów. Albo nawet bez kawy. Takie bez klienta też. Wszystko
zależnie od potrzeb.

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