eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingilu jest programistow na swiecie?
Ilość wypowiedzi w tym wątku: 272

  • 191. Data: 2011-05-19 15:42:13
    Temat: Re: ilu jest programistow na swiecie?
    Od: "Przemek O." <p...@o...eu>

    W dniu 2011-05-19 16:53, Andrzej Jarzabek pisze:

    >> A jaki miałby w tym interes? Po pierwsze uświadamia klientowi dodatkowe
    >> potrzeby o których on nie pomyślał (lub były dla niego oczywiste i o
    >> nich nie wspomniał),
    >
    > I jaką korzyść z tego uświadomienia ma wykonawca?

    Taką że w połowie projektu nie musi renegocjować umowy, bo klientowi coś
    się przypomniało lub o czymś mu się zapomniało. Pół biedy jeśli skończy
    się tylko na renegocjacji a nie pociągnie to za sobą zmiany połowy
    wykonanego projektu. To chyba logiczne?

    > Niby w jaki sposób?

    Odpowiedź powyżej.

    > Albo i nie. Bo przecież z punktu widzenia zleceniodawcy zamawia on
    > ciągle ten sam produkt.

    Też pisze że możliwość, czyli można (jeśli są ku temu powodu) ale nie
    trzeba. Wszystko musi mieć swoje uzasadnienie.

    > No to jak ci napiszę, jak można na to patrzeć, żeby to nie było w
    > interesie wykonawcy: nie uwzględnienie istotnych rzeczywistych wymagań
    > w umowie daje wykonawcy kartę przetargową w scope negotiations. Jeśli
    > np. w umowie zawarty jest bdziąbągator, a w trakcie prac okazuje się,
    > że wykonanie działającego bżdziągąbatora jest bardzo trudne,
    > czasochłonne i kosztowne, a z drugiej strony wiadomo, że bez

    To żaden porządny developer nie wziąłby zlecenia którego nie jest w
    stanie wykonać, a już na pewno nie dałby terminów lub kosztów poniżej
    faktycznie potrzebnych.

    > powiedzieć "bździągąbator jest w umowie, dostarczacie w terminie albo
    > płacicie kary". I teraz jeśli w umowie nie ma błota, to wykonawca mówi

    No logiczne, czemu miałoby być inaczej. W interesie zleceniobiorcy jest
    podawać realne terminy.

    > "ok, dostarczymy traktor z bździągąbatorem, ale za to nie jeżdżący po
    > błocie".

    Jeśli tego nie ma w umowie, to to wspominanie jest bez sensu. A jeśli na
    etapie zbierania wymagań nie wyłapano owego "błota" to na pewno w czasie
    renegocjacji jakiś biały kołnierzyk o tym sobie przypomni... A co.

    Podstawowa różnica że ja zakładam obie strony kompetentne i uczciwe, a
    nie kombinatorskie. Jeśli zleceniodawca podaje nierealne terminy
    wykonania, zniżone koszty lub podejmuje się zleceń o których wie z góry
    że nie jest w stanie wykonać, to powinien być pociągnięty do
    odpowiedzialności za swoje działania. Na drugi raz pomyśli dwa razy
    zanim zacznie kombinować. A jak nie to zniknie z rynku i sprawa też się
    rozwiąże.

    pozdrawiam,
    Przemek O.



  • 192. Data: 2011-05-19 16:13:56
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 193. Data: 2011-05-19 16:35:02
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    On May 19, 4:42 pm, "Przemek O." <p...@o...eu> wrote:
    > W dniu 2011-05-19 16:53, Andrzej Jarzabek pisze:
    >
    > > I jaką korzyść z tego uświadomienia ma wykonawca?
    >
    > Taką że w połowie projektu nie musi renegocjować umowy, bo klientowi coś
    > się przypomniało lub o czymś mu się zapomniało. Pół biedy jeśli skończy
    > się tylko na renegocjacji a nie pociągnie to za sobą zmiany połowy
    > wykonanego projektu. To chyba logiczne?

    Przecież nie mówimy o sytuacji, kiedy w umowie stoi, że traktor
    koniecznie ma grzęznąć w błocie. Jeśli wykonawca wie, że traktor nie
    powinien grzęznąć w błocie (a wie, bo ustalił to pracujący dla niego
    analityk), a zleceniodawca nie nalega na wpis w umowie, to nie ma
    żadnego interesu w tym, żeby nalegać na wpisanie tego do umowy (albo
    choćby sugerować zleceniodawcy, że powinien). W ten sposób bazowo
    zakłada, że zrobi traktor, który nie grzęźnie, ale gdyby były jednak z
    tym trrudności, to nie musi renegocjować umowy i nie musi płacić kar
    za opóźnienia - wiedząc, że jest takie wymaganie _może_ jednak
    próbowac renegocjować umowę na swoją korzyść (np. wydłużając termin
    albo zwiększając cenę za enchancement).

    > > Albo i nie. Bo przecież z punktu widzenia zleceniodawcy zamawia on
    > > ciągle ten sam produkt.
    >
    > Też pisze że możliwość, czyli można (jeśli są ku temu powodu) ale nie
    > trzeba. Wszystko musi mieć swoje uzasadnienie.

    W realistycznych scenariuszach jest oczywiście tak, że często
    współpracują firmy, które mają do siebie jakieś tam zaufanie i dopóki
    wiedzą, że druga strona nie robi ich w bambuko, wykazują elastyczność
    i zrozumienie. I to są właśnie dobre warunki do działania agile:
    niezależnie od tego, jak konkretnie jest sformułowana umowa, wykonawca
    mówi stakeholderom, że są obiektywne trudności takie i takie z
    dostarczeniem takiego i takiego kawałka funkcjonalnosci, ale rozmawiał
    z customer representative i doszli do wnisku, że można trochę okroić
    scope i cośtam uprościć tak, żeby produkt nadal miał sens, ale za to
    zleceniodawca może dostać pierwszy release na trzy miesiące przed
    terminem i zacząć już na nim zarabiać, a my obiecujemy w dalszej
    kolejności zająć się tym, co wypadło. I customer representative i
    tygodniowe iteracje z wersją demo są również po to, żeby zleceniodawca
    wiedział, że nie jest robiony w bambuko.

    > To żaden porządny developer nie wziąłby zlecenia którego nie jest w
    > stanie wykonać, a już na pewno nie dałby terminów lub kosztów poniżej
    > faktycznie potrzebnych.

    Bo każdy porządny developer ma Oracle Machnine wpiętą w slota PCI.

    > > powiedzieć "bździągąbator jest w umowie, dostarczacie w terminie albo
    > > płacicie kary". I teraz jeśli w umowie nie ma błota, to wykonawca mówi
    >
    > No logiczne, czemu miałoby być inaczej. W interesie zleceniobiorcy jest
    > podawać realne terminy.

    W interesie zleceniobiorcy jest również znać notowania giełdy na
    przyszły tydzień, i żeby mu diamenty z nieba do ogródka spadały.

    > > "ok, dostarczymy traktor z bździągąbatorem, ale za to nie jeżdżący po
    > > błocie".
    >
    > Jeśli tego nie ma w umowie, to to wspominanie jest bez sensu. A jeśli na
    > etapie zbierania wymagań nie wyłapano owego "błota" to na pewno w czasie
    > renegocjacji jakiś biały kołnierzyk o tym sobie przypomni... A co.
    >
    > Podstawowa różnica że ja zakładam obie strony kompetentne i uczciwe, a
    > nie kombinatorskie. Jeśli zleceniodawca podaje nierealne terminy
    > wykonania, zniżone koszty lub podejmuje się zleceń o których wie z góry
    > że nie jest w stanie wykonać, to powinien być pociągnięty do
    > odpowiedzialności za swoje działania. Na drugi raz pomyśli dwa razy
    > zanim zacznie kombinować. A jak nie to zniknie z rynku i sprawa też się
    > rozwiąże.

    Ja przecież nie zakładam, że zleceniobiorca wie z góry. Ja zakładam,
    że nikt nie wie z góry.


  • 194. Data: 2011-05-19 16:58:26
    Temat: Re: ilu jest programistow na swiecie?
    Od: "Przemek O." <p...@o...eu>

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

    > Przecież nie mówimy o sytuacji, kiedy w umowie stoi, że traktor
    > koniecznie ma grzęznąć w błocie. Jeśli wykonawca wie, że traktor nie
    > powinien grzęznąć w błocie (a wie, bo ustalił to pracujący dla niego
    > analityk), a zleceniodawca nie nalega na wpis w umowie, to nie ma
    > żadnego interesu w tym, żeby nalegać na wpisanie tego do umowy (albo
    > choćby sugerować zleceniodawcy, że powinien). W ten sposób bazowo

    Nie będę się tłukł z pokrętną logiką. Jeśli coś jest wymagane i obie
    strony o tym wiedzą to musi być to wpisane w umowę lub dokument
    określający zakres zlecenia.

    > zakłada, że zrobi traktor, który nie grzęźnie, ale gdyby były jednak z
    > tym trrudności, to nie musi renegocjować umowy i nie musi płacić kar
    > za opóźnienia - wiedząc, że jest takie wymaganie _może_ jednak
    > próbowac renegocjować umowę na swoją korzyść (np. wydłużając termin
    > albo zwiększając cenę za enchancement).

    Po pierwsze pisz po polsku. Po drugie z czego miały by wynikać te
    trudności? Chyba z niekompetencji zleceniobiorcy. Ale to już jego problem.

    > zleceniodawca może dostać pierwszy release na trzy miesiące przed
    > terminem i zacząć już na nim zarabiać, a my obiecujemy w dalszej

    Zakładając że da się wykroić interesującą zleceniodawcę część.

    > kolejności zająć się tym, co wypadło. I customer representative i
    > tygodniowe iteracje z wersją demo są również po to, żeby zleceniodawca
    > wiedział, że nie jest robiony w bambuko.

    Jeśli coś wypadło i okazuje się że zleceniodawca na pierwszym wydaniu
    może zarabiać, to zleceniobiorca zrobił go już w bambuko i wcisnął
    dodatkowe funkcje których nie potrzebuje do zarabiania. Racja?

    > Bo każdy porządny developer ma Oracle Machnine wpiętą w slota PCI.

    Wiesz, jeśli się robi z nastawieniem "agile" w wydaniu do którego
    próbujesz mnie przekonać to faktycznie powinien.
    Ale mając doświadczenie, porządną analizę wymagań oraz projekt. Nie
    potrzebuje jej, bo może oszacować zarówno koszt jak i termin wykonania.
    Że nie wspominając już o tym, czy w ogóle jest w stanie wykonać to zadanie.

    > W interesie zleceniobiorcy jest również znać notowania giełdy na
    > przyszły tydzień, i żeby mu diamenty z nieba do ogródka spadały.

    ??? Sugerujesz że nie da się oszacować kosztów i terminu wykonania
    projektu. No patrz, genialny jestem bo od wielu lat mi się to udaje. I
    najczęściej stosuje projekty kaskadowe lub kaskadowe z iteracjami. Żyje
    chyba we własnym świecie, tylko dlaczego mi za to płacą???

    > Ja przecież nie zakładam, że zleceniobiorca wie z góry. Ja zakładam,
    > że nikt nie wie z góry.

    Czego nie wie? Banialuki opowiadasz. Zleceniodawca nie wie co potrafi?
    Bierze projekty w ciemno? Kurcze chyba student na IV roku z przerostem
    ambicji tak robi i pewno jeszcze za banany a nie pieniądze.

    pozdrawiam,
    Przemek O.




  • 195. Data: 2011-05-19 17:28:19
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    On Thu, 19 May 2011 12:55:34 +0200, Paweł Kierski<n...@p...net>
    wrote:
    > Iteracje mogą być dłuższe, a nie każda musi się kończyć testowaniem
    od
    > A do Z, a np. tylko nowych ficzerów. Tu pewnie zwolennicy Kanbana

    Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.


  • 196. Data: 2011-05-19 17:46:08
    Temat: Re: ilu jest programistow na swiecie?
    Od: "Przemek O." <p...@o...eu>

    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.



  • 197. Data: 2011-05-20 00:45:19
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    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.


  • 198. Data: 2011-05-20 07:35:13
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

    > On Thu, 19 May 2011 12:55:34 +0200, Paweł Kierski<n...@p...net>
    > wrote:
    >> Iteracje mogą być dłuższe, a nie każda musi się kończyć testowaniem
    > od
    >> A do Z, a np. tylko nowych ficzerów. Tu pewnie zwolennicy Kanbana
    >
    > Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.

    Sek w tym, ze to jest tylko _udawanie_ testowania. Nie da sie _dobrze_
    przetestowac niebanalnego oprogramowania w czasie jednej iteracji (o
    dlugosci proponowanej przez "agile"). A juz tym bardziej zalozenie, ze
    testuje sie "na biezaco", wiec na zakonczenie iteracji mamy juz
    "przetestowane" jest po prostu smieszne.

    Co wiecej - trzeba sobie zdac sprawe z tego, ze _prawdziwe_ testowanie b.
    duzo kosztuje (nie tylko ze wzgledu na czas, lecz takze ze wzgledu na
    zasoby, ktore sa potrzebne do tego). I dalej - ze wzgledu na te koszty nie
    mozna sobie pozwolic na to, zeby robic to zbyt czesto - stad stosuje sie
    metody pozwalajace _unikac_ bledow (a nie je wykrywac i poprawiac) - to jest
    po prostu tansze i - co wiecej - pozwala osiagnac jakosc, ktorej nie da sie
    osiagnac testujac/poprawiajac.
    Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego
    (ew. do powaznego wydluzenia iteracji). Np. unikanie bledow w rozpoznaniu
    wymagan polega na _dokladniejszym_ wyspecyfikowaniu tych wymagan i
    _dokladniejszej_ weryfikacji specyfikacji - nie oplaca sie robic
    oprogramowania _zanim_ sie skonczy specyfikacje, bo to strata czasu i
    pieniedzy na robienie czegos, co potencjalnie nie jest nikomu potrzebne. I
    to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
    automatycznie, ze te prototypy staja sie gotowym produktem - a to znowu z
    tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
    daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu nawet
    probowac, by te prototypy mialy konstrukcje i jakosc produktu koncowego, bo
    dopoki nie skonczymy analizy wymagan, moze sie okazac, ze nieuwzglednione do
    tej pory wymagania beda wymagac calkowitej zmiany konstrukcji
    oprogramowania. Co wiecej - zapewnienie odpowiedniej jakosci wymaga
    _kosztownego_ i dlugotrwalego testowania, wiec zataczamy kolo.

    U podstaw "metodyk agile" lezy (mniej lub bardziej jawne) zalozenie, ze da
    sie tak robic oprogramowanie, ze koszt jego modyfikacji nie wzrasta w miare
    jego rozrastania sie. Co jest zalozeniem po prostu absurdalnym - jezeli np.
    na poczatku podejmiemy decyzje o tworzeniu tego oprogramowania dajmy na to w
    C# (bo zespol uznal, ze tak najlepiej) a potem okaze sie, ze klient
    zapomnial nam powiedziec o tym, ze to ma dzialac na Solarisie (z jakichs tam
    powodow), to jak niby mamy zrobic "refaktoring" nie przepisujac tego
    oprogramowania w calosci???

    --
    Michal


  • 199. Data: 2011-05-20 08:12:36
    Temat: Re: ilu jest programistow na swiecie?
    Od: "Przemek O." <p...@o...eu>

    W dniu 2011-05-20 02:45, Andrzej Jarzabek pisze:

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

    Tak z punktu widzenia wersji 2010. Jednak wersja 1 miała wszystko to co
    było zaplanowane dla wersji 1, a kolejne wersje są jej rozwojem a nie
    dodawaniem funkcjonalności które były zaprojektowane w momencie
    projektowania wersji 1. Czy uważasz że projektując Office'a 1 mieli w
    planach ribbona dodanego w wersji 2007? Jednak mylisz pojęcia.

    > w mniej więcej takim czasie, więc możemy razem zaryzykować, gdzie

    Interesów nie robi się "mniej więcej".

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

    Po pierwsze, prowadzenie biznesu jest ryzykiem samym w sobie. Gdyby było
    inaczej, każdy z nas byłby miliarderem z rentownymi przedsiębiorstwami.
    Po drugie nikt nie przewiduje strat na podstawie patrzenia w szklaną
    kulę i swojego widzimisie. Więc bajek się do umowy nie wpisuje.

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

    Kurcze facet, bzdurzysz niemiłosiernie. Jeśli ktoś pisał np. kalkulator
    i zajęło mu to x tygodni i kosztowało Y pieniędzy, to napisanie takiego
    samego kalkulatora tylko z różowymi przyciskami zajmie mu tyle samo
    czasu + czas na implementacje różowych przycisków i będzie kosztować Y +
    wartość implementacji różowych przycisków.
    I w każdej branży tak jest, a przewinąłem się przez kilka firm robiących
    oprogramowanie dla różnych branży, od usługowych poprzez produkcyjne do
    handlowych.
    Sytuacja o której piszesz, może być jedynie w sytuacji gdy firma
    specjalizująca się w oprogramowaniu księgowym weźmie zlecenie na np.
    ERP. Fakt, mając ogóle doświadczenie w tworzeniu oprogramowania i zerowe
    w zakresie zarządzania produkcją nie ma możliwości poprawnego
    oszacowania kosztów i czasu.

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

    To wszystko jest gdybanie zależne od funkcjonalności która dostarczył
    ten pierwszy po 9 miesiącach. Jeśli ta funkcjonalność była wystarczająca
    do zarabiania (jak to piszesz) to reszta jest w ogóle niepotrzebna.

    >> Pewnie, wszystko można spierniczyć, ale bez projektu jest to
    >> zdecydowanie prostsze.
    >
    > Nie zgodzę się.

    Jesteś fenomenem. Łatwiej trafić do celu z mapą czy bez?

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

    No a o czym ja cały czas pisze? Różne hipotezy są do siebie niepodobne
    (czyli nie mają wspólnych cząstkowych - tak przynajmniej zakładam, bo
    się na tym nie znam) więc nikt nie robił niczego podobnego, stąd nikt
    nie jest w stanie nawet w przybliżeniu podać tych wartości.

    Natomiast jeśli ktoś robił oprogramowanie zarządzające produkcją w
    firmie X, to z dużym prawdopodobieństwem poda realne terminy wykonania i
    koszty zarządzania produkcją dla firmy Y, gdzie wymagania różnią się
    jedynie specyfiką ścieżki produkcji.

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

    Inna sytuacja gospodarcza, inny poziom rozwoju technologii. My piszemy o
    sprawach dla nas oczywistych, gdzie oprogramowania jako takiego jest na
    pęczki. Komputerów na tamten moment (lub maszyn "podobnych") było tyle,
    że można było na palcach policzyć. Tak samo jak w czasach dzisiejszych
    wielka korporacja zbudowałaby teleport wielkości hangaru, za kwotę 9
    zerową - raczej interesu na tym by nie zrobiła, ale jak jakiś Woźniak
    zrobiłby coś podobnego wielkości garażu i za kwotę 5 zerową, to nawet
    jeśli teleportowałby 9 / 10 osób (ta jedna by nie wracała) to jeśli
    byłby popyt na tego rodzaju sprzęt to zarobiłby ogromną kasę.
    I celowo piszę tu o fantazji typu teleport, bo mniej więcej tym samym
    dla przeciętnego człowieka w tamtych czasach był komputer.

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

    Tablety mają o wiele większą funkcjonalność i nie porównuję do nich. I
    tak, po części piszę o tych, jak to nazywasz "imitacjach". Szkoda tylko,
    że "imitacje" są na wyższym poziomie technologicznym, a do tego są o
    połowę tańsze. Szkoda też za Apple zerżnęło design zarówno urządzenia i
    systemu pierwotnego (iPhone) z Samsunga. No ale cóż, lepszy marketing i
    logo obgryzionego jabłka zobowiązuje.

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

    Tablet PC i iPad jest kierowany do innego klienta docelowego.

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

    Model kaskadowy też jest w wersji iteracyjnej.

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

    Nie, bo analiza jest własnością zleceniodawcy. Tak więc robi się ja
    tylko raz.

    pozdrawiam,
    Przemek O.


  • 200. Data: 2011-05-20 08:26:54
    Temat: Re: ilu jest programistow na swiecie?
    Od: Maciej Sobczak <s...@g...com>

    On 20 Maj, 09:35, Michal Kleczek <k...@g...com> wrote:

    > > Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
    >
    > Sek w tym, ze to jest tylko _udawanie_ testowania.

    Zgadzam się.

    Wydaje mi się, że agile/xp opiera się na założeniu, że test jest tani.
    Tak tani, jak build albo nawet pojedynczy commit w repozytorium.
    Dlatego pojawiają się absurdalne pomysły, żeby te rzeczy łączyć.
    Problem w tym, że tanio to można przetestować bezstanowe funkcje typu
    największy wspólny dzielnik (ale ironicznie, jeszcze łatwiej je
    udowodnić) - wystarczy jednak że w systemie pojawia się współbieżność
    albo efekty pamięciowe (cache) i testy "z automata" można sobie
    wsadzić.
    Co się dzieje potem? Potem pojawia się niedotestowanie systemu, któro
    kumuluje się z każdą następną iteracją.

    Najlepsze projekty jakie zrobiłem bardziej przypominały wodospad w
    tym, że:

    1. najpierw był papier - nie musi to być fizycznie papier, może być
    np. wiki - idea jest taka, że jeśli coś nie działa na papierze, to w
    ogóle nie będzie działać, więc jest to etap nie tylko analityczny, ale
    też uwiarygadniający
    2. potem być może osobne drobne elementy jako sprawdzenie, czy
    jakieś odważne i niesprawdzone wcześniej pomysły można sensownie
    zrealizować - z tych drobnych elementów może powstać lokalna
    biblioteka do późniejszego użytku, więc nie jest to throw-away
    3. później implementacja, testy, wdrożenie

    Żadnego z tych punktów nie postrzegam jako zbędny koszt.
    Nie zależy mi na szybkim demo, z którego nie można się wyczołgać - a
    taki właśnie efekt zastosowania Scruma widziałem ostatnio.

    --
    Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

strony : 1 ... 10 ... 19 . [ 20 ] . 21 ... 28


Szukaj w grupach

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: