> I o co chodzi z tymi 2/10 i 8/10? Chcesz
> > powiedziec, ze analiza wymagan powinna zajac 80% czasu projektu? :-)
> >
> Tak. 80% casu powinna zajac analiza planowanie i stworzenie PROJEKTU a nie
> produktu. Stworzenie produktu wg dobrego projektu powinno zajac 20%
> planowanego na wykonanie calosci czasu.

Jest to oczywiscie NTG, ale prezentujesz dosc nietypowe podejscie do tematu.
Mi jest znane inne: analiza, planowanie itp powinno zajac tyle czasu ile
potrzeba :-)
Moim nieskromnym zdaniem zasada podzialu 80/20 (dowolnego innego zreszta tez)
do ustalenia proporcji czynnosci takich projektowanie/analiza/implementacja
et cetera to nieporozumienie, ze sie posluze eufemizmem. Nie da sie ustalic
scislych proporcji pomiedzy analiza a reszta, bowiem dopiero z wykonanej
analizy wynika dokladniejsze oszacowanie czasu na projektowanie,
implementowanie, testowanie itd. W szczegolnosci z owej analizy moze
wyniknac, ze trzeba oprogramowac stacje orbitalna, a moze - ze trzeba zrobic
tylko strone w HTML o stacji orbitalnej. Nie ma tez scislych zaleznosci
pomiedzy czasem trwania implementowania a czasem trwania tprojektowania. Te
czynnosci, zreszta, czesto sa robione w stosunkowo krotkich iteracjach,
czesto przez te same osoby.
Przy tworzeniu produktow nieco wiekszych niz e-sklep w php/mysql, tworzenie w
jednym rzucie projektu na tyle szczegolowego, ze sama implementacja bedzie
trwac krocej niz projektowanie jest na tyle kosztowne i ryzykowne, ze swiat
juz dawno zarzucil podobne pomysly. Inzynierowie doszli to takiego wniosku
juz na poczatku lat 70'. A Fred Brooks napisal w '75 doskonala ksiazke m.i.
na ten temat http://en.wikipedia.org/wiki/Mythical_Man_Month. Znaczy on
zauwazyl ze podejscie "najpierw analiza i szczegolowy projekt calosci, potem
implementacja" skutkuje zazwyczaj wyrzuceniem calosci do kosza.


> > Probujesz narzucic dualizm "spec od zarzadzania"-"spec od programowania",
> tak
> > jakby te rzeczy sie wykluczaly. Tak prosto swiat wyglada tylko na
> folderach
> > reklamowych.
> Nie. Probuje wyjasnic ze PM w projekcie informatycznym wcale nie musi byc
> programista i nigdzie nie napisalem ze nie moze byc programista. Po prostu
> mowie o zagrozeniach: programista bedzie patrzyc na projekt z perspektywy
> "jak to zrobic" a nie "co nalezy osiagnac". Identyfikuje to jako jedno z
> zagrozen Tak samo wiele zagrozen- innego rodzaju moze generowqac PM ktory
> nie jest programista lub informatykiem inneh specjalizacji.

Ale zagrozenie to jest lekko wydumane, opiera sie bowiem na wygodnym dla
danej tezy stereotypie (programista -> bedzie robil to i tamto). FUD jednym
slowem.

>Chce tylko
> powiedziec ze uwazam ze PM w projekcie informatycznym nie musi byc
> programista

A to truizm.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/