W dniu 2011-05-19 18:13, Andrzej Jarzabek pisze:

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

Nie odnoszę się do tego co Ty znasz, bo ja tego nie znam. Ale jeśli ktoś
nie dopilnowuje projektu w jednym miejscu to jaką masz pewność że w
innych to robi (np. kod czy testowanie)?

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

Na czym te twierdzenia opierasz? Ja ze swojej praktyki ma dokładnie
odmienne doświadczenia. Utrzymywanie niekompletnej dokumentacji jest
stratą pieniędzy, bo i tak nie jest użyteczna. Utrzymywanie dokładnej
nie jest wcale mocno zasobożerne, a jest jedynie kwestią dobrej
organizacji pracy.

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

Tia, i jak już będzie trzeba go ruszyć, to stracisz kilka dni na
przekopanie kodu (zakładając że to będzie duży moduł) a w dokumentacji
odpowiednie miejsca znajdziesz w kilka chwil.

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

A widzisz. Mając wszystkie i kompletne wymagania nie mam takiej potrzeby.

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

??? Co? Rozumiem że przez to skrócisz kod skomplikowanej procedury. Aha.
Czyli stosowanie standardów i refaktoryzacja automagicznie każdy problem
sprowadza do postaci a = a+1

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

I niby po niej zaczynasz od razu klepać kod?

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

MS Office 1.0 nie był prototypem. Mylisz fazy cyklu wytworzenia
aplikacji z cyklem rozwoju aplikacji.

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

To że Ty nie potrafisz oszacować czasu trwania i kosztu wytworzenia
aplikacji, nie znaczy że nie ma osób które to potrafią. ROI (czy
cokolwiek innego dającego podobne informacje) nie jest fikcją bo na tym
się opiera biznes, a nie na zapewnieniach że coś kiedyś może, lub
ewentualnie część trochę szybciej, bo z czymś tam mamy problem, bo
czegoś tam niedoszacowaliśmy, bo czegoś nie potrafimy wykonać itd itp.

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

Po pierwsze, jeśli nie dogadujemy się to nie robimy interesu. Jest
wolność zawierania umów. Można ale nie trzeba.
Druga sprawa wartość odszkodowania najczęściej nie przekracza wartości
projektu (przynajmniej nie spotkałem się z tym). Tzw. utracone korzyści
bardzo trudno udowodnić. Żaden szanujący się przedsiębiorca też nie
będzie urządzał szopki z odszkodowaniem wyższym od wartości projektu.
Takie kwiatki szybko się rozchodzą w środowisku i może się okazać, że
nikt nie będzie chciał dla niego robić tego projektu.
I ostatnia sprawa, oprogramowanie najczęściej zamawia się w celu
usprawnienia istniejących procesów. Wychodząc z tego założenia,
niedostarczenie go nie może powodować strat większych niż ewentualna
wartość projektu i ewentualna strata czasu.

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

Jeśli ma doświadczenie to potrafi to ustalić. Jak nie potrafi to znaczy
że nie ma.

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

Istnieje coś takiego jak referencje, i często są one wymagane.

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

Tylko koniec końców, ja skończyłem całość w 16 miesięcy, a oni w 18 bo
musieli dodatkowo przy każdym wydaniu doliczyć czas i koszt jego wydania
w używalnym stanie. Koniec końców jestem i szybszy i tańszy.

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

Pewnie, wszystko można spierniczyć, ale bez projektu jest to
zdecydowanie prostsze.

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

Mieszasz pojęcia. Wiarygodne daliby tylko Ci którzy już znajdowali lub
obalali ową hipotezę.
Ja Ci nie nie dam żadnej propozycji bo się na tym nie znam i jakby nie
sprawdził w google to bym nawet nie wiedział czy mnie przypadkiem nie
obrażasz :)
Natomiast jeśli miałbym Ci oszacować czas i koszt projektu z mojej
dziedziny w którym mam doświadczenie (czytaj już coś takiego robiłem) to
jestem w stanie tego dokonać z bardzo dużą precyzją.

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

Dobrze, gdybanie jest ma poziomie spekulacji o rozwoju itp. Na jego
podstawie nie są podejmowane decyzje. Jeśli znasz spółki giełdowe które
tak działają, to podaj ich nazwy, będę wiedział jakich akcji nie kupować.

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

Porównujesz czasu boomu komputerowego, gdzie komputery się robiło w
garażu. Poczytaj o historiach powstania kilku modeli, oni nie robili ich
z chęcią sprzedaży, ale dla siebie samych, a że zapotrzebowanie rynku w
danym momencie było na to ogromne, to odnieśli sukces także rynkowy.

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

Tablet jest trochę czymś innym niż iPad. Poza tym Apple ma fantastyczny
marketing i grupę oddanych fanów którzy by nawet kupili kibel jeśli by
miał logo nadgryzionego jabłka. Bo jak wytłumaczyć chęć kupienia czegoś
co jest technologicznie gorsze od odpowiedników i jednocześnie raz
droższe???

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

Z każdym następnym projektem lepiej.

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

Hmm... Analiza projektowa/ wymagań jest najczęściej płatna oddzielnie,
niezależnie od podpisania umowy na wytworzenie oprogramowania. Ja
przynajmniej nigdy nie miałem inaczej.

pozdrawiam,
Przemek O.