Andrzej Jarzabek wrote:

> On May 18, 11:14 am, Michal Kleczek <k...@g...com> wrote:
>> Michal Kleczek wrote:
>>
>> Aha - oczywiscie:
>> 4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac sie
>> na "buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej na
>> zasadzie "time and material" i wierza (na jakiej podstawie?), ze to sie
>> oplaci. Klienci ci to albo ci z p. 3) albo zatrudniaja management z p 1)
>> i 2).
>
> A na jakiej podstawie wierzą, ze się opłaci w dowolnym innym
> przypadku? Na jakiej podstawie wierzą, ze jeśli w umowie zapiszą
> funkcjonalność i termin, to produkt z taką funkcjonalnością zostanie
> faktycznie dostarczony w takim terminie?

Np. na podstawie zapisow umowy, ktore mowia o tym, ze dostawca placi kary
umowne za niewywiazanie sie z umowy. Kary sa okreslone w takiej wysokosci,
zeby stanowily mozliwie duza rekompensate za stracony czas, srodki, utracone
korzysci itd.

> Na jakiej podstawie wierzą,
> że produkt formalnie spełniający warunki określone w umowie będzie
> miał dla nich jakąkolwiek wartość?

No chyba nie zapisuja w umowie wymagan na bezwartosciowy dla nich produkt.
Jak firma potrzebuje np. 10 traktorow to wpisuje w umowie, ze chodzi o
traktory a nie - dajmy na to - wagony kolejowe.

--
Michal

do góry

On May 18, 1:02 pm, "R. P." <r...@w...to.wp.pl>
wrote:
> Andrzej Jarzabek wrote:
> > On 18/05/2011 00:55, R. P. wrote:
> >> Andrzej Jarzabek wrote:
>
> >>>> Dlatego świetni matematycy prawie zawsze są świetnymi programistami.
>
> >>> Ciekawa teza, jakieś przykłady? Bo mnie wydaje się równie sensowna, co
> >>> "świetni matematycy prawie zawsze są świetnymi muzykami". Ale uczciwie
> >>> przyznam, że nie śledzę tematu kto jest świetnym matematykiem i co za
> >>> programy pisze.
>
> >> A sam jesteś dobrym algorytmikiem? :)
>
> > Co to ma do rzeczy? Brakuje argumentów i schodzimy na ad hominem?
>
> Ja nie potrzebuje nikogo przekonywać, wiem że implikacja dobry matematy
> => dobry programista jest prawdziwa, natomiast odwrotna już nie zawsze.

A ja uważam, że i w tym nie masz racji, więc możesz spróbować mnie
przekonać.

> Informatyka to praktyczne zastosowania matematyki. A czy muzyka to
> praktyczne zastosowania matematyki? Po części tak, ale tylko po części.
> Dlatego twoje porównanie jest chybione.

Praca barmana to też praktyczne zastosowanie matematyki, bo trzeba
klientom dobrze reszte wydawać. Projektowanie samolotów to też
praktyczne zastosowanie matematyki, a chyba nie powiesz, że każdy
matematyk się świetnie na tym zna.

Praca programisty natomiast nie polega na "uprawianiu informatyki" czy
sotosowaniu matematyki, tylko na pisaniu programów do komputerów.
Wartość kodu nie polega tylko na tym, że ma poprawnie realizowac
jakieś obliczenie, bo często samo obliczenie jest banalne i nie trzeba
szczególnej wiedzy matematycznej, żeby jej poprawnie zaimplemetnować.
O jakości programisty świazy w dużej mierze to, czy kod przez niego
pisany jest czytelny, czy jest jasne, jak go należy prawidłowo używać,
czy innemu programiście łatwo będzie potem ten kod modyfikować, czy
też będzie duże prawdopodobieństwo, że modyfikując wprowadzi błędy.
Jeśli napisany przez takiego matematyka kod jest formalnie poprawny,
ale trudny do użycia i trudny w utrzymaniu, to ten matematyk jest
kiepskim programistą. A żeby pisać dobry kod to nie wystarczy znać
matematykę, trzeba jeszcze znać sztukę inżynierii oprogramowania,
która jest całą odrebną dziedziną wiedzy, matematykom generalnie
nieznaną (bo i czemu niby miałaby być).

