On Dec 21, 6:03 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > Jasne. Ale tydzień później będę robił drugą notatkę. Potem trzecią i N-
> > tą. W sumie napiszę tyle samo. Zdaje się, że to uzgodniliśmy, bo.
>
> Modulo to, że notatka, z której zaczynasz korzystać tego samego dnia,
> a kończysz korzystać w tym samym tygodniu, może być znacznie krótsza
> niż dokument, notatka czy cokolwiek, z czego zanczniesz korzystać za
> miesiąc.

Nie, bo w sumie i tak musi być tego tyle samo - informacji nie da się
zniknąć.
Argument jest taki sam, jak już był.

> Powód nazywa się natura ludzka. Jeśli nie ma aktywnej weryfikacji
> aktualności wymagań w czasie, to fakt, że cośtam, co się zmieniło albo
> okazało powoduje, że cośtam, co kilka miesięcy wcześniej zostało
> zapisane w dokumencie jest nieaktualne i powinno zostać usunięte lub
> zrewidowane, może łatwo umknąć uwadze.

Nic nie umyka uwadze, bo jest DDD. Nie siadasz do kodu, dopóki nowej
wiedzy (albo zupełnie nowej albo zmian do istniejącej) nie przelałeś
na papier. W ten sposób dokumentacja zawsze jest zgodna z kodem.
Równie dobrze mógłbym powiedzieć, że w TDD można napisać nowy kod nie
pisząc do niego testów i w ten sposób coś może umknąć uwadze. Każdy
proces można przeprowadzić źle.

> > Uwaga: trwa to dokładnie tyle samo, ile pisanie notatki.
>
> No więc niekoniecznie. Na przykład notatka, którą teraz mam przed
> oczami brzmi tak: "załączniki!"
> Wpisane do dokumentacji byłoby to bezużyteczne, ale dla mnie w
> aktualnej sytuacji jest wystarczające.

Nie życzę źle, ale co by było, gdybyś dziś wieczorem wpadł pod
przysłowiowy autobus?
Czy ta notatka nadal byłaby "wystarczająca"? Dla kogo?
Albo gdybyś jutro na skutek chwilowej niedyspozycji jednak uznał, że
ta notatka jest za krótka i poszedłbyś ponownie do OSCRa a to on wpadł
pod autobus?
Agile zbyt mocno polega na tym, że "będzie dobrze".

[...]

> Tego nadal może być sporo. Ale jeśli podzieslisz problem na
> odpowiednio małe kawałki, to uważaj, bo zaczynasz być agile :)

Ja nie mam nic przeciwko spontanicznemu byciu agile, jeśli tak ma się
nazywać stan, w którym szybko reaguję na zmiany wymagań. Natomiast to,
co odrzucam w agile i w każdej innej metodologii to stan
fetyszyzowania i wystawiania procesu przed projekt. Mam tu na myśli
narzucanie jakiejś formy na wszystkie okazje - np. reguły, że OSCR
jest jeden, pisanie notatki ma trwać co najwyżej 15 minut a iteracja
ma mieć dokładnie tydzień. Dupatam - rozmawiać trzeba z tyloma ludźmi
ile potrzeba, pisanie notatki (pardon: dokumentacji) ma trwać tyle,
ile potrzeba żeby ją zapisać a iteracja ma trwać tyle, ile potrzeba,
że zrobić etap. Czasem to może być pół dnia a czasem 3 miesiące.
Wciskanie 3-miesięcznego etapu w tygodniową iterację jest głupie -
widziałem to i słabo było.

> > I tym akcentem powoli należy zwijać wątek, bo idą święta i trzeba się
> > zabrać za bigos.
>
> Ano ano. Coś chyba za bardzo nam się świąteczny nastrój udziela i jadu
> brakuje do podtrzymania flejma...

Jakiego flejma? O ile ustaliliśmy już, że agile nie polega na
niepisaniu dokumentacji, to nawet nie ma o co się kłócić.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 21/12/2011 23:03, Maciej Sobczak wrote:
> On Dec 21, 6:03 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>> Powód nazywa się natura ludzka. Jeśli nie ma aktywnej weryfikacji
>> aktualności wymagań w czasie, to fakt, że cośtam, co się zmieniło albo
>> okazało powoduje, że cośtam, co kilka miesięcy wcześniej zostało
>> zapisane w dokumencie jest nieaktualne i powinno zostać usunięte lub
>> zrewidowane, może łatwo umknąć uwadze.
>
> Nic nie umyka uwadze, bo jest DDD. Nie siadasz do kodu, dopóki nowej
> wiedzy (albo zupełnie nowej albo zmian do istniejącej) nie przelałeś
> na papier.

