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.

do góry

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.

do góry

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.

do góry

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.

do góry

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.

do góry

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.

do góry

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.

do góry

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

do góry

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.

do góry

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

do góry