On Sat, 17 Dec 2011 09:20:47 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/12/2011 03:07, A.L. wrote:
>> On Sat, 17 Dec 2011 01:20:59 +0000, Andrzej Jarzabek
>> <a...@g...com> wrote:
>[...]
>>> Nie. W szczególności np. w extreme programming jest wprost powiedziane,
>>> że wymyśla to ktoś nie będący programistą. Jeśli kolega kiedyś zechce
>>> dowiedzieć się czegoś o tym, proponuję na początek zapoznać się z
>>> hasłami "on-site customer" (lub "customer representative") i "product
>>> owner". Oczywiście jeśli kolega nadal woli się wypowiadać w tematach, o
>>> których nie ma pojęcia, to będzie to niekonieczne - w takiej sytuacji
>[...]
>> I co?.. .Ta dokumentacja stoi na polce a programisci robia swoje? BEz
>> cztrania dokumentacji? I programuja na podsatwie objawinia Ducha
>> Swietego?...
>
>Nie potrzeba objawienia Ducha Świętego, skoro są product owner i on-site
>customer.

Ze co?... Jak to bedzie po polsku?...

A.L.

do góry

On 18/12/2011 02:59, A.L. wrote:
> On Sat, 17 Dec 2011 09:20:47 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>>> I co?.. .Ta dokumentacja stoi na polce a programisci robia swoje? BEz
>>> cztrania dokumentacji? I programuja na podsatwie objawinia Ducha
>>> Swietego?...
>>
>> Nie potrzeba objawienia Ducha Świętego, skoro są product owner i on-site
>> customer.
>
> Ze co?... Jak to bedzie po polsku?...

Nie mam pojęcia, czy istnieje jakaś terminologia po polsku. Jeśli
koledeze te hasła nic nie mówią, to proponuję przeczytać na ten temat,
like, cokolwiek - będziemy mogli faktycznie podyskutować o tym, czy to
dobry, czy niedobry pomysł.

do góry

On 18/12/2011 02:58, A.L. wrote:
>
>> Jeśli chodzi o opis działania samego algorytmu, to programiści dysponują
>> znakomitym narzędziem właśnie do tego, jakim są wysokopoziomowe języki
>> programowania.
>
>
> Dupy zawracanie. Oczywiscie, latwo bedzie odcyfrowac taka rzecz jak
> "algorytm pivotingu" algorytmu Simplex przegladajac 150 tysiecy linii
> C jego implemenatcji.

Nie powiedziałbym, że C jest szczególnie dobrym przykładem języka
wysokiego poziomu. Co do przeglądania tysięcy linii kodu, to po to w
języku (nawet w C) są mechanizmy abstrakcji, żeby to nie było konieczne.

> Drodzy Panowie, znow obracacie sie kolo paradygmatu "bazki danych
> szlauchow i kaloszy" i "systemow" pisanych pzrez jednego programiste w
> pare wieczorow. Jeszcze raz: w duzych projektach programista nei
> rozmawia z klientem, w ogole nie widzi go na oczy, a "klient" to nie
> pojedyncza osoba a duza na ogol organizacja.

XP nie jest metodą tworzoną pod kątem jednego programisty piszącego dla
jednego klienta przez kilka dni. Jest zaprojektowany pod kątem zespołu z
6-12 programistami, tworzącego oprogramowanie dla klientów
instytucjonalnych przy czasie trwania projektu liczonym co najmniej w
miesiącach.

> Bez odpowiedniej
> formalizacji procesu projektowania i dokumentowania wymagan dla
> programisty ow programista nei mialby zielonego pojacia co
> programowac, a projekt skutkowalby tym samym czym skutkowala proba
> bucowy Wiezy Babel

Otóż jednak istnieją inne sposoby na to, żeby programista miał pojęcie.

do góry

On 18/12/2011 02:24, Roman W wrote:
> On Dec 18, 1:36 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>> On 17/12/2011 20:02, Roman W wrote:
>>> Systemu jako calosci? Czyli jednak dokumentacja.
>>
>> Systemu jako całości lub danego kawałka. Wiedza to nie jest to samo, co
>> dokumentacja.
>
> Dokumentacja to sformalizowana, usystematyzowana wiedza.

Ale nie jest to jedyny sposób na sformalizowanie i usystematyzowanie
wiedzy. Kod programu i jego testów też bardzo często można sformułować
tak, żeby był równie dobrym, sformalizowanym i usystematyzowanym zapisem
wiedzy. Agile mówi, że w takich przypadkach lepiej poświęcić trochę
więcej czasu na takie zapisanie kodu, niż na tworzenie dokumentacji.