Ale samo przelanie na papier nie zabezpieczy cię przed otrzymaniem w
końcu dokumentacji zawierającej nieaktualne informacje. Co więcej,
możesz mieć w takiej dokumentacji sprzeczne informacje, z których część
jest aktualna, a część nie.

>>> Uwaga: trwa to dokładnie tyle samo, ile pisanie notatki.
>>
>> No więc niekoniecznie. Na przykład notatka, którą teraz mam przed
>> oczami brzmi tak: "załączniki!"
>> Wpisane do dokumentacji byłoby to bezużyteczne, ale dla mnie w
>> aktualnej sytuacji jest wystarczające.
>
> Nie życzę źle, ale co by było, gdybyś dziś wieczorem wpadł pod
> przysłowiowy autobus?

Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
notatka dotyczyła. Sama notatka jest już w śmietniku. Oczywiście nie
zawsze tak będzie, w tej chwili na biurku zostawiłem trochę notatek, z
których ciężko byłoby skorzystać, gdybym dzisiaj wpadł pod autobus. Ale
ponieważ właśnie dzisiaj rozmawiałem z kilkoma osobami na ten temat, to
prawdopodobnie nie byłoby tragedii - razem przypominając sobie, co było
powiedziane, oraz przeglądając notatki byliby prawdopodobnie w stanie
zrekonstruować ich treść.

Problem jest taki: gdybym zamiast każdej z tych notatek, które powstały
w mniej niż minutę, chciał zapisać w postaci dokumentu, który ktokolwiek
mógłby przeczytać i zrozumieć, to prawdopodobnie zajęłoby to wiele
godzin. Biorąc pod uwagę prawdopodobieństwo wpadnięcia pod autobus
(pewnie mniej niż jeden na milion), jaka jest ekonomia takiego działania?

Powiem więcej: gdybym dzisiaj wpadł pod autobus, to prawdopodobnie firma
by trochę ucierpiała, bo jestem w tej chwili jedynym implementatorem
dość krytycznego projektu. Być może koszta by były rzędu nawet zw dwóch
osobomiesięcy (chociaż to jest szacunek na wyrost). Ale to nie przez te
notatki, tylko przez to, że pracując nad tym, nad czym pracuję, zdobyłem
pewną wiedzę w temacie, którą przejmująca temat osoba musiałaby w dużej
mierze zdobyć od nowa. Ale przede wszystkim dlatego, że samo opóźnienie
spowodowałoby problemy organizacyjne zaburzające pracę wielu innych
ludzi. Oczywiście gdybym wszystko, czego się dowiaduję, dokładnie
dokumentował, to potencjalna osoba przejmująca moją pracę po moim
potencjalnym wypadku z autobusem miałaby łatwiej, ale samo pisanie
takiego dokumentu trwałoby z miesiąc, przez co po pierwsze problemy
związane z opóźnieniem miałbym za darmo, a po drugie kosztowałoby to
firmę dodatkowy roboczomiesiąc mojej pracy, i to wszystko, żeby uniknąć
dwóch roboczomiesięcy na wypadek zdarzenia, którego prawdopodobieństwo
jest jeden na milion.

> Albo gdybyś jutro na skutek chwilowej niedyspozycji jednak uznał, że
> ta notatka jest za krótka i poszedłbyś ponownie do OSCRa a to on wpadł
> pod autobus?

W tym przypadku to mało prawdopodobne (żebym uznał, abstrahując już od
prawdopodobieństwa wpadnięcia pod), ale nawet gdyby coś takiego zdarzyło
się z inną notatką, to mój OSCR nie jest jedyną osobą, która posiada
odpowiednią wiedzę. Nawet jeśli uzyskanie tej wiedzy byłoby przez chwilę
trudniejsze, to byłoby to co najwyżej kilkudniowe opóźnienie.

> Agile zbyt mocno polega na tym, że "będzie dobrze".

Właśnie agile tak w ogóle to jest głównie zabezpieczanie się przed tym,
że może być niedobrze.

