On May 17, 1:34 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On May 17, 1:22 pm, "Przemek O." <p...@o...eu> wrote:
>
> > >> ??? Czyżbyś pisał aplikację prototypując i to bez projektu?
>
> > > Jest taka szkoła myślenia jak Agile, która głosi, że tak jest lepiej.
>
> > Jeśli jest lepiej, to dlaczego najczęściej występuje z XP lub jego
> > częścią pair programming???
>
> Podobno dlatego, że tak jeszcze lepiej.
>
> > Ile projektów prowadziłeś stosując Agile, że się z tym zgadzasz?
>
> Nie prowadziłem żadnego, ale robiłem w takich, w których robiono
> design up front,
[...]

Aha, jeszcze, jeśli chodzi o samo pisanie programów bez robienia
najpierw projektu, to jak najbardziej sporo takich napisałem.

do góry

W dniu 2011-05-17 13:40, R. P. pisze:
> Andrzej Jarzabek wrote:
>> On May 17, 11:38 am, "Przemek O." <p...@o...eu> wrote:
>>> W dniu 2011-05-17 12:32, Michoo pisze:
>>>
>>>> Jak już działa i widzisz jak do tego doszedłeś to masz doświadczenie
>>>> potrzebne do napisania tego porządnie. Dzięki temu piszesz coś 2 razy,
>>>> ale nie poświęcasz 9/10 czasu na projektowanie.
>>> ??? Czyżbyś pisał aplikację prototypując i to bez projektu?
>>
>> Jest taka szkoła myślenia jak Agile, która głosi, że tak jest lepiej.
>>
>> I ja np. zasadniczo się z tym zgadzam.
>
> Agile, scrum, te wszystkie nowe "wynalazki" powodują tylko to, że
> aplikacje stają się coraz mniej używalne, coraz więcej w nich błędów.
> Dołóż do tego jeszcze XP, a masz murowaną katastrofę.

Bzdury. Agile mówi z grubsza tylko tyle - proces ma być w minimalnym
stopniu obciążony elementami, które nie prowadzą do działającego
produktu. Na dodatek proces może (i powinien) być cały czas poprawiany.

Jeśli projekt i dokumentacja jest niezbędna do stworzenia działającego
produktu, to powstanie. Ale np. nie musi być sformalizowana, jeśli
zdjęcie tablicy z rysunkiem + 5 zdań objaśnienia jest wystarczające.
Jeśli zespół nie jest w stanie zapanować nad złożonością i ciągle się
wszystko sypie, to raczej dojdzie do wniosku, że formalna dokumentacja
musi powstać. I pewnie powstanie. To jest element uczenia się
i poprawiania procesu wytwarzania.

Tak - to cały czas jest balansowanie na linie i ryzykowanie. Przy silnym
założeniu, że ludzie się uczą na błędach (i nie są za nie karani*) to
wystarcza.

*) Największą karą i motywacją bywa świadomość, że coś się spieprzyło
w sposób absolutnie oczywisty.

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

do góry

W dniu 2011-05-17 15:05, Andrzej Jarzabek pisze:

>>> Ile projektów prowadziłeś stosując Agile, że się z tym zgadzasz?
>>
>> Nie prowadziłem żadnego, ale robiłem w takich, w których robiono
>> design up front,
> [...]
>
> Aha, jeszcze, jeśli chodzi o samo pisanie programów bez robienia
> najpierw projektu, to jak najbardziej sporo takich napisałem.

To były raczej notatniki niż ERP? Co?

Ale na poważnie, jak już ktoś napisał, Agile wcale nie zakłada braku
projektu. Poza tym, jest pewien poziom skomplikowania, od którego
dokumentacja projektowa jest niezbędna do powstania produktu końcowego.
Dodatkowo jest jednak delikatna różnica pomiędzy pisanie programu który
się samemu wymyśliło dla siebie (lub wyimaginowanego klienta) niż dla
realnego zleceniodawcy. W pierwszym przypadku można improwizować,
najwyżej się zmieni, w drugim nie ma miejsca na improwizację, bo produkt
końcowy jest określony poprzez wymagania zleceniodawcy a nie własne
widzimisie.

pozdrawiam,
Przemek O.

do góry