do góry

W dniu 18.05.2011 14:02, R. P. pisze:
> Ja nie potrzebuje nikogo przekonywać, wiem że implikacja dobry matematy
> => dobry programista jest prawdziwa,
Nie musi. Czysta matematyka nie przejmuje się takimi 'pierdołami' jak
skończona pamięć, integer overflow i tym podobne...

Dobry matematyk =(zwzwyczaj)> dobry algorytmik.
Dobry algorytmik =/> dobry programista.

--
Pozdrawiam
Michoo

do góry

On May 18, 1:24 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
> > On May 18, 11:14 am, Michal Kleczek <k...@g...com> wrote:
> >> Michal Kleczek wrote:
>
> >> Aha - oczywiscie:
> >> 4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac sie
> >> na "buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej na
> >> zasadzie "time and material" i wierza (na jakiej podstawie?), ze to sie
> >> oplaci. Klienci ci to albo ci z p. 3) albo zatrudniaja management z p 1)
> >> i 2).
>
> > A na jakiej podstawie wierzą, ze się opłaci w dowolnym innym
> > przypadku? Na jakiej podstawie wierzą, ze jeśli w umowie zapiszą
> > funkcjonalność i termin, to produkt z taką funkcjonalnością zostanie
> > faktycznie dostarczony w takim terminie?
>
> Np. na podstawie zapisow umowy, ktore mowia o tym, ze dostawca placi kary
> umowne za niewywiazanie sie z umowy. Kary sa okreslone w takiej wysokosci,
> zeby stanowily mozliwie duza rekompensate za stracony czas, srodki, utracone
> korzysci itd.

A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
będzie wypłacalny)? Powszechnie wiadomo, ż projekty informatyczne
często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
chętne do brania na siebie ryzyka gigantycznych strat w przypadku
kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.

> > Na jakiej podstawie wierzą,
> > że produkt formalnie spełniający warunki określone w umowie będzie
> > miał dla nich jakąkolwiek wartość?
>
> No chyba nie zapisuja w umowie wymagan na bezwartosciowy dla nich produkt.
> Jak firma potrzebuje np. 10 traktorow to wpisuje w umowie, ze chodzi o
> traktory a nie - dajmy na to - wagony kolejowe.

Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
Firma potrzebuje nowy model traktora, który będzie maił jakiś
specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
okazuje się, że ten model grzęźnie w błocie i jako taki jest
bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
lata.

do góry

Paweł Kierski wrote:

> W dniu 2011-05-18 12:06, Michal Kleczek pisze:
> [...]
>> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak
>> robic oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy
>> niezbedne" i "poprawiaj proces".
>
> Owszem. Ponieważ historycznie te banały zaczęły być stosowane
> w praktyce akurat dość daleko od produkcji oprogramowania.
>
> [...]
>> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie
>> przez programistow pieniedzy bez ponoszenia najmniejszych konsekwencji
>> swoich dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem
>> dla niekompetencji kierownictwa.
>
> Czy widziałeś "na żywo" działający zespół Agile? Choć przez tydzień?
>
> Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
> programiści robiliby cokolwiek bez konsekwencji lub projekty
> prowadziłoby niekompetentne kierownictwo. A są firmy, które tego używają
> i działają. Być może nieoptymalnie - ale jak to sprawdzisz?
>

Tak zupelnie powaznie to mam spore watpliwosci czy sa firmy stosujace
metodyki "agile" w _calosci_ procesu produkcji oprogramowania. Jest to po
prostu niemozliwe, bo "metodyki agile" w ogole nie mowia o wielu istotnych
aspektach takiego procesu, koncentrujac sie tylko na jego drobnym wycinku.
Nie jest mozliwe stosowanie np. XP samego w sobie - wezmy przykladowo kilka
pytan, na ktore trzeba sobie odpowiedziec projektujac system:

