On 2013-07-19 11:37, slawek wrote:
>> 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

Oczywiście że nie. Przeciez to może być fałszywy podpis. Nie zlicze ile
razy w kodzie widziałem takie gówno:

position -= 1 // move forward one step

Bo jakis pokemon zapomniał zmienić komentarz przy refaktoringu.
Wspomniane nagłówki Atmela są znacznie gorsze. Piszą że naprawili
problem xy a potem okazuje sie ze nie naprawili w kodzie a jedynie w
komentarzu w tablece ascii-art. I tak k... dla każdego pliku jest jakiś
błąd lub kilka.

Z doświadczenia wiem, że komentarze nalezy traktować zasadą
ograniczonego zaufania. Fajnie że sa, ale lepiej czytaj *kod* i sprawdź
kto, kiedy i dlaczego go zmienił w VCS.

do góry

Użytkownik "Adam Klobukowski" napisał w wiadomości grup
dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...

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

Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?

> 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

Nie. Nie ty budujesz - tylko owi "chłopcy".

Ty tylko zlecasz budowę. Mówisz "ma być dom". I co? I nic. Od tego domu
jeszcze nie ma. Sprawdź w realu jak to działa.

Musisz, po pierwsze, zawrzeć umowę (zwykle kilka umów, bo np. kredyt). Po
drugie - taka umowa coś musi określać. Co, kto, za ile, kiedy, takie tam. Po
trzecie - zabawa zaczyna się gdy np. "chłopcy" zaczną partolić, a w umowie
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".

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

Ciekawe, jak wygląda małżeństwo agilika? Pewnie "zmiana żony to nie
problem"... ale zwyczajna, wręcz oczekiwana, praktyka.

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

TURE

do góry

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

>Oczywiście że nie. Przeciez to może być fałszywy podpis. Nie zlicze ile
>razy w kodzie widziałem takie gówno:
>
>position -= 1 // move forward one step

To nie jest bez sensu - pojęcie "forward" niekoniecznie musi oznaczać
dodawanie (choć to mało intuicyjne).

"Forward step" może wymagać, od konkretnie zmiennej position, aby właśnie
odejmować 1. Nie wnikając w fakt, czy inne zmienne, są +1, np.:

number +=1;
position -= 1; // move forward one step
delta /= pi;
angle += delta;

do góry

On 2013-07-19, slawek <h...@s...pl> wrote:
> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
> dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...
>
>>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ą.
>
> Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?

Nie widzę z czego taki wniosek wyciągnąłeś. Stosując wprost ten tok
rozumowania: jeśli musisz jeść, to znaczy że jedzenie jest darmowe.

W klasycznych metodach zmiana wymaga wynegocjowania załącznika do umowy,
czyli trzeba zaprząc proces biznesowy, co *zawsze* zauważalnie podnosi
koszt operacji[*].

Agile zakłada, że skoro zmiany pojawiają się i pojawiać się będą, to
trzeba je uczynić *tańszymi* niż do tej pory -- najprościej przez
usunięcie procesu biznesowego z drogi.

[*] Zawsze podnosi koszt i zawsze to widać, ale w pewnych przypadkach
się opłaca (a czasem w ogóle nie ma możliwości zorganizować sprawy
inaczej, np. zakupów sprzętu do serwerowni).

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-07-19 12:07, slawek wrote:
>> Oczywiście że nie. Przeciez to może być fałszywy podpis. Nie zlicze
>> ile razy w kodzie widziałem takie gówno:
>> position -= 1 // move forward one step
> To nie jest bez sensu - pojęcie "forward" niekoniecznie musi oznaczać
> dodawanie (choć to mało intuicyjne).

Tutaj bylo źle. Komentarz jak podpis pod obrazem wprowadza w błąd. I to
trywializm do znalezienia w 30 sek. Teraz pomyśl co brak synchronizacji
tego typu powoduje w bardziej skomplikowanych algorytmach. Widuje bardzo
czesto rózne rzeczy takie jak return true; // failed ale też takie gdzie
ktoś pisze elaborat na dwa ekrany po czym okazuje się że dziala zupełnie
inaczej bo po drodze było kilku poprawiaczy.

Dla mnie jedynym prawidłowym komentarzem jak coś działa w dynamicznie
pisanym sofcie jest kod i unit test do niego.

