Моя команда разработчиков только выросла на 100% (с 1 разработчика до 2). Моя новая группа хочет инвестировать в программное обеспечение для отслеживания ошибок. Есть ли преимущества такого программного обеспечения для такой маленькой команды?

Я думаю, что все ответы «да» имеют большое значение для одобрения идеи. Но я собираюсь отбросить идею, что решение основано на нескольких вопросах:

• Как вы хотите общаться в команде? С двумя разработчиками вы теперь команда. Как вы хотите общаться? Множество гибких команд живут с личными обсуждениями и набросками доски. Но они также могут заходить так далеко, что записывают вещи, особенно если это ошибка, которая некоторое время не будет приоритетной в списке приоритетов.
• Как вы хотите общаться со своими клиентами? Я не знаю ответа на этот вопрос, но если у вас есть какая-либо причина публиковать ошибки (или исправлять ошибки в документе о выпуске версии), то в конечном итоге вы в конечном итоге их запишите. Можно также выбрать систему управления ошибками с низким уровнем стресса и покончить с ней.
• Есть ли ценность для сохранения истории? Ответ может быть «не сейчас», но если вы думаете, что в будущем вам захочется увидеть тенденцию ошибок, чтобы вы могли видеть места, в которых у пользователей больше всего проблем, или места, где вы могли бы потратить некоторое время на проверку и обзор перед основным выпуском - затем получите систему отслеживания ошибок. В истории дело в том, что день, когда вы хотите получить запись, не должен начинаться с учета.

IMO, ответы на эти вопросы больше о том, где вы видите продукт и как вы хотите расширить свою команду, и меньше о том, «2 человека = причина для системы отслеживания ошибок». Главный вопрос, вероятно, заключается в следующем: «Стоит ли система отслеживания ошибок времени на настройку и управление, а также стоимость покупки?»

1, но только если это безболезненно. Например, GitHub имеет очень простой и удобный трекер проблем с более чем достаточным количеством функций для небольшой команды. Bugzilla, Trac или другие хороши, но все они требуют аппаратного обеспечения, установки и настройки перед использованием, и обслуживание, безусловно, не является нулевым расходом.

У нас была очень крошечная команда, когда я впервые использовал программное обеспечение для отслеживания ошибок, и я был поражен тем, сколько мы думали, что нам нужно исправить, что так или иначе никогда не было исправлено. Это того стоит, независимо от того, насколько велика ваша команда.

Да. Тысячу раз да.

Даже не думайте об этом с точки зрения отслеживания ошибок, а как отслеживания билетов.

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

Для отслеживания ошибок вы можете разместить все свои ошибки в одном месте и отслеживать, какие из них были завершены, а какие еще находятся в процессе выполнения.

Это просто помогает вам намного лучше управлять вещами.

Это того стоит с командой из одного или нескольких человек.

Признайтесь, покупаете ли вы формальное программное решение или нет, у вас будет система отслеживания ошибок / функций. Это может быть в блокноте, это могут быть заметки, это может быть блок комментариев в верхней части вашего кода. Однако, если вы просто не разрабатываете случайно, вы будете где-то записывать свои списки дел. Почему бы не использовать более организованную систему, которая может расти вместе с вашей командой?

Также стоит подумать: многие из баг-трекеров бесплатны для использования очень небольшими командами (1-2), так что это не значит, что вы несете какие-либо серьезные расходы на пользу.

Вам не нужно никакого программного обеспечения для отслеживания ошибок, пока каждый член команды

• Имеет отличную фотографическую память и
• Можно синхронизировать свои мысли с любым другим членом команды.

Короткий ответ: да.

Несколько причин почему:

1. Возможность регистрировать ошибки, найденные в определенных версиях.
2. Возможность узнать, какие (известные) ошибки еще не исправлены.
3. Отслеживать, кто исправил ошибку, которая с тех пор была найдена снова.
4. Оборот разработчика - позволяет передавать знания, даже если вас ударили по общеизвестной шине.

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

Этот ответ заключается в добавлении веса в сторону ДА аргумента.

Я в основном команда из одного. Я широко использую отслеживание проблем (redmine) вместе с интеграцией SVN.

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

Инструменты производительности:

• Достойная IDE
• Отслеживание проблем
• Управления источником

Отслеживание проблем; не выходи из дома без него

