Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

• Название: Мифический человеко-месяц или как создаются программные системы
• Автор: Фредерик Брукс
• Жанр: Деловая литература

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта.

---

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

Действия при срыве графика

Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда помогает.

Рассмотрим пример.[3] Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения (рис. 2.5).

Рис. 2.5

Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?

1. Допустим, что необходимо соблюсти срок выполнения задачи, и ошибочно оценена была только первая часть задачи, т.е. рисунок 2.6 верно отражает положение. Значит, остается 9 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 4Ѕ человека, и к троим имеющимся нужно добавить еще двоих.

Рис. 2.6

2. Допустим, что необходимо соблюсти срок выполнения задачи, и одинаково занижена была вся оценка , т.е. положение соответствует рисунку 2.7. Значит, остается 18 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 9 человек. К троим имеющимся нужно добавить еще шестерых.

Рис. 2.7

3. Изменить график. Мне нравится замечание, сделанное П. Фаггом (P. Fagg), опытным инженером по вычислительной технике: «Маленьких задержек не бывает». Это означает, что в новом графике должно быть достаточно времени, чтобы работа была исполнена тщательно и полностью, и не пришлось бы вновь переделывать график.

4. Сократить задачу. На практике этим всегда и кончается, когда команда обнаруживает, что не укладывается в график. Когда очень высоки вторичные издержки, это единственное, что можно сделать. Менеджеру предоставляется возможность официально и аккуратно сократить задачу, изменить график, либо наблюдать, как задача молча урезается при поспешном изменении проекта и неполном тестировании.

В первых двух случаях настаивать на том, чтобы задача в неизменном виде была выполнена за четыре месяца, чревато катастрофой. Рассмотрим, к примеру, восстановительный эффект первой альтернативы (рис. 2.8). Двое новых работников, какими бы знающими они ни были, и как бы быстро не удалось их найти, должны изучить задачу с помощью одного из опытных разработчиков. Если для этого потребуется месяц, то 3 человеко-месяца будут потрачены на работу, которая не учитывается в исходной оценке. Кроме того, задача, разбитая первоначально на три потока, должна быть теперь перекроена на пять частей. Поэтому часть уже сделанной работы будет потеряна, а системное тестирование нужно будет продлить. В результате в конце третьего месяца останется работы существенно больше, чем на 7 человеко-месяцев, а в распоряжении будет 5 подготовленных человек и один месяц. Согласно рисунку 2.8 продукт будет запаздывать так же, как если бы ни одного человека не было добавлено (см. рис. 2.6).

Если рассчитывать управиться за четыре месяца с учетом только времени обучения, но не перераспределения задач и дополнительного системного тестирования, то в конце второго месяца потребуется добавить 4, а не 2 человека. Чтобы компенсировать воздействие перераспределения задач и системного тестирования, потребуются еще новые люди. Теперь, однако, команда состоит не из 3, а, по крайней мере, 7 человек, и такие вопросы, как организация команды и распределение задач приобретают новый качественный уровень.

Обратите внимание, что к концу третьего месяца дело выглядит весьма мрачно. Несмотря на все административные усилия контрольная точка, намеченная на 1 марта, не достигнута. Возникает сильный соблазн повторить цикл, добавив еще людей. Это безумное решение.

Рис. 2.8

В предшествующих рассуждениях предполагалось, что только первая контрольная точка была неверно рассчитана. Если 1 марта сделать консервативное предположение, что весь график был излишне оптимистичен, как отражено на рисунке 2.7, требуется добавить 6 человек к исходной задаче. Расчет воздействия обучения, перераспределения задач и системного тестирования предоставляется сделать читателю в качестве упражнения. Нет сомнений, что при попытке уложиться в срок в итоге получится худший продукт, чем при изменении графика и сохранении первоначальных троих человек без усиления.

Крайне упрощая, сформулируем Закон Брукса:

Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

Это развенчивает миф о человеко-месяце. Продолжительность осуществления проекта зависит от ограничений, накладываемых последовательностью работ. Максимальное количество разработчиков зависит от числа независимых подзадач. Эти две величины позволяют получить график работ, в котором будет меньше занятых разработчиков и больше месяцев. (Единственная опасность заключается в возможном устаревании продукта.) Нельзя, однако, составить работающие графики, в которых занято больше людей и требуется меньше времени. Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.

Глава 3 Операционная бригада

Эти исследования выявили большие индивидуальные различия в производительности между лучшими и худшими работниками, часто на порядок величин.

САКМАН, ЭРИКСОН И ГРАНТ[1]

На встречах компьютерных специалистов можно постоянно слышать утверждения молодых менеджеров программных проектов, что им предпочтительней небольшие деятельные команды первоклассных специалистов, чем проекты, в которых участвуют сотни программистов, что подразумевает их средний уровень. И всем нам тоже.

Такое наивное представление альтернатив уходит от решения сложной задачи — как создавать большие системы в разумные сроки? Рассмотрим этот вопрос более подробно со всех сторон.

Проблема

Менеджеры программных проектов давно поняли, что хорошие и плохие программисты очень сильно различаются между собой по производительности. Однако реально измеренные величины поразительны. В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой-либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)

Выше я доказал, что само число разработчиков, действия которых нужно согласовывать, оказывает влияние на стоимость проекта, поскольку значительная часть издержек вызвана необходимостью общения и устранения отрицательных последствий разобщенности (системная отладка). Это также наводит на мысль, что желательно разрабатывать системы возможно меньшим числом людей. Действительно, опыт разработки больших программных систем, как правило, показывает, что подход с позиций грубой силы влечет удорожание, замедленность, неэффективность, а создаваемые в результате системы не являются концептуально целостными. Список, иллюстрирующий это, бесконечен: OS/360, Exec 8, Scop 6600, Multics, TSS, SAGE и другие.

Вывод прост: если над проектом работают 200 человек, включая менеджеров, являющихся наиболее знающими и опытными программистами, увольте 175 бойцов, и пусть менеджеры снова займутся программированием.

Давайте рассмотрим это решение. С одной стороны, ему не удается приблизиться к идеалу небольшой активной команды, в которой, по общему признанию, должно быть не более 10 человек. Поэтому размер бригады предполагает наличие как минимум двух уровней управления, или около пяти менеджеров. Потребуются дополнительны финансовые расходы, сотрудники, место для работы, секретари и операторы машин.

С другой стороны, исходная команда из 200 человек имела численность, недостаточную для создания действительно крупных систем методом грубой силы. Рассмотрим, к примеру, OS/360. Одно время в ее создании было занято больше 1000 человек — программистов, составителей документации, операторов, клерков, секретарей, менеджеров, вспомогательных групп и т.д. С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеко-лет. Если бы строго соблюдалась пропорция между количеством занятых и продолжительностью работ, нашей предполагаемой команде из двухсот человек потребовалось бы 25 лет, чтобы довести продукт до сегодняшнего уровня!