On Fri, 19 Jul 2013 08:45:08 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

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

Jak ktos zrobil zmiany w moim kodzie, to chce wiedziec KTO i DLACZEGO.
KTO - rzeczywiscie moge sie dowiedziec z CVS siegajac 20 wersji
wstecz. Ale DLACZEGO - to juz nie. A informacja mzoe byc istotna, bo
ten kto to zrobil mzoe byc jus w innej firmie, na przyklad.

A.L.

do góry

On 2013-07-19, A.L <a...@a...com> wrote:
> On Fri, 19 Jul 2013 08:45:08 +0200, Sebastian Biały
><h...@p...onet.pl> wrote:
>
>>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.
>
> Jak ktos zrobil zmiany w moim kodzie, to chce wiedziec KTO i DLACZEGO.
> KTO - rzeczywiscie moge sie dowiedziec z CVS siegajac 20 wersji
> wstecz. Ale DLACZEGO - to juz nie. A informacja mzoe byc istotna, bo
> ten kto to zrobil mzoe byc jus w innej firmie, na przyklad.

I uważasz, że napisałby to w komentarzu do kodu, ale w commit message'u
już nie?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-07-19 16:27, A.L. wrote:
>> Tym burdelem zarządza skutecznie system kontroli wersji powiązany z
>> jakąs bazą danych bugs
^^^^^^^^^^^^^^^^^^^^^^^^^
>> W dużym kodzie jedyne co wzbudza zaufanie to automat CVS.
>
> Jak ktos zrobil zmiany w moim kodzie, to chce wiedziec KTO i DLACZEGO.
> KTO - rzeczywiscie moge sie dowiedziec z CVS siegajac 20 wersji
> wstecz. Ale DLACZEGO - to juz nie. A informacja mzoe byc istotna, bo
> ten kto to zrobil mzoe byc jus w innej firmie, na przyklad.

Podkresliłem.

System kontroli wersji ma byc *POWIĄZANY* z bazą bugs/ficzerów. Sam z
siebie jest gówno wart. Z tej bazy wynika dlaczego i co ważniejsze z tej
bazy wynika gdzie są testy, dlaczego bylo źle i co się stalo że jest
lepiej, kto to robił, kto testował, kto zatwierdził review kodu, czy
unit testy przeszły i kto się pod tym podpisał ...

Osobiście widziałem SVN w powaznej firmie w której kazdy commit to
"fixed problem" albo "refactored, now works" a za bazę bugów robiły
maile. Nie, nie to mam na myśli.

do góry

Użytkownik "Paweł Kierski" napisał w wiadomości grup
dyskusyjnych:ksbbre$7n7$...@s...invalid...

>Teraz czas na rozbieżności - podaj przykłady projektów, w których
>wg Ciebie Agile na pewno się nie sprawdzi.

1. Zamówienia publiczne, które musi (bo takie prawo) rozstrzygnąć przetarg.
2. Programy robione ad hoc w jednoosobowym "zespole". Dotyczy także zespołu
dwuosobowego.
3. Projekty ubezpieczane od ryzyka i szczególnego znaczenia (medycyna). W
tym także związane z ochroną poufności.
4. Projekty tworzone społecznościowo na zasadzie totalnego wolontariatu.

Z Agile trochę jest tak jak z demokracją. Niezła rzecz, byle stosować tam
gdzie ma sens. Bo głosowaniem nie da się ustalić że każdy kwadrat jest
trójkątem.

do góry

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

>Jak ktos zrobil zmiany w moim kodzie, to chce wiedziec KTO i DLACZEGO.
>KTO - rzeczywiscie moge sie dowiedziec z CVS siegajac 20 wersji
>wstecz. Ale DLACZEGO - to juz nie. A informacja mzoe byc istotna, bo

TRUE

do góry

On 19/07/2013 01:13, A.L. wrote:
> On Thu, 18 Jul 2013 06:55:29 -0700 (PDT), Maciej Sobczak
> <s...@g...com> 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ą.
>
>
> Zmiany tanie nie sa. Potwierdzam.
>
> Gdy sie umawia z klientem na wykonanie projektu, to trzeba wiedziec
> ile projekt bedzie kosztowal.