0) czy w ogole potrzebujemy programowac? moze wystarczy kupic produkt z
polki? jesli tak to jaki? albo moze raczej kupic produkt(y) i go (je)
dostosowac lub zintegrowac?
1) potrzebujemy, czy tez nie RDBMS (jezeli tak to jaki) - to wariant 0)
2) w jakim jezyku (jezykach) programowania powinnismy stworzyc system (lub
poszczegolne podsystemy - a wczesniej - jakie podsystemy beda skladac sie na
nasz system?)
3) jakie oprogramowanie firm trzecich potrzebujemy (chociazby jaki(e) OS)
4) w jaki sposob (jesli w ogole) bedziemy integrowac nasz system z innymi
systemami - czy potrzebujemy np. ESB? jesli tak to jaki?
5) jak duzy zespol potrzebujemy?
6) jak bedziemy zarzadzac konfiguracja? jakich narzedzi do tego
potrzebujemy?
7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
sprzet / ludzi do stworzenia centrum testowego?
...) mozna tak dlugo

XP w ogole sie powyzszym nie zajmuje - raczej czyni niejawne zalozenie, ze
pewne decyzje sa juz podjete, infrastruktura istnieje itd, a teraz zostaje
juz tylko zajac sie pisaniem kodu.

>> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest
>> dla mnie troche niepojete. Jest kilka mozliwosci:
>> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w
>> projektach o tak malym znaczeniu i koszcie, ze tak naprawde wszystko
>> jedno jak sie to robi, zas zarzadzanie mozna powierzyc jakiemus matolowi
>> bo nawet jak spieprzy to nic nie nie stanie
>
> Podstaw cokolwiek za "XP/Agile" i będziesz miał prawdziwe zdanie.
>

Nie rozumiem. Twierdze, ze wlasnie uzycie "XP/Agile" powoduje prawdziwosc
tego zdania. Wstawienie tam czegos innego moze (ale nie musi) tworzyc
prawdziwego zdania.

>> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
>> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie
>> czyms wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie,
>> ktore nigdy nie jest skonczone, dlatego patrz p. 1)
>
> Weźmy taki Scrum. Każda iteracja to umowa na wykonanie konkretnych
> funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
> do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
> Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
> kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
> koszty).

Tyle, ze potrzebujemy wiedzy nie na temat 1 krotkiej iteracji, lecz _calego_
projektu, ktory planujemy. Jak mam wydac pieniadze na stworzenie produktu,
to chcialbym - z mozliwie duza pewnoscia - moc zalozyc ile wydam i ile
zyskam. Chociazby po to, zeby wiedziec czy w ogole mi sie oplaca zaczynac, a
nie po prostu kupic sobie nowy samolot albo pol wyspy na Karaibach.

>
>> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
>> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej
>> motywacji, zeby cokolwiek w tej dzialce zmieniac
>
> Patrz odpowiedź do pkt. 1. A na marginesie przypominam, że Agile zakłada
> ciągłe doskonalenie procesu, czyli - niespodzianka! - zmiany.
>

Wybacz, ale Agile z usprawnianiem procesu ma tyle wspolnego, ze zaklada sie,
ze proces sie bedzie "zmienial". Toyota (lub firmy stosujace programy typu
TQM 6sigma itp) rowniez ciagle modyfikuje procesy, a nikt przy zdrowych
zmyslach nie powie ze stosuje "agile" - wrecz przeciwnie.

--
Michal

do góry

Andrzej Jarzabek wrote:

> On May 18, 1:24 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:
>> > On May 18, 11:14 am, Michal Kleczek <k...@g...com> wrote:
>> >> Michal Kleczek wrote:
>>
>> >> Aha - oczywiscie:
>> >> 4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac
>> >> sie na "buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej
>> >> na zasadzie "time and material" i wierza (na jakiej podstawie?), ze to
>> >> sie oplaci. Klienci ci to albo ci z p. 3) albo zatrudniaja management
>> >> z p 1) i 2).
>>
>> > A na jakiej podstawie wierzą, ze się opłaci w dowolnym innym
>> > przypadku? Na jakiej podstawie wierzą, ze jeśli w umowie zapiszą
>> > funkcjonalność i termin, to produkt z taką funkcjonalnością zostanie
>> > faktycznie dostarczony w takim terminie?
>>
>> Np. na podstawie zapisow umowy, ktore mowia o tym, ze dostawca placi kary
>> umowne za niewywiazanie sie z umowy. Kary sa okreslone w takiej
>> wysokosci, zeby stanowily mozliwie duza rekompensate za stracony czas,
>> srodki, utracone korzysci itd.
>
> A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
> będzie wypłacalny)?

