понедельник, октября 10, 2005

Творчество vs. “промышленная” разработка ПО

Программная инженерия – единственная инженерная дисциплина, в практике которой преобладают эвристические, а не формальные методы. Это подтверждено более чем 35-летней историей software engineering.

В предисловии к первому изданию (1974-75 г.) классического труда “Мифический человеко-месяц” Фред Брукс пишет: “Во многих отношениях управление большим проектом разработки программного обеспечения аналогично любому крупному начинанию – в большей мере, чем обычно считают программисты. Однако во многих отношениях имеются и отличия – в большей мере, чем обычно предполагают профессиональные менеджеры.” Эту точку зрения в отношении восприятия разработки программного обеспечения программистами Брукс отстаивает и, в определенной степени, уточняет во втором издании (1995 г.) “управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов.” Отсюда и столь большое внимание процессам разработки.

Говоря о необходимости индустриализации разработки програмного обеспечения, необходимо понимать, что такая индустриализация должна касаться, в первую очередь, технологий (в части их унификации, включая технологии моделирования, тестирования и т.п.) и методов организации производства программного обеспечения, применения управленческих практик и организационного структурирования коллективов разработки.

Многие менеджеры и, как следствие, разработчики воспринимают это в форме создания жестких условий (например, на основе тотального контроля – “большого брата”), в которых люди не могут не работать, т.е. потогонной - конвейерной системы. На самом деле, суть состоит в том, чтобы создать условия, в которых комфортно, а, значит, и хочется работать. Управление – менеджмент – предполагает высокую роль пресловутого “человеческого фактора”. Том Демарко и Тимоти Листер в не менее классической книге “Человеческий фактор: успешные проекты и команды” сформулировали то, что является одной из ключевых проблем индустрии программного обеспечения: “главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические.”

Взрывное развитие и успешное применение agile-практик, уделяющих огромное внимание вопросам спаянности команды разработки, качеству и прозрачности коммуникаций между отдельными личностями в команде, отражает тот факт, что разработка программного обеспечения продолжает оставаться в большей степени трудоемким (это также отмечает Брукс), чем капиталоемким производством.

В процессе перехода от “ремесленического” взгляда (как это принято называть в нашей индустрии “на коленке”) к “промышленному”, сравнительно “рутинные” операции, например, кодирование, все чаще отделяются от деятельности по разработке. Это говорит, по-моему, о сохранении творческой составляющей нашей профессии, что не может не радовать. В противном случае, все новое в области программного обеспечения было бы тем же, что и раньше, просто с большим количеством “бантиков”. А этого, к счастью, не происходит. Количественные изменения дают и качественный рывок. Говорим ли мы о методологиях, технологиях, инструментах, методах или стандартах.

А “бантики” …. они тоже нужны, ведь действительно приятно работать с интуитивно понятным, красивым и, в тоже время, функциональным инструментом ;-)

А что Вы думаете на этот счет?

Ярлыки: ,

Комментарии: 7:

Blogger DmitryKuz сказал(а)...

Замечаю, что творческой составляющей в кодировании становится тоже не много. И не только потому, что все досконально освоили труды Кнута, а потому что разработчики просто не успевают порой разобраться в требованиях, новых протоколах, изменении в библиотеках, стандартах, средствах разработки и т.п. И в результате в лучшем случае преобладают шаблонные решения, в большинстве случаев основная часть работы - это оборачивание кусочка кода в СОАП, JSP, ASP и т.п. Возможно, что это специфично нашей конкретной области и используемым средствам. Как мне кажется в программных продуктах, где используются чистые языки C, C++ и т.п. творчество есть и будет.

вт окт. 11, 04:25:00 ПП  
Blogger Sergey Orlik сказал(а)...

Творческий подход, безусловно, возможен везде. Вопрос - насколько обосновано творчество там, где требуется лишь знание определенных техник и существуют временные и/или другие ограничения, накладываемые на реализацию заданной функциональности.

вт окт. 11, 05:29:00 ПП  
Blogger DmitryKuz сказал(а)...

Творчество - эмоциональный процесс. При жестких временных/технических ограничениях, мне кажется, основная эмоция: "Уффф наконец-то! Вроде работает. Скорее в Fixed ее" :-)

И если вдруг и при таких ограничениях останется еще время, то я, как менеджер, с удовольствием эти ограничения еще больше усилю.

вт окт. 11, 06:09:00 ПП  
Anonymous Eugene Danilenko сказал(а)...

Дмитрий, а что значит чистые языки программирования? C и C++? Хотелось бы продолжение списка. :) Что, тот кусочек кода, который мы оборачиваем в JSP, SOAP и пр.. не является объектом для творчества.

вт окт. 18, 08:32:00 ДП  
Blogger Roman Oksyukovski сказал(а)...

Я считаю, что творчество должно оставаться творчеством. Ведь поймите, что то, что интересно разработчику, во многих случаях совершенно не нужно пользователю разрабатываемой системы.
Считаю, что наиболее эффективным путем разработки - это разделение команды проекта на два потока. Первый занимается непосредственной разработкой ПО (люди в меру творческие, больше нацелены на бизнес), второй - research (творческие люди, параллельно занимающиеся исследованиями и разработками новых программных решений, способные описать свои труды и предоставить механизм перехода от старых технологий к разработанным новым).

чт окт. 20, 06:59:00 ПП  
Anonymous orangy сказал(а)...

http://www.livejournal.com/users/orangyk/139321.html

пн окт. 31, 11:34:00 ДП  
Blogger Ruslan Popov сказал(а)...

> А что Вы думаете на этот счет?

А мы склонны согласиться. Хотя программирование становится задачей все более высокого уровня, потребность в эвристическом подходе не снижается. Тот, кто придумывает, как написать формулу в Excel, также применяет эвристический подход, как и тот, кто разрабатывает компилятор. Получая новые технические средства, мы избавляемся от потребности в эвристическом подходе для решения каких-то задач, но автоматически появляются задачи более высокого уровня, для которых готовое решение еще не написано. И нам снова приходится иметь дело с неизвестным.

пт нояб. 25, 06:30:00 ПП  

Отправить комментарий

Подпишитесь на каналы Комментарии к сообщению [Atom]

Ссылки на это сообщение:

Создать ссылку

<< Главная страница