Игры с планами

больше каналов общения, больше объем координации, больше то% чек возможного срыва. Эта тема обсуждается в классическом труде Брукса «Мифический человеко%месяц». (Brooks 95)

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

Не слишком длинные

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

В такой ситуации выгодно применять итеративную и инкремент% ную разработку (см. раздел «Итеративная и инкрементная разра% ботка» на стр. 545), разбивая крупные графики разработки на более мелкие и менее рискованные итерации, которыми проще управ% лять. Это делает план более динамичным; фактически он воссозда% ется заново в каждый момент поставки. Такой подход является бо% лее безопасным и позволяет выявлять проблемы на ранних стадиях разработки, но он требует большего суммарного объема работы. Многим менеджерам это не нравится – им нравится иллюзия, соз% даваемая схемой «водопада», не допускающей отклонений.

Вхороших планах не просто пригнаны вплотную отдельные оценки.

Вних учитываются реалии программного производства и предусмат% риваются средства снижения рисков. Для этого берутся во внимание следующие факторы:

Отпуска

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

Загрузка

Чтобы быть реалистичным, план должен учитывать обычные отвле% чения (совещания, учебу, болезни и т. д.). Как правило, для каждого разработчика это учитывается в плане в виде загруженности на 80%. Для тех, кто пользуется большим спросом, загруженность оказыва% ется меньше. Нужно честно это учитывать, иначе «популярные»

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

Считайте эту работу частью предыдущего задания (хотя она выполня% ется после того, как прошел день выпуска продукта), а не как начало следующего. Отдайте свой долг тому проекту, который его создал.

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

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

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

Существует много моделей планирования – формальных способов де% лать основанные на фактах догадки. PERT (Program Evaluation and Review Technique – система планирования и руководства разработ# ками) – это классический метод планирования, разработанный в 1950%х годах в ВМФ США. Он напоминает мой расчет времени прибытия при поездке в Бристоль. Для каждой задачи делается три оценки в зависи% мости от вероятности поставки в срок: лучший сценарий, худший и наиболее вероятный. Это связывается с процедурой планирования, в которой определяется критический путь и вычисляется время завер% шения проекта в лучшем и худшем случаях. Чем больше разрыв меж% ду двумя оценками для задачи, тем больший риск с ней ассоциирует% ся. В таком случае она может потребовать более тщательного руково% дства или выделения для своего решения более опытного сотрудника.

Конструктивная модель затрат Боэма (COCOMO – Constructive Cost Model) появилась в 1981 году и представляет собой модель оценки, ос% нованную на анализе реальных программных проектов. На ее базе по% явилась модель COCOMO II, более точно отражающая природу совре% менных программных проектов. (Boehm 81) Проекты в контролируе# мых средах (Projects in Controlled Environments, PRINCE) – это пример классической британской бюрократии, воплощенной в виде управле% ния проектом; если бы можно было потребовать стояния в очередях, это обязательно было бы сделано!1 Эта модель охватывает весь жизненный