Dnia 07.11.2012 AK <n...@n...com> napisał/a:
[...]
> Np zanika tak cos "drzewiej" podstwowego jak dokladny dobry
> _projekt techniczny_ systemu pisany _zanim_ sie rzucalo na klawiature.
> Dzis czesto jest to tylko analityk (a nawet jego czesto brak) a potem
> zgraja "sprytnych" programistow rzucajacych sie z miejsca na
> klawiature/kod i grzejacych sciany na tych spotkaniach scrumowych

Oczywiście są projekty i "projekty" ale generalnie przy robieniu
systemu o bardzo dużej złożoności model kaskadowy tworzenia
oprogramowania (czyli najpierw pełny i dokładny projekt a potem
implementacja bez jakichkolwiek modyfikacji projektu) po prostu się
nie sprawdził - nie da się teoretycznie przewidzieć wszystkiego,
dlatego stosuje się model iteracyjny, czyli projekt techniczny
ewoluuje razem z implementacją. Tak po prostu działa świat, nie da się
zrobić pełnego projektu dojechania samochodem z Krakowa do Warszawy
typu jedź 10s prosto, potem skręć kierownicę o 7 stopni w prawo
itd. zbyt wiele nieprzewidywalnych rzeczy wydarzy się po drodze.
Model kaskadowy wygląda pięknie na wykładach z inżynierii
oprogramowania (też byłem tego uczony w latach 90-tych) ale po prostu
nie działa (chyba, że podejdzie się do sprawy tak jak Donald Knuth,
czyli brak ograniczenia czasowego na powstanie programu - TeX
powstawał 10 lat :D).

Inna rzecz to niedbałość czy kiepskie zarządzanie. Bywa że manager
robi takie ciśnienie (wszystko jest "na wczoraj"), że ktoś kto przez 2
tygodnie nie napisze linijki kodu wylatuje z pracy (bo poświęcił czas
na projektowanie czy na przykład dokształcenie się z dziedziny, w
której ma chodzić system, a przecież klient płaci za kod a nie za
"pierdoły"). Znam też firmę, w której prezes ma podejście typu
"jedynym działem dochodowym to dział sprzedaży, reszta to tylko
koszty" - prowadzi to oczywiście do tego o czym napisałeś poniżej,
czyli "aby tylko sprzedać, a po nas choćby potop", no ale złe wieści
szybko się rozchodzą i poświęcanie długoterminowej "renomy" na rzecz
chwilowego zysku powoduje, że firma szybko ginie z rynku (utapiając
przy okazji część swoich klientów).

> No i oczywicie dokumentacja to czesto zbedna rzecz itp.

Zależy od klienta, czasem klient płaci za "czarną skrzynkę" i nie
wnika w zawartość, a czasem klient płaci za platformę na której buduje
swoje rzeczy i wtedy dokumentacja jest częścią produktu równie ważną
jak kod.

> Slowem inna odmiana metody "po nas chocby potop".

Odejście od modelu kaskadowego często przynosi poprawę jakości
produktu ale oczywiście podejście "płacimy za kod, resztę
minimalizujemy jak się tylko da, bo to marnowanie czasu programisty"
to droga do nikąd.