Если у вас меньше 3, вы, вероятно, можете обойтись с таблицей Google Docs, возможно, я думаю. Но на самом деле стоимость установки bugzilla или чего-то подобного настолько тривиальна по сравнению с затратами программиста, что вам лучше просто сделать это. (Плюс, когда вы вырастете до 7, он уже будет там)

Даже одна команда может извлечь выгоду из какой-то системы отслеживания ошибок, будь то текстовый файл заметок или какое-то полнофункциональное программное обеспечение. Для 2 разработчиков я бы порекомендовал потратить время на настройку системы отслеживания ошибок, а не деньги. В зависимости от проекта вы можете справиться с записью ошибок на бумаге, ведением списка через общий онлайн-документ или с помощью бесплатного программного обеспечения для отслеживания ошибок, такого как Trac или Bugzilla. Fogbugz также доступен в качестве бесплатной пробной версии в течение 45 дней.

Да.

Вы должны отслеживать их как-то!

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

Есть определенное преимущество - я использую программное обеспечение для отслеживания ошибок даже в личных проектах. Это полезно не только для отслеживания ошибок, но и для отслеживания запросов TODO и функций.

Я использовал ошибки везде, когда работал один. Он работает с вашей DVCS, сохраняя информацию об ошибках вместе с вашим источником. Очень низкие накладные расходы, так как не требуют центрального сервера. Недостатком является то, что вы должны быть осторожны, в какие ветви вы вводите новые ошибки, чтобы убедиться, что они распространяются своевременно, хотя это может не иметь большого значения, если вы в основном хотите отслеживать свои собственные ошибки и то, что было исправлено в вашем последнем потоке, скорее чем отслеживать статус команды в целом.

Просто начните использовать один

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

Зрелость развития

Неважно, если у вас есть команда из 100 или 1, я начал использовать отслеживание ошибок и распределенный контроль версий (имеет большой смысл из-за локальных коммитов) только для себя и для себя, и я уже чувствовал себя на другом уровне, но не только это, я мог управлять своей работой на другом уровне ... до уровня, который мог бы масштабироваться без моих дополнительных усилий.

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

Для меня это касается не только программного обеспечения, но и процесса, который обходит его. В своей повседневной работе в качестве менеджера по тестированию я в основном живу в одном, и это дает следующие преимущества:

Я считаю, что это действительно хорошо работает с 2+ тестерами и 3+ разработчиками.

Управление усилиями по исправлению ошибок разработчика

Мы активно управляем разработчиками «очередью ошибок», чтобы контролировать объем работы, которую они им назначили, и обеспечить распределение работы по исправлению ошибок по всей команде.

Решать, что делать, а не исправляться

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

Когда вам нужны метрики

Для меня важна метрика, то есть когда вы хотите иметь возможность просматривать ошибки, находить и исправлять тренды, где находятся области с ошибками кода или как быстро тестировщики находят и повторно тестируют ошибки. Пришло время для системы отслеживания ошибок.

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

Лично я люблю ископаемые как для контроля версий, так и для отслеживания ошибок. Это полноценный распределенный SCM с низкой церемонией, который хорошо интегрирован в систему отслеживания ошибок и вики. И это установка с одним исполняемым файлом, широко переносимая и использующая внутреннее веб-приложение в качестве своего графического интерфейса. Его домашняя страница на самом деле почти полностью представлена ​​копией окаменелости.

С трекером, тесно интегрированным с контролем версий, вы можете легко связать изменения с заявками и просматривать обновления заявок в том же виде временной шкалы, что и редакции (и изменения на вики-странице).

Да, да, да, да! Возможность отслеживать, расставлять приоритеты и управлять своими проблемами является ключом к успешной разработке программного обеспечения. С одним человеком вы можете (почти) сойти с рук с помощью электронной таблицы и архивирования старых исходных деревьев. Добавление даже одного разработчика в проект кардинально меняет ситуацию - внезапно необходимо отслеживать проблемы и контролировать исходный код, или вы будете отбрасывать проблемы, перезаписывать функциональные возможности и, как правило, испытывать их жалкое время.