>>> Ale to opisuje wycinek systemu.
>>
>> Łącznie wszystkie te opisy opisują cały system. Tak samo jak z
>> dokumentacją wymagań zresztą: składa się zwykle z jakichś rozdziałów,
>> które opisują wycinki systemu.
>
> Wiesz, rownie dobrze mozna by argumentowac, ze rozsypana na podlodze
> kupka srubek i sprezynek to jest tak jak zegarek, bo i to i to sklada
> sie z jakichs srubek i sprezynek. Ale jakos jedno powie mi ktora
> godzina, a drugie nadaje sie tylko do zmiecenia szczotka.

W XP wszystko od razu powstaje w kontekście tego, gdzie ma być użyte, bo
masz TDD i YAGNI. To, że w ogóle ktoś się zabiera za pisanie jakiegoś
kawałka programu wynika z tego, że wcześniej określono, że taki kawałek
jest potrzebny, do czego jest potrzebny, co ma robić, i zapisano tę
wiedzę w testach.

>> Jednak nie tylko przechodzący kilka testów, bo jego forma się bierze
>> stąd, że programista _rozumie_ co program ma robić, a nie z tego, że
>> widział kod testów i dostaje zadanie napisania kodu je przechodzącego.
>
> To co widzial? mial objawienie? czy moze cos, gasp, przeczytal?

Jeszcze raz: rozmawiał z OSCR, który mu to wytłumaczył.

do góry

On 18/12/2011 02:25, Roman W wrote:
> On Dec 18, 1:46 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>>> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
>>> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
>>> krótką listą zakupów, ale dłuższe opisy mi się urywają.
>>
>> Sprzedam ci niezły patent: notatki.
>
> Jezeli Koles A przelewa wiedze do glowy kolesia B, to czesto lepiej
> jest, zeby forme pisemna wiedzy nadal koles A, bo on sie w tym lepiej
> orientuje niz B. Dlatego na studiach oprocz notatek miales rowniez
> podreczniki i konspekty.

No to przecież w XP również kolesie A produkują formę pisemną, w postaci
np. user stories.

Jeśli chodzi o różnicę między wykładem na studiach a programowaniem w
reżimie XP, to zauważ, że w drugim przypadku kontakt jest znacznie
bardziej bezpośredni - masz np. parę programistów, którzy potrzebują
czegoś wiedzieć, więc idą do OSCR, który im tłumaczy, rysuje, oni
dopytują, on im coś rysuje na flipcharcie, oni rysują na flipcharcie i
pytają czy jest tak, czy śmak i tak dalej, aż programiści nie poczują,
że wystarrczająco rozumieją problem, żeby napisać kod. Zauważ też, że
sam fakt, że programiści bezpośrednio po takiej sesji będą musieli
wyprodukować kod stanowi jakiś test tego, że zrozumieli to, co było im
tłumaczone.

do góry

On Dec 18, 11:04 am, Andrzej Jarzabek <a...@g...com>
wrote:
> Jeśli chodzi o różnicę między wykładem na studiach a programowaniem w
> reżimie XP, to zauważ, że w drugim przypadku kontakt jest znacznie
> bardziej bezpośredni - masz np. parę programistów, którzy potrzebują
> czegoś wiedzieć, więc idą do OSCR, który im tłumaczy, rysuje, oni
> dopytują, on im coś rysuje na flipcharcie, oni rysują na flipcharcie i
> pytają czy jest tak, czy śmak i tak dalej, aż programiści nie poczują,
> że wystarrczająco rozumieją problem, żeby napisać kod. Zauważ też, że
> sam fakt, że programiści bezpośrednio po takiej sesji będą musieli
> wyprodukować kod stanowi jakiś test tego, że zrozumieli to, co było im
> tłumaczone.

Ja tu widze kilka praktycznych problemow:
- co robia programisci, kiedy OSCR jest chory/poszedl na urlop i nie
ma zastepstwa?
- co sie robi w sytuacji, kiedy OSCR jest, well, glabem? jezeli mam
problem z dokumentem (jest niekompletny, niejasny, zawiera
sprzecznosci) moge go w miare bezpiecznie skrytykowac. Jezeli moim
biezacym zrodlem wiedzy jest czlowiek przyslany przez klienta, to
napisanie maila "X nie rozumie o co biega w projekcie/nie umie
wyjasnic o co biega" jest politycznie trudniejsze niz napisanie
"dokumentacja jest niekompletna, prosze uzupelnic", bo krytykujesz
osobe a nie rzecz.
- bez formalnej dokumentacji jest trudniej sledzic, na jakim etapie
kto zazyczyl sobie zmian w projekcie, kto odpowiada za dane
rozwiazanie, itd. OSCR moze na flipczarcie narysowac programistom cos
co mu akurat przyszlo do glowy, programisci zuzyja X roboczogodzin na
implementacje jego fantazji, a kiedy kupka uderzy w wiatraczek, to
OSCR sie moze wyprzec ze kiedykolwiek o tym mowil - bo przeciez nikt
nie bedzie lazil do OSCR z dyktafonem w kieszeni, nie?