W szczególności np. XP ma wiele praktyk zabezpieczających przed
scenariuszami "wpadł pod autobus" - zaczyna się od przelania wiedzy o
wymaganiach i projekcie na testy, jest programowanie parami, collective
code ownership, regularne spotkania na których jest obecny cały zespół,
i na których się mówi o tym, nad czym aktualnie się pracuje, z czym są
problemy (release planning, iteration planning, daily stand-up) i co tam
jeszcze.

> Ja nie mam nic przeciwko spontanicznemu byciu agile, jeśli tak ma się
> nazywać stan, w którym szybko reaguję na zmiany wymagań. Natomiast to,
> co odrzucam w agile i w każdej innej metodologii to stan
> fetyszyzowania i wystawiania procesu przed projekt.

Wręcz przeciwnie, fetyszyzowanie procesu jest sprzeczne z Agile. Nawet
pierwszy value o tym jest. :)

> Mam tu na myśli
> narzucanie jakiejś formy na wszystkie okazje - np. reguły, że OSCR
> jest jeden,

Nie ma takiej reguły. OSRC-ów jak najbardziej może być kilku.

> pisanie notatki ma trwać co najwyżej 15 minut

To był żart przecież, chodziło o to, że w związku z tym, że przyswajanie
dużej ilości informacji na raz wiąże się z tym, że część się zapomina,
należy przyswajać ją w małych kawałkach i starać się robić jedną rzecz
na raz.

> a iteracja
> ma mieć dokładnie tydzień. Dupatam - rozmawiać trzeba z tyloma ludźmi
> ile potrzeba, pisanie notatki (pardon: dokumentacji) ma trwać tyle,
> ile potrzeba żeby ją zapisać a iteracja ma trwać tyle, ile potrzeba,
> że zrobić etap. Czasem to może być pół dnia a czasem 3 miesiące.
> Wciskanie 3-miesięcznego etapu w tygodniową iterację jest głupie -
> widziałem to i słabo było.

Iteracje nie są po to, żeby w coś w nie wciskać, tylko żeby mieć
regularny odstęp czasu do planowania kolejnych priorytetów i do
planowania. Twój "etap" spokojnie może się mieścić w wielu iteracjach.

Poza tym: niektórzy zalecają inną długość iteracji lub też mówią, żeby
ustalić długość na 1 do 3 tygodni. Owszem, tydzień jest zalecany, i
reguła mówi, że iteracje mają być równej długości. Tylko powiedz
realnie, na czym polega twoja potrzeba, żeby iteracja była dłuższa? Bo
wydaje mi się, że jakoś źle tych iteracji używasz. To nie są inaczej
nazwane "etapy".

do góry

On Wednesday, December 21, 2011 7:53:16 PM UTC, Edek wrote:
> On 12/20/2011 12:56 AM, Roman W wrote:
>
> >
> > W moim srodowisku pracy to sie robi tak, ze sie bierze kolesia A po
> > matematyce albo fizyce, kaze mu przeczytac pare ksiazek i sporo
> > artykulow z dziedziny, po czym sadza sie kolo kolesia B ktory ma
> > zarabiac pieniadze przy uzyciu modeli tworzonych przez kolesia A, po
> > czym B tak dlugo bije i zniewaza A az ten a) nauczy sie pisac
> > przyzwoitej jakosci kod C++ (rzadziej Java) i b) zaimplementuje kod
> > ktory zarabia na pensje i premie obydwu. Moze to nie jest Agile, ale
> > czasami jest bardzo "extreme".
>
> Z ciekawości: dlaczego po matematyce lub fizyce, a nie po informatyce?
> Rozumiem, że łatwiej nauczyć matematyka informatyki niż odwrotnie,
> ale informatyka w Polsce może być zarówno informatyką chemii spożywczej
> jak i stosowaną ekonometrią.

Stosowana ekonometria pewnie bedzie OK (jesli bedzie znal tez rachunek
stochastyczny), ale to IMHO nie jest to, co sie na ogol rozumie przez "computer
science".

>
> Inaczej mówiąc, nie widzę ja akurat powodu dlaczego ktoś ze znajomością
> metod numerycznych nie miałby napisać szybciej i lepiej kodu wg. modeli,
> który koleś B mu podsunie. Jak to jest?

W praktyce nie wystarczy znac tylko metod numerycznych, trzeba znac matematyke ktora
za nimi stoi. Ktos, kto nie zna matematyki, nie zrozumie zreszta i metod
numerycznych, bedzie najwyzej przepisywal na slepo algorytmy z "Numerical Recipes".