Bedzie tak dlugo podnosil wynagrodzenie az:
a) znajdzie sie dostawca
b) stwierdzi ze sie nie oplaca i/lub znajdzie substytut

Jesli chodzi o wyplacalnosc dostawcy to przyjeta praktyka jest wymog roznego
rodzaju zabezpieczen finansowych. Jak dostawcy na takie nie stac, to znaczy
ze jest gowniany i wspolpraca z nim jest ryzykowna. Jezeli i tak go
wybieramy, to znaczy, ze stac nas na takie ryzyko.

> Powszechnie wiadomo, ż projekty informatyczne
> często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
> oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
> chętne do brania na siebie ryzyka gigantycznych strat w przypadku
> kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.

Dlatego tez istnieje cos takiego jak analiza wymagan, studium wykonalnosci i
inne metody pozwalajace zminimalizowac ryzyko wystapienia takiego przypadku.
Gdyby takich metod nie bylo to nikt by sie nie podjal budowy mostu sredniej
wielkosci (bo sa to metody dotyczace zarowno IT jak i innych przedsiewziec).
Te metody maja jedna rzecz wspolna - najpierw sie mysli, potem sie robi -
taki waterfall.

>
>> > Na jakiej podstawie wierzą,
>> > że produkt formalnie spełniający warunki określone w umowie będzie
>> > miał dla nich jakąkolwiek wartość?
>>
>> No chyba nie zapisuja w umowie wymagan na bezwartosciowy dla nich
>> produkt. Jak firma potrzebuje np. 10 traktorow to wpisuje w umowie, ze
>> chodzi o traktory a nie - dajmy na to - wagony kolejowe.
>
> Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> Firma potrzebuje nowy model traktora, który będzie maił jakiś
> specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> okazuje się, że ten model grzęźnie w błocie i jako taki jest
> bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> lata.

To zadna analogia. Jezeli klient nie wyartykuuje, ze traktor ma jezdzic po
blocie i w nim nie grzeznac, to dostanie traktor, ktory byc moze bedzie, a
byc moze nie bedzie grzeznac. Sek w tym, ze metody "agile" zakladaja, ze
najpierw nalezy zrobic w pelni funkcjonalny traktor i za niego zaplacic, a
potem zobaczyc czy sie nada.
Normalni ludzie, jak nie sa pewni czego chca to robia _prototyp_ (lub serie
prototypow). Ale nikt nie wymaga (w odroznieniu od agile), zeby prototyp byl
w pelni funkcjonalny - bo po co za to placic? (zreszta to juz wtedy nie jest
prototyp).

--
Michal

do góry

On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
>
> > Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
> > programiści robiliby cokolwiek bez konsekwencji lub projekty
> > prowadziłoby niekompetentne kierownictwo. A są firmy, które tego używają
> > i działają. Być może nieoptymalnie - ale jak to sprawdzisz?
>
> Tak zupelnie powaznie to mam spore watpliwosci czy sa firmy stosujace
> metodyki "agile" w _calosci_ procesu produkcji oprogramowania. Jest to po
> prostu niemozliwe, bo "metodyki agile" w ogole nie mowia o wielu istotnych
> aspektach takiego procesu, koncentrujac sie tylko na jego drobnym wycinku.
> Nie jest mozliwe stosowanie np. XP samego w sobie - wezmy przykladowo kilka
> pytan, na ktore trzeba sobie odpowiedziec projektujac system:
>
> 0) czy w ogole potrzebujemy programowac? moze wystarczy kupic produkt z
> polki? jesli tak to jaki? albo moze raczej kupic produkt(y) i go (je)
> dostosowac lub zintegrowac?
> 1) potrzebujemy, czy tez nie RDBMS (jezeli tak to jaki) - to wariant 0)
> 2) w jakim jezyku (jezykach) programowania powinnismy stworzyc system (lub
> poszczegolne podsystemy - a wczesniej - jakie podsystemy beda skladac sie na
> nasz system?)

