On 17/05/2011 18:49, Przemek O. wrote:
> W dniu 2011-05-17 18:53, Andrzej Jarzabek pisze:
>
> Dokumentacja jest potrzebna zawsze przy dużych projektach.

Z mojego doświadczenia wynika, że bieżąca dokumentacja w dużych
projektach jest bardzo często mocno niekompletna, nieaktualna, a koszt
jej utrzymania przewyższa korzyści jakie przynosi. W skrócie - niepotrzebna.

> Tak samo jak komentowanie kodu. Oczywiście nikt nie każe dokumentować
> pierdół. Chodzi o to, że przy projekcie oprogramowania które powstaje
> rok i dłużej, po pewnym czasie nawet osoba siedząca w projekcie od
> początku może nie wiedzieć co gdzie i jak się robi.

Ktoś siedzi rok w projekcie i go nie zna? Chyba żartujesz.

> Dochodzenie do tego na podstawie
> analizy kodu i ewentualnego komentowania kodu jest bardziej uciążliwe i
> długotrwałe w porównaniu do szukania tego w dokumentacji projektu.

Po pierwsze, po to masz coding standards, żeby nie było.
Po drugie, w praktyce zespół, który pracuje nad kodem od roku ma o nim
lepszą wiedzę, niż jest zawarta w dokumentacji. Jeśli praktykujesz
shared ownership, to masz sporą szansę na to, że dany programista będzie
sam znał odpowiedź. A jeśli nie, to praktykując kolokalizację zespołu,
łatwo jest mu po prostu zapytać i dostać odpowiedź. A jeśli utknie, to
po to masz daily standup, żeby ci, co wiedzą, mogli się zgłosić do pomocy.

> Czym innym jest dokumentacja projektowa (dokumentacja kodu) a czym innym
> jest projekt (określający założenia projektu, wymagania, sposób
> realizacji itd itp).

Ja mówię o tym, co w waterfallu jest tworzone w design phase. Wymagań i
analizy do tego nie wliczam.

> Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika.

A jednak całkiem spore programy się w ten sposób robi.

> A umowę na co się podpisuje? A na jakiej podstawie projekt jest uznany za
> zakończony? Na podstawie tego że customer powie że tak jest? Nawet jeśli
> wszystko ustalicie i wydaje się ze jest ok, to customerowi nagle może
> się przyśnić coś innego, albo zobaczy coś u kogoś i będzie to chciał.
> Tym sposobem projekt nie będzie zamknięty nigdy.

Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
potem regularni i dość często kolejne release'y, np. co miesiąc albo co
dwa miesiące.

I jeśli to jest zewnętrznie zlecony projekt, to - na ile się orientuję -
preferuje się umowy sformułowane tak, że dopóki zleceniodawca płaci, to
dostaje kolejne wersja - z jakimiś tam zabezpieczeniami dla obydwu stron.

Jeśli się nie da, a decyduje się na XP, to się zakłada, że kontrakt
będzie renegocjowany po zawarciu, że zlecenidawca będzie skłonny do
zmiany kontraktu jak zobaczy, że dostaje w pierwszej kolejności to,
czego najbardziej potrzebuje i że będzie miał szybko funkcjonalny
produkt. Wtedy odpowiednie role w zespole osłaniają przed tym programistów.

No i oczywiście niektóre projekty są wewnętrzne, więc nie ma całego tego
krapu.

> Powiem Ci tak. (bez urazy oczywiście) Po przeczytaniu tego odnoszę
> wrażenie, że piszesz oprogramowanie sam lub w gronie programistów a nie
> w zespole tworzącym oprogramowanie. Czyli tzw. standard - programista
> "wszystkorobiący". Od zbierania wymagań, poprzez opracowanie projektu
> (lub nie), kodowanie, testowanie (!) i wdrażanie. Sam tak robiłem swego
> czasu.

Powieem ci tak: mylisz się.

> I to by tłumaczyło nasze różne podejście do kwestii tworzenia
> oprogramowania.
> Analityk (dobry analityk) jest nieoceniony. Minimalizuje ryzyko
> wystąpienia sytuacji o których piszesz już na etapie zbierania i
> opracowywania wymagań. I czym jest tutaj okres kilku (nastu) tygodni
> poświęconych na stworzenie dokumentacji wymagań, jeśli wynikiem tego
> jest konkretna punkt po punkcie lista opcji które program musi posiadać,
> z opisem konkretnych działań jakie musi wykonywać. Na podstawie wymagań
> mamy już możliwość oszacowania wykonalności i ewentualnego terminu
> wykonania. Ale żeby tak było analityk musi być dobry, znać branże dla
> której piszemy oprogramowanie. A takich niestety jest niewielu, a ich
> wynagrodzenie jest niejednokrotnie wyższe od wynagrodzenia programistów.

Nie wiem, może pracujesz w jakiejś specyficznej branży, albo
specyficznej kulturze, w której waterfall się sprawdza, ale consensus
jest jednak taki, że nie sprawdza się prawie nigdy.

Ja też pracowałem z analitykami, wydaje mi się, że dość dobrymi, ale
zawsze było tak, że dokumenty, które wyprodukowali trzeba było mocno
modyfikować w trakcie developmentu. I komunikacja, a nie dokumentacja,
była kluczowa dla skuteczności realizacji _rzeczywistych_ wymagań.