eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingProwadzenie/dokumentowanie projektu...
Ilość wypowiedzi w tym wątku: 50

  • 31. Data: 2013-01-05 12:46:15
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:

    > On 02/01/2013 17:28, AK wrote:
    >> Użytkownik "Wojciech Muła" <w...@g...com> napisał :
    >>
    >>> Agile skupia się na tworzeniu działającego produktu, nie dostarcza
    >>> żadnych narzędzi dla zespołu w celu tworzenia utrzymywalnego programu
    >> ^^^^^^^^^^^^^^^
    >>
    >> To (i calosc posta Wojtka) to dla mnie sedno tzw. Agile.
    >
    > Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia do
    > tworzenia utrzymywalnego programu. Przedtem było tak, że się tworzyło
    > program, a potem w ramach utrzymywania jego utrzymywalność się stopniowo
    > degradowała, aż dochodziło do tego, że taniej było zrobić rewrite niż
    > zmieniać istniejący kod.

    Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
    dlaczego dotychczas nam nie szło, teraz będzie super".

    --
    Edek


  • 32. Data: 2013-01-05 13:19:17
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Andrzej Jarzabek <a...@g...com>

    On 05/01/2013 11:46, Edek Pienkowski wrote:
    > Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:
    >>
    >> Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia do
    >> tworzenia utrzymywalnego programu. Przedtem było tak, że się tworzyło
    >> program, a potem w ramach utrzymywania jego utrzymywalność się stopniowo
    >> degradowała, aż dochodziło do tego, że taniej było zrobić rewrite niż
    >> zmieniać istniejący kod.
    >
    > Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
    > dlaczego dotychczas nam nie szło, teraz będzie super".

    Jest duży postęp w dziedzinie inżynierii oprogramowania, nic dziwneggo,
    że nowsze metody dają lepsze rezultaty niż stare.


  • 33. Data: 2013-01-05 18:55:50
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:

    > On 05/01/2013 11:46, Edek Pienkowski wrote:
    >> Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:
    >>>
    >>> Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia
    >>> do tworzenia utrzymywalnego programu. Przedtem było tak, że się
    >>> tworzyło program, a potem w ramach utrzymywania jego utrzymywalność
    >>> się stopniowo degradowała, aż dochodziło do tego, że taniej było
    >>> zrobić rewrite niż zmieniać istniejący kod.

    Powtórzę się: tu Agile juz niewiele pomoże.

    >> Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
    >> dlaczego dotychczas nam nie szło, teraz będzie super".
    >
    > Jest duży postęp w dziedzinie inżynierii oprogramowania, nic dziwneggo,
    > że nowsze metody dają lepsze rezultaty niż stare.

    Tak, od małpy do świnki morskiej nastąpiła długa droga ewolucji.

    Ja preferuję Agile, z tym że z zupełnie innych powodów niż prezentujesz.
    Waterfall góruje nad dowolnym amorfizmem.

    --
    Edek


  • 34. Data: 2013-01-05 20:06:54
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Marek Borowski <m...@...borowski.com>

    On 2013-01-05 18:55, Edek Pienkowski wrote:
    > Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
    >
    >
    > Ja preferuję Agile, z tym że z zupełnie innych powodów niż prezentujesz.
    > Waterfall góruje nad dowolnym amorfizmem.
    >
    W przypadku zmienajacych sie w trakcie wymagan klienta rowniez ? ;-)


    Pozdrawiam

    Marek


  • 35. Data: 2013-01-05 22:54:51
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sat, 05 Jan 2013 20:06:54 +0100, Marek Borowski wyszeptal:

    > On 2013-01-05 18:55, Edek Pienkowski wrote:
    >> Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
    >>
    >>
    >> Ja preferuję Agile, z tym że z zupełnie innych powodów niż
    >> prezentujesz.
    >> Waterfall góruje nad dowolnym amorfizmem.
    >>
    > W przypadku zmienajacych sie w trakcie wymagan klienta rowniez ? ;-)

    Eee, nie, waterfall będzie się toczył nawet jak klyent powie "nie,
    już mi sie odechciało" ;) Chyba że szef zadzwoni, żeby odejść od
    klawiatury.

    --
    Edek


  • 36. Data: 2013-01-06 17:25:45
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Andrzej Jarzabek <a...@g...com>

    On 05/01/2013 17:55, Edek Pienkowski wrote:
    > Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
    >
    >> On 05/01/2013 11:46, Edek Pienkowski wrote:
    >>> Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:
    >>>>
    >>>> Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia
    >>>> do tworzenia utrzymywalnego programu. Przedtem było tak, że się
    >>>> tworzyło program, a potem w ramach utrzymywania jego utrzymywalność
    >>>> się stopniowo degradowała, aż dochodziło do tego, że taniej było
    >>>> zrobić rewrite niż zmieniać istniejący kod.
    >
    > Powtórzę się: tu Agile juz niewiele pomoże.

    Nawet wtedy pomoże. Dokładna metoda opisana jest w "Working Effectively
    With Legacy Code" Michaela Feathersa. Przede wszystkim jednak chodzi o
    to, żeby do takiej sytuacji nie doprowadzić, i skuteczne narzędzia do
    tego dają ci TDD i incremental refactoring (plus być może kilka innych
    rzeczy, jak dobre coding standards i karty CRC).

    >> Jest duży postęp w dziedzinie inżynierii oprogramowania, nic dziwneggo,
    >> że nowsze metody dają lepsze rezultaty niż stare.
    >
    > Tak, od małpy do świnki morskiej nastąpiła długa droga ewolucji.

    To trochę OT, ale proponuję podszkolić się z biologii.


  • 37. Data: 2013-01-06 18:03:39
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Edek Pienkowski <e...@g...com>

    Dnia Sun, 06 Jan 2013 16:25:45 +0000, Andrzej Jarzabek wyszeptal:

    > On 05/01/2013 17:55, Edek Pienkowski wrote:
    >> Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
    >>
    >>> On 05/01/2013 11:46, Edek Pienkowski wrote:
    >>>> Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:
    >>>>>
    >>>>> Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia
    >>>>> do tworzenia utrzymywalnego programu. Przedtem było tak, że się
    >>>>> tworzyło program, a potem w ramach utrzymywania jego utrzymywalność
    >>>>> się stopniowo degradowała, aż dochodziło do tego, że taniej było
    >>>>> zrobić rewrite niż zmieniać istniejący kod.
    >>
    >> Powtórzę się: tu Agile juz niewiele pomoże.
    >
    > Nawet wtedy pomoże. Dokładna metoda opisana jest w "Working Effectively
    > With Legacy Code" Michaela Feathersa. Przede wszystkim jednak chodzi o
    > to, żeby do takiej sytuacji nie doprowadzić, i skuteczne narzędzia do
    > tego dają ci TDD i incremental refactoring (plus być może kilka innych
    > rzeczy, jak dobre coding standards i karty CRC).

    No tak, jak coś jest w jakiejś książce, znaczy to jest Święta prawda ;)

    Agile składa się z wielu technik, ale celem większości jest skrócenie
    cyklu feedbacku w wielu procesach, z których zbudowany jest większy
    proces zwany produkcją oprogramowania. Do czego nawiązuje nazwa.

    Przy czym milczącym założeniem jest, że te procesy faktycznie istnieją,
    i że jest nad nimi kontrola, czyli istnieje reakcja adekwatna do
    sprzężenia zwrotnego. Tak jak w kontroli procesów przemysłowych
    procesy i ich kontrola wymagają tych elementów, pomimo tego, że
    tutaj część maszynerii jest białkowa; procesy owe dotyczą wytwarzania
    oprogramowania, dopiero one są inżynierą oprogramowania czyli materią,
    sam Agile/Waterfall to ogólna rama kontroli procesów, same procesy
    są bardzo podobne - z wymienionych testy i coding standards
    są uniwersalne, dochodzi wiele spraw technicznych i ogólne
    zarządzanie utrzymujące wysokie standardy.

    No ale jak ktoś mówi "przepiszmy wszystko", to trochę tak jakby
    ktoś w towarzystwie powiedział "jesteście głupi" (nie mylić
    z "czy aby jesteście trzeźwi, obywatelu"). Albo faktycznie muszą
    gruntownie zmienić zachowanie i jest to mesjasz, który odmieni
    oblicze projektu, albo też nie do końca zrównoważony łepek,
    który ani nie potrafi modyfikować kodu, ani też nie będzie
    potrafił go napisać (tym bardziej) od początku, nie mówiąc
    o "lepiej". Tak czy inaczej, bez więcej niż jednego podbitego
    oka się nie obędzie, więc najwyraźniej coś do tej pory mocno
    zawiodło: albo faktycznie proces pisania kodu nie podlegał
    żadnej kontroli, albo w grupie jest ktoś "nie do końca rozumiejący
    sytuację" i "radykalny wobec istniejących norm społecznych".
    (Słyszałem już parę razy "przepiszmy", częściej był
    to głupi pomysł, ale widziałem też uzasadniony. Zawsze osoba
    wykazująca wtedy niezbędną specjalną troskę była sowicie opłacana,
    błędy katastrofalne kosztują).

    >>> Jest duży postęp w dziedzinie inżynierii oprogramowania, nic
    >>> dziwneggo,
    >>> że nowsze metody dają lepsze rezultaty niż stare.
    >>
    >> Tak, od małpy do świnki morskiej nastąpiła długa droga ewolucji.
    >
    > To trochę OT, ale proponuję podszkolić się z biologii.

    To byłaby połowiczna analiza tekstu pisanego.

    --
    Edek


  • 38. Data: 2013-01-07 01:09:21
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Andrzej Jarzabek <a...@g...com>

    On 06/01/2013 17:03, Edek Pienkowski wrote:
    > Dnia Sun, 06 Jan 2013 16:25:45 +0000, Andrzej Jarzabek wyszeptal:
    >>
    >> Nawet wtedy pomoże. Dokładna metoda opisana jest w "Working Effectively
    >> With Legacy Code" Michaela Feathersa. Przede wszystkim jednak chodzi o
    >> to, żeby do takiej sytuacji nie doprowadzić, i skuteczne narzędzia do
    >> tego dają ci TDD i incremental refactoring (plus być może kilka innych
    >> rzeczy, jak dobre coding standards i karty CRC).
    >
    > No tak, jak coś jest w jakiejś książce, znaczy to jest Święta prawda ;)

    Nie znaczy, ale w tym przypadku akurat tak jest. Podałem namiar na
    literaturę w celu odniesienia do opis tego, o czym mówię - dowodem
    skuteczności natomiast nie jest istnienie książki, tylko korroboracja
    tych technik w bardzo wielu projektach - również przeze mnie.

    > Agile składa się z wielu technik, ale celem większości jest skrócenie
    > cyklu feedbacku w wielu procesach, z których zbudowany jest większy
    > proces zwany produkcją oprogramowania. Do czego nawiązuje nazwa.

    No więc jedną z metodologii, na których zbudowany został ruch Agile jest
    XP, który właśnie wprowadził techniki, o których mówię - jeszcze zanim
    cokolwiek się nazywało Agile. Od tego czasu zresztą te techniki zostały
    mocno rozwinięte i są po prostu częścią ogółu technik określanych jako
    Agile.

    Opierają się one jak najbardziej na cyklach feedbacku (tych
    najkrótszych, liczonych nawet w minutach), ale zasada, z której
    wypływają jest inna: jeśli oddajesz oprogramowanie często, np. co
    tydzień, i z zasady oddajesz je w stanie nadającym się do produkcji, to
    nie masz szczególnych powodów, żeby starać się zrobić więcej w jednym
    tygodniu, jeśli to oznacza, że w następnych zrobisz mniej. Zasadą jest
    "sustainable pace" - starasz się w każdej iteracji oddawać podobnej
    wielkości kawałek roboty, a potem na tym budujesz plany szacujące kiedy
    mniej więcej co zostanie zrobione. Dlatego też jeśli taki proces ma
    działać, twój kod musi cały czas być "maintainable", bo jak się w nim
    zagrzebiesz, to stracisz możliwość dostarczania sensownej wielkości
    inkrementów w kolejnych tygodniach.

    [...]
    > oprogramowania, dopiero one są inżynierą oprogramowania czyli materią,
    > sam Agile/Waterfall to ogólna rama kontroli procesów, same procesy
    > są bardzo podobne - z wymienionych testy i coding standards
    > są uniwersalne, dochodzi wiele spraw technicznych i ogólne
    > zarządzanie utrzymujące wysokie standardy.

    TDD to nie tylko testy, poza tym oczywiście można stosować te wszystkie
    rzeczy nawet w ramach procesów które nie mają nic wspólnego z Agile.

    Ja tylko polemizowałem z tym, że Agile "nie daje narzędzi" - otóż daje,
    bardzo skuteczne narzędzia, tylko trzeba wiedzieć gdzie patrzeć. Prakyki
    Agile tworzą pewne spektrum od "management practices" do "engineering
    practices". Jeśli szukamy narzędzi do utrzymywania "maintainability"
    kodu, to raczej będą one po stronie "engineering" nie "management"
    (gdzie np. leży cały Scrum).

    > No ale jak ktoś mówi "przepiszmy wszystko", to trochę tak jakby
    > ktoś w towarzystwie powiedział "jesteście głupi" (nie mylić
    > z "czy aby jesteście trzeźwi, obywatelu"). Albo faktycznie muszą
    > gruntownie zmienić zachowanie i jest to mesjasz, który odmieni
    > oblicze projektu, albo też nie do końca zrównoważony łepek,
    > który ani nie potrafi modyfikować kodu, ani też nie będzie
    > potrafił go napisać (tym bardziej) od początku, nie mówiąc
    > o "lepiej". Tak czy inaczej, bez więcej niż jednego podbitego
    > oka się nie obędzie, więc najwyraźniej coś do tej pory mocno
    > zawiodło: albo faktycznie proces pisania kodu nie podlegał
    > żadnej kontroli, albo w grupie jest ktoś "nie do końca rozumiejący
    > sytuację" i "radykalny wobec istniejących norm społecznych".
    > (Słyszałem już parę razy "przepiszmy", częściej był
    > to głupi pomysł, ale widziałem też uzasadniony. Zawsze osoba
    > wykazująca wtedy niezbędną specjalną troskę była sowicie opłacana,
    > błędy katastrofalne kosztują).

    Nie do końca wiem jak zinterpretować tę wypowiedź. Ja w życiu
    uczestniczyłem w kilku rewrite-ach, i newt nie twierdzęę, że to zawsze
    zły pomysł (chociaż zawsze ryzykowny). Natomiast jet to świadectwo
    osatecznego krachu "maintainability" - pomijając szczególne sytuacje,
    jeśli znajdujemy się w sytuacji, gdzie bardziej opłaca się napisać coś
    od nowa niż poprawiać istniejący program, to raczej mamy do czynienia z
    nagromadzeniem dużej ilości błędów, z której nie bardzo wiadomo, jak się
    wycofać. Zwykle takich decyzji się lekką ręką nie podejmuje.

    >>>> Jest duży postęp w dziedzinie inżynierii oprogramowania, nic
    >>>> dziwneggo,
    >>>> że nowsze metody dają lepsze rezultaty niż stare.
    >>> Tak, od małpy do świnki morskiej nastąpiła długa droga ewolucji.
    >> To trochę OT, ale proponuję podszkolić się z biologii.
    >
    > To byłaby połowiczna analiza tekstu pisanego.

    Masz na myśli tekst "O pochodzeniu gatunków" Darwina?


  • 39. Data: 2013-01-10 10:13:18
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: firr kenobi <p...@g...com>

    W dniu poniedziałek, 31 grudnia 2012 18:12:49 UTC+1 użytkownik M.M. napisał:
    > W dniu niedziela, 30 grudnia 2012 20:42:52 UTC+1 użytkownik firr kenobi napisał:
    >
    > >(zeby cos zaprogramowac wystarczy zaprogramowac a zeby cos ladnie wygladalo
    >
    > >czeba to czasem programowac 15 razy nim sie trafi na cos co wyglada a i tak
    >
    > >posniej efekt sie moze posypac przy kolejnych dobudowach)
    >
    > Powiedzmy umownie, ze sa dwa rodzaje aplikacji.
    >
    >
    >
    > Jedne po prostu sie pisze, maja dzialac, a szczegoly typu: szybkosc
    >
    > dzialania, ilosc pamieci, rodzaj wykorzystanych technik programistycznych -
    >
    > mozna z jakis powodow calkowicie, albo prawie calkowicie pominac.
    >
    >
    >
    > Drugi rodzaj to taki, w których rzeźbi się tygodniami, żeby przyspieszyć o
    >
    > kilka milisekund, albo myśli się miesiącami, żeby opracować lepszy algorytm.
    >
    > Czasami trzeba udowodnić czy dany algorytm w ogóle może rozwiązywać jakieś
    >
    > zadanie. Do tego drugiego rodzaju można by jeszcze sporo dorzucić, Ty np.
    >
    > dorzucasz dopracowanie grafiki, efektów, itd.
    >
    >
    >
    >
    >
    > Wszystko wskazywałoby na to, że ten drugi rodzaj aplikacji jest dużo
    >
    > trudniejszy, bardziej ambitny, czy wymagający większych umiejętności. Okazuje
    >
    > się jednak, że ten pierwszy typ aplikacji, może po pierwsze znacznie
    >
    > się rozrosnąć - zgranie dużej ilości rożnych elementów programu powoduje,
    >
    > że staje się on równie trudny jak te z drugiego rodzaju. Po drugie, może
    >
    > być bardzo mały budżet na ich wykonanie, wtedy trzeba taką aplikację szybko
    >
    > zrealizować żeby wyjść na jakiś minimalny plus.
    >

    no i co? ja sie prawie wylacznie interesuje
    ta opcja z optymalizacja no i tyle -
    [[ aczkolwiek ostatnio wogole wzialem sobie
    troche urlop od kodowania znowu "nie firrr,
    to koniec, nie bedzie nic wiecej... ZALUJE ZE
    CIE ZNALAM A A xD" ;-) ]]
    - Teraz jest w sumie tak ze pc ma akurat
    dosyc mocy do pewnych zastosowan ale z
    drugiej strony ciagle jednak trzeba sie
    nabiedzic by ramka miala 15 ms a nie 30
    a jest to bardzo znaczna roznica w
    feelingu






  • 40. Data: 2013-01-15 23:28:58
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Gotfryd Smolik news <s...@s...com.pl>

    Ja tak z pozoru offtopicznie:

    On Thu, 27 Dec 2012, boryspower wrote:

    > Przykład: Stworzenie aplikacji do fakturowania

    1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
    2. Spytać "fachowca" jak ma być
    3. Stwierdzić że coś nie pasuje
    4. Sprawdzić to i owo w internecie
    5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

    Potem można zabrać się za rozważania jak program ma działać.

    Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
    na to jak można wtopić na błędach założeń :)
    Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
    podatek który musi być ujawniany na dokumencie) jest dopuszczalne
    na wiele sposobów, w tym takich trudniejszych do wymyślenia,
    ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
    się do któregoś spośród tych wielu) i wtedy na .podatki pojawia
    post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
    bo twierdzą że system nie pozwala" :P

    Nie, nie mam na myśli stawki itede :)

    Obstawiam że takich przypadków jest sporo - coś co wydaje się
    proste zawiera pułapki które później trudno usunąć.
    Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
    "24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
    umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
    poprawienie wszystkich pól, bo nie sposób przewidzieć która
    z kombinacji "metod" może wyskoczyć.
    Uczciwie - przewidziałbyś?
    Nie ma to nic wspólnego z tym co opisałeś - co wykonawca może
    zrobić doskonale po stworzeniu własnego opisu.

    > - jak przygotować dokumentację/opis projektu

    Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
    narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
    (patrz p.1 :), polecam osobiście zajrzeć do treści)

    pzdr, Gotfryd

strony : 1 ... 3 . [ 4 ] . 5


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: