W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:
> 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,

Kierownik projektu - dupa.

nieaktualna,

j.w.

> a koszt jej utrzymania przewyższa korzyści jakie przynosi.

To nie jest prawdą. Koszt utrzymania przy wykorzystaniu automatów
dokumentujących jest niewielki (zarówno czasowy jak i kwotowy). Tylko
trzeba mieć dobry i sumienny zespół który wie co robi.

> W skrócie - niepotrzebna.

To już bujda na resorach. Jeśli nigdy nie była Ci potrzebna, to masz
szczęście.

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

Ktoś kto siedzi rok w projekcie razem z kilkoma innymi programistami ma
prawo nie pamiętać implementacji wszystkiego co zrobił na początku, lub
tym bardziej co ktoś inny zrobił.

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

Teoria... piękna. W praktyce to tak nie działa.

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

Tylko że to powstaje na ich podstawie. Z ogólnych bajek zleceniodawcy
oprogramowanie się nie zmaterializuje. A i umowę wypadałoby podpisać na
coś konkretnego, a nie na wyimaginowaną możliwość otrzymania być może
czegoś co potrzebuje w bliżej nieokreślonym terminie.

>> 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 bo ja wiem, nie spotkałem się jeszcze z dużym projektem tworzonym w
całości z uwzględnieniem Agile. Częściowo tak, w całości nie. Ale może
pracuje w dziedzinach gdzie z założenia nie można sobie na to pozwolić.

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

To co opisujesz, to bardziej mi pasuje do starej definicji
prototypowania z ominięciem najważniejszej części, że prototypu nie
wdraża się produkcyjnie.

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

Nie rozumiem. Patrzę teraz z perspektywy przedsiębiorcy. Mnie interesuje
na kiedy mogę mieć produkt i ile za niego mam zapłacić. Średnio mnie
interesuje czy dostanę jakiś kawałek wcześniej czy później. Ważna jest
data wdrożenia całości.
Przykład z życia. Właśnie będą mi kłaść kostkę na posesji. Rozmawiałem z
kilkoma firmami i ważne dla mnie jest cena i termin wykonania. Jeśli
mieliby to robić 'agile' to po położeniu iluś metrów dopiero bym
sprawdzał czy dobrą kostkę kładą, czy kolor mi pasuje itd itp. Dostałbym
prototyp działający (no bo jest kostka, jest położona i można bo niej
chodzić). Szkoda tylko, że nie pasuje mi jej grubość, kolor i wzór. I
teraz to rozbierają i robią zgodnie z moimi sugestiami. Oczywiście po
drodze może się okazać że wzór nie do końca jest taki jak chciałem (tzn
początek był dobry, ale rozwinięcie złe). Następna poprawka, a płace im
od metra. Po położeniu okazało się że nie zrobili odwodnień, bo myśleli
że ich nie potrzebuje i znowu poprawka.
W tym momencie pomimo że mam 350m2 kostki do położenia zapłacę im za
położenie jakiegoś 1tyś m2.
A wystarczyło zrobić na początku analizę, spytać co po tym będzie
jeździć, zaproponować wzór, kolor itd itp. Jeden projekt, jedno
wykonanie i płaca za faktyczny metraż i brak straconego czasu.
I tylko pozornie nie ma to związku z tworzeniem oprogramowania.


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

To całkiem inna bajka. Jeśli ktoś choć raz pisał projekt wewnętrzny to
dobrze o tym wie.

> Powieem ci tak: mylisz się.

No to moment, macie tych analityków i projektantów w zespole czy nie?

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

Żartujesz chyba, przez tyle lat się sprawdzał i nagle przestał? Fakt mam
specyficzną branżę, wymagającą dużego nadzoru i certyfikowania
oprogramowania. I jedno powiem, jeśli chcesz mieć oprogramowanie
certyfikowane, to nie przejdzie brak projektu, analizy czy dokumentacji
kodu.

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

Ale komunikacja zawsze jest istotna. Tyle że analityk musi znać zarówno
specyfikę branży dla której pisze się oprogramowanie, jak i możliwości
zespołu. Z mojej strony mogę jedynie zauważyć, że o ile modyfikacja
wymagań (z zasady ich doprecyzowanie) ma miejsce, jednak wyłapywane to
jest na etapie tworzenia projektu aplikacji a nie w fazie kodowania.
Zmiany w fazie projektowania są dużo mniej kosztowne niż w fazie kodowania.

pozdrawiam,
Przemek O.