Искусство управления IT-проектами

 Была ли реально завершена последняя работа? Этот вопрос касается выполненных работ. Кому-то нужно следить за результатами контрольной проверки работы и удостовериться в том, что она отвечает всем ожиданиям заказчика. Действительно ли последняя из выполненных работ наделила продукт требуемыми функциональностью и поведением? Согласна ли с этим команда тестировщиков? Прошли ли все блочные тесты? Занимается ли кто-нибудь элементарным обнаружением ошибок, чтобы отследить все упущения? Ежедневные сборки (которые будут рассмотрены в следующей главе) представляют собой простой способ отслеживания всех этих вопросов, поскольку всегда можно проверить текущее состояние проекта, обнаружить пробелы в законченном продукте и понять, что необходимо доработать. Чем сложнее работа, тем важнее становятся эти обстоятельства.

У одних программистов чувство ответственности за свой конвейер больше, у других – меньше. Многие будут тщательнее выискивать проблемы одного рода (технические) и стараться игнорировать или откладывать до поры до времени проблемы другого рода (относящиеся к бизнесу и политике). Частью ваших взаимоотношений с каждым программистом должно стать понимание, сколько сил вам нужно приложить, чтобы управлять его конвейером. Кем именно это будет сделано, не так уж и важно. Активно проверять качество работ может кто-то другой. (Это относится к назначению ролей, о чем рассказывалось в главе 9.)

Агрессивный и консервативный варианты производственного конвейера

Иногда конвейеру разработки кода нужно опережать команду программистов всего лишь на три работы (если на каждую работу требуется два дня, то на выполнение трех таких работ понадобится больше недели). Чтобы прийти к согласию по поводу следующей логической последовательности работ, вполне может хватить и свободной дискуссии между руководителем проекта и программистами. (Или, если есть главный критический путь или график Гантта, в котором отражены не только прошлые недели, конвейер можно загрузить с его помощью.) Таким образом, создается вполне достаточный по объему буфер, позволяющий программисту и руководителю проекта своевременно подобрать подходящую работу вместо той, которая застопорилась из-за той или иной не решенной своевременно проблемы, и продолжить выполнение, пока проблема не будет решена.

Команда с агрессивной позицией в выборе приоритетов может в большей степени полагаться на конвейер по разработке кода. Вместо проведения сложной структурной декомпозиции всех работ команда делает ставку на внесение изменений и на способности руководителя проекта или ведущего программиста управлять конвейером. При этом возникает весьма рискованная ситуация: если конвейер даст задний ход или не сможет быть выстроен заранее, с опережением хода работ, это приведет к принятию далеко не самых лучших решений и к ненужной потере времени. Подробную информацию о качественном проведении структурной декомпозиции работ (WBS) при планировании проекта вы найдете в книге Стивена Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999) или в любых традиционных информационных источниках, касающихся руководства проектами.

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

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

Превращение конвейера по созданию кода в конвейер по исправлению ошибок

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

Отслеживание хода процесса