Творчество vs. “промышленная” разработка ПО
Программная инженерия – единственная инженерная дисциплина, в практике которой преобладают эвристические, а не формальные методы. Это подтверждено более чем 35-летней историей software engineering.
В предисловии к первому изданию (1974-75 г.) классического труда “Мифический человеко-месяц” Фред Брукс пишет: “Во многих отношениях управление большим проектом разработки программного обеспечения аналогично любому крупному начинанию – в большей мере, чем обычно считают программисты. Однако во многих отношениях имеются и отличия – в большей мере, чем обычно предполагают профессиональные менеджеры.” Эту точку зрения в отношении восприятия разработки программного обеспечения программистами Брукс отстаивает и, в определенной степени, уточняет во втором издании (1995 г.) “управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов.” Отсюда и столь большое внимание процессам разработки.
Говоря о необходимости индустриализации разработки програмного обеспечения, необходимо понимать, что такая индустриализация должна касаться, в первую очередь, технологий (в части их унификации, включая технологии моделирования, тестирования и т.п.) и методов организации производства программного обеспечения, применения управленческих практик и организационного структурирования коллективов разработки.
Многие менеджеры и, как следствие, разработчики воспринимают это в форме создания жестких условий (например, на основе тотального контроля – “большого брата”), в которых люди не могут не работать, т.е. потогонной - конвейерной системы. На самом деле, суть состоит в том, чтобы создать условия, в которых комфортно, а, значит, и хочется работать. Управление – менеджмент – предполагает высокую роль пресловутого “человеческого фактора”. Том Демарко и Тимоти Листер в не менее классической книге “Человеческий фактор: успешные проекты и команды” сформулировали то, что является одной из ключевых проблем индустрии программного обеспечения: “главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические.”
Взрывное развитие и успешное применение agile-практик, уделяющих огромное внимание вопросам спаянности команды разработки, качеству и прозрачности коммуникаций между отдельными личностями в команде, отражает тот факт, что разработка программного обеспечения продолжает оставаться в большей степени трудоемким (это также отмечает Брукс), чем капиталоемким производством.
В процессе перехода от “ремесленического” взгляда (как это принято называть в нашей индустрии “на коленке”) к “промышленному”, сравнительно “рутинные” операции, например, кодирование, все чаще отделяются от деятельности по разработке. Это говорит, по-моему, о сохранении творческой составляющей нашей профессии, что не может не радовать. В противном случае, все новое в области программного обеспечения было бы тем же, что и раньше, просто с большим количеством “бантиков”. А этого, к счастью, не происходит. Количественные изменения дают и качественный рывок. Говорим ли мы о методологиях, технологиях, инструментах, методах или стандартах.
А “бантики” …. они тоже нужны, ведь действительно приятно работать с интуитивно понятным, красивым и, в тоже время, функциональным инструментом ;-)
А что Вы думаете на этот счет?
В предисловии к первому изданию (1974-75 г.) классического труда “Мифический человеко-месяц” Фред Брукс пишет: “Во многих отношениях управление большим проектом разработки программного обеспечения аналогично любому крупному начинанию – в большей мере, чем обычно считают программисты. Однако во многих отношениях имеются и отличия – в большей мере, чем обычно предполагают профессиональные менеджеры.” Эту точку зрения в отношении восприятия разработки программного обеспечения программистами Брукс отстаивает и, в определенной степени, уточняет во втором издании (1995 г.) “управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов.” Отсюда и столь большое внимание процессам разработки.
Говоря о необходимости индустриализации разработки програмного обеспечения, необходимо понимать, что такая индустриализация должна касаться, в первую очередь, технологий (в части их унификации, включая технологии моделирования, тестирования и т.п.) и методов организации производства программного обеспечения, применения управленческих практик и организационного структурирования коллективов разработки.
Многие менеджеры и, как следствие, разработчики воспринимают это в форме создания жестких условий (например, на основе тотального контроля – “большого брата”), в которых люди не могут не работать, т.е. потогонной - конвейерной системы. На самом деле, суть состоит в том, чтобы создать условия, в которых комфортно, а, значит, и хочется работать. Управление – менеджмент – предполагает высокую роль пресловутого “человеческого фактора”. Том Демарко и Тимоти Листер в не менее классической книге “Человеческий фактор: успешные проекты и команды” сформулировали то, что является одной из ключевых проблем индустрии программного обеспечения: “главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические.”
Взрывное развитие и успешное применение agile-практик, уделяющих огромное внимание вопросам спаянности команды разработки, качеству и прозрачности коммуникаций между отдельными личностями в команде, отражает тот факт, что разработка программного обеспечения продолжает оставаться в большей степени трудоемким (это также отмечает Брукс), чем капиталоемким производством.
В процессе перехода от “ремесленического” взгляда (как это принято называть в нашей индустрии “на коленке”) к “промышленному”, сравнительно “рутинные” операции, например, кодирование, все чаще отделяются от деятельности по разработке. Это говорит, по-моему, о сохранении творческой составляющей нашей профессии, что не может не радовать. В противном случае, все новое в области программного обеспечения было бы тем же, что и раньше, просто с большим количеством “бантиков”. А этого, к счастью, не происходит. Количественные изменения дают и качественный рывок. Говорим ли мы о методологиях, технологиях, инструментах, методах или стандартах.
А “бантики” …. они тоже нужны, ведь действительно приятно работать с интуитивно понятным, красивым и, в тоже время, функциональным инструментом ;-)
А что Вы думаете на этот счет?
Ярлыки: Разное, Innovations
Автор: Сергей Орлик в
10.10.05
Комментарии: 5:
Творческий подход, безусловно, возможен везде. Вопрос - насколько обосновано творчество там, где требуется лишь знание определенных техник и существуют временные и/или другие ограничения, накладываемые на реализацию заданной функциональности.
Дмитрий, а что значит чистые языки программирования? C и C++? Хотелось бы продолжение списка. :) Что, тот кусочек кода, который мы оборачиваем в JSP, SOAP и пр.. не является объектом для творчества.
Я считаю, что творчество должно оставаться творчеством. Ведь поймите, что то, что интересно разработчику, во многих случаях совершенно не нужно пользователю разрабатываемой системы.
Считаю, что наиболее эффективным путем разработки - это разделение команды проекта на два потока. Первый занимается непосредственной разработкой ПО (люди в меру творческие, больше нацелены на бизнес), второй - research (творческие люди, параллельно занимающиеся исследованиями и разработками новых программных решений, способные описать свои труды и предоставить механизм перехода от старых технологий к разработанным новым).
http://www.livejournal.com/users/orangyk/139321.html
> А что Вы думаете на этот счет?
А мы склонны согласиться. Хотя программирование становится задачей все более высокого уровня, потребность в эвристическом подходе не снижается. Тот, кто придумывает, как написать формулу в Excel, также применяет эвристический подход, как и тот, кто разрабатывает компилятор. Получая новые технические средства, мы избавляемся от потребности в эвристическом подходе для решения каких-то задач, но автоматически появляются задачи более высокого уровня, для которых готовое решение еще не написано. И нам снова приходится иметь дело с неизвестным.
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница