Tue 17 Oct 2006
Trac - швейцарский нож среди инструментов управления проектом
Posted by Alex Lebedev under процесс разработки, инструменты
Процесс разработки ПО со временем обрастает множеством вспомогательных инструментов. Не только теми, которые помогают лучше писать, компилировать или тестировать код, но и теми, чье единственное предназначение - упорядочивать рабочий процесс. Вот практически минимальный набор для небольшого проекта: система контроля версий, багтреккинговая система, wiki. Действительно ли это нужно вашему проекту?
Зачем это нужно
Могу вывести несколько эмпирических закономерностей появления потребности в определенных инструментах:
- Система контроля версий нужна даже для соло-проектов. Очень важна возможность не думать о ведении истории и о резервном копировании старых версий. Настолько важна, что глупо от нее отказываться для любого проекта длиннее пары дней, результаты которого могут вам понадобиться больше одного раза.
- Пока разработчик один, обсуждать найденные ошибки можно и по электронной почте. Как только в проекте появляется два разработчика, вам становится нужен багтреккинг: как решение проблемы единого хранилища информации об ошибках. Эти же соображения относятся к планам работ, которые лучше всего вести в той же багтреккинговой системе. Туда же должны попадать все “заявки” от заказчиков - как сообщения об ошибках и неудобствах, так и запросы на добавление нового функционала.
- Когда проекту становится нужна wiki? Как только написанием и редактированием документации начинает заниматься более одного человека. Я считаю, что в идеале написанием и редактированием документации должны хоть немного зниматься все разработчики. В противном случае страдает как качество и полнота документации, так и качество и полнота осмысления проекта его участниками. Первое - ерудна, но от второго проект будет очень сильно страдать. Для аутсорсинга wiki обладает еще одним преимуществом - чтобы документы читали, и программистам и заказчикам нужна возможность сделать это легко и просто. Чтение через браузер вполне подходит. Скачивание отдельных doc-файлов с FTP – не очень. Если документация лежит на FTP, то, как показывает мой опыт, практически никто до этого FTP не добирается.
Таким образом, уже для небольшого проекта, включающего менеджера, двух разработчиков, бизнес-аналитика и тестировщика, весь перечисленный набор инструментов из прихоти превращается в необходимость.
Все в одном
Есть замечательный инструмент, который обеспечит вас “базовым набором” для управления проектом. Я говорю о Trac. Это багтреккинговая система, wiki и тесная интеграция с subversion в одном флаконе. Основная цель Trac в том, чтобы обеспечить проект основным инструментарием управления, как можно меньше путаясь при этом под ногами участников. Заявленная цель достигнута: Trac действительно объединяет в себе практически все необходимые функции инструмента управления проектом и одновременно по минимуму заставляет участников проекта заниматься ненужной работой. В других багтреккинговых системах, которыми я пользовался, рутинные и не очень нужные операции отнимают гораздо больше ценного человеческого времени.
Что мне понравилось в Trac
- Автоматическое закрытие бага при помещении исправления в source control. Если вы пользуетесь Subversion, то разработчику достаточно написать в комментарий “Fixes #89. Now database exceptions are handled properly” при очередном коммите - и баг номер 89 будет отмечен как fixed с соответствующим комментарием. Вот так выглядит такой баг в истории изменений:
- Wiki для всей документации. Огромный шаг вперед по сравнению с набором несвязанных документов, разбросанных по FTP / файловому серверу. Вы получаете:
- Возможность с легкостью создавать ссылки между документами
- Полную историю изменений любого документа
- Беспроблемное совместное редактирование
- Timeline. Функция Timeline позволяет получить единый отчет о всех изменениях в коде, документации и багах. Позволяет постоянно “держать руку на пульсе” прогресса работ. Очень удобно не только для менеджера, но и для разработчиков, у которых по определению мало времени на отслеживание текущей ситуации.
- Интегрированный просмотр изменений. Любое изменение кода можно просмотреть в виде раскрашенного diff прямо в Trac. Эта возможность экономит много времени при ревью исправлений или изменений - не нужно смотреть в одном окне историю изменений, а в другом - искать эти изменения в логе Subversion и генерить diff; вместо этого достаточно просто открыть ссылку в Trac. Вот как это выглядит:
Что не понравилось
- Долгая и сложная инсталляция. Trac требует для своей работы несколько сторонних компонентов, которые надо ставить отдельно. Инсталляция всего этого зоопарка на моем хостинге отняла у меня около 7 часов, заполненных попытками все это правильно поставить. И это при наличии инструкции. Впрочем, установка под root была бы заметно проще. Помимо инсталляции ядра, я потратил несколько часов на то, чтобы настроить автоматическое изменение багов по результатам коммитов в subversion - так ничего и не добился. Буду пробовать еще, но доказательство сложности инсталляции налицо.
Материалы по теме
11 Responses to “ Trac - швейцарский нож среди инструментов управления проектом ”
Comments:
Leave a Reply
Trackbacks & Pingbacks:
-
Pingback from Немного довести напильником… » Outsourcing stories
October 26th, 2006 at 09:55[…] Другой пример. Посмотрим на комментарий, подтолкнувший меня к написанию этого поста: # Алексей says: […]
-
Pingback from Почему Microsoft Project нельзя использовать для управления проектами » Outsourcing stories
January 6th, 2007 at 12:49[…] Моя статья про один из лучший инструментов Issue Tracking на данный момент “Trac - швейцарский нож среди инструментов управления проектом” « Хорошая статья про поджект менеджмент | add to del.icio.us […]

