Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 125

Рис. 15.6. Обобщенная, но реалистичная диаграмма угла сближения, в которой предполагается, что работа идет с равномерным напряжением сил

Угол сближения этапа или всего проекта с точкой завершения работы не является какой-то тайной за семью печатями. Как и в любой связанной с планированием задачей (см. главу 2), есть определенные размышления о том, как повысить точность предсказания угла.

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

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

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

Не пейте Kool-Aid. Вычертить диаграмму совсем не трудно. Вы можете начертить линию где угодно, не сообразуясь с реальным положением вещей, и вполне вероятно, что вам даже удастся убедить других в том, что в форме линий, которые вы нарисовали, присутствует некая логика. Поставьте себя на место пилота нашего самолета: смогли бы вы полететь под этим углом, исходя из имеющихся у вас сведений? Подымите красный флаг; признайтесь в ошибках. Защитите свою команду от крушения при посадке. Если ваш подход излишне консервативен, то самое страшное, что может случиться, – это преждевременное завершение этапа, в то же время при слишком агрессивном подходе может произойти масса неприятностей.

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

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

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

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

Ежедневная сборка проекта вынуждает разбираться с множеством различных проблемных вопросов в реальном времени, не откладывая их на будущее. Любой может просмотреть текущую сборку и сразу же определить, насколько продвинулся проект. При этом снижается зависимость от людей, работающих над отчетами о состоянии проекта или другой какой-нибудь канцелярщиной. Взамен всегда можно составить примерное представление, загрузив текущую сборку и проверив конкретную функцию или характеристику. Как бы дорого не обходилась ежедневная сборка (и необходимый для этого инструментарий [93] ), ею все же стоит заниматься.

Ежедневные сборки позволяют программистам (да и всей команде) сразу же находить те компоненты, работа которых отрицательно сказывается на других компонентах, что помогает сохранить высокий качественный уровень сборки. Назначьте конкретное время для ежедневной сборки проекта, настроив людей на подготовку стабильной кодовой основы, позволяющей запускать тесты по проверке качества сборки. (Такие тесты часто называют «проверками на отсутствие дыма» по аналогии с тестами электронных компонентов, при которых монтажные платы подключаются к напряжению, а окружающие внимательно смотрят, не пойдет ли из плат дым.) После назначенного часа все проверки, касающиеся ключевых ветвей кода, просто переносятся на следующую сборку.

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

Подобные тесты на качество, известные также как проверочные тесты сборки (Build-Verification Tests, BVT), должны быть включены в набор критериев завершения этапа. На ранних стадиях этапа эти критерии могут быть более мягкими, чем критерии выхода; например, вполне приемлемым может быть получение всего лишь одной «хорошей» сборки в неделю. Однако по мере приближения команды к завершению работы над какой-нибудь функцией или характеристикой критерии должны становиться все более жесткими. Ежедневные сборки и тесты на качество всегда позволят вам иметь и показатели качества, и инструменты управления его уровнем.