On 24/07/2012 21:48, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>> No to albo ja mam skrajnie nietypowe doświadczenia, albo nie jest to
>> prawdą.
>
> Po prostu malo jest takich zespolow, bo.. brakuje dobrych ludzi/sa drodzy.
> Programowanie (i rynek) juz dawno zwyczajnie spsialo (pod kazdym wzgledem).
> PS: Mowie glownie o Polsce. Na "zagranicy" srednio "sie znam".

W Polsce też różnie zdaje się bywa, ale jakiegoś szczególnie wielkiego
doświadczenia nie mam. W ogóle oczywiście to często zależy od rodzaju i
wielkości instytucji: tam, gdzie oprogramowanie tworzy, jak to pisze
Roman, "dział IT", a biznesem firmy jest co innego, to być może jest
tak, że kierownictwo się za bardzo nie wtranżala programistom w to, jak
mają pracować. Ja z kolei mam raczej doświadczenie z firmami, w których
"dział IT" jest od zakładania (między innymi) programistom kont na
domenie i tym podobnych, a biznees firmy polega na produkcji
oprogramowania, często jednocześnie wielu różnych programów tworzonych
przez różne zespoły. Zwłaszcza w większych firmach taka konfiguracja
jest podatna na różne dziwne pomysły kierownictwa średniego szczebla na
np. "ujednolicone procesy", których celem jest przypuszczam na ogół
ułatwienie wygenerowania ładnych raportów i wykresów, które stwarzają
pozór przekazywania jakichś istotnych informacji na temat całokształtu
działań firmy.

Małe zespoły w małych firmach, zwłaszcza złożone z bardziej
doświadczonych ludzi, mogą częściej organizować się same, ale w takich
przypadkach łatwiej o pułapkę "cowboy coding". I chociaż akurat
teoretycznie doświadczenie i wiedza mogą temu zapobiegać, to jednak ten
syndrom został wykryty na bardzo doświadczonych koderach. Można mieć
ogromną wiedzę, doświadczenie i praktyczną umiejętność wytwarzania
działających programów, ale nadal być "cowboy coder", wystarczy, że się
albo nie zna, albo z założenia nie uznaje jako "nowomodne fanaberie"
różnych co nowszych (lub po prostu relatywnie niedawno
spopularyzowanych) osiągnięć inżynierii oprogramowania (i tak, OOP/OOD
też się do tego zalicza), na zasadzie "my ze szwagrem po pijaku nie
takie rzeczy na GOTO stawialiśmy".

Osobną sprawą jest kwestia zewnętrznych warunków powstawania takiego
oprogramowania, czyli raportowania, estymowania i inputu. Pewnym ideałem
jest, kiedy wymagania są od początku znane i rozumiane i można po prostu
wziąć dobry zespół i kazać im to zrobić, wiedząc że skoro są dobrzy i
sumienni, to i tak zrobią to szybciej i lepiej niż przypadkowy inny
zespół. Rzeczywistość niestety jest bardziej skomplikowana: są klienci,
którzy nie zawsze i nie do końca wiedzą, czego chcą, ale jedno co
wiedzą, to że potrzebują tego na wczoraj, dziedzina jest skomplikowana,
klient robi wiele rzeczy po swojemu, a w ogóle to chciałby robić jeszcze
inaczej (chociaż do końca nie wie jak), tylko nie ma odpowiedniego
oprogramowania, i po to właśnie przyszedł do ciebie; co gorsza jeszcze
takich klientów może być kilku, ich żądania będą miały różne priorytety,
dział sprzedaży będzie chciał wiedzieć, na kiedy co będzie zrobione,
kierownictwo będzie chciało wiedzieć jaki jest stan prac, a developerzy
będą chcieli wiedzieć, co właściwie mają robić i jak właściwie ma to
działać.

W zależności jak to wszystko jest zorganizowane, możesz mieć z łatwością
sytuację, kiedy zespół złożony z dobrych ludzi jest dysfunkcjonalny. Na
ten przykład (true story) developer, kiedy widzi, że feature request
jest co prawda niezbyt skomplikowany, ale za to prawdopodobnie
bezsensowny, i domyśla się, że temu, kto go napisał wydawało się, że
dzięki takiemu ficzerowi cośtam osiągnie, czego w rzeczywistości raczej
nie osiągnie, zamiast chrzanić się, biegać od Annasza do Kajfasza,
tłumaczyć, dopytywać i ściągać na siebie gniew, machnie na to ręką i
powie "zrobię to tak, jak napisali, chociaż to bez sensu, jak się okaże,
że nie da się tego używać, to będzie to problem kogoś innego".