W dniu 2011-09-02 15:24, Andrzej Jarzabek pisze:

> potrąci ciężarówka są bardzo rzadkie. A i na nie są inne, moim zdaniem
> znacznie bardziej skuteczne sposoby: coding standards, shared (albo
> propagowany w Agile collective) ownership, code review, change
> control, widoczność zmian na poziomie team lead, orientacja testerach
> w funkcjonalności produktu i zmian w tejże i tak dalej.

Aha... I one nie powodują dodatkowego narzutu czasowego?
Nie licytujmy się co ma większy narzut. Ty po prostu przenosisz brak
dokumentacji na inne sposoby ratowania się przed nieoczekiwanymi
zdarzeniami.

> Bo jeśli zamiast analityka i developera masz analityka, projektanta i
> programistę, to zamiast jednego dokumentu, który analityk przygotowuje
> a developer czyta, masz dwa dokumenty, jeden pisany przez analityka a
> czytany przez projektanta i drugi, pisany przez projektanta i czytany
> przez programistę. Jeśli rozbijesz to dalej na domain experta,
> analityka software'owego, projektanta i programistę, to dokumentów
> masz trzy razy tyle co w wariancie pierwotnym.

No i? Zakładając tylko analityka i developera, zakładasz dodatkowe
zasoby wiedzy u obydwu stron. Inaczej nie było by możliwości
zrozumienia. Dla mnie tworzysz mniejszą efektywność pracy najwidoczniej
nie rozumiejąc lub nie widząc sposobu pracy takiego zespołu (czemu dałeś
wyraz poniżej).

> Jedno i drugie jest do bani, jakby sam projektował, to by nie musiał
> ani pisać dokumentu, ani czytać ani o tym rozmawiać.

Tak, oczywiście :/ Jeśli to nie jest notatnik, to powodzenia...

> Ale tak poza tym to oczywiście rozmowa jest szybsza niż pisanie
> dokumentów.

Bierz jeszcze pod uwagę że pamięć ludzka jest zawodna.

> naniesione na projekt? Programista, który nie rozumie co jest po co i
> dlaczego zrobi zmiany zgodne z dokumentem dokumentującym zmiany
> projektu, ale niekoniecznie zgodne z nowym projektem całości...

Po pierwsze jak nie zrozumie i co gorsze nawet nie będzie wiedział że
nie zrozumiał, to znaczy że projektant dał ciała.
Po drugie, czy zakładasz że rozgraniczenie funkcji w zespole, oraz
istnienie dokumentacji jest równoznaczne z wsadzeniem ludzi w klatki bez
możliwości komunikacji bezpośredniej???

> No więc jeśli on rzeczywiście jednoznacznie i dla każdego przypadku
> opisuje to, co piszesz, to to jest to samo co pseudokod, tylko że
> prozą. Na przykład zamiast
> if inpout[0] = 'x' then output[3] = 'y'
> można napisać
> Jeśli pierwszym znakiem komunikatu wejściowego będzie literka 'x', to
> na czwartym znaku komunikatu wyjściowego powinna pojawić się literka
> 'y'.

Trywializujesz. Chyba że typowe IO jest dla Ciebie sednem algorytmu...

> Nie może, bo programista potrafi tylko impelmentować zmiany
> wyspecyfikowane w dokumentacji dostarczonej przez projektanta, a
> projektant nie dostarcza dokumentów, bo zajmuje się dochodzeniem gdzie
> trzeba zmienić true na false żeby program robił to, co ma robić.

Nie rozumiesz, lub starasz się nie zrozumieć jak działa zespół.
Poprawki/zmiany są wprowadzane zazwyczaj, gdy projekt główny jest gotowy
zatwierdzony i przekazany do realizacji. Tak więc programista, nawet
jeśli później zdarzy się problem i trzeba coś zmieniać, ma jeszcze
duuuużo innej pracy którą najczęściej może wykonywać równolegle.

> wydalają z wypełnianim wszystkich zadań. Jak jesteś w innej fazie
> projektu, gdzie powstaje bardzo dużo nowego kodu, a wymagania się nie
> zmieniają, to z kolei potrzebujesz tych wszystkich programistów, więc
> nie wyjdziesz na tym najlepiej, jeśli w poprzedniej fazie ich

Zmiany w projekcie powodowane zmianą wymagań są bardzo rzadkie... albo
analityk nie wykonał swojego zadania poprawnie.

> zwolnisz. No chyba że bierzecie programistów z jakiejś agencji pracy
> tymczasowej, co by mnie nawet nie zdziwiło, sądząc po tym, co piszesz.

Raczej dokładnie odwrotnie, czas pracy programisty jest na tyle cenny,
że nie widzę żadnych obiektywnych powodów, żeby tracił go na inne czynności.

> A to przepraszam, ja raczej pracuję przy produktach, których nie da
> się po prostu douczyć. Najszybszym sposobem douczania się jest i tak
> praca przy wdrażaniu, ale nawet ludzie, którzy robią to od wielu lat
> nie wiedzą wszystkiego.

Konsultant / wdrożeniowiec musi mieć określoną wiedzę. Odnosiłem się do
stwierdzenia, że nie nauczy się bo nie chce sobie utrudniać życia, a
przy okazji może wykorzystać zespół (w tym programistów). Nikt nie
twierdzi (w tym i ja), że musi wiedzieć wszystko, bo wiedzieć
wszystkiego się nie da, choćby właśnie ze względu na specyfikę
oprogramowania.

> No ale skoro poprzedni konsultant z kilkuletnim doświadczeniem miał
> szkolenia a jednak nie wiedział wszystkiego, to na jakiej podstawie
> uważasz, że osoba z call center będzie widziała?

J.W. Chodziło o Twoje stwierdzenie, że osoba _nie_ _musi_ się niczego
uczyć, bo może się pytać np. programistów.

> Najwyraźniej jednak nie z tej przyczyny, bo poza waszą firmą i jej
> oprogramowaniem jest jednak sporo zewnętrznych konsultantów od
> oprogramowania kupowanego w ten sposób. Znaczy oprogramowanie robione
> jest jednak w taki sposób, że po dostarczeniu klient może sobie
> samodzielnie dostosowaać, dokonfigurować, oskryptować, pospinać z
> innymi systemami i tak dalej.

Najwyraźniej wiesz lepiej i więcej o oprogramowaniu które produkuje i
sprzedaje. No nic...

> Niemniej jednak raczej normą było, że jak klient opłacił licencję, to
> miał dostęp do instalek, które mógł sobie zainstalować, miał możliwość
> zmiany konfiguracji i dostawał end user documentation wyjaśniającą jak
> instalowac i jak konfigurować produkty, dodatkowo też konrakt
> supportowy, który uprawniał go do uzyskiwania dodatkowych odpowiedzi i
> objaśnień w tej kwestii.

No widzisz, u mnie powoli odchodzi się od tego modelu na rzecz SAS
(choćby właśnie ze względu na stopień skomplikowania procesu
instalacji), więc to powyżej za chwilę nie będzie miało sensu.


pozdrawiam,
Przemek O.