On 18/12/2011 15:28, A.L. wrote:
> On Sun, 18 Dec 2011 10:41:42 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>>> 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.
>
> Dyc o tym pisze. DOKUMENTACJA.

A ja piszę - cytuję - "istnieją inne sposoby". Z kontekstu wynika, że
inne niż dokumentacja.

> Juz pisalem, ze w jednym z projektow w
> ktorych biore udzial, same "requitements" maja ponad 3000 stron

I o czym to ma niby świadczyć?

do góry

On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

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

PROGRAMISCI kontaktuja sie z uzytkownikiem gdy tzreba pierdyknac bazke
danych szlauchow i kaloszy. W duzych projektach, programiste od
klienta dzieli dobre pare warstw organizacji i kudzi.

Ciekawe ile jescza razy trzeba bedzie to powtarzac?

A.L.

do góry

On 2011-12-18, A.L <l...@a...com> wrote:
[...]
> Jezeli Kolega powtarza to co Kolege nauczyli na studiach, to powinien
> Kolega poprosic o zwrot kosztow edukacji. Jezeli zas kolega jest
> praktykiem, to w celu uwierzytelnienia Kolegi pogladow - to znaczy ze
> Kolega do nich doszedl na podstawie wlasnej praktyki - proponuje aby
> Kolega opublikwoal swe resume z lista projektow i ich szczegolowa
> charakterystyka.

Ja wiem że A.L ma mnie w KF, ale nie mogę się zwyczajnie powstrzymać.

A.L, neich Kolega opublikuje swe resume z lista projektow i ich
szczegolowa charakterystyka. Chyba że Kloedze "NDA" nie pozwalaja, bo,
zdaje się, to jest typowa dla Koelgi wymwoka?

> Inaczej mi to wyglada jak przyslowiowe opowiesci slepego o kolorach.

Mnie przypomina to przypowieść o belce i źdźble.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 18/12/2011 15:38, A.L. wrote:
> On Sun, 18 Dec 2011 11:52:26 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> 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 projektach wiekszych niz jednoosobowe klient nic nie mowi do
> programistow.

Klient często w ogóle nie mówi do nikogo, bo jest instytucją. Natomiast
w projektach większych niż 5 i mniejszych niż 50 osób osoby
reprezentujące klienta jak najbardziej mówią do programistów.

> Podobnie jak osoba zamawiajaca budowe mostu przez Wisle
> nic nie mowi do spawaczy. Most projektuje architekt, na podsatwie
> wymagan klienta ktorym to klientem sa wladze miasta, potem projekt
> bierze inzynier budowlany i okreska szczegoly konstrukcji - sposob
> realizacji przesel, grubosc belek itede oraz organizacje procesu
> budowy. Na podstawie tego powsztaje dokumentacja i dopiero wtedy
> spawacze (czytaj: programisci) dostaja polecania aby zepsawac to z
> tamtym.
>
> Dokladnie tak samo wyglada realizacja pzredsiewziec programistycznych.

W waszej firmie. W innych firmach wygląda to inaczej. Wychodzi na to, że
w niektórych firmach oprogramowanie tworzy się metodami do tworzenia
oprogramowania, a w innych firmach metodami do tworzenia mostów.

> Programista ma niewielki wplyw na postac produktu koncowego, bo to nie
> programista decuduje jak ten produkt bedzie wygladal. Z wyjatkiem
> pierdykniecia bazki danych szlauchow i kaloszy.

W opisywanej przeze mnie metodologii też nie programiści decydują o tym.
W szczególności decyduje o tym product owner albo klient.

> Jezeli Kolega powtarza to co Kolege nauczyli na studiach, to powinien
> Kolega poprosic o zwrot kosztow edukacji. Jezeli zas kolega jest
> praktykiem, to w celu uwierzytelnienia Kolegi pogladow - to znaczy ze
> Kolega do nich doszedl na podstawie wlasnej praktyki - proponuje aby
> Kolega opublikwoal swe resume z lista projektow i ich szczegolowa
> charakterystyka.
>
> Inaczej mi to wyglada jak przyslowiowe opowiesci slepego o kolorach.

Przykro mi, nie odczuwam żadnej potrzeby uwierzytelnienia się przed
kolegą. A może by kolega opublikował swoje resume w celu
uwierzytelnienia swoich poglądów, np. że programowanie buduje się
właśnie tak, jak mosty.

do góry

On Dec 18, 1:18 pm, Andrzej Jarzabek <a...@g...com>
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 na ironię, dokładnie tak tłumaczy się przypadek Ariane V. Kupa
dymu, bo program zadziałał zgodnie ze specyfikacją.

