eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingpl. usenet o agileRe: pl. usenet o agile
  • Data: 2013-07-21 20:17:10
    Temat: Re: pl. usenet o agile
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 21/07/2013 10:54, slawek wrote:
    > Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
    > dyskusyjnych:ksfevv$9th$...@s...invalid...
    >
    >> Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy
    >> w ogóle się na to nie zgodzą, bo do budowania systemów używają
    >> istniejącego wcześniej kodu, który jest objęty tajemnicą handlową.
    >
    > No popatrz - cały Linux jest open source - i jak najbardziej nadaje się
    > do wielu rzeczy, choć przecież jest darmowy.

    Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
    systemu CRM, księgowości czy payroll?

    > Więc dywagacje "drożej-taniej" są równie dobre jak wróżenie z fusów. Czy
    > 10x tyle to drożej? A czy lepiej kupić coś, co posłuży 10 lat, czy
    > system na 1 rok? Możemy gdybać, możemy snuć różnego rodzaju domysły...
    > ale bez konkretów to do sensownych wniosków nie dojdziemy.

    Powiem w ten sposób - mam wiele lat przepracowanych w dużych firmach (a
    więc takich, które ewentualnie można pozwać na te miliony i mieć
    nadzieję je dostać) robiące oprogramowanie dla dużych firm (które stać
    na zakup oprogramowania za miliony). I te firmy nie oferowały klientom
    kodu źródłowego swoich produktów.

    >> z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie
    >> kodu źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji
    >
    > Dlaczego jedynie "kodu źródłowego"? Jest dokumentacja,

    O ile jest, znaczy pewnie jest 'end user documentation' do programu, ale
    czy jest dokumentacja opisująca architekturę systemu i projekt kodu to
    osobna kwestia. A nawet jeśli jest, bo taka dokumentacja jest wymogiem
    umowy, to kolejne pytanie ile taka dokumentacja jest warta w momencie
    kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
    najtrudniej było z niej skorzystać.

    > kod źródłowy też
    > nie śmieciowy, ale spełniający określone standardy itd.

    Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które
    by można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.

    > Oczywiście,
    > wymaga to wszystko IQ rzędu 130 i być może znajomości jakiegoś języka
    > programowania, ale to nie są wyśrubowane wymagania w XXI wieku.

    Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
    wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten,
    co je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego
    czasu. Na podstawiee tych obserwacji uważam, że jest to trudne,
    czasochłonne, kosztowne i ryzykowne - efektywne zapoznanie się z cudzym
    kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny
    z napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja
    zapewne mam niskie IQ (nie mierzyłem, to nie wiem), ale moim
    niewątpliwie inteligentnym kolegom również sprawiało to problemy.

    > Odwrotnie - zgadzanie się na closed source i nie wnikanie "co jest w
    > środku" prowadzi do uzależnienia od określonej zewnętrznej firmy. Jeżeli
    > ta firma opiera się na jakimś geniuszu, który akurat postanowił sobie
    > umrzeć, to wali się wszystko niczym klocki domina. Takie rzeczy były już
    > przerabiane przez branżę.

    Naprawdę? Gdzie/kiedy?

    Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale
    też zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają,
    albo proponują wyższe ceny.

    Weź więc pod uwagę w naszym scenariuszu, że masz nieprzekraczalny budżet
    na system w kwocie czterech milionów. I masz jednego dostawcę, który
    oferuje umowę na system bez źródeł za dwa miliony, i drugiego, który
    daje źródła, ale za cztery miliony. Którego wybierzesz? Przecież jeśli
    się okaże, że system wymaga zmian w specyfikacji, żeby go wdrożyć, to co
    z tego, że będziesz mógł poszukać innego dostawcy które ci te zmiany
    zaimplementuje, skoro już nie będziesz miał czym zapłacić? A nawet jak
    ci jeszcze rtrochę zostanie, to nikt ci niezrobi tej modyfikacji za
    grosze, bo wejście w cudzy codebase to duża inwestycja upfront.

    >> wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
    >> zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek
    >
    > Takich wykonawców eliminuje się już na początku.

    Na jakiej podstawie?

    > Wykonawcy musi zależeć

    A skąd wiesz, komu zależy? Do umowy przecież tego nie wpiszesz.

    > i musi trzymać się standardów,

    Jakich standardów?

    > a to co robi musi być "łatwe do zrozumienia" przynajmniej przez fachowców.

    Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?

    >> Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest
    >> tak zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów.
    >> Dalsze
    >
    > Ba! Życie to ciężkie jest, a życie programisty szczególnie: nie każdy
    > może pić drinki z palemką jak AL czy Knuth.

    Nie rozumiem w jaki sposób taka konstatacja niweluje fakt, że wiele
    specyfikacji zawiera błędy.

    >> Drugi powód jest taki, że język naturalny nie jest wystarczająco
    >> precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym
    >
    > Jeżeli - jako programista - nie potrafisz opisać wymagań - to nie
    > potrafisz - także jako programista - napisać programu. ;)

    Przecież gdyby zamawiający miał na etacie programistów potrafiących
    napisać ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.

    >> według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co
    >> go mam na majątku firmy, a z oszczędności zakupię kolejnego laptopa i
    >> użyję go jako kapitału założycielskiego kolejnej spółki z oo.
    >
    > Zbankrutujesz... zdarza się. Ale twoja wiarygodność jako partnera w
    > biznesie będzie równa zero, jeżeli nie ujemna. Dlatego na tym laptopie
    > będziesz mógł ewentualnie pograć w Sapera.

    E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś
    działają, często z większym powodzeniem niż poprzednio.

    >> stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
    >> jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub
    >> większe straty - nie wiadomo jakie, ale można oszacować
    >> prawdopodobieństwo, że będą np. w przedziale 100-150 tys. I kwestia jest
    >
    > To po co się przejmować? Koszt wprowadzenia poprawki to 250 000 euro,
    > bez poprawki straty wynoszą 150 000 euro.

    Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
    przesłanek. W rzeczywistości mogą być dużo wyższe.

    > Nie wprowadzenie poprawki daje
    > +100 000 euro. Wprowadzenie poprawki daje -100 000 euro oraz brak
    > pewności, że to przyniesie spodziewane rezultaty i zakończy się
    > wydatkiem jedynie tych 100 000 euro. Właśnie odkryliśmy czym jest
    > konserwatyzm liberalny.

    Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
    oparta była na szacowanych zyskach czy oszczędnościach z użycia tego
    systemu, wysokości powiedzmy pół miliona rocznie. To, że źle umieszczony
    przycisk generuje rocznie 100 tysięcy strat powoduje, że korzyści z
    oprogramowania są niższe niż oczekiwane. Znajdź cztery podobne problemy
    i okaże się, że system za dwa miliony przynosi tyle samo strat, co
    korzyści - równie dobrze możnabyuło tymi dwoma milionami napalić w piecu.

    Co gorsza, ponieważ mówimy nie o pewnych zdarzeniach, tylko o ryzyku, to
    może być tak, że wymieniasz pewny i stały koszt na ruletkę. Regularne
    tracenie 100 tysięcy rocznie obniża twoją rentowność, ale można
    przewidzieć i zarządzać firmą tak, żeby działała mimo tego. Losowy
    problem narażający cię na losowe straty o wartości oczekiwanej 100
    tysięcy może działać tak, że w pierwszym roku nie będzie żadnych strat,
    w drugim żadnych, a w trzecim będzie pięć milionów, przez co firma
    zbankrutuje i cała zabawa się zakończy.

    W kmońcu problem klienta jest taki, że to, że cena zmiany wynosi 250
    tysięcy, i wynikające z tego straty 100 tysięcy rocznie, są konsekwencją
    złych wyborów samego zamawiającego, a w szczególności błędnego
    przekonania, że kontrakt fixed price fixed scope jest dla niego
    korzystniejszy.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: