Я созрел и прочитал книгу "Мифический человеко-месяц" Федерика Брукса - американского ученого в области теории вычислительных систем, который управлял разработкой OS/360 в IBM. Также Брукс был награжден Премией Тьюринга - самой престижной премией в информатике в 1990 году. Поделюсь впечатлениями от прочитанной книги.
Книгу можно считать классикой
В книге рассматриваются фундаментальные процессы, которые протекают в командах, разрабатывающих программные системы. Почему фундаментальные? Потому что основные главы книги были впервые изданы в 1975 (!) году и они актуальны по сей день. Поэтому "Мифический человеко-месяц" можно с уверенностью отнести к классике, которая как и классика художественной литературы не устаревает. А не устаревает она, потому что каждый из нас, читая "Отцов и детей", находит среди героев романа своих знакомых, близких и себя самого, потому что люди не меняются во времени. Постоянно из поколения в поколение люди сталкиваются с одними и теми же проблемами и приходят к одним и тем же решениям этих проблем. Разработка программных продуктов в большей своей части - это люди и процессы. И уже несколько поколений программистов и менеджеров ломают голову над одними и теми же вопросами, пытаются эффективно разрабатывать программное обеспечение.
Основные моменты
Книга состоит из серии статей, в каждой из которых раскрывается методики управления программным продуктом и приводятся примеры из практики автора.
Закон Брукса
В первой статье объясняется различие между программой, программным комплексом, программным продуктом и системным программным продуктом. Далее Брукс рассказывает, почему нельзя время разработки системного программного продукта исчислять напрямую в человеко-месяцах, разбирается в причинах срыва сроков поставки ПО, а также формулирует закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
То есть, если при разработке программного продукта по каким-то причинам срываются сроки, то менеджерам нужно быть осторожным и не поддаваться инстинкту добавить новых людей в проект.
Концептуальная целостность, важность архитектора
Автор много уделяет внимания важности сохранения концептуальной целостности программной системы на протяжении всего времени ее жизни. Для этого необходимо сконцентрировать ответственность за архитектуру системы в руках одного человека - архитектора.
Также в данной статье Брукс формирует идею поэтапной разработки ПО (incremental development), которая может значительно улучшить производительность. Можно эту идею считать предвестником гибких методологий разработки, которые так популярны сегодня.
Серебряной пули нет
Брукс утверждает (в статье "Серебряной пули нет", написанной в 1986 году) и пытается доказать, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту». Он также утверждает, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке программного обеспечения, как это происходит с разработкой аппаратного обеспечения.Также в данной статье Брукс формирует идею поэтапной разработки ПО (incremental development), которая может значительно улучшить производительность. Можно эту идею считать предвестником гибких методологий разработки, которые так популярны сегодня.
Цитаты
Про архитектора
Под архитектурой я понимаю полную и подробную спецификацию интерфейса пользователя. ... Для системы в целом это набор всех руководств, к которым должен обращаться пользователь при работе.Архитектор системы, как архитектор здания, является представителем пользователя. Его задача - использовать все свои профессиональные и технические знания исключительно в интересах пользователя, а не продавца, изготовителя и т.п.
Планируйте на выброс
... проблема не в том, создавать или нет опытную систему, которую придётся выбросить. Вы все равно это сделаете. Вопрос лишь в том, планировать ли заранее разработку системы на выброс или обещать клиентам поставку системы, которую придётся выбросить. ... Поставка хлама клиенту позволяет выиграть время, но происходит это ценой мучений пользователя, отвлечений разработчиков, поддерживающих систему во время перепроектирования, и дурной репутации продукта, которую даже самой удачной перепроектированной программе будет трудно победить.
Поэтому планируйте выбросить первую версию - вам все равно придется это сделать.
