>
> > recepta na kleske. Istotny jest tutaj efekt skali. Sredniego rozmiaru soft
> to
> > kilka tysiecy klas - kilkaset tysiecy linii kodu. Circa
> > kilkanascie-kilkadziesiat osobolat na sama implementacje. To pare lat w
> > kilkunasto-kilkudziesiecio osobowym zespole. Chcesz powiedziec, ze nalezy
> > najpierw 8 lat projektowac, a pozniej 2 lata implementowac?
> >
> Oczywiście masz racje co do efektu skali i wiadomym jest ze nie robi sie
> tego w calosciowych blokach tylko mniejszymi iteracjami np tak jak to
> opisuje model spiralny czy nowsze podejścia. Upieram sie tylko przy tym ze
> programowanie w sensie kodowania i testowania powinno byc tylko funkcja
> wykonawcza w stosunku do tego co opracuje analityk i projektant. Twierdze
> tez ze bolaczka i przyczyna porazki wielu projektow jest skupienie tych
> trzech funkcji w jednej osobie. Zapewne dzieje sie tak z przyczyn
> ekonomicznych, ale wlasnie praca analityka i projektanta stanowic powinna
> 80% ilosci (czasu) i ciezaru gatunkowego a praca programisty- kodera 20%.

Ale dlaczego "powinna"?

IMO mieszasz troche. Tu jest kilka rzeczy; to, ze role projektanta i analityka
powinny byc przypisane do roznych osob wynika z jednego (analityk potrzebuje
zupelnie innych umiejetnosci i wiedzy niz reszta - biznesowych, a nie
technicznych), to ze programista nie powinien testowac wynika z czegos innego
(testowanie to zadanie osobnego zespolu QA). Natomiast programista-projektant
to sensowne rozwiazanie w wielu przypadkach. Wydaje mi sie ze nie do konca
wiesz na czym polega praca projektanta w normalnym projekcie i dlatego starasz
sie przeciwstawic role projektanta i programisty. Zadaniem projektanta jest (pi
razy oko) zidentyfikowac i zaproponowac rozwiazania dla najwazniejszych
technologicznie problemow, a takze stworzyc i zaproponowac tzw architekture
przyszlego systemu. Jest to w pewnym sensie "programowanie" ale na nieco
wyzszym poziomie abstrakcji i, z reguly, w mniej formalnym jezyku. Nie ma
scislej granicy miedzy programowaniem a projektowaniem - ta granica jest
ustalana dla roznych technologii empirycznie i oznacza zazwyczaj subiektywny
podzial problemow na ogolne i szczegolne, te wazne i te mniej. Podzial
na "projektowanie" i "programowanie" jest w pewnym sensie podobny do podzialu
na "strategie" i "taktyke". Jest w ogolnym przypadku prawda, ze jesli sie nie
przyznaczy odpowiednia ilosc czasu na "strategie" to moze powstac koszmarny
system, ale konkretne proporcje powinny wynikac z logiki sytuacji, a nie byc
odgornie ustalone. Empiria zas pokazuje ze 80/20 do rzeczywistosci sie nie ma
nijak. "80/20" raczej wyglada na haslo wyjete z prezentacji marketoidow - trąci
bowiem przywiazaniem do zaokraglonych liczb i uproszczonej wizji swiata.
Dlaczego nie 81/19? Albo 82/18, czy 71,333/28,667?


> Mialem okazje pracowac w firmie gdzie ten podzial byl bardzo wyraźny i moim
> zdaniem przekladalo sie to na naprawde dobre efekty.

80%/20% ?? Caly czas piszesz tak jakbys gdzies widzial duzy dzialajacy soft
stworzony za sensowne pieniadze w taki sposob, ze implementacja zajela 20%.
Przyznam, ze dla mnie to sa bajki o zelaznym wilku. Mozesz mi przyblizyc nieco
szczegoly tego projektu? Moze byc na priva.


A.

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl