Время — деньги. Создание команды разработчиков программного обеспечения - Салливан Эд Страница 23

• состояние проблемы: расследуется, требуется больше информации, ожидается внешнее событие, решена и т.д.;

• приоритет проблемы: низкий, средний, высокий;

• выпуск, в котором присутствует проблема;

• статут процедуры контроля качества;

• количество попыток неуспешного решения проблемы;

• список изменений к отчёту о проблеме или неисправности.

Посмотрим, как мы использовали ПО для устранения проблем и неисправностей в NuMega.

Из собственного опыта

Когда я начинал работать в NuMega, «жучки» и другие различные неисправности фиксировались на доске (если вообще фиксировались). Они оставались там до тех пор, пока не были исправлены, а затем их просто стирали. Когда доска заполнялась полностью, новые записи втискивали в уголок или, чтобы освободить место, стирали другие ошибки. Эта система работала для одного-двух человек, но истории работы над ошибками не было.

С ростом организации становилось очевидно, что нам требуется автоматизированное решение. Если бы мы в то время не перешли к нему, то не смогли бы успешно вырастить свою команду. Хотя поиск инструмента, способного решить наши проблемы, и не был сложен, способ его использования часто становился предметом спора. В конце концов мы выяснили, что для группы нашего размера куда важнее выполнять на «отлично» всего несколько функций, чем пытаться делать всё, что мы можем только представить.

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

Как далеко это заходит? Значит ли это, что если у одного разработчика возникла проблема с API, который реализовал другой разработчик, то её сразу же нужно запротоколировать? Вовсе нет. Разработчики могут решить проблему друг с другом самостоятельно, и тогда её не нужно протоколировать. Однако если решение проблемы займёт некоторое время и требует наблюдения (что особенно важно), то необходимо занести её в систему и описать, чтобы не забыть о её существовании. Эти правила распространяются на всех членов команды и на все отделы.

Другое преимущество от протоколирования неполадок — возможность отчитываться о них. Как здорово пойти на текущее совещание с полным списком всех крупных неполадок и людей, над ними работающих! Это эффективный способ фокусировать внимание в процессе разработки на важных вопросах. Заявивший об ошибке будет польщён тем, что её признали и она обсуждается. А тот, кто назначен для её разрешения, поймёт, что теперь не отвертеться.

Как было сказано в начале этого раздела, процесс управления изменениями может осуществляться при помощи системы устранения проблем и неисправностей. Так как все серьёзные проблемы запротоколированы, вы можете составить список необходимых исправлений. После того, как по конкретной неисправности принято решение, просто внесите информацию об исправлении в историю. Возможность пересматривать прошлые решения и причины их принятия — большой плюс. Это позволит избежать отговорок типа «я не помню» или «кажется, меня не было на том совещании». Все просто, понятно и под контролем.

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

Рассмотрите включение поля «Исправить к дате» для установления приоритетов на основе критерия времени. Значения, помещаемые в это поле, могут браться на основе внутреннего графика выпуска проекта, например, здесь может быть указан определённый этап, бета-версия или кандидат на выпуск. Чтобы определиться с приоритетом, задайте себе вопросы: «эту проблему нужно решить к этапу 2 или бета-версии 1?», «Что, если мы выпустим продукт сейчас, а ошибку исправим в следующем выпуске?»

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

Одна из главных задач, выполняемых при контроле качества, — проверка того, что ошибки на самом деле исправлены. На этом этапе мы убеждаемся в том, что разработчик действительно осознал проблему и провёл достаточное количество испытаний. Когда ошибка исправлена и соответствующие изменения внесены в исходный код, разработчик устанавливает значение поля «Контролю качества: подтвердить» на «Истина», а статус — на «Ожидается процедура контроля качества». После того, как система контроля качества проверила исправление ошибки, тестировщик устанавливает её статус «Закрыто». Проблема может быть закрыта только системой контроля качества после соответствующей проверки.

Когда мы сталкивались с неполадкой, которую следует описать в замечаниях по выпуску или файле Read Me, мы изменяли её статус на «Release Notes», но оставляли её открытой. В примечаниях по выпуску описываются известные проблемы, способы их обойти и информация, появившаяся в последний момент и не попавшая в официальную документацию. Когда наступал момент выпуска бета-версии или окончательной версии, было очень просто составить список проблем, о которых следует указать в замечаниях по выпуску. И только после того, как проблему разрешили, мы окончательно её закрывали.

Чтобы осуществлять полноценный поиск по базе данных проекта, важно иметь набор стандартных запросов. Эти запросы должны использоваться совместно и быть доступны всем членам команды; важно, что у каждого будет одинаковая картина данных. Хотя частные запросы хороши для редких и особых требований, их не следует использовать для распределения заданий членам команды. Риск неправильного составления запроса или указания неиспользуемого более поля достаточно велик. В таблице представлены наиболее важные запросы.

Все открытые ошибки

Позволяет менеджеру проекта и руководству оценить проект в целом

Все открытые ошибки для конкретного этапа

Позволяет команде увидеть, какие ошибки остаются открытыми в проекте для заданного этапа.

Все открытые ошибки для конкретного человека

Позволяет каждому человеку просмотреть свой текущий список ошибок

Все открытые ошибки для конкретного этапа и человека

Позволяет каждому человеку просмотреть свой список ошибок для заданного этапа.

Все открытые ошибки тестировщиков с полем «Контролю качества: проверить» = «Истина»

Позволяет команде просмотреть свой план тестирования