do góry

On Friday, 19 July 2013 11:58:35 UTC+2, slawek wrote:
> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
>
> dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...
>
> >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ą.
>
> Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?

Nie, ale może być. W klasycznej metodyce, nawet jeśli projekt jest dostarczany
w milestonach, to są one dosyć monolityczne (i zazwyczaj dopiero przy okazji
takich dostaw okazuje się że trzeba cos zmienić). W przypadku Agile reagujemy
na zmianę o wiele wcześniej i dzięki temu możemy zminimalizować jej koszty lub
(oczywiście zależy to od szczęścia) nawet całkowicie wyeliminować.

Rozważmy przykład milestona w którym realizujemy elementy od 0 do 9, każdy
element ma koszt 1.

Dla uproszczenia załóżmy że realizujemy je w kolejności rosnącej (Agile tego
nie zakłada).

Zakładamy że np. na elemencie 5 będzie zmiana, co spowoduje że elementy 6,7,8
będą wymagały zmiany, 9 stanie się niepotrzebny ale za to dojdzie nowy, 10.

W zależności od tego jak wcześnie dowiemy się o zmianie założeń, koszt tej
zmiany będzie rósł wraz z zaawansowaniem projektu.

W przypadku Agile, klient po realizacji każdego elementu jest zapraszany i może
pokręcić nosem jak mu się coś nie podoba. Może też nas wówczas poinformować o
zmianach wymagań.

W przypadku klasycznych modelach, klient widzi dostarczony milestone i
zazwyczaj dopiero wówczas dowiemy się o zmianie wymagań.

> > 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
>
> Nie. Nie ty budujesz - tylko owi "chłopcy".
>
> Ty tylko zlecasz budowę. Mówisz "ma być dom". I co? I nic. Od tego domu
> jeszcze nie ma. Sprawdź w realu jak to działa.
<ciach>

Ale proszę nie mieszać odpowiedzi różnych osób.

> >Owszem, ale w klasycznym modelu, zmiana już dostarczonych elementów to...
> >problem. Z Agile to normalna, wręcz oczekiwana praktyka.
>
> Ciekawe, jak wygląda małżeństwo agilika? Pewnie "zmiana żony to nie
> problem"... ale zwyczajna, wręcz oczekiwana, praktyka.

Trzymajmy się tematu.

AdamK

do góry

On Friday, 19 July 2013 10:41:39 UTC+2, Paweł Kierski wrote:
> 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.

Dodam od siebie, że najgorszy klient to taki który nie wie czego chce i o tym
nie wie, a najlepszy to taki który nie wie czego chce i jest tego świadomy :)

Po prostu bardzo rzadko zdarzają się klienci którzy potrafią jasno, dokładnie,
jednoznacznie i w sposób ograniczony sprecyzować swoje wymagania co do systemów
informatycznych. Do tego są jeszcze czynniki zewnętrzne takie jak zmienne prawo
czy koniunktura, które mogą spowodować że to co klient dwa lata temu z pełną
świadomością zamówił, dziś nie jest mu już do niczego potrzebne.

AdamK

P.S. Zaś ostatecznie najgorszym klientem jest taki, który zupełnie nie wie
czego chce, ale zrobi wszystko aby to dostać ;)

do góry

W dniu 2013-07-18 21:15, slawek pisze:
[...]
> Ad rem: swego czasu pomagałem komuś przepisać jego twórczość literacką
> do postaci pliku wymaganego przez redakcję. Ponieważ był to przyjaciel,
> to znosiłem cierpliwie
[...]
> trwało, rok, czy trochę dłużej.
> Jednym z zasadniczych problemów polegał bowiem na tym, iż ów literat nie
> płacił, więc nie odczuwał jakiegokolwiek przymusu ogarnięcia się co do
> organizacji pracy. Wprost powiedzieć żeby poszedł szukać innego naiwnego
> nie było można, bo obraziłaby się rodzina, ksiądz proboszcz i lokalna
> społeczność. Zresztą to był przyjaciel.
>
> Jeżeli w Agile zakłada się "przyjacielski" kontakt producenta software
> (a wręcz programistów) z zamawiającym dzieło klientem, to naprawdę
> wątpię, czy udaje się uniknąć podobnych sytuacji.