Jeszcze zapomniałeś dodać, że procesy Agile na ogół nie określają w
jaki sposób wybiera się nazwę dla tworzonego programu.

Pomijając jednak to, to można zwrócić uwagę, że jednak pewne aspekty
tego, o czym piszesz są uwzględnione gdzie niegdzie w Agile. Na
przykład praktyka samoorganizacji zespołów mówi coś o tym, że zespół
dobiera sobie narzędzia potrzebne do realizacji zadania zgodnie ze
swoimi umiejętnościami i wiedzą. Co oczywiście do końca nie rozwiązuje
problemu, bo trzeba najpierw taki zespół dobrać i z pewnością
znajomości pewnych języków czy technologii będą kluczem.

Tylko że właściwie co z tego wynika?

> 5) jak duzy zespol potrzebujemy?

Akurat do tego agile się odnosi, tylko raczej z drugiej strony: przy
jak dużym zespole stosowanie praktyk będzie możliwe/skuteczne?

> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
> sprzet / ludzi do stworzenia centrum testowego?

W tej kwestii akurat XP ma sporo do powiedzenia.

> XP w ogole sie powyzszym nie zajmuje - raczej czyni niejawne zalozenie, ze
> pewne decyzje sa juz podjete, infrastruktura istnieje itd, a teraz zostaje
> juz tylko zajac sie pisaniem kodu.

No niekoniecznie, ale raczej przyjmuje założenie (sensowne IMO), że
pewnych rzeczy nie ma sensu określać w ramach metodologii towrzenia
oprogramowania, bo są głównie zależne od specyfiki projektu i różnych
innych czynników, np. instytucjonalnych. Z dugiej strony metodologie
agile jak najbardziej odnoszą się przecież do różnych kwestii
organizacyjnych poza samym pisaniem kodu, np. obecnośc customera,
organizacja miejsca i czasu pracy, interakcji między uczestnikami
projektu. Oczywista jest sprawa, ze są rzeczy, które są "out of
scope", ale nimi też często pośrednio różne metodologie zajmują się
poprzez np. definiowanie kompetencji pewnych ról.(product owner,
visionary itd.)


> > Weźmy taki Scrum. Każda iteracja to umowa na wykonanie konkretnych
> > funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
> > do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
> > Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
> > kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
> > koszty).
>
> Tyle, ze potrzebujemy wiedzy nie na temat 1 krotkiej iteracji, lecz _calego_
> projektu, ktory planujemy. Jak mam wydac pieniadze na stworzenie produktu,
> to chcialbym - z mozliwie duza pewnoscia - moc zalozyc ile wydam i ile
> zyskam. Chociazby po to, zeby wiedziec czy w ogole mi sie oplaca zaczynac, a
> nie po prostu kupic sobie nowy samolot albo pol wyspy na Karaibach.

Tylko że alternatywy nie dają ci możliwie dużej pewności. Natomiast
krótki cykl i feedback daje orientację co do realnych postępów i
możliwość wyciągnięcia wtyczki na wczesnym etapie, zanim zbyt wiele
się utopi w projekcie.

> Wybacz, ale Agile z usprawnianiem procesu ma tyle wspolnego, ze zaklada sie,
> ze proces sie bedzie "zmienial".

Nie no, bez przesady, konkretne metodologie mają do tego konkretne
praktyki.

do góry

W dniu 2011-05-18 11:10, Andrzej Jarzabek pisze:
> On May 18, 9:57 am, Paweł Kierski<n...@p...net> wrote:
>> W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:
>
>>
>> Dorzucę swoje trzy grosze - gdyby analiza była tak dobra, że dokumenty
>> nie musiałyby się zmieniać, to znaczyłoby, że na ich podstawie kod może
>> tworzyć przysłowiowy student za 1200.
>
> Ja się nie zgodzę. Znaczy, niby oczywiście może, ale żadna analiza nie
> zapobiegnie błędom w kodie, niskiej czytelności, słabej wydajnosci,
> kiepskiemu maintainability i tak dalej.
>
> Problem polega na tym, że taka analiza czy dokumentacja wymagań to
> taka sama fikcja, jak by powiedzieć, że jak się zatrudni bardzo
> dobrych programistów za grube pieniądze, to nie trzeba testowac
> oprogramowania, bo dobrzy programiści nie robią błędów.