Widzialem raz taki eksperyment, kiedy koles po CS dostal opisany model, i go
zaimplementowal. Implementacja przechodzila iles testow, ale byla matematycznie
schrzaniona, bo programista zrobil przeksztalcenia ktore jemu wydawaly sie
nieszkodliwe, ale niestety byly.

RW

do góry

On Thursday, December 22, 2011 1:25:33 AM UTC, Andrzej Jarzabek wrote:
> Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
> notatka dotyczyła. Sama notatka jest już w śmietniku.

To na czym ma polegac osoba, ktora przejmuje taki kod? Tylko na komentarzach?

RW

do góry

On 2011-12-22, Roman W <b...@g...pl> wrote:
> On Thursday, December 22, 2011 1:25:33 AM UTC, Andrzej Jarzabek wrote:
>> Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
>> notatka dotyczyła. Sama notatka jest już w śmietniku.
>
> To na czym ma polegac osoba, ktora przejmuje taki kod? Tylko na komentarzach?

Po co komentarze? Przecież my rozumiemy własny kod :>

--
Secunia non olet.
Stanislaw Klekot

do góry

On Dec 22, 8:53 am, Roman W <b...@g...pl> wrote:
> On Thursday, December 22, 2011 1:25:33 AM UTC, Andrzej Jarzabek wrote:
> > Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
> > notatka dotyczyła. Sama notatka jest już w śmietniku.
>
> To na czym ma polegac osoba, ktora przejmuje taki kod? Tylko na komentarzach?

Tego kodu akurat nikt nie przejmie. Prawdopodobnie za jakieś trzy
tygodnie zostanie wykonany raz w produkcji i odłożony do lamusa.

W ogólnym przypadku polega się przede wszystkim na czytelnym kodzie i
czytelnych testach.

do góry

On Thursday, December 22, 2011 10:11:51 AM UTC, Andrzej Jarzabek wrote:
> On Dec 22, 8:53 am, Roman W <b...@g...pl> wrote:
> > On Thursday, December 22, 2011 1:25:33 AM UTC, Andrzej Jarzabek wrote:
> > > Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
> > > notatka dotyczyła. Sama notatka jest już w śmietniku.
> >
> > To na czym ma polegac osoba, ktora przejmuje taki kod? Tylko na komentarzach?
>
> Tego kodu akurat nikt nie przejmie. Prawdopodobnie za jakieś trzy
> tygodnie zostanie wykonany raz w produkcji i odłożony do lamusa.
>
> W ogólnym przypadku polega się przede wszystkim na czytelnym kodzie i
> czytelnych testach.

IMHO to jest za malo.

RW

do góry

On Dec 21, 7:26 pm, Edek <e...@g...com> wrote:
> On 12/21/2011 06:40 PM, Andrzej Jarzabek wrote:
>
> > Oczywiście zespoły agile mogą funkcjonować w kontekście istnienia
> > architekta poza zespołem - jeśli np. jest kilka zespołów tworzących
> > różne "produkty", architektem można nazwać kogoś, kto decyduje ite
> > tych "produktów" ma być i w jaki sposób funkcjonalność będzie dzielona
> > między nimi, jak również może decydować o rzeczach typu Unix czy
> > Windows, Oracle czy Sybase itd.
>
> O kurde. Mamy inne doświadczenia.

Moje doświadczenie w ogóle jest takie, że "architekt" znaczy różne
rzeczy w różnych organizacjach.

Natomiast jeśli masz coś do powiedzenia na temat swoich doświadczeń w
kwestii tego, co napisałem, to nie krępuj się i wal prosto z mostu.

> >> Co do dużych zespołów - x>>  50, powiedzmy 500 - też się stosuje Agile,
> > 500-osobowy zespół? Stosujący agile? Masz jakieś przykłady? Jakie
> > metodologie się w tych zespołach stosuje?
>
> 30MLOC to ile osób? Tak naprawdę to źle użyłem słowa zespół: dział,
> albo i większa struktura.

No więc to trochę jakby robi różnicę. Dla uwagi jeszcze należałoby
ustalić, czy te 500 osób to programiści lub zespoły developerskie
złożone głównie z programistów, czy wliczają się w to też supportowcy,
obsługa data centre, handlowcy, office management i tak dalej.

