On May 19, 12:00 pm, "Przemek O." <p...@o...eu> wrote:
> 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.

No więc ja przecież mówię o konkretnych projektach (nie agile
bynajmniej), w których pracowałem: według twojego rozumienia źle
zarządzane, ale jednak produkujące dobrej jakości soft, za który
klienci płacili i który zarabiał dla firmy kokosy (i na ile się
orientuję dalej zarabia).

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

Tak czy inaczej, im więcej trzeba ręcznie przy tym dłubać, tym więcej
trzeba ręcznie przy tym dłubać.

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

No ale nie była. A poza tym, że kompletna i aktualna byłaby _czasem_
potrzebna, to utrzymywanie kompletnej i aktualnej _cały czas_
pochłaniałoby wielokrotie więcej zasobów niż utrzymywanie
niekompletnej i nieaktualnej.

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

Po to masz shared code żeby nie było wiele takich obszarów. A jeśli
jest jakiś kawałek kodu, który jest ruszany raz na rok, to oszczędność
czasu na udokumentowaniu go też masz raz na rok.

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

Moje doświadczenie jest takie, że nowe wymagania powodują konieczność/
potrzebę rozbudowy i przebudowy istniejących modułów.

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

Czasem tak jest, ale agile/XP mówi, że lepszym sposobem na uniknięcie
tego są coding standards i refaktoryzacja.

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

No więc ja też nie wiem. Ale wydaje mi się, że czasem może być.

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

O takiej instytucji jak business lunch słyszałeś?

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

A jednak MS Office 1.0 nie miał pełnej funkcjonalności MS Office 2010.

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

Ale tylko w korelacji z rzeczywistym czasem i kosztem wykonania, a nie
fikcją usyskaną przez analizę ROI lub konsultację z astrologiem.

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

Na razie jeszcze nie ma mowy o targowaniu się, pytasz za ile zrobią,
oni robia analizę i przedstawiają propozycję ceny z uwzględnieniem kar
za opóźnienia. Patrząc na propozycję dochodzisz do wniosku, że jak
będzie opóźnienie, to kary nie zrekompensują ci strat i będziesz na
minusie. W tym momencie możesz się zacząć targować, ale czy naprawdę
spodziewasz się, że jakikolwiek wykonawca jak usłyszy "mogę zapłacić
$NUM, ale kara za opóźnienie musi wynosić $BIGNUM" miesięcznie - dla
dowolnie wielkiego $BIGNUM? Bo wiedzą, że jak zrobili solidną analizę,
to prawdopodobieństwo opóźnień jest infitezymalne?

> I dalszy
> wywód nie ma już sensu. Wybrałbym tego który ma doświadczenie poparte
> działającymi wdrożeniami.

A jeśli to właśnie ten trzeci?
Albo: jeśli ten, który ma doświadczenie poparte działającymi
wdrożeniami mówi, że nie da się ustalic scope, time and price i on by
wolał umowę negotiated scope albo time&materials?
Albo: ten z doświadczeniem co prawda ma działające wdrożenia, ale
nigdy jeszcze nie wdrożył w terminie produktu z pełną uzgodnioną
funkcjonalnością?

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

Beta testing był normalnie. Zdążyli w 9 miesięcy, bo scope jest
znacznie mniejszy niż w twoich wymaganiach.

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

Oczywiście. Ale z określeniem wymagań i projektem można tez
spierniczyć dokładnie wszystko, so no difference there.

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

No i popatrz, tyle lat była nagroda za udowodnienie/obalenie Wielkiego
Twierdzenia Fermata i jakoś nikt w tym czasie nie udowodnił. A
twierdzenie udowodniono dopiero po zniesieniu nagrody. I kto to
zrobił? Matematyk na uczelnianej pensji, którą by dostawał czy by
udowodnił, czy nie.

Teraz napisz szybko, jak proponujesz zrobić viability study i projekt
znalezienia dowodu (lub obalenia) Hipotezy Riemanna, które by
określały ilu matematyków potrzeba, w jakim terminie to zrobia i ile
to będzie kosztować. Zresztą myślę, że każda uczelnia, która ma
wydział matematyki zo doświadczeniem popartym wieloma udowodnionymi
twierdzeniami, da ci wiarygodne estymaty.

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

Czasem się jednak gdyba. Tak, w dużych firmach, spółkach akcyjnych,
dobrze sobie radzących, powstające w ten sposób produkty odnoszą
sukces, dostają nagrody, wnoszą wartość, podnoszą reputację firmy.

Jeśli chodzi o osobiście znane mi przykłady, to nie będę przytaczał,
ale z folkloru branży komputerowej to choćby Apple i pierwszy
Macintosh (i wcześniej Lisa).
Zresztą innych produktów to też dotyczy. I oczywiście tez mają z tego
powodu niewypały, jak Newton, ten wczesny aparat cyfrowy czy ostatnio
Apple TV, ale na tym polega biznes, że się ryzykuje. I jak się chce
być innowatorem, to trzeba ufać instynktom, bo inaczej jak to się
stało, że przez tyle lat nieudanych, nie odnoszących sukcesów
"komputerów typu tablet" nikt nie zrobił analizy potrzeb, a dopiero
ktoś w Apple wpadł na ten genialny pomysł, zrobił analizę i odkrył, że
świat potrzebuje iPada?

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

Ale o to cały czas mi chodziło przecież. Znaczy nie jest kompletną i
zamkniętą w tym sensie, że już nic się nie doda, ale jest kompletną w
sensie nadającą się do wykorzystania.

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

Odpowiem linkiem:
http://jamesshore.com/Articles/Business/Software%20P
rofitability%20Newsletter/Phased%20Releases.html

> > Nigdy się nie sprawdzał.
>
> Aha, a programy to tej pory to w kapuście się znajdowało? :/

Ej moment, ale waterfall miał nie tylko produkować programy, jego
wyróżniającą zaletą miało być to, że się z góry będzie dało
przewidzieć, ile program będzie kosztował i ile czasu zajmie
development. I jak tam z trafnością tych przewidywań?

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

Ano tak. A jeśli chce się ułatwić zadanie, to można analizę
przeprowadzać _w trakcie_ tworzenia projektu, na koniec tworząc
dokumentację wszystkiego, co zostało odkryte w ramach analizy, a
wymagany dokument opisujący projekt systemu można stworzyć po
zamknięciu kodu, mając wtedy pewność, że udokumentowany projekt
rzeczywiście odzwierciedla program, a jednocześnie unikając overheadu
dokumentowania elementów które ostatecznie wylatuja z produktu lub są
zmieniane.

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

Nie olali. Po prostu są ludźmi i się mylą.

> Byłyby wyciągnięte konsekwencje,

Jakie konsekwencje?

> a firma poniosłaby stratę.

My point exactly.
Tzn. oczywiście ostatecznie straty by ponieść nie musiała, bo po
wyrzuceniu 1/2 kodu i 3/4 projektu produkt mógłby nadal odnieść
sukces. Ale koszt jest duży i ryzyko znaczne.

> Natomiast byłaby mądrzejsza o te doświadczenia przy następnym projekcie.

No właśnie agile jest pewną próbą wyciągnięcia wniosków z takich
przypadków.

> Analityk ma dociec co klient naprawdę chce, a nie doprowadzić żeby ten
> tylko powiedział że o to mu chodzi.

No ale jednak nie wszystko się da stwierdzić przed podpisaniem umowy.
Zwłaszcza, że dopóki umowa nie jest podpisana, to wykonawca ponosi
ryzyko, że jednak nie zostanie podpisana i pensja analityka pójdzie w
błoto.