On Tue, 17 May 2011 08:02:52 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/05/2011 03:13, A.L. wrote:
>> On Mon, 16 May 2011 23:35:14 +0100, Andrzej Jarzabek
>> <a...@g...com> wrote:
>>>
>>> Co do tego, żeby ktoś robił testy, to jak najbardziej słyszałem, nawet
>>> spotkałem się z tym, że duża i znana amerykańska firma tak robiła.
>>
>> Ach.. pewnie amerykanska w Europie?... To taka amerykanska firma jak
>> kura jest ptak.
>
>Owszem, chodziło o rekrutację do oddziału w Europie, ale firma jest dość
>mocno scentralizowana i proces rekrutacyjny był ustalany i testy
>organizowane przez centralny HR w Stanach. Sama firma testująca
>(Previsor konkretnie) była też amerykańska i zdaje się sporą część
>biznesu robiła na amerykańskim rynku.


Nie chce mi sie dalej pisac na ten temat....

A.L.

do góry

On May 17, 4:02 pm, A.L. <l...@a...com> wrote:
> On Tue, 17 May 2011 08:02:52 +0100, Andrzej Jarzabek
>
>
>
>
>
>
>
>
>
> <a...@g...com> wrote:
> >On 17/05/2011 03:13, A.L. wrote:
> >> On Mon, 16 May 2011 23:35:14 +0100, Andrzej Jarzabek
> >> <a...@g...com>  wrote:
>
> >>> Co do tego, żeby ktoś robił testy, to jak najbardziej słyszałem, nawet
> >>> spotkałem się z tym, że duża i znana amerykańska firma tak robiła.
>
> >> Ach.. pewnie amerykanska w Europie?... To taka amerykanska firma jak
> >> kura jest ptak.
>
> >Owszem, chodziło o rekrutację do oddziału w Europie, ale firma jest dość
> >mocno scentralizowana i proces rekrutacyjny był ustalany i testy
> >organizowane przez centralny HR w Stanach. Sama firma testująca
> >(Previsor konkretnie) była też amerykańska i zdaje się sporą część
> >biznesu robiła na amerykańskim rynku.
>
> Nie chce mi sie dalej pisac na ten temat....
>
> A.L.

To odwińmy może stos: jak pisałem, testy online nie służą znalezieniu
kompetentnego programisty, tylko zlikwidowaniu problemu kandydatów,
których kretynizm zwala z nóg. To są ortogonalne problemy: można z
jednej strony mieć mnóstwo kretynów przychodzących na rozmowy, a nie
mieć problemu ze znalezieniem kompetentnych kandydatów, a z drugiej
strony nie mieć rozmów z kretynami, ale też nie mieć rozmów z
kompetentnymi. Wspomniałeś o kretynach u was w firmie tak, jakby to
był problem, dlatego napisałem o testach. Oczywiście całkiem możliwe,
a nawet prawdopodobne, że ten problem nie jest dla was tak wielki,
żeby się wam opłacało organizować testy. Bo w znalezieniu
kompetentnego kandydata pewnie wam i tak nie pomogą.

Natomiast jeśli chodzi o znajdowanie komptentnych programistów przez
headhuntera, to pytanie brzmi tak: jak reprezentujący was headhuunter
znajdzie i zadzwoni do kompetentnego programisty, który już ma jakąś
tam swoja pracę, to czym może go zachęcić, do zainteresowania się
możliwością pracy dla was? Bo że nie kasą, to już wiemy.

do góry

On May 17, 3:35 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-17 15:05, Andrzej Jarzabek pisze:
>
> >>> Ile projektów prowadziłeś stosując Agile, że się z tym zgadzasz?
>
> >> Nie prowadziłem żadnego, ale robiłem w takich, w których robiono
> >> design up front,
> > [...]
>
> > Aha, jeszcze, jeśli chodzi o samo pisanie programów bez robienia
> > najpierw projektu, to jak najbardziej sporo takich napisałem.
>
> To były raczej notatniki niż ERP? Co?

Powiedzmy że gdzieś pomiędzy.

> Ale na poważnie, jak już ktoś napisał, Agile wcale nie zakłada braku
> projektu.

Żeby rozwiać niejednoznaczności, uściślijmy może, że chodzi o
tworzenie dokumentu projektowego, na podstawie którego tworzony jest
kod. Oczywiście kod, który piszę, posiada ostatecznie i na każdym
etapie "projekt" w sensie jakiejś struktury konceptualnej. Również,
jeśli jest takie wymaganie, mogę ten projekt udokumentować ex post, co
się dzieje np. po release albo przed hand-offem.