Tu się zgadzam w 100% - nie ma idealnie pełnej i poprawnej dokumentacji
i nie ma idealnego kodu. I to, i to powinno być tak dobre, żeby spełnić
wymagania, i nie powinno być "na siłę" lepsze (bo to kosztuje).

Warto tylko pamiętać, że najczęściej na końcu sprzedaje się działający
kod. I w tę stronę sensowniej jest patrzeć.

--
Paweł Kierski
n...@p...net

do góry

Michal Kleczek <k...@g...com> napisał(a):

> Paweł Kierski wrote:
>
> > W dniu 2011-05-18 12:06, Michal Kleczek pisze:
> > [...]
> >> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak
> >> robic oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy
> >> niezbedne" i "poprawiaj proces".
> >
> > Owszem. Ponieważ historycznie te banały zaczęły być stosowane
> > w praktyce akurat dość daleko od produkcji oprogramowania.
> >
> > [...]
> >> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie
> >> przez programistow pieniedzy bez ponoszenia najmniejszych konsekwencji
> >> swoich dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem
> >> dla niekompetencji kierownictwa.
> >
> > Czy widziałeś "na żywo" działający zespół Agile? Choć przez
tydzień?
> >
> > Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
> > programiści robiliby cokolwiek bez konsekwencji lub projekty
> > prowadziłoby niekompetentne kierownictwo. A są firmy, które tego
używają
> > i działają. Być może nieoptymalnie - ale jak to sprawdzisz?
> >
>
> Tak zupelnie powaznie to mam spore watpliwosci czy sa firmy stosujace
> metodyki "agile" w _calosci_ procesu produkcji oprogramowania. Jest to po
> prostu niemozliwe, bo "metodyki agile" w ogole nie mowia o wielu istotnych
> aspektach takiego procesu, koncentrujac sie tylko na jego drobnym wycinku.
> Nie jest mozliwe stosowanie np. XP samego w sobie - wezmy przykladowo kilka
> pytan, na ktore trzeba sobie odpowiedziec projektujac system:
>
> 0) czy w ogole potrzebujemy programowac? moze wystarczy kupic produkt z
> polki? jesli tak to jaki? albo moze raczej kupic produkt(y) i go (je)
> dostosowac lub zintegrowac?
> 1) potrzebujemy, czy tez nie RDBMS (jezeli tak to jaki) - to wariant 0)
> 2) w jakim jezyku (jezykach) programowania powinnismy stworzyc system (lub
> poszczegolne podsystemy - a wczesniej - jakie podsystemy beda skladac sie
na
> nasz system?)
> 3) jakie oprogramowanie firm trzecich potrzebujemy (chociazby jaki(e) OS)
> 4) w jaki sposob (jesli w ogole) bedziemy integrowac nasz system z innymi
> systemami - czy potrzebujemy np. ESB? jesli tak to jaki?
> 5) jak duzy zespol potrzebujemy?
> 6) jak bedziemy zarzadzac konfiguracja? jakich narzedzi do tego
> potrzebujemy?
> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
> sprzet / ludzi do stworzenia centrum testowego?
> ....) mozna tak dlugo
>
> XP w ogole sie powyzszym nie zajmuje - raczej czyni niejawne zalozenie, ze
> pewne decyzje sa juz podjete, infrastruktura istnieje itd, a teraz zostaje
> juz tylko zajac sie pisaniem kodu.
>
> >> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest
> >> dla mnie troche niepojete. Jest kilka mozliwosci:
> >> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w
> >> projektach o tak malym znaczeniu i koszcie, ze tak naprawde wszystko
> >> jedno jak sie to robi, zas zarzadzanie mozna powierzyc jakiemus matolowi
> >> bo nawet jak spieprzy to nic nie nie stanie
> >
> > Podstaw cokolwiek za "XP/Agile" i będziesz miał prawdziwe zdanie.
> >
>
> Nie rozumiem. Twierdze, ze wlasnie uzycie "XP/Agile" powoduje prawdziwosc
> tego zdania. Wstawienie tam czegos innego moze (ale nie musi) tworzyc
> prawdziwego zdania.
>
> >> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
> >> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie
> >> czyms wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie,
> >> ktore nigdy nie jest skonczone, dlatego patrz p. 1)
> >
> > WeĹşmy taki Scrum. KaĹźda iteracja to umowa na wykonanie konkretnych
> > funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
> > do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
> > Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
> > kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
> > koszty).
>
> Tyle, ze potrzebujemy wiedzy nie na temat 1 krotkiej iteracji, lecz
_calego_
> projektu, ktory planujemy. Jak mam wydac pieniadze na stworzenie produktu,
> to chcialbym - z mozliwie duza pewnoscia - moc zalozyc ile wydam i ile
> zyskam. Chociazby po to, zeby wiedziec czy w ogole mi sie oplaca zaczynac,
a
> nie po prostu kupic sobie nowy samolot albo pol wyspy na Karaibach.
>
> >
> >> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
> >> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej
> >> motywacji, zeby cokolwiek w tej dzialce zmieniac
> >
> > Patrz odpowiedĹş do pkt. 1. A na marginesie przypominam, Ĺźe Agile
zakłada
> > ciągłe doskonalenie procesu, czyli - niespodzianka! - zmiany.
> >
>
> Wybacz, ale Agile z usprawnianiem procesu ma tyle wspolnego, ze zaklada
sie,
> ze proces sie bedzie "zmienial". Toyota (lub firmy stosujace programy typu
> TQM 6sigma itp) rowniez ciagle modyfikuje procesy, a nikt przy zdrowych
> zmyslach nie powie ze stosuje "agile" - wrecz przeciwnie.
>

