W dniu 2011-05-19 12:02, Andrzej Jarzabek pisze:

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

Zakładając ze go po drodze nie położy. Ale mniejsza z tym.

> Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
> też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).

Nie chodzi o poleganie na automatycznie generowanej dokumentacji, ale o
wspomaganie się automatami w procesie jej powstawania.

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

To już jest zadaniem prowadzącego projekt wymóc aby dokumentacja była
kompletna i aktualna.

> Ale jednak większość implementacji będzie pamiętał,

A niby czemu? Jak czegoś nie dotykasz przez rok, to naturalne jest że
zapomnisz szczegóły.

> bo regularnie
> wchodzi w nią debuggerem, refaktoryzuje itd. Pytanie, czy overhead

Po kiego grzyba? Moduł zakończony i się go nie tyka bez potrzeby, a już
na pewno nie debuguje się go przy okazji innych zadań tylko
korzystających z niego.

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

Tyko, że czasami żeby sprawdzić co będzie wynikiem danej funkcji trzeba
prześledzić tonę kodu, a w dokumentacji jest to opisane łącznie z wyjątkami.
To nie jest tak, że dokumentacja się nie przydaje bo jej nigdy nie
potrzebowałeś.

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

Ale co Ci mam powiedzieć, że już wiele razy dokumentacja przyspieszyła
proces tworzenia? Nie wiem, nie mam innych doświadczeń, ale mogę sobie
jedynie wyobrazić efekt jej braku w projektach. Poza tym, nie jestem
pewien czy koszt wytworzenia dobrej dokumentacji jest wyższy niż
przypadku pair programming.

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

Chyba nie ma sensu dalej ciągnąć tej dyskusji. Ja tak nie uważam. Co
więcej uważam takie podejście za nieodpowiedzialne. Równie dobrze można
się umówić z klientem na piwo i na podstawie pogawędek zacząć pisać program.

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

Tylko że release ma pełną funkcjonalność, a prototyp częściową. I to
jest różnica.

>> 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 została podjęta decyzja o zamówieniu oprogramowania, to była
poprzedzona analizą ROI lub czymś podobnym. Więc aspekt zarobku jest
ważny ale tylko w korelacji z czasem i kosztem wykonania.

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

Co za mętny wywód. Po pierwsze nie wziąłbym trzeciego wykonawcy, bo
targowanie się o ewentualne kary prowadzi do wniosku, że
najprawdopodobniej zaistnieje sytuacja że będą one wymagane. I dalszy
wywód nie ma już sensu. Wybrałbym tego który ma doświadczenie poparte
działającymi wdrożeniami.
Poza konkurent po 9 miesiącach ma raczej wersję 0.1 niż 1 :) I na koniec
okazuje się, że program robi poważne błędy w obliczaniu VAT bo nie było
beta testingu i przedsiębiorca dostaje kare z US i na drzwiach firmy
zakłada kłódkę.
Wiesz co? Bajki można układać dowolnie żeby potwierdzić swoją rację.

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

Guzik przebiłem. Nie chcesz zrozumieć podstawy że bez określenia wymagań
i projektu można spierniczyć dokładnie wszystko. Nie odnosi się to tylko
do oprogramowania. A takie spierniczenie na pierwszym etapie skutkuje
kilka razy wyższą ceną i dłuższym terminem wykonania. Bo komuś nie
chciało się kilku dni na początku poświęcić na projekt.

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

Przecież to Ty starasz się dowieść że płaci się za czas produkcji a nie
jej efekt?

> 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

Gdzie ty masz taką firmę? Zamiast gdybania robi się analizę potrzeb
rynku i na tej podstawie rozpoczyna się myślenie o projekcie.

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

Zakładając że program z okrojoną funkcjonalnością jest zamkniętą
kompletną całością to się zgodzę.
Natomiast jeśli zamawiam np. program księgowy to co mi po okrojonej
funkcjonalności np. księgowania tylko kosztów a nie zakupów (które będą
w następnej wersji), skoro i tak resztę będę musiał robić ręcznie?
Wszystko zależy od tego, co mamy na myśli pisząc "okrojona" funkcjonalność.

> Nigdy się nie sprawdzał.

Aha, a programy to tej pory to w kapuście się znajdowało? :/

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

Wiesz co? Chyba naprawdę czas zakończyć tę dyskusje. To bez sensu.
Pewnie jak się ktoś uprze to można robić i analizę założeń po
zakończeniu projektu. Wszystko można, jak ktoś sobie lubi utrudniać zadanie.

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

Naprawdę koniec dyskusji. Jakby tak było to analityk / projektant olali
sprawę. Byłyby wyciągnięte konsekwencje, a firma poniosłaby stratę.
Natomiast byłaby mądrzejsza o te doświadczenia przy następnym projekcie.
Analityk ma dociec co klient naprawdę chce, a nie doprowadzić żeby ten
tylko powiedział że o to mu chodzi.

pozdrawiam,
Przemek O.