Natomiast twierdzę, i Agile tak twierdzi, że można (a niekiedy nawet
należy) pisać program bez dokumentu projektowego up front, czyli
takiego, który dokumentuje nieistniejący jeszcze kod, który będzie w
dalszej kolejności pisany według tego projektu.

Oczywiście jedna z rzeczy, do której projekt jest potrzebny, to
koordynacja równoległej pracy wielu programistów nad tym samym
projektem. Jak rozumiem Agile (powiedzmy konkretnie XP) zakłada tu
dwie możliwości: albo zaczyna się od tego, że w pierwszym dniu/
tygodniu kod produkcyjny tworzy jedna para programistów, podczas gdy
reszta konfiguruje source control i build machine, robi research,
rozmawia z customerami albo przestawia biurka. Druga możliwość jest
taka, że zespół robi zebranie i ustala nieformalny bardzo ogólny
projekt up front, który pozwoli im na dalszy podział pracy. W każdym
przypadku projekt jest formalizowany nie do dokumentu projektowego,
tylko do zestawu unit testów, które w sposób jednoznaczny określają
jakie komponenty mają istnieć, jakie interfejsy udostępniac i jaką te
interfejsy mają mieć funkcjonalność.

> Poza tym, jest pewien poziom skomplikowania, od którego
> dokumentacja projektowa jest niezbędna do powstania produktu końcowego.