Żatry na bok, ale w powyższym przypadku jest bug w dokumentacji. Jej
zaletą jest fakt, że łatwiej znaleźć buga w dokumentacji, która
istnieje, niż w dokumentacji, która nie istnieje. W szczególności,
dokumentacja jest materiałem, który odtwarza się w posób powtarzalny,
podczas gdy rozmowy z OSCR mogą zawierać składnik stochastyczny
zależny od tego, ile kawy OSCR w danym dniu wypił.
Dlatego dokumentację można np. powielić i dać do audytu. Nawet
równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.

Nadal wolę dokumentację, zwłaszcza w przypadku elektrowni atomowej.

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

Jakich testów? Tych, które powstały na podstawie nieistniejącej
dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?

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

do góry

On Sun, 18 Dec 2011 15:40:28 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 18/12/2011 15:28, A.L. wrote:
>> On Sun, 18 Dec 2011 10:41:42 +0000, Andrzej Jarzabek
>> <a...@g...com> wrote:
>>
>>>> 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.
>>
>> Dyc o tym pisze. DOKUMENTACJA.
>
>A ja piszę - cytuję - "istnieją inne sposoby". Z kontekstu wynika, że
>inne niż dokumentacja.
>
>> Juz pisalem, ze w jednym z projektow w
>> ktorych biore udzial, same "requitements" maja ponad 3000 stron
>
>I o czym to ma niby świadczyć?

O tym ze poziom "bicia piany" w tym watku osiagnal prog taki przy
ktorym watek blokuje pzred dalsza "dyskusja"

A.L.

do góry

On Dec 18, 2: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.

Zaraz, zaraz. Pisałeś na początku, że dokumentacji ma nie być. Teraz
piszesz, że ma być?

Czyli rozumiem, że w Agile chodzi o to:

- Drogi kliencie, po co będziemy marnować N miesięcy na pisanie
dokumentacji. Zrezygnujmy z niej w imię oszczędności i przyśpieszenia
projektu.
- OK! Oszczędności i przyśpieszenie to jest to, co lubimy najbardziej!
- Fajnie. Kupiliśmy zapas kawy i cisteczek na N miesięcy. Zapraszamy
do naszego biura, spędzimy ten czas na pisaniu notatek. Jak tych
notatek będzie bardzo dużo, to zepniemy do segregatora.

Coś jakby mi sprzedawca samochodów wciskał, że jak kupię u niego auto,
to przez następne 10 lat nie będę musiał *w ogóle* płacić za benzynę.
Tyle, że będę musiał płacić za olej napędowy. Słaby pomysł (zwłaszcza
teraz).

Sorki, ale na czym polega postęp? Na wciskaniu ludziom kitu, czy na
tym, że słowo "notatki" albo "user stories" jest bardziej cool, niż
"dokumentacja"?
(fakt, że krótsze słowa prędzej się zmieszczą w Twitterze - może o to
chodzi?)

I przede wszystkim - w jakiż to sposób zapewnimy, że notatki będą
zgodne z rzeczywistością, że się nie rozjadą i że i tak dalej - tutaj
wstaw *wszystkie* zarzuty, które miałeś do dokumentacji a nagle
problemu cudownie nie ma przy notatkach?
Czary mary?

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

do góry

On 18/12/2011 15:40, A.L. wrote:
> On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>>
>> 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.
>
> PROGRAMISCI kontaktuja sie z uzytkownikiem gdy tzreba pierdyknac bazke
> danych szlauchow i kaloszy. W duzych projektach, programiste od

Jak rozumiem dla kolegi duży projekt to jest taki,w którym pracuje 50
programistów i więcej. Więc ja powtórzę - te metodologie sie stosuje, i
moje doświadczenia dotyczą niedużych projektów - mniej więcej od 6 do 20
programistów. Nie mam pojęcia, jakiej wielkości są projekty tworzenia
baz danych szlayuchów i kaloszy, bo przyznam, że w tej akurat dziedzinie
doświadczenia żadnego nie mam, ale takie wielkości projektów, o których
mówię, to są np. market data systems, tradig platforms, order routing,
algorithmic trading, securities finance, różne systemy middle i back
office itd.

> klienta dzieli dobre pare warstw organizacji i kudzi.

Dodatkowo, w wielu organizacjach struktura jest taka, że klientem
jednego zespołu jest inny zespół w tej samej firmie. Na przykład
klientami dla systemu podającego dane z giełdy może być kilka zespołów
tworzących produkty korzystające z tych danych.

> Ciekawe ile jescza razy trzeba bedzie to powtarzac?

