BuildingBlog

Хочу рассказать о том, как мне для работы понадобился багтрекер, и как я его реализовал в итоге за полчаса и абсолютно бесплатно. Я занимаюсь разработкой небольшого сайта.
После того, как тех задание было написано, а затем выполнено, началась работа по отладке — устранению багов, тонкой настройке и тп.
Я понял, что нужен багтрекер. Перебрав все возможные варианты я пришел к выводу, что завести себе свой багтрекер я сейчас не смогу по ряду причин:
1. Хорошие багтрекеры (например, Багзиллу) нужно устанавливать на свой сервер. Это затраты по времени + затраты на сервер, каким бы он там ни был.
2. Онлайновые багтрекеры — либо платные, либо неудобные. Я попробовал работать с некоторыми бесплатными — не понравилось.

Тогда я просто завел гугл док и начал в нем писать — баг такой-то, статус — New. Как только программист его исправлял — он заходил и менял статус на Done, и если тесты проходили нормально, то я менял статус на Accepted и переносил запись в нижнюю часть страницы. Таким образом, все новые баги всегда были на виду и работать было довольно удобно.

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

А чем WordPress не багтрекер?

1. Зарегистрировал новый блог.
2. Создал учетные записи для тех кто будет им пользоваться
3. Убрал галочку Appear in search engines such as Google and Technorati (что за технорати? никогда о нем не слышал)
4. Создал категории для постов — Bugs, Critical bugs, Testing, Enhancement, Future, Solved.

Вот и весь багтрекер.
Каждый новый пост присвается одной из вышеперечисленных категорий.
Программист с утра заходит и видит — ага, пополнился раздел Bugs и добавился один Critical bug. Естественно, первым делом он решает критичный баг, и присваивает ему статус Testing. Тестер видит что ему есть что делать и если баг действительно исправлен то переводит его в категорию Solved.
Еще каждому новому посту присваивается тег с именем человека, который должен решать этот баг. Если баг по верстке — то это один тег, если по программированию — то другой.
В итоге программист или дизайнер может зайти на багтрекер, кликнуть по своему тегу и увидеть весь список задач, которые он должен выполнить.

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

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

Мы пользуемся этой системой уже некоторое время. И она работает, причем довольно удобно. Для небольших команд и проектов — заменяет багтрекер запросто.

Удачной вам разработки.