W dniu 2011-05-17 18:53, Andrzej Jarzabek pisze:

>> Poza tym, jest pewien poziom skomplikowania, od którego
>> dokumentacja projektowa jest niezbędna do powstania produktu końcowego.
>
> Nie zgodzę się. Dokumentacja projektowa może być potrzebna jeśli np.
> zespół po zakończeniu projektu ma być rozwiązany lub przeniesiony do
> innego projektu, a maintenance ma robić ktoś inny (co jest sensownym
> scenariuszem, bo zespół agile powołany do tworzenia projektu ab initio
> nie będzie najlepszym zespołem do jego maintainowania po zredukowaniu
> ilości bieżącej pracy.
>
> W drugiej kolejności dokumentacja może być potrzebna firmie jako
> dupochron na wypadek, gdyby jakaś większa liczba członków zespołu
> zechciała sobie pójśc gdzie indziej.
>
> I w końcu jeśli zakładasz, że będzie duża rotacja pracowników w czasie
> trwania projektu, dokumentacja projektowa jest potrzebna, ale jeśli
> będzie duża rotacja, to prawdopodobie nie powinieneś stosować Agile.

Dokumentacja jest potrzebna zawsze przy dużych projektach. 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. 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.

> Projekt to projekt, a wymagania to wymagania. Nawet jeśli dostraczenie
> dokumentu projektowego jest w wymaganiach, to raczej się nie wymaga,
> żeby dostarczyć go up front - przed napisaniem programu. No chyba że
> pracodawca/zleceniodawca ma też takie wymaganie, ale wtedy nie
> praktykujesz agile, tylko narzucony z góry proces waterfall lub
> iterative.

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

> Jeśli chodzi o same wymagania, to XP ma takie podejście, że od
> udokumentowanych wymagań lepszy jest customer w zespole. Oczywiście
> musisz tego customera mieć, w dodatku musi być kompetentny i mieć
> realną możliwość podejmowania decyzji i brak tego jest poważną
> obiektywną przeszkodą w stosowaniu XP. Z drugiej strony oczywiście
> należy do tego przyłożyć zdrowy rozsądek - podejście to nie oznacza
> zakazu istnienia dokumentów z wymaganiami, istotne są natomiast dwie
> rzeczy: po pierwsze, że realne wymagania będą się zmieniać w miarę
> pracy z customerem i w związku z tym dokument z wymaganiami nie może
> być wiążącą umową, a po drugie że jak programista będzie miał
> jakiekolwiek problemy, uwagi czy propozycje co do tego, co wyczytał w
> dokumentacji wymagań, to będzie mógł usiąść z customerem i wypytać się
> go, czego on naprawdę chce. Jeśli te warunki nie moga być spełnione,
> to jest to kolejna obiektywna przeszkoda w stosowaniu XP.

Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika. 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.

> Jeśli chodzi o moje osobiste doświadczenie, to mam właśnie takie:
> dokument z wymaganiami się szybko dezaktualizuje, możliwość szybkiego,

<CIACH>

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.
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.
Na tej podstawie podpisujemy umowę która sztywno określa zakres zadania
i termin jego ukończenia. Wiadomo z czego i na jakiej podstawie jesteśmy
rozliczani.

pozdrawiam,
Przemek O.