Nie ma potrzeby - bez kwatyfikatora to zdanie ma zerową wartość
informacyjną.

do góry

On 18/12/2011 16:22, Maciej Sobczak wrote:
> On Dec 18, 2: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.
>
> Zaraz, zaraz. Pisałeś na początku, że dokumentacji ma nie być. Teraz
> piszesz, że ma być?

Jeśli wynotowanie sobie czegoś podczas rozmowy na kartce papieru to już
"dokumentacja" to się nie zrozumieliśmy. Oczywiście w ramach powiedzmy
XP jak najbardziej notuje się rzeczy na kartkach papieru.

> Czyli rozumiem, że w Agile chodzi o to:
>
> - Drogi kliencie, po co będziemy marnować N miesięcy na pisanie
> dokumentacji. Zrezygnujmy z niej w imię oszczędności i przyśpieszenia
> projektu.
> - OK! Oszczędności i przyśpieszenie to jest to, co lubimy najbardziej!
> - Fajnie. Kupiliśmy zapas kawy i cisteczek na N miesięcy. Zapraszamy
> do naszego biura, spędzimy ten czas na pisaniu notatek. Jak tych
> notatek będzie bardzo dużo, to zepniemy do segregatora.

Nie, nie ma żadnych N miesięcy na pisanie notetek i nie ma wpinania
notatek do segregatora. Notatki służą do tego, żeby pomiędzy rozmową z
OSCR-em a zakodowaniem uzyskanej informacji rozmawiający nie zapomniał.
Ten czas, to bardzo rzadko więcej niż dzień, nigdy więcej niż 3-4 dni.

> Sorki, ale na czym polega postęp? Na wciskaniu ludziom kitu, czy na
> tym, że słowo "notatki" albo "user stories" jest bardziej cool, niż
> "dokumentacja"?
> (fakt, że krótsze słowa prędzej się zmieszczą w Twitterze - może o to
> chodzi?)

Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
przez OSCR-ów są priorytetyzowane na początku każdej iteracji i według
ich ważności i szacowanego czasu wykonania wybierany jest zestaw do
wykonania w czasie następnej iteracji (np. tygodnia). Wszystkie user
stories, które nie są zaplanowane na kolejną iterację, mogą do następnej
iteracji zostać wykreślone albo zmienione. Z kolei w ciągu tego tygodnia
mogą zostać stworzone nowe stories, które dla klienta będą ważniejsze
niż te, które są już w backlogu. Co tydzień kolejna iteracja planowana
jest na zasadzie: wybiera się stories, które są najważniejsze do
zrobienia; programiści szacują, ile zajmie zrobienie każdej story, po
czym product owner w porozumieniu z ewentualnymi OSCR-ami decyduje co
będzie robione w kolejnej iteracji. W ramach kompletowania danej story
oczywiście może powstawać dokumentacja końcowa, w której jest napisane,
że program ma daną funkcjonlaność i jak ona działa.

> I przede wszystkim - w jakiż to sposób zapewnimy, że notatki będą
> zgodne z rzeczywistością, że się nie rozjadą i że i tak dalej - tutaj
> wstaw *wszystkie* zarzuty, które miałeś do dokumentacji a nagle
> problemu cudownie nie ma przy notatkach?
> Czary mary?

Przede wszystkim czas - czas życia notatki mierzony jest raczej w
godzinach, od momentu zrobienia do momentu zapisania odpowiedniej treści
w postaci testów i (potencjalnie jeszcze nie działającego) kodu. Potem
już nikogo nie obchodzi, że się rozjedzie, bo będzie w koszu na śmieci.

do góry

On 18/12/2011 16:11, Maciej Sobczak wrote:
>
> Żatry na bok, ale w powyższym przypadku jest bug w dokumentacji. Jej
> zaletą jest fakt, że łatwiej znaleźć buga w dokumentacji, która
> istnieje, niż w dokumentacji, która nie istnieje. W szczególności,
> dokumentacja jest materiałem, który odtwarza się w posób powtarzalny,
> podczas gdy rozmowy z OSCR mogą zawierać składnik stochastyczny
> zależny od tego, ile kawy OSCR w danym dniu wypił.
> Dlatego dokumentację można np. powielić i dać do audytu. Nawet
> równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.

Acceptance tests mają takie ficzery.

>> Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
>> testów i nie może zostać zreleasowany.
>
> Jakich testów? Tych, które powstały na podstawie nieistniejącej
> dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?

Testów, które powstały na podstawie rozmowy z OSCR-em i zostały przez
tego OSCR-a zatwierdzone.

do góry