On 19/05/2011 18:46, Przemek O. wrote:
> 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)?

Zależy, jak rozumiesz "pewność". W praktyce wygląda to tak, że się
ustala priorytety i ma proces opary na tych priorytetach. Kompletna i
aktualna dokumentacja nie jest priorytetem, bo nie jest wymagana do
dostarczenia (kolejnej) funkcjonalnej wersji programu.

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

Na doświadczeniu. Nie przeczę, że inne doświadczenia mogą być inne mówię
tylko, że rozumiem, skąd się wzięły takie koncepcje, bo moje własne
doświadczenia to potwierdzają.

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

No i moja perspektywa jest taka: jakbym miał utrzymywać dokładną i
kompletną dokumentację tego, co koduję, to zajęłoby to dwa razy tyle
czasu co tworzenie kodu.

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

No to powiem tylko tyle, że to jest symptom źle napisanego kodu. I nie
przeczę, źle napisany kod się zdarza, ale można się zastanowić, czy
lepiej włożyć wysiłek w dokumentowanie źle napisanego kodu, czy w
unikanie sytuacji, że źle napisany kod w ogóle powstaje i jest
wprowadzany do produkcji.

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

Lucky you.

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

Spowoduje to, że kod funkcji wyraża to, co wyrażałaby specyfikacja.
Czyli jeśli specyfikacja mówi, że foo(x) zwraca balmdorial od x dla x
większych od zera, sramdorial od x dla x mniejzych od zera, a dla x=0
zgłasza błąd, bo to nielegalna wartość, i taki opis jest potrzebny, bo
treść foo(x) to jakiś spaghetti code z którego nie wynika jasno i wprost
co powyżej, to znaczy, że ciało foo(x) jest napisane z naruszeniem
coding standards, bo powinno mieć sześć linijek, a brambdorial i
srambdorial powinny być oddelegowane do osobnych funkcji. I w ten
sposób, każdy, kto zna język programowania widzi jasno, że foo zwraca
brambdorial albo srambdorial albo zgłasza błąd że x jest zero, czyli
dokładnie to samo, co by wyczytał z dokumentacji.

Refaktoryzacja daje tyle, że jeśli jednak się zdarzy, że nie będzie to
jasne, to zdarzy się to tylko raz.

>> O takiej instytucji jak business lunch słyszałeś?
>
> I niby po niej zaczynasz od razu klepać kod?

Być może, zależy od okoliczności.

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

Nie mylę, tylko zwraqcam uwagę na wieloznaczność pojęcia "częściowa
funkcjonalność". Funkcjonalność jest częściowa lub nie częściowa
względem czegoś, co arbitralnie uznajesz za kompletną funkcjonalnośc.
Jeśli przyjmiesz Office 2010 zqa kompletną funkcjonalność pakietu
biurowego, to Office 1.0 ma funkcjonalność częściową.

A release w metodologii agilee też powstaje w cyklu rozwoju, w którym ma
funkcjonalność zaplanowaną na ten release.

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

Ale też dogadanie się może polegać na tym, że wykonawca mówi, że spytał
swoich najlepszych ludzi, i oni mówią, że tak w ogóle program robiący
to, co zleceniodawca chce, żeby robił, jest wykonalny i że się da zrobić
w mniej więcej takim czasie, więc możemy razem zaryzykować, gdzie
zarówno wykonawca jak i zleceniodawca mają pełną widoczność tego, co się
dzieje i jak się ustala priorytety dla dalszej pracyi ewentualnie jakie
są problemy.

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

Przecież nie chodzi o to, że trzeba udowodnić, tylko że zleceniodawca
przewiduje takie straty, więc nalega na wpisanie ich do umowy. Tak jak
piszesz, w praktyce to się nie dzieje, ale to dlatego, że w praktyce
zleceniodawca zwykle bierze część ryzyka na siebie i ewentualnie ponosi
część kosztów opóźnień bądź wycofania się z 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.

To bzdurne założenie: jeśli wchodzisz w biznes tworzenia nowego
oprogramowania, to ponosisz ryzyko choćby spowodowane związaniem
kapitału, nie mówiąc już o innych działaniach, które podejmujesz w
związku z tym co spowodowało potrzebę nowego oprogramowania (np.
ekspansja firmy) i czynniki zewnętrzne (potrzebujesz nowe
oprogramowanie, żeby dalej robić to, co robisz).

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

