Чтение онлайн

В течение нескольких лет я успешно применял следующее практическое правило планирования работ по созданию программного обеспечения:

* проектирование - 1/3,

* написание команд -1/6,

* отладка компонент и отдельных подсистем - 1/4,

* системная (комплексная) отладка всех компонент - 1/4.

Это разбиение отличается от общепринятого по нескольким важным показателям:

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

2) половина времени отводится на отладку написанной программы, что гораздо более обычного;

3) часть, которую легко оценить, т. е. собственно написание команд, занимает только одну шестую графика.

Знакомясь с проектами, планируемыми по общепринятой методике, я обнаружил, что по графику только в некоторых из них половина времени отводилась на отладку, но в действительности так получалось в большинстве проектов. Многие проекты до этапа комплексной отладки еще как-то укладывались в график2).

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

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

Объективность оценки

Отметим, что настойчивость руководителя может определить график выполнения задания, но не в состоянии определить срок его действительного завершения. Омлет, обещанный через две минуты, может быть подан в срок, но если за две минуты он еще не готов, у заказчика два выбора - подождать или съесть его сырым. Заказчики программного обеспечения находятся перед таким же выбором.

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

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

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

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

Нарастающие катастрофы с графиком

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

Давайте рассмотрим пример3). Допустим, что трудоемкость задачи оценена в 12 человеко-месяцев и троим сотрудникам отвели на нее 4 месяца, причем установили количественные вехи А, В, С и D, которых в соответствии с графиком нужно достичь в конце каждого месяца (рис. 2.5).

Допустим теперь, что первая отмотка достигнута только через два месяца (рис. 2.6). Перед какими альтернативами оказался руководитель?

1. Допустим, что задачу нужно сделать вовремя. Допустим также, что неверно оценено только время выполнения первой части (см. рис. 2.6). Тогда остается 9 человеко-месяцев усилий и два месяца времени, т. е. задача требует 4,5 человека. Добавим двоих людей к трем первоначальным.

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

3. Составление нового графика. Мне нравится девиз П. Фагга, опытного инженера, специалиста по вычислительной технике: "Не исправляйте понемногу". Другими словами, делайте новый график достаточно свободным, чтобы работу можно было сделать тщательно и основательно без последующего перепланирования.

4. Ослабление задания. На практике это происходит довольно часто, когда рабочий коллектив вдруг обнаруживает отставание от графика. Если вторичная стоимость задержки очень высока, это является единственно приемлемым. У руководителя есть голько две возможности: или тщательно и формально сократить задание, составив новый график, или же просто наблюдать, как поспешное проектирование и незавершенная отладка мало-помалу сокращают объем задачи.

В двух первых случаях настаивать на том, чтобы задача бело всяких изменений была закончена за четыре месяца, по меньшей мере ошибочно. Рассмотрим, например, какие помехи возникают в первом случае (рис. 2.8).

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

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