eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingpl. usenet o agile
Ilość wypowiedzi w tym wątku: 143

  • 31. Data: 2013-07-19 03:08:38
    Temat: Re: pl. usenet o agile
    Od: A.L. <a...@a...com>

    On Fri, 19 Jul 2013 00:05:48 +0100, Andrzej Jarzabek
    <a...@g...com> wrote:

    >wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
    >komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
    >przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
    >komentarze są bez sensu.
    >

    Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
    zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
    CO. Inaczej zrobi sie niekontrolowany burdel

    >To, co przedstawiasz, to fałszywa alternatywa. Albo zatrudniasz
    >fachowców i wtedy masz wybór między zatrudnianiem fachowców i
    >testowaniem a zatrudnianiem fachowców i nie testowaniem,

    To jest nonsens. WSZYSCY robia bledy, rowniez wysoko kwalifikowani
    fachowcy.

    >Jakie testy do testów? Do testów nie piszesz testów przecież.

    Pisze sie testy do testow. Ja pisalem, na przyklad. Testy moga byc
    calkiem skomplikowanymi procedurami. Musi byc pewnosc ze test jako
    taki dziala prawidlowo. Z rdguly test polega na tym ze dla okreslonych
    danych wejsciowych metoda musi generowac okreslone wyniki. Ale to czy
    ustalilismy JAKIE wyniki sa prawidlowe? I czy jak ktos cos zmieni w
    tescie, to przypadkiem nei spieprzy testu?

    Przyklad - pewna metoda rozwiazuje "w srodku" zadanie metoda
    Programowanie Liniowego. Tezt musi sparedzic czy dla okreslonych
    danych wynik jest prawidlowy. Wiec tez musi rozwiazac zadanie
    programowania liniowego, ale metoda "na skroty" - z pominieciem calej
    zlozonosci testowanej metody. Czy to obliczanei "na skroty" ma sens?
    Do tego potzrebny jest test

    Oczywiscie, nikt nei robi tego w nieskonczonosc, ale test do testu to
    czesto spotykana praktyka

    Poza tym koncepcja ze "siada sie i pisze test a potem implementacje"
    sprawdza sie tylko przy programowaniy "getters" i "setters".

    > Co to jest
    >w tym przypadku "moduł weryfikujący"? Testy jednostkowe (a także
    >acceptance tests) są testowane w metoldach TDD ręcznie w bardzo prostu
    >sposób - zaczynasz od pisania testu, jeśli test przechodzi, znaczy że
    >jest źle napisany.

    Ze co?...

    >Następnie implementujesz to, co test testuje i
    >regularnie zapuszczasz testy, jeśli testy przejdą zanim skończysz, to
    >znaczy że test jest źle napisany. Jeśli skończysz, a test nie
    >przechodzi, to dedukujesz tradycyjnymi metodami dlaczego i albo
    >znajdujesz błąd w kodzie, albo w teście.
    >

    Przepraszam, ale to nei ma sensu. Wiem ze to jest napisane w
    ksiazkach, ale to niczego nei dowodzi

    >> Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych
    >> zasobów jest ograniczona ilość.
    >
    >Oczywiście, ale konsekwencje braku unit testów (i innych testów
    >automatycznych) często zabierają więcej czasu i zasobó niż pisanie tych
    >testów.
    >

    W normalnych warunkach pzremyslowych czas projektu oblicza sie z
    testami. Srednio 75% kodu pisanegp pzrez programiste to sa testy.

    Jak u mnie, testy sa puszczane kazdej nocy pzrez specjalny zespol
    zajmujacy sie testowaniem. Maja do tego dedykowany hardware i dosyc
    skomplikowany software. Dodatkowo, kazdy programista musi puszczac
    testy, i jak robi "check in" do systemu kontroli kodu (Subversion
    konkretnie) to musi miec pewnosc ze jego testy pzrechodza. Jak nei
    pzrechodza i wykryje to team testujacy, to programista dostaje
    starszny opierdol

    A.L.


  • 32. Data: 2013-07-19 03:14:38
    Temat: Re: pl. usenet o agile
    Od: A.L. <a...@a...com>

    On Fri, 19 Jul 2013 01:38:36 +0100, Roman W
    <b...@g...pl> wrote:

    >On Thu, 18 Jul 2013 08:09:35 -0500, A.L. <a...@a...com> wrote:
    >> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme
    >Programming
    >> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
    >
    >No więc ja pracuję w firmie ktora buduje cos czego nikt inny przedtem
    >nie zrobil, i wymagania wobec systemu zmieniają sie praktycznie co
    >tydzień w miarę jak uczymy sie nowych rzeczy o tym czego potrzeba
    >klientom, czego klienci myślą ze im potrzeba i jakie sa warunki
    >przyrodnicze w których to ma byc zrealizowane. I Agile jest w
    >zasadzie jedynym rozwiązaniem: żeby przeżyć i osiągnąć swoj cel,
    >firma nie moze reagować na zmianę wymagań i uwarunkowań z
    >parotygodniowym opóźnieniem potrzebnym na uzgodnienie aneksu do
    >umowy.
    >

    Jezeli macie klientow ktorzy sa gotowi placic za wasza nauke i
    pomylki, to nic tylko pogratulowac. Ale obawiam sie ze to raczej
    wyjatek niz regula

    A.L.


  • 33. Data: 2013-07-19 07:08:50
    Temat: Re: pl. usenet o agile
    Od: Adam Klobukowski <a...@g...com>

    On Thursday, 18 July 2013 15:09:35 UTC+2, A. L. wrote:
    > On Thu, 18 Jul 2013 04:47:22 -0700 (PDT), Adam Klobukowski
    >
    > <a...@g...com> wrote:
    >
    > >Nigdy nie napisałem że metodologia Agile jest najlepsza.
    >
    > >Tu nie chodzi o to że programiści źle zrozumieli. Zasadą metodyk Agile jest to że
    wymagania są płynne i mogą się zmienić. Taka zmiana nie jest czymś negatywnym.
    >
    > No, ale to przeciez od zawsze bylo. Pisal sie ansksy do omowy i tak
    > dalej. Ale wszystko zalatwialo sie porzadnie a nei an "urrraaa"

    Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania oprogramowania to
    zawsze problem, bo założeniem jest że wymagania nie powinny się zmieniać. W Agile
    nigdy, bo założenie jest że wymagania się zmienią.

    > >> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
    > >> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
    > >> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
    > >> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
    > >> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
    > >> w sadzie. O czym prasa fachowa od czasu do czasu donosi
    >
    > >Nie chodzi też o odstępstwa od umowy. Wystarczy podpisać umowę która zakłada że
    finalny produkt może się zmienić.
    >
    > Buduje dom, Ustalamy ze ma byc dom i w zasadzie moze nadawac sie do
    > mieszkania. Przychodza chlopcy i leja beton. I mowia: jak sie cos nei
    > spodoba to potem odkujemy. I drapia sie w glowe: tu pierdykniemy
    > sreczyk a tu kuchnie. Kuchnia bedzie na pieterku a sraczyk w piwnicy.
    > ten facio co bedzie tu mieszkal i tak nei ma pojecia. A mysmy tu tylle
    > domow wybudowali... No a w koncu w umowie jest napisane ze mzoemy
    > sobie wybudowac co chcemy
    >
    > Tak sie domow nie buduje. I softu tez. Byc moze gdzies sie buduje. Ale
    > nei slyszalem.

    Domy to nie oprogramowanie. Porównywać można, ale budowa oprogramowania to zupełnie
    co innego niż budowa domu.


    > >Przy budowie każdego dużego systemu informatycznego wymagania zmieniają się
    praktycznie zawsze. Czas powstawania dużego projektu to zazwyczaj co najmniej rok,
    zazwyczaj więcej. W tym czasie wiele może się zmienić. W przypadku klasycznych
    metodologii, klient zazwyczaj widzi system dwa razy - jak mu go sprzedają i jak mu go
    dostarczają. Odstęp czasowy pomiędzy tymi momentami jest dużym problemem. To że
    klient coś zamówił, to nie znaczy że jak to dostanie to właśnie tego chce.

    >
    > Przy budowie duzego systemu informatycznego projekt dzieli sie na
    > etapy - ?\"milestones'. Po kazdym etapie nastepuje pzreglad zgodnosci
    > z umowa. Jezeli cos sie nie zgadza algo klientowi sie cos odwidzialo,
    > pisze sie "protokol niezgodnosci", potem ustala sie dalsza akcje.
    > Czestosc takich spotkan zalezy od umowy. W piecioletnim projekcie z
    > klientem w Euuropie a firma robiaca soft w USA takie spotkania byly co
    > 6 miesiecy.

    W przypadku Agile reprezentant klienta uczestniczy w projekcie na bierząco. Nie co 6
    miesięcy, ale założenie jest że jest on członkiem zespołu wytwarzającego system.

    > >W przypadku Agile, klient jest włączony w cały proces powstawania systemu, często
    może zacząć go używać już w trakcie jego powstawania. W ten sposób klient ma lepszą
    widoczność tego jak system będzie wyglądał a kiedy (co nieuniknione) zmienią się jego
    wymagania co do systemu, to wykonawca nie wypnie się mówiąc 'mieliśmy taką a taką
    umowę' ale odpowiednio dostosuje się to tych wymagań. W ten sposób klient dostanie
    produkt z jego punktu widzenia lepszy i lepiej dostosowany do tego do czego jest mu
    potrzebny.

    > Bez systemu Agile tez sie tak robi. Nazywa sie to "partial
    > deployment". Gdy projekt trwa 5 lat, raczej nie czeka sie az caly
    > projekt sie skonczy tylko oddaje po kawalku.

    Owszem, ale w klasycznym modelu, zmiana już dostarczonych elementów to... problem. Z
    Agile to normalna, wręcz oczekiwana praktyka.

    > Wszsystkie "niowoczesne methodologie" typu Agile, Extreme Programming
    > itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
    > "Wicie, rozumicie, zastsowalismy najnowsza merodologie - Agile - i nie
    > wyszlo. The act of God. Sila wyzsza"

    W taki sposób rozumując, to każda metodologia jest dupochronem.

    AdamK


  • 34. Data: 2013-07-19 07:14:17
    Temat: Re: pl. usenet o agile
    Od: Adam Klobukowski <a...@g...com>

    On Thursday, 18 July 2013 15:55:29 UTC+2, Maciej Sobczak wrote:
    > > Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.
    >
    > Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.
    >
    > Widziałem ostatnio (ale nie mam linka) takie rozważania, że w "tradycyjnej"
    metodologii zmiany były kosztowne, ale wszyscy o tym wiedzieli - klienci też, dlatego
    klienci *starali się*, żeby tych zmian było jak najmniej. Starali się przez
    poważniejsze potraktowanie początkowych etapów, czyli analizy i zbierania wymagań.
    >
    > Agile niejawnie sugeruje, że zmiany były są i będą, w związku z tym są normalne -
    czyli tanie. I przy takim założeniu klienci w ogóle się nie starają, przez co zmiany
    są dużo częstsze, niż mogłby by być, gdyby się starali.
    >
    > Pytanie teraz: który wariant jest korzystniejszy.

    Nikt nie mówił że zmiany będą tanie.

    W metodologiach Agile, klient jest (teoretycznie) nieco głębiej zaangażowany w
    projekt. W ten sposób, przy wprowadzaniu zmian ma lepszą widoczność kosztów zmian.
    Przy założeniu że rezultaty projektu są widoczne wcześniej, zmiany też mogą pojawić
    się wcześniej, co dodatkowo obniża ich koszt.

    Zresztą Agile to nie tylko relacje klient-wytwórca. To też relacje wewnątrz wytwórcy
    pomiędzy menagerami a zespołami wytwórczymi.

    AdamK


  • 35. Data: 2013-07-19 08:45:08
    Temat: Re: pl. usenet o agile
    Od: Sebastian Biały <h...@p...onet.pl>

    On 2013-07-19 03:08, A.L. wrote:
    >> wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
    >> komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
    >> przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
    >> komentarze są bez sensu.
    > Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
    > zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
    > CO. Inaczej zrobi sie niekontrolowany burdel

    Tym burdelem zarządza skutecznie system kontroli wersji powiązany z
    jakąs bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na
    programistów kończy się tak jak pliki nagłówkowe do mikrokontrolerów
    Atmela które są perfekcyjnym anty-przykładem. Co chwile inna permutacja
    fixów, wersji, numerków często identycznych, nieaktualnych komentarzy i
    ad-hoc poprawek która wynika z założenia że historia pliku przechowywana
    jest w nim i zarzadzana przez ludzi. Wyszła sieczka.

    W dużym kodzie jedyne co wzbudza zaufanie to automat CVS.


  • 36. Data: 2013-07-19 10:41:39
    Temat: Re: pl. usenet o agile
    Od: Paweł Kierski <n...@p...net>

    W dniu 2013-07-17 17:56, A.L. pisze:
    [...]
    > To jest mniej wiecej takie pisanie jak to ze komunizm jest najlepszym
    > ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta ktory placi
    > dodatkowo za to ze programisci cos na odwrot zrozumieli.

    Współpraca z klientem oznacza, że to nie programiści coś na odwrót
    zrozumieli, tylko programiści i klient nie porozumieli się. W ramach
    umowy zrobili wszystko, co trzeba - nie ma "winnych". Teraz mogą
    zakończyć współpracę (bo się nie dogadują), albo zastanowić się nad
    zmianą w metodach komunikacji (bo chcą dalej _współpracować_).

    > Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
    > pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
    > umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
    > rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
    > programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
    > w sadzie. O czym prasa fachowa od czasu do czasu donosi

    Tyle, że umowa może być albo "twarda" - czyli załącznikiem jest
    kilkaset lub kilka tysięcy stron wymagań, albo "miekka" - z deklaracją
    współpracy i krótkimi okresami rozliczeń i wypowiedzeń. Faktycznie to
    drugie często wynika z tego, że klient sam nie wie dokładnie czego chce
    i - co ważne - ma tego świadomość i nie boi się do tego przyznać. Taka
    sytuacja bywa nieusuwalną cechą pewnych biznesów (być może nie tych,
    z którymi masz styczność). A klient woli mieć choćby ułomny, ale jakoś
    działający kawałek funkcjonalności za miesiąc. Jak poświęci choć dwa
    tygodnie na negocjację umowy z załącznikami jak Biblia, to już jest
    w plecy.

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


  • 37. Data: 2013-07-19 11:06:24
    Temat: Re: pl. usenet o agile
    Od: "slawek" <h...@s...pl>

    Użytkownik "A.L." napisał w wiadomości grup
    dyskusyjnych:v60hu8914m576u2i5utsudha48i9cbrkiv@4ax.
    com...

    >swobodnie agilowac. Ale obawiem sie ze nawet Przedsiebiorstwo
    >Kanalizacyjne nie wmontowaloby sie w projekt bez ustalenia ile

    Czemu nie? Jeżeli firma realizująca projekt należy do zięcia teścia
    szwagra...

    >deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
    >Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

    Marzenie! Utopia!



  • 38. Data: 2013-07-19 11:23:38
    Temat: Re: pl. usenet o agile
    Od: "Ghost" <g...@e...pl>


    Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości
    news:ksau48$11u$1@somewhere.invalid...
    >W dniu 2013-07-17 17:56, A.L. pisze:
    > [...]
    >> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
    >> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
    >> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
    >> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
    >> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
    >> w sadzie. O czym prasa fachowa od czasu do czasu donosi
    >
    > Tyle, że umowa może być albo "twarda" - czyli załącznikiem jest
    > kilkaset lub kilka tysięcy stron wymagań, albo "miekka" - z deklaracją
    > współpracy i krótkimi okresami rozliczeń i wypowiedzeń. Faktycznie to
    > drugie często wynika z tego, że klient sam nie wie dokładnie czego chce
    > i - co ważne - ma tego świadomość i nie boi się do tego przyznać. Taka
    > sytuacja bywa nieusuwalną cechą pewnych biznesów (być może nie tych,
    > z którymi masz styczność). A klient woli mieć choćby ułomny, ale jakoś
    > działający kawałek funkcjonalności za miesiąc. Jak poświęci choć dwa
    > tygodnie na negocjację umowy z załącznikami jak Biblia, to już jest
    > w plecy.

    Z tego co ja widze, to AL nigdy nie mial stycznosci z klientem. Najwyrazniej
    wlasnie bazuje na doniesieniach prasowych. Wyobrazanie sobie, ze klient od
    razu wie czego chce, albo, ze ma czas i srodki zeby kazdy szczegol opisywac
    dokladnie w setkach zalacznikow oraz omawiac na gremialnych spotkaniach to
    jakas utopia. Albo chcesz wspolpracowac, albo napierdzielac sie i traktowac
    caly swiat jak terytorium wroga. Ci drudzy zwykle szybko koncza wszelkie
    biznesowe przygody (sprawdzic czy nie mafia).


  • 39. Data: 2013-07-19 11:32:27
    Temat: Re: pl. usenet o agile
    Od: "slawek" <h...@s...pl>

    Użytkownik "A.L." napisał w wiadomości grup
    dyskusyjnych:353hu8ddr8vgbq5kkva6tlbnk4phsdsuac@4ax.
    com...

    >Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
    >zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
    >CO. Inaczej zrobi sie niekontrolowany burdel

    We wspomnianej książce Robert Martin nie ma nic przeciw "udokumentowywaniu",
    jednak uważa, że tego rodzaju (kto np. napisał dany fragment) notki powinny
    być w zapisywane osobno, w systemie kontroli wersji. I w czasie pracy nad
    tekstem źródłowym programu po prostu ma ich być nie widać.

    Autor ma prawo (chyba że go nie ma, tzn. kwestia na ile ma prawa do kodu, a
    na ile te prawa ma np. firma) umieszczać informację kto jest autorem danego
    dzieła (tj. pliku, fragmentu pliku) wprost w dziele, tj. np. właśnie
    wewnątrz pliku. Zwłaszcza, że tego rodzaju wpis nijak nie wpływa na finalny
    produkt (tj. nie jest kompilowany itd.)

    Jeszcze inaczej: w każdej książce jest napisane, kto jest autorem. Gdyby zaś
    konsekwentnie realizować pomysł Martina, to książki nie powinny zawierać
    imienia i nazwiska autora, bo przecież te są dostępne w katalogu
    bibliotecznym i/lub w bazie danych wydawnictwa.

    Po pierwsze, integralność podpisu twórcy i dzieła jest uznawaną praktyką
    (podpis Picassa na obrazie Picassa to chyba normalne?).

    Po drugie, jest prawdopodobne że informacje o pliku z systemu kontroli
    wersji mogą po prostu zaginąć.

    Po trzecie, rozwiązania w rodzaju javadoc dobrze się sprawdzają - a przecież
    dokumentacja też mogłaby być trzymana osobno, czyż nie...

    Teraz kwestia widać-nie-widać. Jeżeli autor podpisał swoje dzieło, to trochę
    szczeniackie jest udawać że kod jest anonimowy. A takim udawaniem jest
    kasowanie komentarzy zawierających nazwiska autorów lub ukrywanie ich w inny
    sposób.



  • 40. Data: 2013-07-19 11:37:20
    Temat: Re: pl. usenet o agile
    Od: "slawek" <h...@s...pl>

    Użytkownik "Sebastian Biały" napisał w wiadomości grup
    dyskusyjnych:ksan9m$aue$...@n...news.atman.pl...

    >Tym burdelem zarządza skutecznie system kontroli wersji powiązany z jakąs
    >bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na

    Przecież nie trzeba pisać kto jest autorem książki/filmu - jakaś baza danych
    wystarczy.

    Przecież nie ma sensu aby malarz podpisywał się na obrazie - wystarczy że
    mamy rachunek za malowidło.

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


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: