On May 18, 8:37 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-17 23:20, 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.
[...]
> j.w.

Może i tak, ale ostatecznie produkt idzie do produkcji i zarabia dla
firmy pieniądze, so he must be doing something right.

> > a koszt jej utrzymania przewyższa korzyści jakie przynosi.
>
> To nie jest prawdą.

Przynajmniej w niektórych przypadkach jest to 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.

Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).
Czy ta wartość równoważy overhead, nie mam na ten temat zdania, ale
zdecydowanie uważam, że nie robi to większej różnicy.

Z drugiej strony nie jestem tez przekonany, czy automatyczne
generowanie dokumentacji jest jakoś sprzeczne z agile.

> > W skrócie - niepotrzebna.
>
> To już bujda na resorach. Jeśli nigdy nie była Ci potrzebna, to masz
> szczęście.

Byłaby potrzebna, gdyby była kompletna i aktualna. W takiej postaci
jak była, to pożytki korzystania z niej były równoważone przez szkody
- sumaryczna wartość zerowa, a koszt tworzenia i utrzymywania jednak
niezerowy.

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

Ale jednak większość implementacji będzie pamiętał, bo regularnie
wchodzi w nią debuggerem, refaktoryzuje itd. Pytanie, czy overhead
związany z utrzymywaniem aktualnej i szczegółowej dokumentacji przez
cały czas równoważy to, że raz na rok komuś ta dokumentacja się przyda
żeby trochę szybciej zrozumieć jakiś rzadko używany kawałek kodu. I
jak na tę odpowiedź wpływa stosowanie np. rygorystycznych coding
standards, które zabraniają pisania kodu tak, żeby trudno go było
czytać.

Moje zdanie jest takie, że dla większości kodu da się go napisać tak,
żeby intencja była jasna i w tkaich przypadkach dokumentacja ma
niewielką wartość, a jej tworzenie jest stratą czasu. Są też
przypadki, gdzie problem jest nieredukowalny i kod będzie z
konieczności trudny do zrozumienia dla kogoś, kto nie siedzi w
problemie i nie zna koncepcji danego rozwiązania. I w takich
przypadkach dokumentację jak najbardziej należy tworzyć. Wydaje mi
się, że takie podejście nie jest sprzeczne z agile tak jak ja tę
koncepcję rozumiem.

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

Dobrze, w takim razie, i pytam o to bez żadnej szydery, proszę
opowiedz o swoich doświadczeniach, jak to działa w praktyce w
kolokalizowanych zespołach praktykujących coding standards, shared
ownership, daily standup i najlepiej jeszcze pair programming (albo
przynajmniej code review).

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

Ja mówię, że design phase to jest osobny problem. Nawet jeśli masz
zformalizowane, udokumentowane i zakontraktowane wymagania, to możesz
pominąć design phase i od razu zabrać się za kodowanie.

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

A ja się spotkałem (nie z bardzo bliska co prawda). Tzn. oczywiście w
aspekatch, które były objęte 'scope' danej metodologii.

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

Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
kolejne wersje.

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

Nieprawda. Jako przedsiębiorcę, interesuje cię, czy zarobisz na tym
oprogramowaniu i ile.

Jeśli dochodzisz do wniosku, że potrzebujesz jakiegoś programu do
zarabiania, i określasz zespół ficzerów jaki ten program (jak ci się
wydaje) powinien mieć, to zawsze musisz brać pod uwagę taki
scenariusz, że jeden kontrahent powie, że zajmie to trzy lata, drugi
zażyczy sobie 150 milionów dolarów, a trzeci powie że zrobi w 12
miesięcy, ale nie zgodzi się na takie kary za opóźnienie, jakbyś
chciał (w praktyce pozostawiając sobie furtkę do nawet znacznych
opóźnień).