Nie da się wiedzieć. Można się umówić, że wykonawca dostarczy program w
terminie według specyfikacji i że zapłacimy mu dwa miliony, to tylko
idiota może wierzyć, że znaczy to, że "projekt będzie kosztował dwa
miliony". Nawet zakładając, że wykonawca wywiąże się w 100% z umowy.

Tzn. faktycznie projekt może kosztować dwa miliony, ale tylko pod
warunkiem, że przyjmiemy możliwość (a nawet wysokie prawdopodobieństwo),
że za te dwa miliony dostaniemy software, którego nie będziemy mogli używać.

> Ustala sie to na podstaawie dokumentu
> wysylanago pzrez klienta do potencjalnych wykonawcow. gdzie sa
> wyspecyfikowane wymagania dotyczace projektu. Firmy wyceniaja i klient
> wybiera firme ktora chce. Niekoniecznie najtansza. Normalka.

Jest to jedna z możliwości, nie jedyna.

> Teraz, jak sie podpisze kontrakt, to jest obopolne porozumienie ze a)
> klient nie bedzei wymagal wiecej niz jest w kontrakcie, ani inaczej
> niz jest w kontrakcie b) dostawca dostarczy produkt zgodznie ze
> specyfikacja, w budzecie i w czasie.
>
> Wszelkie zmiany dotyczace zakresu projektu natychmiast rodza pytanie:
> "kto za to zaplaci". Bo wykonawcanei widzi powodu - tej dodatkowej
> funkcjonalnosci nie bylo w specyfikacji. Dodatkowo, takie extra
> wymagania naruszaja "timing" projektu - projektu nei da sie wykonac na
> czas, a za opoznienia moga byc kary umowne. Wiec co bedzie z tymi
> karami?
>
> Obie wysokie strony musza sie dogadac - w sparwie pieniedzy i w
> sprawie terminow.

Ale też taki układ niekoniecznie jest korzystny dla zleceniodawcy.
Przede wszystkim dlatego, że wykonawca ma w tym momencie wszelkie
powody, żeby wydoić z niego ile się da - w kwestii terminów i w kwestii
kosztów, żeby więcej zarobić i żeby zredukować swoje ryzyko. Jeśli np.
przy pierwotnych negocjacjach proponował termin będący dwukrotnością
szacowaneo czasu projektu i rentowność na poziomie 100%, to już
szacując, że poprawka będzie kosztowała dwa tysiące i zajmie tydzień,
powie zleceniodawcy że zrobi ją za dodatkowe 20 tysięcy i przesunięcia
terminu o sześć tygodni.

Ponieważ ilość poprawek nie może być znana z góry, odpowiedź na pytanie
"jeśli się umówimy na dwa miliony i dwa lata, to za ile pieniędzy i za
ile czau będziemy mieli system, którego używanie będzie miało sens"
brzmi "nie wiadomo, może za dwa lata i dwa miliony, ale to raczej mało
prawdopodobne; może to będą cztery lata i dziesięć milionów, a może
takiego systemu nie dostaniemy nigdy, i nawet nie będziemy mieli kogo
pozwać".

To nie jest tak, że z time and materials nie wiadomo ile będzie trwało i
kosztowało, a z fixed price, fixed scope wiadomo. Tak czy inaczej nie
wiadomo.

Z Agile różnica jest taka, że rzeczy są robione poczynając od
najbardziej wartościowych, dąży się do tego, żeby klient jak najszybciej
dostał coś, co się nadaje do użytku, i że jeśli uważa, że szacunki
podawane przez wykonawce są zawyżane, to może zakończyć współpracę i
wziąć to, co jest.

> Byc moze w sytuacji gdy caly projekt polega na "pierdyknieciu bazki
> szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa Kanalizacyjnego" i
> jest robiony pzrez pojedynczego junior developera, mozna sobie
> swobodnie agilowac. Ale obawiem sie ze nawet Przedsiebiorstwo
> Kanalizacyjne nie wmontowaloby sie w projekt bez ustalenia ile
> kosztuje i kiedy bedzie zrobiony.