Kontakt jest bardziej... hm... "towarzyski" niczym w wyrażeniu
"agencja towarzyska" 8-)

Jeśli jesteśmy umówieni na koleją iterację, to kontakt jest właśnie taki
"przyjacielski" - a właściwie do takiego powinno się dążyć, bo jest
najefektywniejszy: robimy coś razem, a nie przeciwko sobie. Różnica
w porównaniu do opisywanego do Ciebie przypadku jest taka, że na końcu
iteracji klient płaci wcześniej umówioną stawkę. I podejmuje decyzję
o kontynuowaniu lub zakończeniu współpracy.

Z anegdot znam przypadki o wystawieniu faktury za iterację, w której
klientowi "nie chciało się" skontaktować. Po zapłaceniu zorientowali
się, że jednak sensowniej będzie aktywnie współpracować. Szczęśliwie
byli rozsądni. Gdyby im się nie spodobało, to byłaby oczywiście
pierwsza i ostatnia faktura. Uwaga - nadal tylko za iterację.

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

do góry

W dniu 2013-07-19 02:13, A.L. pisze:
> 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. 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.
>
> 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.

Mała złośliwość:
Jakbym miał taką szklaną kulę, która z sensowną dokładnością poda mi
budżet po określeniu wymagań, to bym z marszu użył jej do typowania
Lotto.

Poważnie:
Na ile dokładne i wiążące, a na ile negocjowalne są wg Ciebie pierwotne
ustalenia dotyczące budżetu i terminów? Co z sytuacjami, gdy trzeba
wyceniać rzeczy, o których od początku wiadomo, że są bardzo
nowatorskie (w domyśle - wycena na pewno nie będzie ścisła, bo zakres
jest nieznany obu stronom)?

Jest taki fajny obrazek budowania piramidy:
- klasycznie kładziemy poziome warstwy od dołu: musimy mieć wcześniej
określone, jak duża ta piramida będzie, bo trzeba wiedzieć, jak duża ma
być pierwsza warstwa. Tu można całkiem nieźle oszacować, ile czasu to
zajmie i jak drogie będzie
- agile: mamy zamówienie na "super wypasiony grobowiec dla władcy",
ale nie mamy terminu ("Faraon - oby żył wiecznie - jest w dobrym
zdrowiu, ale kto to wie..."), w sumie to może nie będzie to piramida
tylko wieża (jeszcze się pomysł nie wykluł). To zaczynamy od komory
grobowej i "oklejamy" ją kolejnymi warstwami tak, żeby na koniec każdego
miesiąca mieć gotową budowlę (co znaczy "gotowa" w tym miesiącu umawiamy
się na początku miesiąca). Inaczej niż w klasycznym podejściu możemy
tylko powiedzieć ile kosztuje nasz miesiąc pracy.


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

Ale nie musi siedzieć. Byle tylko deweloper mógł w miarę często
zaprezentować, czy to co robi, to jest to, o co faktycznie chodziło.
Innymi słowy - twierdzę, że gdyby Przedsiębiorstwo Kanalizacyjne
potrafiło wyprodukować specyfikację wystarczającą dla "code monkey",
to powinno zająć się analizą systemów informatycznych, a nie
kanalizacją.

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

do góry

W dniu 2013-07-18 21:43, slawek pisze:
> 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.
>
> Możemy się zgodzić, że jeżeli dział IT jest w jakimś dużym zaibatsu, to
> Agile też jest ok - bo nad "klientem" i nad "programistami" jest ten sam
> uber-szef (lub uber-szefowa). I jakby coś było bardzo nie tego, to
> wszyscy i tak płyną w tej samej łodzi. Dotyczyć może to m.i. branży gier
> komputerowych.
>
> Możemy się także zgodzić, że Agile może nie być najlepszą metodą dla
> "pewnego typu projektów". Tzn. że jeżeli ktoś WIE czym jest Agile i
> ŚWIADOMIE nie używa - to widocznie jest to z jego strony spostrzegane
> jako racjonalna decyzja... i naprawdę nic nam do tego.

Fajny początek na "protokół zgodności i rozbieżności" 8-)

Wspólnie w tym miejscu twierdzimy, że istnieją projekty, w których
Agile jest co najmniej jednym z najlepszych rozwiązań.

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

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

do góry