W końcu bierzesz tego trzeciego, umawiasz się na 18 miesięcy i
czekasz. Po 9 miesiącach twój konkurent zaczyna eksploatację swojego
programu, który ma 1/3 ficzerów zamówionych przez ciebie, ale już
pozwala mu zarabiać. Zarobione pieniądze idą między innymi na
finansowanie dalszego dewelopmentu, i brakujące ficzery stopniowo
pojawiają się w programie konkurencji w wersjach 1.1, 1.2, 1.3. Po 18
miesiącach twój wykonawca ci mówi, że niestety nie ma jeszcze dla
ciebie zamówionego programu, bo wystąpiły obiektywne problemy z
implementacją niektórych ficzerów, ale że za dwa miesiące już będzie.
Na otarcie łez dostajesz symboliczną karę. Po kolejnych dwóch
miesiącach kontrahent mówi, że beta testing wyłapał poważny problem i
potrzebuje jeszcze miesiąc. W międzyczasie świat się zmienia, bo
regulator wprowadził nowe przepisy, albo tąpnął rynek metali
nieżelaznych, albo ktoś wymyślił nowy rodzaj kauczuku i okazuje się,
że połowa ficzerów, które wpisałeś w kontrakt jest ci niepotrzebnych,
a za to przydałoby się kilka nowych ficzerów. Idziesz z tym do swojego
wykonawcy a on na to, że tak, owszem, da się zrobić, możemy
renegocjować kontrakt.

> Przykład z życia. Właśnie będą mi kłaść kostkę na posesji. Rozmawiałem z

O kurcze, w tym momencie przebiłes o kilka długości wszystkie
idiotyczne metafory i analogie jakie pojawiły się w tej dyskusji.

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

I tylko pozornie nie ma związku z dowodzeniem Wielkiego Twierdzenia
Fermata.

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

Jeszcze uściślę, nie chodzi mi o projekt wewnętrzny w sensie "jest
używany przez firmę a nie klientów", tylko "jest zamawiany przez
kierownictwo firmy, a nie przez klienta". W odróżnieniu od sytuacji,
kiedy przychodzi klient do firmy i mówi "chcę to a to", sytuacja kiedy
ktoś w firmie wychodzi z inicjatywą "gdybyśmy zrobili program, który
robi to-a-to, to może udałoby się to komuś sprzedać". I ja w takim
sensie pracuję głównie przy projektach wewnętrznych, i wtedy myślenie
jest takie, że jeśli można zacząć sprzedawać program z okrojoną
funkcjonalnością za 6 miesięcy, a potem dodawać ficzery w kolejnych
wersjach, albo można zażądać pełnego zestawu ficzerów i czekać 18
miesięcy na wersję 1.0, to to pierwsze rozwiązanie ma duży sens
biznesowy.

> > Powiem ci tak: mylisz się.
>
> No to moment, macie tych analityków i projektantów w zespole czy nie?

Mamy.

> > 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ł?

Nigdy się nie sprawdzał.

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

Wiesz, to jest oczywiste, że jak potrzebujesz certyfikacji, to
spełniasz wymogi certyfikacji niezależne od tego, czy one mają poza
tym sens, czy nie.

Tak z ciekawości, ta certyfikacja polega też na tym, że certyfikują
wam cały proces, tzn. muszą być jakieś konkretne fazy zbierania
wymagań, analizy, designu itd. z datami rozpoczęcia i zakończenia, czy
tylko wymagają artefaktów? Bo przecież to, o czym ja piszę, nie
wyklucza wcale istnienia projektu, analizy i dokumentacji kodu w
momencie zakończenia projektu.

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

To ja powiem tak: może w waszej specyficznej branży się sprawdza, ale
poza nią to jest piękna teoria, bo w fazie projektowania klient czy
domain expert przeczyta dokument, popatrzy na schemat i powie "tak,
tak to właśnie ma działać", a jak mu pokażesz wersję alfa, to powie
"nie, zuepłnie nie o to chodziło", "jeśli nie ma tej informacji, to ta
funkcja jest bezużyteczna", "owszem, w dokumencie tego nie ma, ale to
oczywiste". I okazuje się, że musisz wyrzucić połowę kodu i 3/4
projektu.