W jakim sensie "ustalenia"? Jeśli ustalenie nie musi mieć podkładki w
postaci umowy, to przecież ktośtam może ustalić.

Zresztą przy umowie typu time and materials też można to bardzo łatwo
ustalić. Na przykład iteracja trwająca tydzień kosztuje dwadzieścia
tysięcy, pierwszy release plan jest na dwadzieścia pięć iteracji,
zakłada się więc, że całość projektu będzie trwała pięćdziesiąt
iteracji, więc ustalono, że projekt będzie kosztował milion i będzie
zrobiony za rok.

> I na pewno Pzredsiebiorstwo
> Kanalizacyjne nie wydeleguje swojego pracownika zeby siedzial z owym
> deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
> Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

Zaopatrzenie przedsiębiorstwa w bazę szlauchów i kaloszy to też częśc
zajmowania się kanalizacją.

> Zeby bylo konkretnie - bylem swiadkiem projektu w ktorym dodanie pol
> strony do specyfikacji kosztowalo zleceniodawce cwierc miliona
> dolarow. I nie bylo to nic takiego nadzwyczajnego

I dlatego klient nie będący idiotą może właśnie woleć Agile - żeby
uniknąć takiej sytuacji.

do góry

On Fri, 19 Jul 2013 16:02:57 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Kod może być i na tysiące linijek o ile jego działanie opisane jest
> testami. I który w przypadku watpliwości mogę przedebugować. Bo
testy to
> jedyna *pewna* dokumentacja projektu, szczególnie z wesołych
metodyk
> pisania byle jak.

Test może byc typu

x = 4.5;
expected = 10.4;
assertEquals (expected, f (x));

I jaka ma wtedy wartość jako dokumentacja?

RW

do góry

On 18/07/2013 20:43, slawek wrote:
> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
> dyskusyjnych:3e898997-4438-4dc0-a895-f82da449ba62@go
oglegroups.com...
>
>> W przypadku Agile, klient jest włączony w cały proces powstawania
>> systemu, [...]
>
> Możemy chyba się zgodzić, że dla oprogramowania "sweterkowego", tj.
> jakieś Linuksy, GNU, akademickie projekty (bynajmniej nie dezawuuję) -
> to Agile może być niezłym sposobem organizacji pracy, nieco bardziej
> formalnym niż brak jakiejkolwiek organizacji.

Właśnie niedobrym - Agile jest zaprojektowany pod kątem tworzenia
oprogramowania biznesowego pod klienta, i ma pewne cechy, które
powodują, że się słabo nadaje do tego, co napisałeś: kolokacja zespołu i
narzucone godziny pracy (Linuksy i GNU tworzone są zwykle w trybie
rozproszonym) i dyktowanie wymagań i priorytetów z zewnątrz zespołu z
brakiem własnego interesu członków zespołu w tym co i jak ma robić
system (decyduje o tym wyłącznie przedstawiciel klienta lub product owner).

do góry

On Fri, 19 Jul 2013 11:58:35 +0200, "slawek" <h...@s...pl> wrote:
> będą niejasności. Co innego jak budujesz systemem gospodarczym - ty
i
> szwagier kładziecie cegła do cegły - ale to właśnie takie "agile".

Bzdura. Nawet ze szwagrem dom budujesz według projektu. Nie zmienisz
w połowie budowy liczby pieter, czy rozmieszczenia scian nośnych.

Budowa domów a budowa software to zupełnie inne rzeczy i takie
analogie sa bez sensu.

RW

do góry

On Fri, 19 Jul 2013 14:41:00 +0200, Paweł Kierski<n...@p...net>
wrote:
> > 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 może wręcz przeciwnie? Może wygrywają klienci, którzy gotowi są
> zaryzykować kasę na użyteczny produkt, którego konkurencja jeszcze
nie
> ma?

Na razie płacą inwestorzy.

RW

do góry