Ogólnie to nieprawda, chociaż nie będę się kłócił, że być może w twojej
branży tak właśnie jest.

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

No i co z tego, referencje niekoniecznie powiedzą ci takie rzeczy. To,
że klient jest zadowolony nie jest jednoznaczne z tym, że dostał
dokładnie to, czego sobie na początku zażyczył. Jeśli nie dostał
dokładnie tego, ale na wskutek uzgodnień dostał i tak coś, na czym
zarobił kupę szmalu, to i tak może być zadowolony. Problem masz taki, że
z twoim podejściem możesz mieć skrajnie odmienne customer experience niż
ten, kto wystawia refenrecje.

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

Tylko koniec końców klient konkurencji miał większe korzyści, bo przez
te 9 miesięcy zarobił więcej kasy, niż ty przez swoje dwa.

Poza tym właśnie jest cała dziedzina agile zajmujące się tym, żeby
zmininalizować overhead związany z releasem. Po to masz np. continuous
integration, automatyzację testów, single code base, Ten-minute build,
krótkie iteracje, stakeholder demo itd.

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

Nie zgodzę się.

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

No i tak samo wiarygodne estymaty czasu i budżetu programu z danym
zestawem wymagań dadzą ci tylko ci, którzy robili program z dokładnie
takim samym zestawem wymagań.

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

No więc ciesz się, że masz taką dziedzinę. Ludzie siedzą w dziedzinie
hipotezy Riemanna od lat i daliby wiele za wiarygodną metodę mówiącą ile
czasu i ilu matematyków potrzeba do rozstrzygnięcia tej hipotezy.
Niestety okazuje się, że nawet 50 lat analizowania tej hipotezy przez
najlepszych specjalistów w tej dziedzinie nie przyniosło takich rezultatów.

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

Znałem spółkę akcyjną, która tak robiła niecały rok temu. Nie wiem jak
teraz robi, ale w międzyczasie jej akcje poszły do góry o prawie 30
procent. Publicznie nie będę podawał nazwy, ale jeśli bardzo chcesz, to
napisz na priva.

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

Za przeproszeniem pieprzysz bzdury. Przedstawicielstwo Apple zostało
zaproszone do siedziby Xerox PARC w ramach przygotowań do IPO.

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

To ty sobie poczytaj o tym, co robiło Apple w momencie, kiedy im
pokazano Xerox PARC Alto. I wytłumacz mi, jak to się mogło stać, że
Xerox, w końcu poważna spółka akcyjna, zainicjowała i przeprowadziła
development nowego projektu nigdy nie zdając sobie sprawy, że siedzą na
żyle złota. Czyżby nie potrafili wykonać prostej analizu potrzeb rynku?

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

Jakich odpowiedników? Mówisz o tabletowych pecetach, które były na rynku
przed iPadem, czy wchodzącej narynek fali tabletów imitujących iPada?

> i jednocześnie raz droższe???

Bardzo prosto. Apple po prostu zrobiło analizę potrzeb rynku, na co nikt
inny nie wpadł, zapewne dlatego, że firmy próbujące wprowadzać wcześniej
tablet PC są kiepsko zarządzane.

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

To może u was w firmie, bo jeśli chodzi o całość branży to nie jest tak
fajnie, czego efektem modele iteracyjne i również agile.

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

Ale to tylko przenosi ryzyko na zleceniodawce. Zleceniodawca szuka więc
wykonawcy do programu, który mu jest potrzebny, więc robi analizę u
pierwszego wykonawcy i dostaje cenę nie do przyjęcia, robi u drugiego
wykonawcy i dostaje termin nie do przyjęcia, robi u trzeciego i dostaje
propozycję kar za opóźnienie nie do przyjęcia, robi u czwartego i
czwarty proponuje formy konktraktów nie dające odpowiednich gwarancji.
Stwierdza więc, że nie chce jednak zamawiać tego programu, a tymczasem
stracił już x milionów na te wszystkie analizy.