October 18th, 2006 at 02:26
По идее, это фича целиком Subversion. Там можно настроить вызов своих действий на каждый коммит, и в прицнипе, никто не мешает связать это практически с любой багтракинговой системой, которая работает по HTTP.
Но в заслугу Trac’у безусловно идет то, что это настроено
October 24th, 2006 at 02:02
Я вот обнаружил, что для моего проекта Trac не очень подходит, а хотелось бы, т.к. интерфейс действительно удобный.
В Trac понятия “version” и “milestone” привязаны к проекту целиком. В моём же проекте есть тесно зависимые по документации, но сильно отличающиеся по срокам релиза/версиям части. Поэтому, хотя Trac и поддерживает несколько проектов на одном компьютере, и даже исходники никто не мешает хранить в одном репозитории, я не могу пользоваться Trac, т.к. документация и тикеты не могут быть общими на несколько проектов, а версию/дату релиза невозможно сделать разными для частей одного проекта.
February 21st, 2007 at 12:05
Сильно не понравились сложности с русским языком. Любые комментарии и строки, попадающие в SVN на русском языке показываются не по-русски. Установка плагинов - тоже крайне неудобоваримый процесс.
May 7th, 2007 at 07:44
Не правда, поверхностный осмотр настроек навел на кодировку и благополучному решению всех проблем.
May 9th, 2007 at 01:51
Спасибо, мне тоже помогло. Сменил в trac.ini кодировку на utf-8: теперь русские комментарии отображаются корректно. Сейчас потребности в русских комментариях нет, но приятно быть готовым к ее появлению.
July 27th, 2007 at 07:38
Для тех кому не хочется возится с установкой Trac (как мне например) есть уже готовые решения:
http://trac.cz
http://www.assembla.com
February 6th, 2008 at 06:14
А никто не пробовал искать русскоязычный интерфейс для трека? И вообще есть ли там поддержка многоязычности?
February 6th, 2008 at 06:25
Локализации интерфейса, насколько я знаю, нет.
Wiki и описания тикетов поддерживают русский язык. Как насчет показа изменений из Subversion с комментариями на русском — не знаю. Не знаю даже, поддерживает ли это сам Subversion.
February 12th, 2008 at 11:28
Всё работает. И описание коммитов, и svn-postcommit хуки для работы с тикетами (refs, fixes).