Z tego jak ja kojarze te sprawy to 'agile' bierze sie ze spostrzezenia
ze programistyczni maniacy w stanie mani koduja wielokrotnie szybciej
i lepiej niz programisci odwalajacy kodowanie w trybie biurowym - >

( tak ze nie mysl ze agile jest po to by 'oszukiwac biznes'
jest odwrotnie, agile jest po to, by programowac wiecej i bardziej)

-> i to jest chyba raczej prawda - ale tacy maniacy zdarzaja dzis moge
powiedziec chyba dosyc rzadko (kiedys wydawalo mi sie ze jest ich
wiecej, a i mnie samemu takie maniackie napady zdarzaja sie ostatnimi
czasy dosyc malo, i stawiam raczej na spokojna wiedze i niezbedny
odpoczynek: wydajnosc i jakosc niezwykle spada z przemeczenia, nie ma
bata, potrzebne jest duzo czasu i duzo wiedzy i nauki




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On May 18, 2:19 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:.
>
> > A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> > zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
> > będzie wypłacalny)?
>
> Bedzie tak dlugo podnosil wynagrodzenie az:
> a) znajdzie sie dostawca
> b) stwierdzi ze sie nie oplaca i/lub znajdzie substytut

No i w praktyce substytutem będzie wzięcie ryzyka na siebie.

> Jesli chodzi o wyplacalnosc dostawcy to przyjeta praktyka jest wymog roznego
> rodzaju zabezpieczen finansowych. Jak dostawcy na takie nie stac, to znaczy
> ze jest gowniany i wspolpraca z nim jest ryzykowna. Jezeli i tak go
> wybieramy, to znaczy, ze stac nas na takie ryzyko.

No i tak samo jest z agile: jak je wybieramy, to znaczy, że stac nas
na takie ryzyko. Albo i nie stać, rzecz jasna.

> > Powszechnie wiadomo, ż projekty informatyczne
> > często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
> > oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
> > chętne do brania na siebie ryzyka gigantycznych strat w przypadku
> > kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.
>
> Dlatego tez istnieje cos takiego jak analiza wymagan, studium wykonalnosci i
> inne metody pozwalajace zminimalizowac ryzyko wystapienia takiego przypadku.

