Читать онлайн «Искусство управления IT-проектами». Страница 104

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

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

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

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

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

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

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

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

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

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

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

 Приоритетность. Все должно быть проще простого. Приоритет 1 – ошибка должна быть устранена; приоритет 2 – ошибка по возможности должна быть устранена; приоритет 3 – устранение ошибка желательно, но не обязательно; приоритет 4 – ошибка вряд ли будет устранена.

 Серьезность. Насколько серьезно влияние данной ошибки? Серьезность 1 – потеря данных, крах системы, проблемы безопасности; серьезность 2 – основная функция не работает так, как ожидалось (предписывалось); серьезность 3 – неосновная функция не работает так, как ожидалось (предписывалось). Серьезность отличается от приоритетности. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе слова «PAPAYA!» одними заглавными буквами в поле ввода электронного адреса на странице регистрации, у нее низкий приоритет (серьезность 1, но приоритет 4).

 Данные о том, кто исправит ошибку. Работа над всеми ошибками должна быть поручена конкретным людям. Распределение новых ошибок может быть отложено, но одной из задач классификации ошибок (которую мы вкратце уже рассматривали) является как можно быстрее назначить конкретных ответственных за их устранение. Чтобы показать, что ошибка может проявляться в альфа– и бета-версиях, создайте для нее атрибут под названием «действующая» или «отложенная». Ошибки с таким атрибутом позже должны быть классифицированы и их устранение поручено конкретным людям.

 Воспроизведение. Это последовательность действий, позволяющая кому-то вызвать проявление ошибки. В классификации ошибок это, пожалуй, самая важная графа. Сложные случаи воспроизведения отнимают у команды время, заставляя программистов тратить больше энергии, чем необходимо на простое определение природы ошибки. «Хорошие» ошибки воспроизводятся простыми и короткими действиями.[94]

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

 Данные о том, кто обнаружил ошибку. Имя человека, обнаружившего ошибку, с указанием контактной информации.

 Статус. Ошибка может иметь только четыре состояния: активна, исправлена, решена или закрыта. Активной считается ошибка, которая еще не исправлена и требует внимания. Исправленной ошибка становится, когда программист решает, что она исправлена. Решенной ошибка становится лишь тогда, когда обнаруживший ее человек согласится с тем, что она исправлена, или с тем, что ее исправление можно отложить. Статус закрытой свидетельствует о том, что ошибки больше нет и команда тестировщиков данный факт подтвердила.