Закон Брукса - это наблюдение об управлении проектами программного обеспечения, согласно которому «добавление рабочей силы в поздний проект программного обеспечения делает его позже». [1] [2] Он был придуман Фредом Бруксом в его книге 1975 года «Мифический человеко-месяц» . По словам Брукса, при определенных условиях добавление нового человека в проект требует больше, а не меньше времени.
Пояснения
По словам самого Брукса, закон является «возмутительным упрощением» [1], но он отражает общее правило. Брукс указывает на основные факторы, объясняющие, почему это работает:
- Чтобы люди, добавленные в проект, стали продуктивными, требуется некоторое время . Брукс называет это временем « наращивания мощности ». Программные проекты - это сложная инженерная задача, и новые работники проекта должны сначала узнать о работе, которая им предшествовала; это образование требует отвлечения ресурсов, уже работающих над проектом, временного снижения их производительности, пока новые работники еще не вносят значимого вклада. Каждый новый работник также должен интегрироваться с командой, состоящей из нескольких инженеров, которые должны обучать нового работника в своей области знаний основам кода, день за днем. Помимо уменьшения вклада опытных работников (из-за необходимости обучения), новые сотрудники могут даже внести отрицательный вклад, например, если они вносят ошибки, которые отодвигают проект от завершения.
- Накладные расходы на коммуникацию увеличиваются по мере увеличения количества людей. Из-за комбинаторного взрыва количество различных каналов связи быстро увеличивается с увеличением количества людей. [3] Все, кто работает над одной задачей, должны синхронизироваться, чтобы по мере добавления новых людей они тратили больше времени, пытаясь выяснить, что делают все остальные.
- Добавление большего количества людей к очень делимой задаче, такой как уборка комнат в отеле, уменьшает общую продолжительность задачи (до точки, когда дополнительные работники мешают друг другу). Однако другие задачи, в том числе многие специальности в программных проектах, менее делимы; Брукс указывает на эту ограниченную делимость другим примером: в то время как одной женщине требуется девять месяцев, чтобы родить одного ребенка, «девять женщин не могут зачать ребенка за один месяц».
Исключения и возможные решения
В законе Брукса есть несколько ключевых моментов, которые позволяют делать исключения и открывают дверь для возможных решений. [4] [5]
Во-первых, следует отметить, что закон Брукса применяется только к проектам, которые уже просрочены. [6] Проекты можно вернуть под контроль (или оставить под контролем), если люди будут добавлены ранее в процессе. [7] Также важно определить, действительно ли проект задерживается или график изначально был слишком оптимистичным. Ошибки планирования являются причиной большого количества поздних проектов. Корректировка графика - лучший способ определить точные и надежные временные рамки для завершения проекта. [8]
Также необходимо учитывать количество, качество и роль людей, добавленных к проекту. Один простой способ обойти закон о перерасходе проекта - добавить больше людей, чем необходимо, таким образом, чтобы дополнительная мощность компенсировала накладные расходы на обучение и общение. [9] Можно добавить хороших программистов или специалистов с меньшими накладными расходами на обучение. [10] Люди могут быть добавлены для выполнения других задач, связанных с проектом, например, обеспечения качества или документации; учитывая, что задача ясна, время нарастания сводится к минимуму. [11]
Хорошая сегментация помогает минимизировать накладные расходы на общение между членами команды. Более мелкие подзадачи решаются небольшой командой, а команда верхнего уровня отвечает за системную интеграцию. Чтобы этот метод работал, сегментация проблемы должна быть сделана в первую очередь правильно; если все сделано неправильно, это может усугубить проблему, а не улучшить, затрудняя общение между программистами, работающими над частями проблемы, которые на самом деле тесно связаны, даже если в плане проекта указано, что это не так.
Примером сегментации являются шаблоны проектирования, которые упрощают распределение работы, потому что вся команда может выполнять свою часть работы в рамках, предоставляемых этим шаблоном. Шаблон проектирования определяет правила, которым следуют программисты, упрощает общение за счет использования стандартного языка и обеспечивает согласованность и масштабируемость.
План Бермудских островов , где большинство разработчиков на проекте будут удалены ( «отправлено на Бермуды») , а остальные оставлены для завершения программы, был предложен как способ обойти закон Брукс. [12]
Смотрите также
Заметки
- ^ a b Фредерик П. Брукс-младший . Мифический человеко-месяц . 1995 [1975]. Эддисон-Уэсли.
- ↑ Мэгги Фокс, NBC News, 21 октября 2013 г., Лучше пользуйтесь телефоном: почему веб-сайт Obamacare потерпел неудачу . Проверено 21 октября 2013 г. «И отправка слишком большого количества« лучших и самых ярких »тоже может быть неправильным решением, отмечают эксперты по программному обеспечению. Они часто ссылаются на закон Брукса, который гласит, что добавление людей в проект замедляет его ".
- ^ Джеймс Тейлор, «Руководство по выживанию для менеджеров проектов», 2-е издание, AMACOM [ требуется пояснение ] , 2006, ISBN 978-0814408773 , стр. 21.
- ^ «Вопреки закону Брукса, добавление людей в поздний проект остается обычным делом» ... «Я сам много раз проповедовал этот потрепанный каштан программной инженерии, но больше не думаю, что это правда». (МакКоннелл, 1999)
- ^ «Проблема в том, что есть важные исключения, которые многие люди не тратят времени на рассмотрение, используя закон Брукса для оправдания чего-либо». (Беркун, 2006)
- ^ «В этих проектах подразумевается, что это применимо только к заключительным этапам проекта. Вопрос в том, как узнать, находитесь ли вы на заключительных этапах проекта?» (МакКоннелл, 1999)
- ^ «Мы обнаружили, что добавление людей в поздний проект всегда увеличивает его стоимость, но проект не всегда может опаздывать, поскольку может быть достаточно графика, чтобы их поглотить, и проект может не быть укомплектован максимальным персоналом. последовательные ограничения среди задач проекта приведут к задержке проекта ". (Ся, Сюй, Кунг, 1999)
- ^ Поздние хаотичные проекты, вероятно, будут намного позже, чем думает руководитель проекта - до завершения проекта не три недели, а шесть месяцев. Давай, добавь сотрудников. У вас будет время, чтобы они стали продуктивными. Ваш проект все равно будет позже вашего плана, но это не результат закона Брукса. Это в первую очередь результат недооценки проекта »(McConnell, 1999).
- ^ «Гордон и Лэмб изучили закон Брукса и предположили, что лучший способ оправиться от отставания графика - это добавить больше людей, чем можно было ожидать, и добавить их раньше». (Ся, Сюй, Кунг, 1999)
- ^ «Закон предполагает, что все добавленные трудозатраты равны, что неверно. Учитывая выбор в пользу добавления хорошего программиста, который знает кодовую базу и дружит с половиной команды, я бы рассмотрел это». (Беркун, 2006)
- ^ "Печальный, но популярный подход состоит в том, чтобы бросить людей без особых объяснений и позволить каждому понять это для себя. Но если менеджер поясняет, почему Салли и Руперт присоединяются, и определяет для них хорошие роли с участием команды, они будет настроен на плавный переход ". (Беркун, 2006)
- ^ Ши, Том (7 мая 1984). «Разработчики обнародуют„фантомные “ » . InfoWorld . InfoWorld Media Group. 6 (19): 48. ISSN 0199-6649 . Проверено 13 апреля 2010 .
Рекомендации
- Стив МакКоннелл. «Закон Брукса отменен», IEEE Software, vol. 16, нет. 6, pp. 6–8, Nov / Dec, 1999. Также доступно на сайте авторов ( закон Брукса отменен? ).
- Пей Ся, Чжи-дун Сю, Дэвид К. Кунг. «Новый взгляд на закон Брукса: подход системной динамики», compsac, p. 370, Двадцать третья ежегодная международная конференция по компьютерному программному обеспечению и приложениям, 1999 г.
- RL Gordon и JC Lamb. «Внимательный взгляд на закон Брукса», Datamation, июнь 977 г., стр. 81–86.
- Беркун, Скотт (11 января 2006 г.). «Исключения из закона Брукса» . Проверено 28 июля 2008 .
- Закон Брукса применим ко многим совместным действиям людей