Я удивлен, что никто не упомянул материнскую компанию StackExchange, FogCreek, - их программное обеспечение FogBugz - лучшее приложение для отслеживания проблем, которое я когда-либо использовал. Высокая скорость, низкое сопротивление и доступность, особенно если вы используете их решение для хостинга. Раньше у них была бесплатная размещенная пробная версия, в которой, как я полагаю, было две бесплатные лицензии для пользователей - это может быть уже не так, но я бы рекомендовал проверить это.

вот мои 2 цента.

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

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

Некоторым клиентам требовалось использовать стороннее или другое подобное программное обеспечение для управления проектами / отслеживания ошибок, но я бы предпочел бесплатные решения, о которых я упоминал выше.

Если у вас есть минималистичный баг-трекер, я бы сказал, что он полезен даже для одной команды. На одном из проектных сайтов моего друга QuokForge они предоставляют экземпляр Red Mine для каждого проекта. Red Mine, на мой взгляд, имеет хороший баг-трекер (хотя иногда и немного странный). А именно потому, что вы можете сообщить об ошибке, введя текст только в ОДНОМ поле. Я также использовал FogBugz раньше. Это бесплатно для 2 или менее человек. И это позволяет такую ​​же простоту, регистрируя ошибку, заполняя только одно текстовое поле. (Он также предоставляет графики и другие вещи, которые безумно полезны)

По сути, не делайте регистрацию ошибок строгим и формальным процессом, требующим отводить 30 минут на заполнение отчета об ошибке (BugZilla, я смотрю на вас). Это просто означает, что люди не будут его использовать.

Наконец, наличие списка ошибок (даже если каждая ошибка содержит около 50 символов текста) чрезвычайно ценно. «Хм, как насчет выпуска 1.0. Думаю, я исправил последние ошибки». И для менеджеров также замечательно видеть, что вы на самом деле что-то делаете :). В команде это более ценно, потому что вы оба не пытаетесь держать в уме другой набор мысленных списков дел. И это исправляет «Вы исправили эту [действительно плохую ошибку безопасности]? Хм, да, я ДУМАЮ так. Хорошо, тогда давайте выпустим 1.0».

Я также люблю отслеживать функции, а также. Это немного более необязательный, но я все еще нахожу выгоду от возможности снять с ума умственную задачу - сохранить список задач в моей голове.

Также посмотрите, что сказал Джоэл об этом.

Вы только что достигли этого числа ... 2 ! Хотя я вижу преимущества использования программного обеспечения для отслеживания ошибок, даже если вы являетесь единственным разработчиком ... вы можете просто обойтись без него, когда общее количество разработчиков равно 1.

Однако, как только у вас появятся два или более разработчиков, нет ни единой причины не иметь программного обеспечения для отслеживания ошибок, ни одного.

Да. И рекомендация - bitbucket http://www.bitbucket.org. Они предоставляют бесплатное отслеживание ошибок, а также бесплатные частные репозитории в Mercurial.

Один. В этом случае это больше похоже на список дел.

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

Я думаю, что ваш вопрос высветил ваше заблуждение. Для отслеживания ошибок не команда, а продукт (ы).

Итак, нужно ли отслеживать ошибки в программном обеспечении? Ну, это поможет, тебе не кажется?

Это может не стоить того, если присутствуют следующие два условия:

1. Проблемы имеют короткий срок службы. В этом случае этого может быть достаточно с простой доской задач (поскольку разумно визуализировать рабочий процесс по многим другим причинам). Однако, если вы не можете решить проблемы быстро, например быстро исправляя ошибки, вам будет полезно отследить проблему.
2. Изменения кода документируются с помощью автоматических тестов как живая документация. То есть, ошибки и исправления документируются с ошибочными тестами, когда они появляются, а проходящие тесты становятся регрессионными тестами после исправления. - А изменения функциональности документируются с помощью автоматических приемочных тестов (например, с использованием некоторого инструмента BDD, такого как FitNesse или Cucumber). Такая документация должна быть легко доступна с CI-сервера, такого как Jenkins.

Если 1 или 2 отсутствует, вы выиграете от отслеживания проблемы.

нет

Не отслеживайте ошибки, исправляйте их .

Важен не размер команды, а то, сколько времени вы готовы посмотреть на ошибки в списке, прежде чем их исправлять.

Если вы используете Agile / TDD, ваш список ошибок будет коротким, и ошибки не будут долго оставаться в списке. В этом случае будет достаточно любой системы отслеживания.