Nie zgodzę się. Dokumentacja projektowa może być potrzebna jeśli np.
zespół po zakończeniu projektu ma być rozwiązany lub przeniesiony do
innego projektu, a maintenance ma robić ktoś inny (co jest sensownym
scenariuszem, bo zespół agile powołany do tworzenia projektu ab initio
nie będzie najlepszym zespołem do jego maintainowania po zredukowaniu
ilości bieżącej pracy.

W drugiej kolejności dokumentacja może być potrzebna firmie jako
dupochron na wypadek, gdyby jakaś większa liczba członków zespołu
zechciała sobie pójśc gdzie indziej.

I w końcu jeśli zakładasz, że będzie duża rotacja pracowników w czasie
trwania projektu, dokumentacja projektowa jest potrzebna, ale jeśli
będzie duża rotacja, to prawdopodobie nie powinieneś stosować Agile.

> Dodatkowo jest jednak delikatna różnica pomiędzy pisanie programu który
> się samemu wymyśliło dla siebie (lub wyimaginowanego klienta) niż dla
> realnego zleceniodawcy. W pierwszym przypadku można improwizować,
> najwyżej się zmieni, w drugim nie ma miejsca na improwizację, bo produkt
> końcowy jest określony poprzez wymagania zleceniodawcy a nie własne
> widzimisie.

Projekt to projekt, a wymagania to wymagania. Nawet jeśli dostraczenie
dokumentu projektowego jest w wymaganiach, to raczej się nie wymaga,
żeby dostarczyć go up front - przed napisaniem programu. No chyba że
pracodawca/zleceniodawca ma też takie wymaganie, ale wtedy nie
praktykujesz agile, tylko narzucony z góry proces waterfall lub
iterative.

Jeśli chodzi o same wymagania, to XP ma takie podejście, że od
udokumentowanych wymagań lepszy jest customer w zespole. Oczywiście
musisz tego customera mieć, w dodatku musi być kompetentny i mieć
realną możliwość podejmowania decyzji i brak tego jest poważną
obiektywną przeszkodą w stosowaniu XP. Z drugiej strony oczywiście
należy do tego przyłożyć zdrowy rozsądek - podejście to nie oznacza
zakazu istnienia dokumentów z wymaganiami, istotne są natomiast dwie
rzeczy: po pierwsze, że realne wymagania będą się zmieniać w miarę
pracy z customerem i w związku z tym dokument z wymaganiami nie może
być wiążącą umową, a po drugie że jak programista będzie miał
jakiekolwiek problemy, uwagi czy propozycje co do tego, co wyczytał w
dokumentacji wymagań, to będzie mógł usiąść z customerem i wypytać się
go, czego on naprawdę chce. Jeśli te warunki nie moga być spełnione,
to jest to kolejna obiektywna przeszkoda w stosowaniu XP.

Jeśli chodzi o moje osobiste doświadczenie, to mam właśnie takie:
dokument z wymaganiami się szybko dezaktualizuje, możliwość szybkiego,
częstego i osobistego kontaktu z człowiekem, który rozumie wymagania i
będzie je mógł wyjaśnić - jest niezastąpiona. Sytuacja, w której
wymagania są kontraktem, w którym każdą zmianę trzeba negocjować jest
szkodliwa dla jakości tworzonego oprogramowania - prędzej czy później
nastąpi któraś z poniższych sytuacji:
- nagle się okaże, że jakiś feature opisany w wymaganiach jest Bardzo
Trudny do zaimplementowania i trzeba renegocjować kontrakt albo
ponosić ryzyko (np. opóźnień). Z drugiej strony ten sam feature może
wcale nie być tak istotny dla klienta, lub być łatwy do zastąpienia
czymś, co dla klienta ma prawie taką samą wartość, a jest trywialne do
zrobienia. Sam overhead renegocjonowania umowy może być w tym
przypadku gigantyczny w porównaniu do wysiłku podjęcia decyzji co do
wartości tego feature'a i zamiplementowania go w tej czy innej
postaci.
- okaże się, że wymaganie interpretowane w pewien sposób (powiedzmy -
rozumiane dosłownie, np. tak, jak by zrozumiał je pedantyczny
programista o matematycznym umyśle, nie mający szczególnie dużej
wiedzy o zastosowaniach wymaganego feature'a) jest jednocześnie
kosztowne w realizacji i kompletnie niepotrzebny, a nawet absurdalny.
To doprowadza do jescze gorszej sytuacji, gdzie programista pokaże
paluchem że jest napisane, że działać ma właśnie tak i tak właśnie
działa, zleceniodawca powie, że nie tego chciał i nie o to chodziło w
tym punkcie umowy i powstaje kwas na zasadzie czy to zleceniodawca źle
wyspecyfikował i powinien podpisać odbiór, a jak chce, żeby inaczej
działało, to niech negocjuje umowę na enchancement i przygotuje się,
żeby słono zapłacić, czy jednak jest to bug, który wykonawca musi
naprawić na własny koszt i ewentualnie nawet ponieść konsekwencje
(dodatkowego) opóźnienia. Zauważ, że w tym przypadku może chodzić o
kluczowy element programu, od którego masa innych rzeczy jest zależna
i którego przerobienie, żeby było tak, jak ma być, to poważny effort,
np. przepisanie na nowo 1/3 kodu.

do góry

W dniu 2011-05-17 18:53, Andrzej Jarzabek pisze:

>> Poza tym, jest pewien poziom skomplikowania, od którego
>> dokumentacja projektowa jest niezbędna do powstania produktu końcowego.
>
> Nie zgodzę się. Dokumentacja projektowa może być potrzebna jeśli np.
> zespół po zakończeniu projektu ma być rozwiązany lub przeniesiony do
> innego projektu, a maintenance ma robić ktoś inny (co jest sensownym
> scenariuszem, bo zespół agile powołany do tworzenia projektu ab initio
> nie będzie najlepszym zespołem do jego maintainowania po zredukowaniu
> ilości bieżącej pracy.
>
> W drugiej kolejności dokumentacja może być potrzebna firmie jako
> dupochron na wypadek, gdyby jakaś większa liczba członków zespołu
> zechciała sobie pójśc gdzie indziej.
>
> I w końcu jeśli zakładasz, że będzie duża rotacja pracowników w czasie
> trwania projektu, dokumentacja projektowa jest potrzebna, ale jeśli
> będzie duża rotacja, to prawdopodobie nie powinieneś stosować Agile.

Dokumentacja jest potrzebna zawsze przy dużych projektach. Tak samo jak
komentowanie kodu. Oczywiście nikt nie każe dokumentować pierdół. Chodzi
o to, że przy projekcie oprogramowania które powstaje rok i dłużej, po
pewnym czasie nawet osoba siedząca w projekcie od początku może nie
wiedzieć co gdzie i jak się robi. Dochodzenie do tego na podstawie
analizy kodu i ewentualnego komentowania kodu jest bardziej uciążliwe i
długotrwałe w porównaniu do szukania tego w dokumentacji projektu.

> Projekt to projekt, a wymagania to wymagania. Nawet jeśli dostraczenie
> dokumentu projektowego jest w wymaganiach, to raczej się nie wymaga,
> żeby dostarczyć go up front - przed napisaniem programu. No chyba że
> pracodawca/zleceniodawca ma też takie wymaganie, ale wtedy nie
> praktykujesz agile, tylko narzucony z góry proces waterfall lub
> iterative.

Czym innym jest dokumentacja projektowa (dokumentacja kodu) a czym innym
jest projekt (określający założenia projektu, wymagania, sposób
realizacji itd itp).

> Jeśli chodzi o same wymagania, to XP ma takie podejście, że od
> udokumentowanych wymagań lepszy jest customer w zespole. Oczywiście
> musisz tego customera mieć, w dodatku musi być kompetentny i mieć
> realną możliwość podejmowania decyzji i brak tego jest poważną
> obiektywną przeszkodą w stosowaniu XP. Z drugiej strony oczywiście
> należy do tego przyłożyć zdrowy rozsądek - podejście to nie oznacza
> zakazu istnienia dokumentów z wymaganiami, istotne są natomiast dwie
> rzeczy: po pierwsze, że realne wymagania będą się zmieniać w miarę
> pracy z customerem i w związku z tym dokument z wymaganiami nie może
> być wiążącą umową, a po drugie że jak programista będzie miał
> jakiekolwiek problemy, uwagi czy propozycje co do tego, co wyczytał w
> dokumentacji wymagań, to będzie mógł usiąść z customerem i wypytać się
> go, czego on naprawdę chce. Jeśli te warunki nie moga być spełnione,
> to jest to kolejna obiektywna przeszkoda w stosowaniu XP.

Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika. A
umowę na co się podpisuje? A na jakiej podstawie projekt jest uznany za
zakończony? Na podstawie tego że customer powie że tak jest? Nawet jeśli
wszystko ustalicie i wydaje się ze jest ok, to customerowi nagle może
się przyśnić coś innego, albo zobaczy coś u kogoś i będzie to chciał.
Tym sposobem projekt nie będzie zamknięty nigdy.

> Jeśli chodzi o moje osobiste doświadczenie, to mam właśnie takie:
> dokument z wymaganiami się szybko dezaktualizuje, możliwość szybkiego,

<CIACH>

Powiem Ci tak. (bez urazy oczywiście) Po przeczytaniu tego odnoszę
wrażenie, że piszesz oprogramowanie sam lub w gronie programistów a nie
w zespole tworzącym oprogramowanie. Czyli tzw. standard - programista
"wszystkorobiący". Od zbierania wymagań, poprzez opracowanie projektu
(lub nie), kodowanie, testowanie (!) i wdrażanie. Sam tak robiłem swego
czasu.
I to by tłumaczyło nasze różne podejście do kwestii tworzenia
oprogramowania.
Analityk (dobry analityk) jest nieoceniony. Minimalizuje ryzyko
wystąpienia sytuacji o których piszesz już na etapie zbierania i
opracowywania wymagań. I czym jest tutaj okres kilku (nastu) tygodni
poświęconych na stworzenie dokumentacji wymagań, jeśli wynikiem tego
jest konkretna punkt po punkcie lista opcji które program musi posiadać,
z opisem konkretnych działań jakie musi wykonywać. Na podstawie wymagań
mamy już możliwość oszacowania wykonalności i ewentualnego terminu
wykonania. Ale żeby tak było analityk musi być dobry, znać branże dla
której piszemy oprogramowanie. A takich niestety jest niewielu, a ich
wynagrodzenie jest niejednokrotnie wyższe od wynagrodzenia programistów.
Na tej podstawie podpisujemy umowę która sztywno określa zakres zadania
i termin jego ukończenia. Wiadomo z czego i na jakiej podstawie jesteśmy
rozliczani.

pozdrawiam,
Przemek O.

do góry

On Tue, 17 May 2011 08:28:11 -0700 (PDT), Andrzej Jarzabek
<a...@g...com> wrote:

>Natomiast jeśli chodzi o znajdowanie komptentnych programistów przez
>headhuntera, to pytanie brzmi tak: jak reprezentujący was headhuunter
>znajdzie i zadzwoni do kompetentnego programisty, który już ma jakąś
>tam swoja pracę, to czym może go zachęcić, do zainteresowania się
>możliwością pracy dla was? Bo że nie kasą, to już wiemy.

kazdy normalny pracownik, ejzeli tylko troche ma poczucie realnosci,
utzrymuje kontakty ze swoja siecia headhunterow. Albowiem tutaj umowy
o prace maja klauzule: "kazda ze stron moze rozwiazac umowe w cowolnej
chwili bez podania przyczyn". Na dodatek, jak sie pracuje w jednej
firmie dluzej niz 5 lat, to sie staje "unemployable". A na jeszcze
jeden dodatek, nie ma tu regularnych podwyzek pensji, i jak sie chce
dostac odpowiednio wiecej czy awansowac to nalezy zmienic prace.

Wiec ma sie ilus tam headhunterow. Z kolei headhunters cenia sobie
takie kontakty, wiec wydzwaniaja srednio raz w miesiacu mowiac "co w
trawie piszczy" i pytajac sie "czy nie jestem zainteresowany".

I tak sie kreci. Pracownika nei tzreba ZAINTERESOWAC zmiana pracy.
Pracownik jest zainteresowany caly czas. Na ogol mowi swojemu
headhunterowi "dziekuje" ale czesto mowi ze jest zainteresowany. Bo
nikt nie jest zainteresowany JAKAS TAM praca. Natomiast kazdy jes
tzaintelerowany LEPSZA PRACA niz ma.

A jak pracownik nie jest zainteresowany, to predzej czy pozniej
skonczy na flipowaniu burgerow w McDonalds.

Swiezy abslowent uczelni na ogol zaczyna kariere od skontaktowania sie
z jedna z firm headhunterskich. Inaczej nie ma szans.

Headhunter nie podaje pensji, albowiem pensja jest sprawa negocjacji
meidzy kandydatem a pracodawca. Owszem, pyta kandydata ile ten sobie
zyczy, ale nie po to aby przekazac pracodawcy, ale aby powiedziec
kandydatowi czy jego wymagania sa realne czy nie.

A.L.

P.S. Mam 5 headhunterow, i mimo ze dosyc dawno nei zmienialem pracy,
ciagle do mnie dzwonia.

do góry

R. P. wrote:
> Andrzej Jarzabek wrote:
>> On 16/05/2011 19:14, R. P. wrote:
>>> Andrzej Jarzabek wrote:
>>>>
>>>> Możesz rozwinąć? Wszedłem na stronę i widziałem tylko zestawienia
>>>> punktów, z tego co rozumiem, te punkty są za napisanie poprawnie
>>>> działającego programu.
>>>
>>> Tak,
>>
>> No i co to ma wspólnego z byciem Prawdziwym Programistą? Poprawnie
>> działający program to można napisać nawet, za przeproszeniem, w Pascalu.
>
> A czym jest programowanie? Nie chodzi w nim przede wszystkim o napisanie
> poprawnie działającego programu? :)
>
>> tym coraz trudniej. Polacy są świetnymi algorytmikami.
>>
>> Słyszałem o algorytmie Dijkstry, o algorytmie Fulkersona-Forda, o
>> algorytmie Rivesta, Shamira i Adelmana, ale nie kojarzę żadnego
>> znaneego algorytmu wymyślonego przez Polaka.
>
> A zastosowania algorytmów? Przeglądałeś zadania? Uważasz, że umiejętność
> stosowania znanych algorytmów w różnych kontekstach jest trywialna?

HEhe, odpowiedzi nie dostałem. Wnioski pozostawię dla siebie...

do góry

On 17/05/2011 18:49, Przemek O. wrote:
> W dniu 2011-05-17 18:53, Andrzej Jarzabek pisze:
>
> Dokumentacja jest potrzebna zawsze przy dużych projektach.

Z mojego doświadczenia wynika, że bieżąca dokumentacja w dużych
projektach jest bardzo często mocno niekompletna, nieaktualna, a koszt
jej utrzymania przewyższa korzyści jakie przynosi. W skrócie - niepotrzebna.

> Tak samo jak komentowanie kodu. Oczywiście nikt nie każe dokumentować
> pierdół. Chodzi o to, że przy projekcie oprogramowania które powstaje
> rok i dłużej, po pewnym czasie nawet osoba siedząca w projekcie od
> początku może nie wiedzieć co gdzie i jak się robi.

Ktoś siedzi rok w projekcie i go nie zna? Chyba żartujesz.

> Dochodzenie do tego na podstawie
> analizy kodu i ewentualnego komentowania kodu jest bardziej uciążliwe i
> długotrwałe w porównaniu do szukania tego w dokumentacji projektu.

Po pierwsze, po to masz coding standards, żeby nie było.
Po drugie, w praktyce zespół, który pracuje nad kodem od roku ma o nim
lepszą wiedzę, niż jest zawarta w dokumentacji. Jeśli praktykujesz
shared ownership, to masz sporą szansę na to, że dany programista będzie
sam znał odpowiedź. A jeśli nie, to praktykując kolokalizację zespołu,
łatwo jest mu po prostu zapytać i dostać odpowiedź. A jeśli utknie, to
po to masz daily standup, żeby ci, co wiedzą, mogli się zgłosić do pomocy.

> Czym innym jest dokumentacja projektowa (dokumentacja kodu) a czym innym
> jest projekt (określający założenia projektu, wymagania, sposób
> realizacji itd itp).

Ja mówię o tym, co w waterfallu jest tworzone w design phase. Wymagań i
analizy do tego nie wliczam.

> Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika.

A jednak całkiem spore programy się w ten sposób robi.

> A umowę na co się podpisuje? A na jakiej podstawie projekt jest uznany za
> zakończony? Na podstawie tego że customer powie że tak jest? Nawet jeśli
> wszystko ustalicie i wydaje się ze jest ok, to customerowi nagle może
> się przyśnić coś innego, albo zobaczy coś u kogoś i będzie to chciał.
> Tym sposobem projekt nie będzie zamknięty nigdy.

Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
potem regularni i dość często kolejne release'y, np. co miesiąc albo co
dwa miesiące.

I jeśli to jest zewnętrznie zlecony projekt, to - na ile się orientuję -
preferuje się umowy sformułowane tak, że dopóki zleceniodawca płaci, to
dostaje kolejne wersja - z jakimiś tam zabezpieczeniami dla obydwu stron.

Jeśli się nie da, a decyduje się na XP, to się zakłada, że kontrakt
będzie renegocjowany po zawarciu, że zlecenidawca będzie skłonny do
zmiany kontraktu jak zobaczy, że dostaje w pierwszej kolejności to,
czego najbardziej potrzebuje i że będzie miał szybko funkcjonalny
produkt. Wtedy odpowiednie role w zespole osłaniają przed tym programistów.

No i oczywiście niektóre projekty są wewnętrzne, więc nie ma całego tego
krapu.

> Powiem Ci tak. (bez urazy oczywiście) Po przeczytaniu tego odnoszę
> wrażenie, że piszesz oprogramowanie sam lub w gronie programistów a nie
> w zespole tworzącym oprogramowanie. Czyli tzw. standard - programista
> "wszystkorobiący". Od zbierania wymagań, poprzez opracowanie projektu
> (lub nie), kodowanie, testowanie (!) i wdrażanie. Sam tak robiłem swego
> czasu.

Powieem ci tak: mylisz się.

> I to by tłumaczyło nasze różne podejście do kwestii tworzenia
> oprogramowania.
> Analityk (dobry analityk) jest nieoceniony. Minimalizuje ryzyko
> wystąpienia sytuacji o których piszesz już na etapie zbierania i
> opracowywania wymagań. I czym jest tutaj okres kilku (nastu) tygodni
> poświęconych na stworzenie dokumentacji wymagań, jeśli wynikiem tego
> jest konkretna punkt po punkcie lista opcji które program musi posiadać,
> z opisem konkretnych działań jakie musi wykonywać. Na podstawie wymagań
> mamy już możliwość oszacowania wykonalności i ewentualnego terminu
> wykonania. Ale żeby tak było analityk musi być dobry, znać branże dla
> której piszemy oprogramowanie. A takich niestety jest niewielu, a ich
> wynagrodzenie jest niejednokrotnie wyższe od wynagrodzenia programistów.

Nie wiem, może pracujesz w jakiejś specyficznej branży, albo
specyficznej kulturze, w której waterfall się sprawdza, ale consensus
jest jednak taki, że nie sprawdza się prawie nigdy.

Ja też pracowałem z analitykami, wydaje mi się, że dość dobrymi, ale
zawsze było tak, że dokumenty, które wyprodukowali trzeba było mocno
modyfikować w trakcie developmentu. I komunikacja, a nie dokumentacja,
była kluczowa dla skuteczności realizacji _rzeczywistych_ wymagań.

do góry