> > W XP i XP-podobnych wariantach Scrum jest takie wymaganie.
> > Oragnizacyjnie, nie może być tak, że zespół nie może zrefaktoryzować
> > swojego kodu i wywalic np. jakieś funkcje czy klasy, bo inny zespół z
> > nich korzysta. Każdy komponent musi tylko udostępniać dobrze
> > zdefiniowane i obwarowane acceptance testami interfejsy, i ci, którzy
> > korzystają z tych interfejsów to "klienci" danego zespołu.
> > Implementacja tych interfejsów jest własnością zespołu i zespół musi
> > mieć na tyle autonomii, żeby sobie tę implementację móc zmieniać
> > według potrzeb. To miałem na myśli pisząc "autonomiczne komponenty",
> > oczywiście nie chodzi o to, żeby każdy z nich mógł być używany bez
> > pozostałych.
>
> To w specyficzny sposób wspiera tezę z mojego pierwszego posta: dzięki

Nie mam pojęcia o jaką tezę ci chodzi. Możesz przypomnieć?

> Agile odkryliśmy abstrakcję API. Kiedyś odkryjemy, że API to jeszcze nie
> wszystko i warstwy muszą działać razem.

Kiedyś może odkryjecie, że do tego właśnie służy abstrakcja API.

> Dziękujemy o Agile za odkrycie warstw abstrakcji i testów. Ja tu nie
> widzę żadnej różnicy pod względem metodyki, ale to pewnie zależy od
> punktu, z jakiego się startuje zmieniając religię na zwinniejszą.

Różnicy między czym a czym?

do góry

On Dec 22, 10:18 am, Roman W <b...@g...pl> wrote:
> On Thursday, December 22, 2011 10:11:51 AM UTC, Andrzej Jarzabek wrote:
> > On Dec 22, 8:53 am, Roman W <b...@g...pl> wrote:
> > > On Thursday, December 22, 2011 1:25:33 AM UTC, Andrzej Jarzabek wrote:
> > > > Już nic, bo zanim wyszedłem z pracy zdążyłem zaimplementować to, czego
> > > > notatka dotyczyła. Sama notatka jest już w śmietniku.
>
> > > To na czym ma polegac osoba, ktora przejmuje taki kod? Tylko na komentarzach?
>
> > Tego kodu akurat nikt nie przejmie. Prawdopodobnie za jakieś trzy
> > tygodnie zostanie wykonany raz w produkcji i odłożony do lamusa.
>
> > W ogólnym przypadku polega się przede wszystkim na czytelnym kodzie i
> > czytelnych testach.
>
> IMHO to jest za malo.

Bywa, ale często wystarczy. Wracając do kontekstu: jeśli zamiast
trzech słów notatki, na podstawie której będziesz tworzyć
implementację tego samego dnia, lub w tym samym tygodniu, napiszesz
pięciostronicowy dokument w ten sposób, żeby mógł go zrozumieć i
implementację zrobić ktoś inny, a następnie zrobisz tę implementację
sam, to z konieczności w takim pięciostronicowym dokumencie znajdzie
się wiele informacji, która będzie redundantna, o ile piszesz czytelny
kod i testy. Jeśli napiszesz trzy słowa notatki, potem testy i
implmenetację, a to, czego nie potrafisz wyrazić w testach i kodzie,
umieścisz w komentarzach lub w dokumencie, to łączna ilość wysiłku nie
jest taka sama, bo unikniesz pracochłonnego zapisywania znacznej
części informacji dwa razy - w dokumencie w języku naturalnym
(pseudokodzie, diagramie itd) i drugi raz w kodzie. A przede wszystkim
omijasz problem potencjalnie uciążliwego procesu synchronizacji
dokumentacji i kodu (lub przynajmniej znacznie zmniejszasz jego
uciążliwość).

do góry

On 12/22/2011 11:33 AM, Andrzej Jarzabek wrote:
>> To w specyficzny sposób wspiera tezę z mojego pierwszego posta: dzięki
> Nie mam pojęcia o jaką tezę ci chodzi. Możesz przypomnieć?
>

Proszę, cytat:

> że w Javie najczęściej występuje Agile,
> którego jednym z głównych założeń jest niwelowanie
> "technical debt" - potrzeba matką wynalazku?


On 12/22/2011 11:33 AM, Andrzej Jarzabek wrote:
>> Agile odkryliśmy abstrakcję API. Kiedyś odkryjemy, że API to jeszcze nie
>> > wszystko i warstwy muszą działać razem.
> Kiedyś może odkryjecie, że do tego właśnie służy abstrakcja API.

Ale ja wiem, że do tego służy abstrakcja API. Nie będę Pana za bardzo
wpieniać przed świętami, ok?

Edek

do góry