eGospodarka.pl
eGospodarka.pl poleca

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

  • 141. Data: 2011-05-18 14:15:09
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

    > On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
    >>
    >> 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?
    >

    Z tego wynika, ze to cale "agile" to machanie rekami i "buzzwordy" i - jak
    napisalem - nikt tak naprawde ich nie stosuje (bo sie nie da) ale wszyscy o
    tym mowia.
    Co komu po metodykach, ktore nawet nie probuja odpowiadac na istotne pytania
    dot procesu produkcji oprogramowania? (Juz pomijajac kwestie, ze odpowiedzi
    na pytania, na ktore odpowiadaja sa hmm... kontrowersyjne)

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

    Ogon macha psem.
    To pytanie jest interesujace dla propagatorow agile, a nie dla kogos, kto ma
    zaplanowac projekt.

    >> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
    >> sprzet / ludzi do stworzenia centrum testowego?
    >
    > W tej kwestii akurat XP ma sporo do powiedzenia.
    >

    Eee tam. Proponuje przeczytac ksiazke powiedzmy:
    http://www.amazon.com/Testing-Object-Oriented-System
    s-Models-
    Patterns/dp/0201809389

    XP do testowania sie ma tyle, ze mowi "trzeba testowac".

    [ciach]
    >> > 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.

    "Agile" za to mowia, ze w ogole nie nalezy probowac. To nie do przyjecia o
    tyle, ze wywraca do gory nogami cale doswiadczenie wielu (wszystkich?)
    organizacji. Trzeba by rezygnowac z tworzenia wieloletnich planow
    inwestycyjnych, budzetowania z perspektywa dluzsza niz miesiac itp.
    Jak chcesz przekonac inwestorow gieldowych, ze inwestycja w oprogramowanie
    ma sens, jezeli jedyne co im jestes w stanie powiedziec, to ze "wywalimy
    tylko X PLN na dwa miesiace pracy zespolu i wtedy zobaczymy co dalej".

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

    Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic, ze
    sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
    programujemy.

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

    A jakie np?

    --
    Michal


  • 142. Data: 2011-05-18 14:39:48
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

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

    Nie wiem jak "wziecie ryzyka" moze byc substytutem (zamiennikiem) produktu.

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

    Tyle, ze przy "agile" nie kupujemy produktu tylko _prace_ - to tu jest
    roznica, a nie w sposobach zabezpieczania potencjalnych roszczen.

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

    Oczywiscie. Ale i tak jest taniej niz robic produkt do momentu az juz
    bedziemy pewni, ze sie nie da.

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

    To jest sprowadzenie ad absurdum, ktore nie ma IMO w tej dyskusji
    zastosowania, bo projekty IT w przemysle nie sa badaniami naukowymi
    (oczywiscie poza centrami badan). Podobnie jak budowa mostu nie jest
    projektem majacym na celu wynalezienie antygrawitacji by przenosic pojazdy
    ponad rzeka.

    [ciach]
    >> 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.
    >

    No a jednak jak kupujesz samochod to nic takiego sie nie dzieje. Rozumiem,
    ze zanim go kupisz, to wspolpracujesz z dealerem na zasadzie "agile".

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

    No to albo klient powie o jakims wymaganiu albo nie powie - sugerujesz ze
    "agile" jakos magicznie wplywa na klienta, ze powie?

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

    Nie rozumiem po co klient ma placic za stworzenie demo traktora tylko po to,
    zeby powiedziec, ze traktor ma jezdzic po blocie. Taniej by bylo po prostu
    sie zastanowic po co nam ten traktor i jak go bedziemy uzywac.

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

    To jest wlasnie teza propagowana przez zwolennikow "agile". Ja sie z nia nie
    zgadzam - i _nigdy_ nie wdrazam produkcyjnie prototypu (podobnie jak nie
    kupuje prototypu samochodu, zeby jechac nim na wakacje).

    --
    Michal


  • 143. Data: 2011-05-18 15:00:24
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

    > On May 18, 11:06 am, Michal Kleczek <k...@g...com> wrote:
    >>
    >> 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
    >
    [snip]
    > Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
    > wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
    > około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
    > pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
    > to do wymagań i dalej planować development tak, żeby w miarę
    > możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
    > zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
    > jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
    > taką funkcjonalnością, ale za to w dwa miesiące.

    To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
    _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie, to
    oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.

    --
    Michal


  • 144. Data: 2011-05-18 15:13:07
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    On May 18, 3:15 pm, Michal Kleczek <k...@g...com> wrote:
    > Andrzej Jarzabek wrote:
    > > On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
    >
    > > Tylko że właściwie co z tego wynika?
    >
    > Z tego wynika, ze to cale "agile" to machanie rekami i "buzzwordy" i - jak
    > napisalem - nikt tak naprawde ich nie stosuje (bo sie nie da) ale wszyscy o
    > tym mowia.

    No więc właśnie to bzdura, bo nic takiego nie wynika. Jeśli kopiesz
    rowy koparką, ale w ramach kopania rowów masz też etap gdzie
    decydujesz czy i gdzie kopać, i do decydowania o tym koparki nie
    używasz, to nie znaczy, że ta cała koparka jest bezuzyteczna, bo
    przecież jej i tak "naprawdę" nie używasz.

    > Co komu po metodykach, ktore nawet nie probuja odpowiadac na istotne pytania
    > dot procesu produkcji oprogramowania? (Juz pomijajac kwestie, ze odpowiedzi
    > na pytania, na ktore odpowiadaja sa hmm... kontrowersyjne)

    Oczywiście że próbują i odpowiadają na istotne pytania. Że nie na
    wszystkie? Otóż to po nich komu, że na niektóre jednak odpowiadają i
    że stosowanie tych odpowiedzi przynosi korzyści.

    > >> 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?
    >
    > Ogon macha psem.
    > To pytanie jest interesujace dla propagatorow agile, a nie dla kogos, kto ma
    > zaplanowac projekt.

    To jest pytanie interesujące dla kogoś, kto decyduje jakie metody/
    procesy stosować dla jakich projektów. Samo pytanie jest przecież
    zależne od szczegółów projektu.

    > >> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
    > >> sprzet / ludzi do stworzenia centrum testowego?
    >
    > > W tej kwestii akurat XP ma sporo do powiedzenia.
    >
    > Eee tam. Proponuje przeczytac ksiazke
    powiedzmy:http://www.amazon.com/Testing-Object-Orien
    ted-Systems-Models-
    > Patterns/dp/0201809389

    Załóżmy, że przynajmniej na razie jej nie przeczytam. Możesz jakoś bez
    tego rozwinąć swoje "e tam"?

    > XP do testowania sie ma tyle, ze mowi "trzeba testowac".

    Nieprawda. Proponuję przeczytać jakąś książkę o XP, powiedzmy
    http://www.amazon.com/Art-Agile-Development-James-Sh
    ore/dp/0596527675/

    > >> 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.
    >
    > "Agile" za to mowia, ze w ogole nie nalezy probowac. To nie do przyjecia o
    > tyle, ze wywraca do gory nogami cale doswiadczenie wielu (wszystkich?)
    > organizacji.

    To nie tak. Agile mówi, że skutecznośc długotrwałego i skrupulatnego
    planowania nie jest dużo większa niż skuteczność planowania w postaci
    półodzinnego zebrania, a za to dużo więcej kosztuje no i pochłania
    czas.

    > Trzeba by rezygnowac z tworzenia wieloletnich planow
    > inwestycyjnych, budzetowania z perspektywa dluzsza niz miesiac itp.

    E tam. Budżetowanie i inwestowanie nie jest przecież funkcją
    dostarczenia takich czy innych ficzerów w kodzie, tylko strumieni
    przychodów i wydatków. Dla dostawcy oprogramowania każdy nowy projekt
    to niewspółmierne ryzyko, pieniądze robi się na ciągnięciu kasy od
    istniejących klientów za istniejące produkty. Dla większej firmy
    zawsze kalkulacja wygląda tak: "żeby się rozwijać, musimy zrobić nowy
    produkt. Zapewne na tym stracimy, ale jest szansa, że produkt odniesie
    sukces i w przyszłości zamieni się w stałe źródło zysków". Żadne
    planowanie w tym nie pomoże, bo przecież nie uwzględnisz w planowaniu
    tego, czy pomysł jest dobry, czy oprogramowanie będzie dobrej jakości
    i jak się świat zmieni w przyszłości.

    Oczywiście w przypadku firmy robiącej program na konkrene zamówienie,
    strumienie przychodów i wydatków zależą od podpisanych kontraktów i od
    kosztów operacyjnych, więc też się poddają łatwemu planowaniu
    niezależnie od tego, czy istnieje plan implementowania konkretnch
    features.

    > Jak chcesz przekonac inwestorow gieldowych, ze inwestycja w oprogramowanie
    > ma sens, jezeli jedyne co im jestes w stanie powiedziec, to ze "wywalimy
    > tylko X PLN na dwa miesiace pracy zespolu i wtedy zobaczymy co dalej".

    Ale o czym ty mówisz? O firmie, która nie ma gotowych produktów, nie
    ma płacących klientów, ma tylko pomysł i zespół - i wchodzi na giełdę?

    > > 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.
    >
    > Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic, ze
    > sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
    > programujemy.

    Agile też na tym polega. Z tą różnicą, że myślenie jest timeboxowane
    na 15 minut. :)

    > >> 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.
    >
    > A jakie np?

    Np. retrospective.


  • 145. Data: 2011-05-18 15:13:07
    Temat: Re: ilu jest programistow na swiecie?
    Od: A.L. <l...@a...com>

    On Wed, 18 May 2011 04:21:53 -0700 (PDT), Andrzej Jarzabek
    <a...@g...com> wrote:

    >Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
    >wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
    >około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
    >pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
    >to do wymagań i dalej planować development tak, żeby w miarę
    >możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
    >zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
    >jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
    >taką funkcjonalnością, ale za to w dwa miesiące.

    W dwa meisiace to sie mozna podrapac w glowe.

    W dwa meisiace to student nie dokonczy programu studenckiego.

    "Agile" a wczesniej "extreme programming" to "metodologie" dla
    kretynow i neiudacznikow z przemyslu ktorzy nie wiedza jak porzadnei
    zorganizowac prace, jak robic specyfikacje projektowe, jak
    przetsrzegac tych specyfikacji, jak robic testowanie i potem jak robic
    dokumentacje.

    To tak jakby zaczac budowanei domu od sprowadzenia ciezarowki z
    betonem i "Wacek, lejmy beton! Co tam projekt, niepotzrebne odkuje sie
    potem!"

    A.L.


  • 146. Data: 2011-05-18 15:23:52
    Temat: Re: ilu jest programistow na swiecie?
    Od: "R. P." <r...@w...to.wp.pl>

    A.L. wrote:
    > To tak jakby zaczac budowanei domu od sprowadzenia ciezarowki z
    > betonem i "Wacek, lejmy beton! Co tam projekt, niepotzrebne odkuje sie
    > potem!"

    W PL wlasnie tak sie buduje ;)


  • 147. Data: 2011-05-18 15:26:02
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    R. P. wrote:

    > A.L. wrote:
    >> To tak jakby zaczac budowanei domu od sprowadzenia ciezarowki z
    >> betonem i "Wacek, lejmy beton! Co tam projekt, niepotzrebne odkuje sie
    >> potem!"
    >
    > W PL wlasnie tak sie buduje ;)

    Ale ideologia "agile" to USA pochodzi...

    --
    Michal


  • 148. Data: 2011-05-18 15:40:08
    Temat: Re: ilu jest programistow na swiecie?
    Od: Andrzej Jarzabek <a...@g...com>

    On May 18, 4:00 pm, Michal Kleczek <k...@g...com> wrote:
    > Andrzej Jarzabek wrote:
    > > On May 18, 11:06 am, Michal Kleczek <k...@g...com> wrote:
    >
    > >> 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
    >
    > [snip]
    > > Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
    > > wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
    > > około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
    > > pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
    > > to do wymagań i dalej planować development tak, żeby w miarę
    > > możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
    > > zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
    > > jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
    > > taką funkcjonalnością, ale za to w dwa miesiące.
    >
    > To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
    > _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie, to
    > oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.

    Można to też ująć w ten sposób, że prawie zawsze złożone
    oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
    minimalnym stopniu, rdzeń.

    Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
    miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
    produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
    w dowolnym momencie. Od tego memntu masz możliwość ustalania, które
    konkretnie dodatkowe ficzery implementować w jakiej kolejności tak,
    żeby użytecznośc produktu rosła jak najszybciej, żeby stakeholder mógł
    w pewnym momencie powiedzieć "to skoro mamy już killer ficzer A,
    chociaż nie mamy jeszcze B i C, które też by mi się przydały, to
    jednak bym chciał wdrożyć już produkt z A a bez B i C, bo już mogę na
    tym zacząć zarabiać. To kiedy mogę dostać wersję 1.0?" i usłyszeć
    odpowiedź "za 2 tygodnie".


  • 149. Data: 2011-05-18 15:51:47
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

    > On May 18, 3:15 pm, Michal Kleczek <k...@g...com> wrote:
    >> Andrzej Jarzabek wrote:
    >> > On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
    >>
    >> > Tylko że właściwie co z tego wynika?
    >>
    >> Z tego wynika, ze to cale "agile" to machanie rekami i "buzzwordy" i -
    >> jak napisalem - nikt tak naprawde ich nie stosuje (bo sie nie da) ale
    >> wszyscy o tym mowia.
    >
    > No więc właśnie to bzdura, bo nic takiego nie wynika. Jeśli kopiesz
    > rowy koparką, ale w ramach kopania rowów masz też etap gdzie
    > decydujesz czy i gdzie kopać, i do decydowania o tym koparki nie
    > używasz, to nie znaczy, że ta cała koparka jest bezuzyteczna, bo
    > przecież jej i tak "naprawdę" nie używasz.

    To oznacza tylko tyle, ze ta "koparka" jest malo wazna/interesujaca z punktu
    widzenia calosci przedsiewziecia. Reklamowanie jej jako panaceum (a tak jest
    reklamowane "agile") na cokolwiek jest albo glupota albo oszustwem.

    [ciach]
    >
    >> >> 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?
    >>
    >> Ogon macha psem.
    >> To pytanie jest interesujace dla propagatorow agile, a nie dla kogos, kto
    >> ma zaplanowac projekt.
    >
    > To jest pytanie interesujące dla kogoś, kto decyduje jakie metody/
    > procesy stosować dla jakich projektów. Samo pytanie jest przecież
    > zależne od szczegółów projektu.
    >

    Tyle ze zanim zadamy to pytanie, to trzeba np. okreslic wielkosc projektu i
    wielkosc potrzebnego zespolu. Zeby to zrobic trzeba wykonac jakies czynnosci
    (hint: analiza wymagan i projekt - w kazdym razie wstepny projekt).

    >> >> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
    >> >> sprzet / ludzi do stworzenia centrum testowego?
    >>
    >> > W tej kwestii akurat XP ma sporo do powiedzenia.
    >>
    >> Eee tam. Proponuje przeczytac ksiazke
    >> powiedzmy:http://www.amazon.com/Testing-Object-Orien
    ted-Systems-Models-
    >> Patterns/dp/0201809389
    >
    > Załóżmy, że przynajmniej na razie jej nie przeczytam. Możesz jakoś bez
    > tego rozwinąć swoje "e tam"?
    >
    >> XP do testowania sie ma tyle, ze mowi "trzeba testowac".
    >
    > Nieprawda. Proponuję przeczytać jakąś książkę o XP, powiedzmy
    > http://www.amazon.com/Art-Agile-Development-James-Sh
    ore/dp/0596527675/
    >

    Tej akurat nie czytalem - wystarczyly mi wypociny niejakiego Kenta Becka -
    oparcie testowania (ale takze przeciez i projektu oprogramowania, ktory
    zarowno wynika jak i wplywa na sposoby testowania) o automatyczne "unit
    testy" i "customer testing" (jak w XP) jest po prostu liznieciem tematu.
    Ksiazka (gruba jak cholera - ok 1tys stron) tak naprawde tylko ilustruje jak
    szeroki on jest i ze nie ma mozliwosci organizacji procesu wytworczego bez
    przewidzenia miejsca dla _specjalizowanej_ grupy/roli testerow czy tez
    projektantow testow (bo przecietny programista nie ma o tym wiekszego
    pojecia). Znane mi metodyki agile (fakt - tylko XP) nie przewiduja takiej
    roli.

    >> >> 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.
    >>
    >> "Agile" za to mowia, ze w ogole nie nalezy probowac. To nie do przyjecia
    >> o tyle, ze wywraca do gory nogami cale doswiadczenie wielu (wszystkich?)
    >> organizacji.
    >
    > To nie tak. Agile mówi, że skutecznośc długotrwałego i skrupulatnego
    > planowania nie jest dużo większa niż skuteczność planowania w postaci
    > półodzinnego zebrania, a za to dużo więcej kosztuje no i pochłania
    > czas.

    Jasne - w pol godziny mozna zaplanowac budowe nietrywialnego systemu
    informatycznego. Ciekawe dlaczego nie daje sie tego zrobic z banalnym
    remontem parokilometrowego odcinka drogi powiatowej.

    >
    >> Trzeba by rezygnowac z tworzenia wieloletnich planow
    >> inwestycyjnych, budzetowania z perspektywa dluzsza niz miesiac itp.
    >
    > E tam. Budżetowanie i inwestowanie nie jest przecież funkcją
    > dostarczenia takich czy innych ficzerów w kodzie, tylko strumieni
    > przychodów i wydatków.

    No ale skad sie biora wydatki? Przeciez taki zespol programistow XP to spory
    koszt, ktory trzeba uwzglednic.

    > Dla dostawcy oprogramowania każdy nowy projekt
    > to niewspółmierne ryzyko, pieniądze robi się na ciągnięciu kasy od
    > istniejących klientów za istniejące produkty. Dla większej firmy
    > zawsze kalkulacja wygląda tak: "żeby się rozwijać, musimy zrobić nowy
    > produkt. Zapewne na tym stracimy, ale jest szansa, że produkt odniesie
    > sukces i w przyszłości zamieni się w stałe źródło zysków". Żadne
    > planowanie w tym nie pomoże, bo przecież nie uwzględnisz w planowaniu
    > tego, czy pomysł jest dobry, czy oprogramowanie będzie dobrej jakości
    > i jak się świat zmieni w przyszłości.

    Oczywiscie, ze uwzglednisz - sugerujesz, ze taki dajmy na to MS nie planuje
    wydatkow, deadlinow i ficzerow w nowej wersje Windows? (tylko prosze bez
    argumentu, ze Win jest be, bo to nie ma nic do rzeczy - zreszta nie jest
    taki be skoro wszyscy kupuja)

    >
    > Oczywiście w przypadku firmy robiącej program na konkrene zamówienie,
    > strumienie przychodów i wydatków zależą od podpisanych kontraktów i od
    > kosztów operacyjnych, więc też się poddają łatwemu planowaniu
    > niezależnie od tego, czy istnieje plan implementowania konkretnch
    > features.

    Oczywiscie, ze nie, bo takie podejscie zaklada, ze mamy stale koszty (w
    postaci stalego zespolu) lub stale przychody (bo z grubsza za kazdy
    "feature" jest dodatkowa kasa). A przeciez ludzi mozna po prostu (w
    uproszczeniu) zwolnic, jak sa niepotrzebni - tym samym zmniejszajac koszty.
    Lub mozna dorzucic features zwiekszajac margines zysku.

    >
    >> Jak chcesz przekonac inwestorow gieldowych, ze inwestycja w
    >> oprogramowanie ma sens, jezeli jedyne co im jestes w stanie powiedziec,
    >> to ze "wywalimy tylko X PLN na dwa miesiace pracy zespolu i wtedy
    >> zobaczymy co dalej".
    >
    > Ale o czym ty mówisz? O firmie, która nie ma gotowych produktów, nie
    > ma płacących klientów, ma tylko pomysł i zespół - i wchodzi na giełdę?
    >

    Nie - firma notowana na gieldzie musi non-stop przekonywac inwestorow, ze
    jej plany inwestycyjne maja sens - w przeciwnym wypadku akcje stanieja,
    posiadacze akcji straca, zdenerwuja sie i zmienia zarzad. Proste jak budowa
    cepa.

    >> > 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.
    >>
    >> Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic,
    >> ze sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
    >> programujemy.
    >
    > Agile też na tym polega. Z tą różnicą, że myślenie jest timeboxowane
    > na 15 minut. :)

    Na to odpowiem w oddzielnym poscie, bo to (zartobliwe) ale istotne
    spostrzezenie.

    >
    >> >> 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.
    >>
    >> A jakie np?
    >
    > Np. retrospective.

    Jakis link?

    --
    Michal


  • 150. Data: 2011-05-18 16:05:32
    Temat: Re: ilu jest programistow na swiecie?
    Od: Michal Kleczek <k...@g...com>

    Andrzej Jarzabek wrote:

    > On May 18, 4:00 pm, Michal Kleczek <k...@g...com> wrote:
    >> Andrzej Jarzabek wrote:
    >> > On May 18, 11:06 am, Michal Kleczek <k...@g...com> wrote:
    >>
    >> >> 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
    >>
    >> [snip]
    >> > Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
    >> > wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
    >> > około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
    >> > pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
    >> > to do wymagań i dalej planować development tak, żeby w miarę
    >> > możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
    >> > zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
    >> > jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
    >> > taką funkcjonalnością, ale za to w dwa miesiące.
    >>
    >> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
    >> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie,
    >> to oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.
    >
    > Można to też ująć w ten sposób, że prawie zawsze złożone
    > oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
    > minimalnym stopniu, rdzeń.
    >

    Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz uzyteczny
    rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie do
    produkcji?
    Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
    "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
    dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej firma
    moze stracic tzw "dobre imie" co sie przeklada na przyszle przychody.

    > Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
    > miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
    > produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
    > w dowolnym momencie.

    Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms innym
    niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy problem).

    --
    Michal

strony : 1 ... 10 ... 14 . [ 15 ] . 16 ... 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: