работников для совместного решения вопросов, положение становится ещё хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи и привести к положению, описываемому рисунком 2.4.
Поскольку создание программного продукта является по сути системным проектом — практикой сложных взаимосвязей, затраты на обмен данными велики и быстро начинают преобладать над сокращением сроков, достигаемым в результате разбиения задачи на более мелкие подзадачи. В этом случае привлечение дополнительных работников не сокращает, а удлиняет график работ.
Системное тестирование
Из всех элементов графика работ наибольшему воздействию со стороны ограничений на последовательность выполнения действий подвержены отладка компонентов и системное тестирование. Кроме того, затраты времени зависят от количества выявленных ошибок и от того, насколько они «скрытые». Теоретически, ошибок быть не должно. Из-за своего оптимизма мы обычно склонны недооценивать действительное количество ошибок. Поэтому в программировании придерживаться графиков работ обычно труднее всего при отладке.
В течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.
Это правило имеет несколько важных различий с общепринятым планированием:
1. На планирование отводится больше времени, чем обычно. И все равно этого времени едва достаточно для разработки подробных и надёжных технических условий и недостаточно для проведения исследовательских работ или поиска новейших технологий.
2.Половинаграфика работ, отведённая на отладку законченного кода, значительно выше нормы.
3. Та часть, которую легко оценить, т.е. написание кода, занимает всего одну шестую общего времени.
Изучая проекты, график которых был составлен традиционным образом, я обнаружил, что немногие из них отводили по графику половину времени на отладку, но на практике в большинстве случаев тратили на неё половину фактического времени. Многие проекты укладывались в график на всех этапах, исключая системное тестирование. [3]
Особенно катастрофические последствия может иметь недостаток времени для системного тестирования. Поскольку задержка происходит в конечной части графика, никто не подозревает о том, что график находится под угрозой срыва вплоть до дня сдачи продукта. Плохие вести, полученные поздно и без предупреждения, обескураживают клиентов и менеджеров.
Более того, задержка на этом этапе имеет особенно тяжёлые материальные и психологические последствия. Проект осуществляется при полной укомплектованности работниками и максимальных финансовых издержках. Что важнее, программное обеспечение должно обеспечить поддержку другой деловой активности (поставки компьютеров, запуска новых производственных мощностей и т.п.), и связанные с задержкой вторичные издержки очень высоки. На практике эти вторичные издержки могут быть выше, чем все прочие. Поэтому очень важно в изначальном графике работ отвести достаточно времени для системного тестирования.
Робость в оценках
Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время её фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать ещё или съесть его сырым. Тот же выбор встаёт и перед заказчиком программного обеспечения.
У повара есть ещё одна возможность: добавить жару. В результате омлет часто оказывается безнадёжно испорченным: горелым с одного края и сырым — с другого.
Я не думаю, что у менеджеров программных продуктов меньше храбрости или твёрдости, чем у поваров или других менеджеров в инженерных областях. Но липовые графики, нацеленные на желательную хозяину дату, встречаются здесь значительно чаще, чем в любых других инженерных областях. Очень тяжело, рискуя потерять рабочее место, с энергией и любезностью отстаивать срок, который определён без применения каких-либо количественных методов при недостатке данных и подкреплён, в основном, интуицией менеджера.
Очевидно, необходимо сделать две вещи. Мы должны получить и сделать общедоступными численные данные, характеризующие производительность, частоту программных ошибок, методы оценки и т.д. Вся отрасль может только выиграть от опубликования таких данных.
Пока методы оценивания не получат более прочной основы, менеджерам остаётся только мужаться и защищать свои прогнозы, утверждая, что полагаться на их слабую интуицию все же лучше, чем основываться на одних желаниях.
Действия при срыве графика
Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда помогает.
Рассмотрим пример. [4] Предположим, что трудоёмкость задачи оценивается в 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 человеко-месяца будут потрачены на работу, которая не учитывается в исходной оценке . Кроме того, задача, разбитая первоначально на три потока, должна быть теперь перекроена на пять частей.