Tylko że wtedy ponisimy takie ryzyko, że metody moga być kosztowne i
czasochłonne, a minimalizacja mało efektywna.

> Gdyby takich metod nie bylo to nikt by sie nie podjal budowy mostu sredniej
> wielkosci (bo sa to metody dotyczace zarowno IT jak i innych przedsiewziec).
> Te metody maja jedna rzecz wspolna - najpierw sie mysli, potem sie robi -
> taki waterfall.

Mosty mają swoją specyfikę, a oprogramowanie swoją. Jakby takie metody
można było przyłożyć do wszystkiego, to można by było mieć
przedsięwzięcie na zasadzie:
"potrzebuję wiedzieć czy P=NP" albo
"czy da się faktoryzować w czasie wielomianowym", albo
"udowodnić/obalić hipotezę Riemanna",
a kiedyś jeszcze - Wielkie Twierzenie Fermata.
I dla każdego z tych problemów możnaby zrobić analizę i studium
wykonalności, które by powiedziały jaki jest wymagany budżet, ilu
matematyków trzeba wynająć i ile im to czasu zajmie. Uważasz, że tak
się da?

> > Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> > Firma potrzebuje nowy model traktora, który będzie maił jakiś
> > specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> > okazuje się, że ten model grzęźnie w błocie i jako taki jest
> > bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> > wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> > który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> > 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> > lata.
>
> To zadna analogia. Jezeli klient nie wyartykuuje, ze traktor ma jezdzic po
> blocie i w nim nie grzeznac, to dostanie traktor, ktory byc moze bedzie, a
> byc moze nie bedzie grzeznac.

No ale ponieważ oprócz grzęźnięcia w błocie jest milion innych
problemów, które spowodują, że traktor będzie bezużyteczny, i ponieważ
w praktyce spisując umowę zleceniodawca będzie w stanie sobie
wyobrazić i zawrzeć klauule najwyżej na 100 tysięcy takich powodów, to
pozostanie jeszcze 900 tysięcy sposobów, żeby traktor był kompletnie
bezużyteczny, mimo że w 100% zgodny z umową:
być może będzie a być może nie będzie grzęznąć
silnik byc może się zatrze a byc może nie zatrze po dwóch minutach
pracy
chłodnia byc może będzie, a być może nie będzie cieknąć
opony być może się nie stopią, a być może się stopią w temperaturze
powyżej 30 stopni.
itd. itp.
Patrząc na to w ten sposób, zleceniodawca może się co najwyżej modlić
i liczyć na cud, że 100% zgodny z umową produkt będzie się w ogóle
nadawał do eksploatacji.

> Sek w tym, ze metody "agile" zakladaja, ze
> najpierw nalezy zrobic w pelni funkcjonalny traktor i za niego zaplacic, a
> potem zobaczyc czy sie nada.

Ale to jest przecież nieprawda. Agile (np. XP) zakłada, że
zleceniodawca wyśle swojego speca od traktorów żeby siedział z
zespołem projektującym traktor i z jednej strony mówił projektantom,
że to jest jednak bardzo wazna sprawa, żeby traktor nie grzęzł w
błocie. Zakłada, że po dwóch tygodniach będzie demo, gdzie zamawiający
będzie mógł zobaczyć pierwszy prototyp i spytać "a po błocie to to
pojedzie"? Że jeśli pierwszy protoyp grzęźnie w błocie, to spec od
traktorów zgłosi user story "wjeżdżam traktorem na błoto i chciałbym,
żeby on się nie zagrzebał" i przy planowaniu kolejnej iteracji i
odpowiednio określi jego ważność. I że zleceniodawca będzie wiedział,
że wykonawca pracuje nad jeżdżeniem po błocie, bo go jego
przedstawiciel o tym poinformuje.

> Normalni ludzie, jak nie sa pewni czego chca to robia _prototyp_ (lub serie
> prototypow). Ale nikt nie wymaga (w odroznieniu od agile), zeby prototyp byl
> w pelni funkcjonalny - bo po co za to placic? (zreszta to juz wtedy nie jest
> prototyp).

Ale cały development oprogramowania, to tworzenie prototypów.
Produkcja seryjna to tłoczenie płytek. :)

do góry