RW

do góry

On Dec 18, 2:58 am, A.L. <l...@a...com> wrote:
> On Sun, 18 Dec 2011 01:36:16 +0000, Andrzej Jarzabek
> Dupy zawracanie. Oczywiscie, latwo bedzie odcyfrowac taka rzecz jak
> "algorytm pivotingu" algorytmu Simplex przegladajac 150 tysiecy linii
> C jego implemenatcji.

*Ile* linii? Sa tak dlugie implementacje tego algorytmu?

RW

do góry

On 17/12/2011 22:51, Maciej Sobczak wrote:
> On Dec 17, 4:58 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
>> długo, żeby zrozumieć co program ma robić,
>
> I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
> procesu.
>
> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
> krótką listą zakupów, ale dłuższe opisy mi się urywają.
>
> [*] Z obserwacji wynika, że nie tylko ja mam ten defekt. Akurat mamy
> weekend - stań przed jakimś kościołem i zapytaj wychodzących ludzi o
> czym było kazanie. Pamiętaj, że wszyscy słuchali tego samego, ale
> zapytaj kilka różnych osób.
> Dobre, nie?
>
> Pytanie: jak długa jest rozmowa z tym - jak mu tam - OSCR, żeby
> przekazać równoważnik kilkuset stron tekstu? Krócej, niż kazanie, czy
> dłużej?

Ale moment, ty to sobie wyobrażasz na zasadzie "kazanie" - programiści
siadają wszyscy w sali i klient im mówi od początku do końca jak program
ma działać, po czym bierze walizeczkę i idzie do domu?

W takiej sytuacji mogę tylko powiedzieć, że po prostu niee zrozumiałeś,
o co chodzi. On-site customer polega właśnie na tym, że pracuje razem z
zespołem, siedzi razem z zespołem w godzinach pracy i jeśli programiści
nie wiedzą jak coś konkretnie powinno działać, to idą i on im mówi. To
może równie dobrze trwać dwie minuty.

Ze szczegółowymi wymaganiami robi się tak, że rozbija się na małe
kawałki, tzw "user stories". Potem te stories się planuje i konkretni
programiści zajmujący się akurat implementacją konkretnej story
rozmawiają z OSRC na temat tego jak program ma działać we fragmencie
związanym z tą właśnie story.

>> a jeśli nie jest w stanie
>> zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
>> rozmawia z OSCR jeszcze trochę.
>
> No właśnie.
> Otóż zaletą metodologii "dokumentacyjnych" jest to, że kiedyś,
> ostatecznie, *można się rozejść*. Bo nawet jeśli się odbiorcy się
> urwał wątek, to może sobie do niego wrócić we własnym zakresie i nie
> potrzebuje "rozmawiać z OSCR jeszcze trochę".

Jak "rozejść"? Jakiemu odbiorcy? Nie bardzo rozumiem, co masz na myśli.
On-site customer representative reprezentuje twojego klienta
(zewnętrznego, wewnętrznego lub wyobrażonego). Dopóki masz klienta, to
możesz mieć osobę reprezentującą to, co klient chce.

Jeśli z "rozejściem" chodziło o to, że programiści mogą się fizycznie
oddalić od OSCR, to przecież nie chodzi o to, że oni fizycznie
rozmawiają z nim cały czas. Rozmawiają tyle, ile potrzeba żeby się
dowiedzieli, czego nie wiedzą, zrozumieli, czego nie rozumieją, a co
jest im akurat potrzebne do zaimplementowania kolejnego kawałka
funkcjonalności, zanotowali co trzeba, a potem oddalili się do
stanowiska programistycznego i przelali to, co właśnie usłyszeli do
postaci tesów i kodu.

