Как только появляется необходимость в баг-трекере, в первую очередь обращают внимание на бесплатные open-source системы. Самые известные представители этого класса: Bugzilla, Mantis, Trac и Redmine - они обладают всей необходимой функциональностью, и делают это достаточно хорошо.
Однако пользователи постоянно переходят с бесплатных баг-трекеров, на JIRA, коммерческий продукт, к тому же не из дешевых. В чем причина такой миграции? Эта первая из двух статей, которая отвечает на вопрос "Почему переходят на JIRA?"
Функциональность
Бесплатные баг-трекеры хороши. Они выполняют свои основные задачи, такие как создание, назначение, отслеживание дефектов, создание отчетов. Но они зачастую сильно ограничены в настраиваемости и расширяемости. Некоторые из них позволяют настроить дополнительные поля, другие к тому же имеют возможность изменения жизненного цикла дефекта. Но более сложные задачи, как, например, построение help desk системы,- в лучшем случае потребуют значительной доработки, а в худшем - полной переделки.
История повторяется, когда дело доходит до интеграции с другими инструментами разработки. Хотите подключить Subversion или Git? -Никаких проблем. Но стоит вам захотеть связь с автоматизированной системой продаж или системой управления тестами - будьте готовы к длительной нервотрепке.
Open-source нехватает продуманной архитектуры и инструментов, чтобы реализовать такие сложные пожелания. К примеру, для модификации Mantis необходимо править PHP файлы. А Bugzilla хоть и поддерживает расширения, никто всерьез, похоже, этим не занимался.
При этом настраиваемость и интегрируемость - две самые сильные стороны JIRA. Создание нового типа задачи - Help Desk Ticket, настройка отдельного набора полей и цикла обработки в JIRA делается в несколько движений.
Уже сейчас JIRA может интегрироваться не только с Subversion и Git, но и с другими системами версионного контроля (Perforce, VSS, Mercurial, Bazaar), а также с Salesforce.com, Agile инструментами Rally Software, Системой управления тестами Zephyr и десятками других (см. полный список расширений для JIRA). И уж конечно, JIRA тесно интегрируется с прочими продуктами Atlassian: Confluence (wiki), Crucible (code-review), Bamboo (continuous integration) и прочими.
Благодаря архитектуре JIRA с поддержкой плагинов (кстати, еще одно преимущество над open-source приложениями), возможностям расширения нет границ. Выбор готовых решений не ограничивается такими замечательными коммерческими плагинами как Balsamiq Mockups, GreenHopper (поддержка Agile разработки) или ALM Works JIRA Client. Существует уже более 100 готовых бесплатных расширений, не говоря уже о возможности написания собственных. Вы едва ли найдете подобную библиотеку расширения для какого-либо open-source продукта.
Цена
Конечно, стоимость приложения играет немаловажную роль. Сложно соревноваться в стоимости с бесплатными продуктами, но мы попробуем. Для начала, если сравнить JIRA с коммерческими аналогами, то окажется, что не так и дорого: 4800$ за полную неограниченную лицензию и даже меньше за упрощенную.
Помните, что стоимость лицензии на ПО - не единственная, и часто даже не основная статья расходов. "Хардверные" расходы, такие как стоимость серверов - одинаковы для open-source систем и для JIRA. Есть и "софтверные" расходы, например,- администрирование, затраты на внедрение, повышение эффективности работы. Здесь JIRA побеждает с большим перевесом: административные задачи, которые делаются бесконечно долго в open-source приложениях, выполняются в JIRA быстро и легко.А ведь у JIRA есть еще и более широкие возможности: из инструмента разработки JIRA может превратиться в систему управления IT проектами, проектами по рекрутингу и маркетингу или систему поддержки пользователей.
В следующей статье будут описаны механизмы и инструменты, при помощи которых можно мигрировать в JIRA без потери данных.
Оригинал статьи:
http://blogs.atlassian.com/news/2008/12/switching_from.html
