|
На теория RUP е конфигурируем и до lightweight process, на практика който опре до него свършва с купища документация и без промяна в качеството на самия дизайн.
Joel има една на тема бизнес процеси и софтуер. Проблемът е, че тежките процеси дават детайлни рецепти, и съответно са полезни за компании, чиито competitive edge не е свързан с никаква изобретателност и иновативност при изпълнението на този процес. Конкурентното предимство най-често е във философията, заложена в създаването на процеса, и ефективността му, следствие на многократно приложение и проверка (напр. McDonalds, произволна банка). Самото правене на софтуер е дейност, чиято основа е "creativity" на много нива (код, дизайн, архитектура от високо ниво, UI layout, product features), и съответно не може да бъде уловено добре в книга с рецепти.
Програмирането не е твърде уникална дейност в това отношение. Да сте чували например за адвокатска кантора, сертифицирана по ISO?  Все пак там има best practices и те са полезни; да кажем никой да не взема еднолични решения по правни въпроси без да го дискутира с друг от фирмата, някой винаги да проверява съдебната практика свързана с казуса, и т.н.
Тежките процеси могат обаче да осигурят, че ако някакъв софтуер бъде направен (в срок или не), той ще отговаря на изискванията, клиента поне няма да може да ви съди, да откаже да плати, и т.н. Това е за сметка на голяма неефективност, и тази неефективност може да е OK само в голяма фирма, където се компенсира с economies of scale, маркетинг, и т.н. Вероятно табела като "RUP" или "ISO" помага в маркетинга, но по-често недостатъчно за да компенсира неефективността, породена от реализирането на процеса, особено ако екипа и сам знае какво прави.
Според мен, от програмистка гледна точка, процеси от този тип говорят предимно негативно за фирмата като място на работа, защото:
1) вкарват бюрокрация, и
2) говорят, че ще попаднете в екип с хора, които са по-добри в следването на предписания, отколкото в интелигентно ориентиране в обстановката.
Да започнеш работа във фирма с реализиран тежък процес има смисъл, когато човек иска да се научи как да ръководи група от недобри програмисти и все пак да свършва някаква работа (което може да му се наложи най-вече в контекста на голяма компания).
Извинявам се за дългия постинг, просто съм мислил доста по темата.
|
Re: Малко за "Rational unified process":) [re: focusnik]