> Możliwość rozejścia się jest kluczowa dla postępu projektu. Bez tej
> możliwości albo masz zastój (znaczy: odbiorca "rozmawia jeszcze
> trochę" w nieskończoność), albo urwaną treść. Osobiście nie widzę
> siebie w rozmowie na temat czegoś, co na papierze ma kilkaset stron.

Ale jesteś w stanie przeczytać te kilkaset stron od deski do deski i
pamiętać każdy szczegół?

> Napisanie dokumentacji służy przekazaniu wiedzy i jest to proces,
> który może być zarówno kompletny, jak i obustronnie potwierdzony.

Pisanie acceptance testów też może być takim procesem.

> Minimalizacja bugów, jeśli w ogóle występuje, jest tu procesem
> pobocznym a nie celem samym w sobie. Celem minimalizacji bugów może
> być np. zastosowanie metod formalnych. Albo unit testy. Albo voo-doo.
> Albo co tam kto umie i czemu ufa, zależnie od budżetu i lokalnej
> kultury. Jednak żadna z tych metod nie wyklucza użycia dokumentacji,
> która służy tylko (i aż!) do skompletowania procesu przekazywania
> wiedzy.
> Dlatego nie ma problemu, żeby zrobić dokumentację *oraz* unit testy
> (przykładowo).

Problem jest taki, że masz ograniczone zasoby i musisz rozwiązać problem
efektywnego ich wykorzystania. Jeśli ktoś pisze dokumentację, to nie
może w tym samym czasie odpowiadać na pytania ani pisać testów. Porządne
pisanie kodu i testów może trwać dłużej niż pisanie byle jak: do tego
stopnie, że być może będziesz chciał np. tworzyć albo adaptować DSL-e
i/lub frameworki do tego, żeby można było automatyczne testy wyrazić w
sposób maksymalnie deklaratywny i przy użyciu domain concepts.

> Problem z agile polega na tym, że przekazywanie wiedzy oparte jest na
> machaniu rękami i jest to najsłabsze ogniwo z powodów powyżej. A
> ponieważ to ogniwo jest na początku procesu, to dalej buduje się na
> gównianych fundamentach i stąd te ciągłe dema i walenie klienta po

Nie jest na początku procesu. Jest cały czas.

Natomiast problem z pisaniem dokumentacji jest taki, że jest oparte na
machaniu rękami, a ponieważ dokumentację pisze się na początku, to dalej
buduje się na gównainych fundamentach i stąd te ciągłe opóźnienia i
dostarczanie po terminie "kompletnej" funkcjonalności kompletnie nie
odpowiadającej potrzebom klientów.

> głowie niedokończonymi wersjami.
> Pominięcie dokumentacji *nie jest tańsze*. Tak przynajmniej wynika z
> moich obserwacji.

Z moich wręcz przeciwnie.

do góry

On 17/12/2011 22:43, A.L. wrote:
>
> Nie ma sie Pan co obawiac. To jest "metodologia Agile". Ponoc jedynie
> sluszna.
>
> Ciekawe jak "agilowcy" wyobrazaja sobie projekt w ktorym pracuje,
> powiedzmy, 50 programistow, i owi programisci nigdy nie kontaktuja sie
> z przyszlym uzytkownikiem systemu?

Po pierwsze, nie ma czegoś takiego jak "metodologia Agile". Można
ewnetualnie rozpatrywać konkretne metodologie jak XP czy Scrum, albo
zastanawiać się nad ogólnym podejściem Agile do tego tematu - ale w tym
drugim przypadku trzeba wziąć pod uwagę, że istnieją metodologie czy
procesy, które mieszczą się nadal w ogólnym nurcie Agile, ale stosują
pewne rozwiązania spoza tego nurtu.

Więc po pierwsze temat kontaktów z przyszłym użytkownikiem: generalnie
nie jest konieczny. XP zaleca, żeby w miarę możliwości "on-site
customer" był przedstawicielem typowego użytkownika systemu, ale nie
jest to jedyna możliwość. Podstawą jest to, żeby ludzie występujący w
rolach "customer representative" albo "product owner" rozumieli potrzeby
użytkownika, ewentualnie mieli możliwość szybkiego dowiedzenia się jakie
one są w szczególnym przypadku.

Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
je zastosować do większych projektów, pod warunkiem, że da się podzielić
zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
(komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,
albo ma się zespół zajmujący się integracją systemu i ten zespół pracuje
z końcowym klientem i podaje wymagania zespołom wykoującym poszczególne
komponenty. Czasem jest to niemożliwe albo niepraktyczne, i w takich
sytuacjach po prostu nie należy stosować tych metodologii.

do góry

On 17/12/2011 22:27, Maciej Sobczak wrote:
> On Dec 17, 4:30 pm, Roman W<b...@g...pl> wrote:
>
>> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
>> co jest bugiem, a co nie.
>
> Bingo.

Czyli jeśli zachowując się zgodnie z dokumentacją program doprowadza do
wybuchu elektrowni ataomowej, to nie ma buga, po prostu to właśnie miał
zrobić?

>> Jak programista Agile ma eliminowac bugi,
>> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu?
>
> No właśnie. Bo jeśli program działa niezgodnie z istniejącą
> dokumentacją, to coś należy poprawić. Ale jeżeli działa niezgodnie z
> nieistniejącą dokumentacją, to projekt jest w ciemnej d*pie. I to jest
> właśnie ta perspektywa, której się obawiam.

Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
testów i nie może zostać zreleasowany.

do góry