Outsourcing stories

Процесс разработки ПО со временем обрастает множеством вспомогательных инструментов. Не только теми, которые помогают лучше писать, компилировать или тестировать код, но и теми, чье единственное предназначение – упорядочивать рабочий процесс. Вот практически минимальный набор для небольшого проекта: система контроля версий, багтреккинговая система, 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 – так ничего и не добился. Буду пробовать еще, но доказательство сложности инсталляции налицо.

Материалы по теме

• Домашняя страница Trac
• Trac на википедии