Комментарии 26
багтрекер - вещь хорошая.
бедные разработчики.. сочувствую им, работы прибавится
бедные разработчики.. сочувствую им, работы прибавится
бедные разработчики.. сочувствую им, работы прибавится
Можно не мучать разработчиков, в взять готовый багтрекер http://sourceforge.net/search/?type_of_s…
Не смотря на богатство выбора, ни один open source багтрекер не позволяет создавать разные workflow для разных задач, связывать задачи между собой тоже умеют не все.
Open source багтрекилки можно использовать для собирания запросов от пользователей (вообще без проблем), для управления разработкой - уже хуже, для того и другого одновременно - почти нереально.
Open source багтрекилки можно использовать для собирания запросов от пользователей (вообще без проблем), для управления разработкой - уже хуже, для того и другого одновременно - почти нереально.
Да, интересная штука. Апачевцы он JIRA используют, сами продуцируют опенсорс, а issue tracking system - проприетарный. Инь-янь и всё такое :)
Ну, JIRA - это очень условно пропиретарная система, т.к.:
1) Она писалась опенсоурсниками (Mike - один из основателей и активный участик opensymphony, JIRA - их первый коммерческий продукт).
2) Идеология продукта там совершенно опенсоурсная, это "красивая bugzilla на стероидах". Архитектурно JIRA имеет куда больше общего с системами типа bugzilla или mantis, чем с коммерческими системами, Этим, во многом, и объясняется ее популярность - многим был просто нужен коммерческий аналог устаревшей bugzilla и ничего больше.
3) Для разработки коммерческих продуктов JIRA заточена так же плохо, как и большинство open source продуктов. Посмотрите список багов тут, большая часть "старых висняков" (начиная с field level security) важна именно для коммерческой разработки софта и совершенно не актуальна для open source проектов.
4) Внутри самой компании Atlassian, JIRA используется только для общения с пользователями. Для управления проектом они печатают задачи на бумагу и развешивают их на стену, дальше весь трекинг идет именно по этим бумажкам, а потом в JIRA сообщают пользователям, что все готово. Кому интересны подробности - смотрите описание процесса в блоге одного из их разработчиков. Они, как раз, не мешают bug tracking и change requests в одной системе, зато на эти грабли наступают некоторые их клиенты.
1) Она писалась опенсоурсниками (Mike - один из основателей и активный участик opensymphony, JIRA - их первый коммерческий продукт).
2) Идеология продукта там совершенно опенсоурсная, это "красивая bugzilla на стероидах". Архитектурно JIRA имеет куда больше общего с системами типа bugzilla или mantis, чем с коммерческими системами, Этим, во многом, и объясняется ее популярность - многим был просто нужен коммерческий аналог устаревшей bugzilla и ничего больше.
3) Для разработки коммерческих продуктов JIRA заточена так же плохо, как и большинство open source продуктов. Посмотрите список багов тут, большая часть "старых висняков" (начиная с field level security) важна именно для коммерческой разработки софта и совершенно не актуальна для open source проектов.
4) Внутри самой компании Atlassian, JIRA используется только для общения с пользователями. Для управления проектом они печатают задачи на бумагу и развешивают их на стену, дальше весь трекинг идет именно по этим бумажкам, а потом в JIRA сообщают пользователям, что все готово. Кому интересны подробности - смотрите описание процесса в блоге одного из их разработчиков. Они, как раз, не мешают bug tracking и change requests в одной системе, зато на эти грабли наступают некоторые их клиенты.
НЛО прилетело и опубликовало эту надпись здесь
Про "раздуют" - это опечатка почти по Фрейду :-) Если первые версии Jira хвалили как очень простые, то сейчас жалоб на громоздкость интерфейса Jira становится все больше. С IDEA аналогично: 99% виденного мною негатива по поводу последних версий IDEA - это про сложность конфигурирования и тормоза.
Если по существу, то Atlassian МОЛОДЦЫ в плане маркетинга, в этом плане они обогнали конкурентов года на 2-3. Собственно, они первыми начали раздавать бесплатные лицензии open source проектам, активно пиарить Jira в блогах, вести разработку коммерческого продукта "в открытую".
Несколько лет назад я читал пост примерно такого содержания в блоге автора какого-то очень известного open source проекта (кажется, Gavin King-а, но не могу утверждать на 100%): "Сегодня ко мне постучался по IM Mike и сказал что он проимпортировал все баги из нашей старой багзиллы (или чего там) в JIRA, уже можно пользоваться. Круто, ура, переходим на JIRA.". Хотя на ASF переползали на JIRA не так гладко, многие сопротивлялись по идеологическим мотивам и их убалтывали :-)
Но, опять же, все это стало возможным из-за заточенности JIRA под open source проекты. Скажем, доступ к багобазе без регистрации - это критически важная фича для open source проектов и довольно сомнительная затея для коммерческих продуктов (см оригинальный пост). Большинство других производителей коммерческих систем при всем желании не смогли бы так эффективно раздать свой продукт open source проектам, без анонимного доступа к списку багов он open source проектам не нужен.
В коммерческих багтрекилках большое внимание уделяется поддержки workflow, security, а для небольших команд open source разработчиков это не нужно и только усложняет конфигурирование.
Если по существу, то Atlassian МОЛОДЦЫ в плане маркетинга, в этом плане они обогнали конкурентов года на 2-3. Собственно, они первыми начали раздавать бесплатные лицензии open source проектам, активно пиарить Jira в блогах, вести разработку коммерческого продукта "в открытую".
Несколько лет назад я читал пост примерно такого содержания в блоге автора какого-то очень известного open source проекта (кажется, Gavin King-а, но не могу утверждать на 100%): "Сегодня ко мне постучался по IM Mike и сказал что он проимпортировал все баги из нашей старой багзиллы (или чего там) в JIRA, уже можно пользоваться. Круто, ура, переходим на JIRA.". Хотя на ASF переползали на JIRA не так гладко, многие сопротивлялись по идеологическим мотивам и их убалтывали :-)
Но, опять же, все это стало возможным из-за заточенности JIRA под open source проекты. Скажем, доступ к багобазе без регистрации - это критически важная фича для open source проектов и довольно сомнительная затея для коммерческих продуктов (см оригинальный пост). Большинство других производителей коммерческих систем при всем желании не смогли бы так эффективно раздать свой продукт open source проектам, без анонимного доступа к списку багов он open source проектам не нужен.
В коммерческих багтрекилках большое внимание уделяется поддержки workflow, security, а для небольших команд open source разработчиков это не нужно и только усложняет конфигурирование.
Трекер веб-приложений очень удобен для хакеров. Они ищут подходящую ошибку, а затем ищут того, у кого стоит старая версия с неисправленной ошибкой. Пишут эксплоит и вперед.
Лишнее приватное сообщение о давно найденной ошибке не повредит разработчику, но публикация неисправленных ошибок может весьма сильно навредить клиентам и ухудшить репутацию самих разработчиков.
Лишнее приватное сообщение о давно найденной ошибке не повредит разработчику, но публикация неисправленных ошибок может весьма сильно навредить клиентам и ухудшить репутацию самих разработчиков.
Я думаю, нужно позволить посылать сообщения об ошибках на некий bugs@example.com с тем, чтобы разработчик (ответственное за ошибки лицо) ответил на письмо и внёс баг в список.
Пользователю будет приятно, а разработчику — легче.
Пользователю будет приятно, а разработчику — легче.
НЛО прилетело и опубликовало эту надпись здесь
Кстати, а почему именно bugs@example.com, а не support@example.com? Мне кажется, что отдельный адрес для багов - верный признак того, что ответ от саппорта Вы получите не скоро.
Если я не получаю ответа на первое письмо на этот ящик, то вряд ли я напишу туда еще раз. На моей памяти, Sun и BEA я писал по одному разу, они не ответили, больше я их не беспокоил.
Если я не получаю ответа на первое письмо на этот ящик, то вряд ли я напишу туда еще раз. На моей памяти, Sun и BEA я писал по одному разу, они не ответили, больше я их не беспокоил.
НЛО прилетело и опубликовало эту надпись здесь
Общение пользователей и разработчиков просто обязано быть публичным вне зависимости от того, что пользователь хочет сообщить разработчикам или о чем узнать. Пользователь будет общаться неформально, поэтому описать такое общение багой, фичей или еще чем-то задача неблагодарная и непрактичная.
Другое дело, что круг пользователей может быть совершенно различным: постоянные пользователи, которым интересно развитие продукта - обязательно публичное общение с разработчиками, с большей степенью открытости; просто покупатели продукта, которых все устраивает - достаточно отправки сообщения по email.
Конечно не стоит заставлять пользователя искать ранее введенные похожие баги и т.п. Это должны делать разработчики, поскольку только им известно, что есть дубль, а что нет. Но пользователю НУЖНО показывать как заведенную им багу, так и все с ней связанные, заведенные другими пользователями, это даст возможность глубже понять проблему или шире понять контекст (например, Oracle Metalink)
В некоторых системах (JIRA, DEVPROM.net) пользователю предлагается вводить т.н. Issue (проблема по-русски). Что это на самом деле ошибка или доработка или просто бред - решать разработчикам (их менеджерам и аналитикам).
В процессе разработки любое Issue проходит по одному и тому же циклу разработки, поэтому нет смысла в отдельных workflow для каджой разновидности issue, при том что семантика такой разновидности может быть далеко не однозначной.
Другое дело, что круг пользователей может быть совершенно различным: постоянные пользователи, которым интересно развитие продукта - обязательно публичное общение с разработчиками, с большей степенью открытости; просто покупатели продукта, которых все устраивает - достаточно отправки сообщения по email.
Конечно не стоит заставлять пользователя искать ранее введенные похожие баги и т.п. Это должны делать разработчики, поскольку только им известно, что есть дубль, а что нет. Но пользователю НУЖНО показывать как заведенную им багу, так и все с ней связанные, заведенные другими пользователями, это даст возможность глубже понять проблему или шире понять контекст (например, Oracle Metalink)
В некоторых системах (JIRA, DEVPROM.net) пользователю предлагается вводить т.н. Issue (проблема по-русски). Что это на самом деле ошибка или доработка или просто бред - решать разработчикам (их менеджерам и аналитикам).
В процессе разработки любое Issue проходит по одному и тому же циклу разработки, поэтому нет смысла в отдельных workflow для каджой разновидности issue, при том что семантика такой разновидности может быть далеко не однозначной.
Зачем мне, как пользователю НУЖНО показывать заведенную мной багу? Что я с ней делать-то буду? Заходить раз в неделю и любоваться?
И потом, бывают пользователи, а бывают - пользователи. Сильно не все из пользователей вообще представляют себе, что такое багтрекер. У них "выскочило окошко" и все.
Firefox вон вообще, когда падает, просто отсылает фидбэк и все. Я понятия не имею, что там дальше с этим фидбэком происходит, я же не в курсе их кухни. Мне бы, возможно, хотелось бы знать, когда моя проблема будет решена и будет ли, но это только в том случае, если ошибка критическая и приложение с ней вообще не выполняет нужную мне функцию.
Вот поднимите руки те, кто знает адрес багтрекера, куда заносятся ошибки в Firefox?
И потом, бывают пользователи, а бывают - пользователи. Сильно не все из пользователей вообще представляют себе, что такое багтрекер. У них "выскочило окошко" и все.
Firefox вон вообще, когда падает, просто отсылает фидбэк и все. Я понятия не имею, что там дальше с этим фидбэком происходит, я же не в курсе их кухни. Мне бы, возможно, хотелось бы знать, когда моя проблема будет решена и будет ли, но это только в том случае, если ошибка критическая и приложение с ней вообще не выполняет нужную мне функцию.
Вот поднимите руки те, кто знает адрес багтрекера, куда заносятся ошибки в Firefox?
Забавно, но существуют такие пользователи, которые кроме IE и офисного пакета ничего и не знают. И пугать их подобными вещами смысла нет. Нужно иметь возможность получать репорты о багах в автоматическом режиме, но так же иметь канал для связи с продвинутыми пользователями которых не пугает общение с саппортом и подобные слова.
Встраиваение системы сбора данных об ошибках в программу тоже является спорной идеей. Кто знает, что разработчики пожелают включить в отчёт?
Вы доверяете им свою приватность?
Её полное отсутстве для сложных ПП тоже черевато ещё большими проблемами.
Как промежуточный выход. Можнго в бета-сборки включать наиболее развёрнутый сбор статистики (тестеры знают на что идут). Ну а в финальных релизах беспокоить пользователей только в случае критических ошибок.
Встраиваение системы сбора данных об ошибках в программу тоже является спорной идеей. Кто знает, что разработчики пожелают включить в отчёт?
Вы доверяете им свою приватность?
Её полное отсутстве для сложных ПП тоже черевато ещё большими проблемами.
Как промежуточный выход. Можнго в бета-сборки включать наиболее развёрнутый сбор статистики (тестеры знают на что идут). Ну а в финальных релизах беспокоить пользователей только в случае критических ошибок.
1) А почему общение пользователя и разработчика обязано быть публичным ? Ну т.е. определенная польза для разработчиков в этом есть, но как заставить пользователей сообщать обо всем в багтрекер/форум - я не знаю. Во многих компаниях саппорт через форум - это что-то неофициальное и без гарантий ответа, поэтому часто пользователи предпочитают писать почтой.
Мне кажется, что сообщать можно как угодно, хоть по телефону, а уж разработчики потом разберуться что с этим делать.
2) Если мы имеем дело только с багами, то смысла в разных workflow в самом деле нет. Но если исправление проблемы включает в себя несколько задач (общение с пользователем, исправление кода, документации, сайта, поддержка версий на других языках, etc) и эти задачи выполняют разные люди, то поддержка разных workflow будет очень желательна.
Тут недавно обсуждался вопрос - а сколько состояний (new, resolved, closed, etc) лучше всего определить для баги. Думаю, что самое правильное решение - делать отдельное состояние на каждое изменение ответственного в организации.
Например, если исправлением проблемы и тестированием занимается один человек - достаточно 1 состояния "протестировано и исправлено", иначе разработчики будут просто игнорировать разницу между ними. А если один человек исправляет проблему, другой - тестирует, третий - обновляет документацию, то нужно уже 3 состояния.
Т.е. единого и правильного для всех workflow для багтрекинга не существует, конфигурация workflow определяется структурой организации и мало зависит от категории задачи (bug report, feature request, и т.п.).
Обратите внимание, что в персональных todo list-ах обычно есть всего 2 состояния - сделано/не сделано. Если человек один - ему больше состояний и не надо.
Мне кажется, что сообщать можно как угодно, хоть по телефону, а уж разработчики потом разберуться что с этим делать.
2) Если мы имеем дело только с багами, то смысла в разных workflow в самом деле нет. Но если исправление проблемы включает в себя несколько задач (общение с пользователем, исправление кода, документации, сайта, поддержка версий на других языках, etc) и эти задачи выполняют разные люди, то поддержка разных workflow будет очень желательна.
Тут недавно обсуждался вопрос - а сколько состояний (new, resolved, closed, etc) лучше всего определить для баги. Думаю, что самое правильное решение - делать отдельное состояние на каждое изменение ответственного в организации.
Например, если исправлением проблемы и тестированием занимается один человек - достаточно 1 состояния "протестировано и исправлено", иначе разработчики будут просто игнорировать разницу между ними. А если один человек исправляет проблему, другой - тестирует, третий - обновляет документацию, то нужно уже 3 состояния.
Т.е. единого и правильного для всех workflow для багтрекинга не существует, конфигурация workflow определяется структурой организации и мало зависит от категории задачи (bug report, feature request, и т.п.).
Обратите внимание, что в персональных todo list-ах обычно есть всего 2 состояния - сделано/не сделано. Если человек один - ему больше состояний и не надо.
1) Если ваши пользователи хотят коммуницировать с разработчиками, то для этого нужно использовать соответствующий инструмент (багтрекинг или еще что-то). Коммуникация довольно быстрая и чистая: пользователь написал - разработчик (в общем смысле) увидел и отреагировал, пользователь видит результат (или его отсутствие, что тоже некоторый результат использования разрабатываемого продукта).
2) Любая активность, которая отражается на программном коде продукта проходит строго определенный набор фаз: анализ, проектирование, разработка/проверка, тестирование/багфиксинг, документирование. Все что касается остальных задач вытекающих из специфики данного продукта - это тоже некие активности, но выполняющиеся на одной из этих фаз.
3) Состояния, в которых может находиться, например, бага, определяются исключительно бизнес-процессом используемым в той или иной команде/организации. Но есть и безусловно обязательные: Назначено, Открыто, Выполнено.
То есть не нужно путать элементы стандартного процесса девелопмента (фазы имплементации) с организационной спецификой обработки некоторой задачи.
2) Любая активность, которая отражается на программном коде продукта проходит строго определенный набор фаз: анализ, проектирование, разработка/проверка, тестирование/багфиксинг, документирование. Все что касается остальных задач вытекающих из специфики данного продукта - это тоже некие активности, но выполняющиеся на одной из этих фаз.
3) Состояния, в которых может находиться, например, бага, определяются исключительно бизнес-процессом используемым в той или иной команде/организации. Но есть и безусловно обязательные: Назначено, Открыто, Выполнено.
То есть не нужно путать элементы стандартного процесса девелопмента (фазы имплементации) с организационной спецификой обработки некоторой задачи.
Сделайте, пожалуйста, верстку вашего поста в нормальном виде.
А что не нравится в нынешнем виде ?
Тем, что такая верстка говорит о фактическом незнании автором поста языка HTML. Только незнающий человек может делать _такую_верстку: все строки отбиваются дополнительными брейками
(). А уж после каждого элемента списка делать отступ - вообще грех.
Что я хочу от автора поста: уберите, пожалуйста, ВСЕ внутри текста, и текст станет гораздо лучше и правильнее с точки зрения логики верстки.
(). А уж после каждого элемента списка делать отступ - вообще грех.
Что я хочу от автора поста: уберите, пожалуйста, ВСЕ внутри текста, и текст станет гораздо лучше и правильнее с точки зрения логики верстки.
Не очень хорошая идея - заставлять пользователей писать багрепорты. Ну, то есть вообще, заставлять их что-либо делать это уже плохая идея, но здесь речь немного о другом.
Репорты от пользователей приходят в очень плохом виде: без анализа проблемы, без информации о версиях, окружении и тд и тп.
Думается, дешевле и эффективнее всё-таки способ, когда пользователи шлют свои проблемы (или звонят) в саппорт, а там уже решается, в чем действительно заключается проблема (и может быть порожден баг-репорт).
Репорты от пользователей приходят в очень плохом виде: без анализа проблемы, без информации о версиях, окружении и тд и тп.
Думается, дешевле и эффективнее всё-таки способ, когда пользователи шлют свои проблемы (или звонят) в саппорт, а там уже решается, в чем действительно заключается проблема (и может быть порожден баг-репорт).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А нужно ли список багов в проекте делать публичным?