Опубликовано: Алексей Качаев |

Спонсор поста: “Медсервис-М” - круглосуточная стоматологическая клиника в центре Москвы: демократичные цены и профессиональные специалисты.

Говоря простым языком, Issue Tracking — процесс учета/отслеживания/решения проблем, возникающих в программе, обработка запросов на изменение, неточности, улучшения и т. д. Наиболее важная часть этого процесса - Bug Tracking - подразумевает обработку ошибок и неточностей.

Из своего опыта работы с различными заказчиками выношу несколько полезных советов.

Совет #1. Issue Tracking - “работа для двоих” (заказчика и исполнителя).

Если, конечно, проект не на два часа :). И не говорите, что можете реализовать что-то серьезное без багов. Даже если серьезных ошибок не будет, все равно будут мелкие доработки, улучшения и т.д. И именно эти мелочи могут остаться для вас незамеченными, а вот заказчику они сразу бросятся в глаза. Из баг-листа также часто рождаются идеи по улучшению продукта.

Совет #2. Используйте специальные инструменты.

Таких, слава богу, создано очень много. Ознакомиться с полным (?) списком можно здесь - “Comparison of issue tracking systems“, заодно почитать о преимуществах и недостатках каждой.

По мелким проектам я веду список багов и доработок на листах A4 со специальной табличной разметкой. Но для крупных проектов - это слишком экстремальный вариант Переписка по электронной почте с десятками встречных писем с описаниями багов и скриншотами - тоже плохо. В таком режиме информация в голове сбивается в кучу и очень просто о чем-то забыть.

В работе с заказчиком важно, чтобы баг-трекер был интуитивно понятен пользователю (заказчик не должен быть ни программистом, ни тестером, он вообще может слабо в компьютерах разбираться:)) и, что самое главное, доступен в сети. Поэтому локально установленный вам вряд ли поможет. Я остановился на таком варианте: http://www.assembla.com, которая дает возможность бесплатно вести публичный проект\ты. Если у вас в баг-трекере ничего серьезного не планируется держать, то это вполне подойдет.

Совет #3. Расставляйте приоритеты.

Отмечайте высоким приоритетом те баги и\или доработки, которые нужно закрыть срочно (в ближайшее время), и наоборот низким - то, что можно оставить на потом. При этом обязательно прислушивайтесь к заказчику! Вы смотрите на проект с точки зрения разработчика, поэтому некоторые моменты могут показаться вам не существенными (например, точки в отображении даты нужно заменить на слеши), а для заказчика они очень важны. Пусть это не имеет никакого основания - но ни в коем случае не игнорируйте такие вещи! Если заказчик поставил высокий приоритет, и вы с ним не согласны - объясните ему свою точку зрения и выслушайте его. Договоритесь - снижайте приоритет, не договоритесь - лучше закройте баг сразу.

Совет #4. Заносите в список багов даже те проблемы, которые тут же устраняете.

Для заказчика это не важно. А вот для процесса разработки может очень даже сгодиться. Тем более, что иногда проблема кажеться маленькой и не серьезной, а потом из нее начинает вылазить такое…

Совет #5. Разделяйте задачи.

Система Trac предлагает по умолчанию 3 вида тикетов (Type): defect, task, enhancement. На практике этого вполне достаточно для большинства проектов, и именно таким набором я пользуюсь. Уверен, не стоит объяснять какие тикеты для каких задач используются :).

Совет #7. Указывайте ревизии.

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

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!

Также читайте по теме:

• Украина первая в мире по запросу “Zend” (18)
• Мое Live Street творчество (2)
• Комментарии: апгрейдим Wordpress (10)
• Вышел Zend Framework 1.9.0 (0)
• PHP-кейс #1: “Переменные, Классы и Клонирование” (8)