Насколько велика команда, которая вам нужна для отслеживания ошибок? [закрыто]

59

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

plntxt
источник
136
Команда из одного пользуется программным обеспечением для отслеживания ошибок.
Доминик Макдоннелл
5
Возможно, вы захотите попробовать FogBugz Student and Startup Edition - очень простую и удобную в настройке и использовании ( fogcreek.com/fogbugz/StudentAndStartup.html ).
Максим Заславский
2
даже команда из <1 человека нуждается в программном обеспечении для отслеживания ошибок ...
vrdhn
5
@Vardhan Команда из менее чем одного человека? Мол, несуществующая команда?
Ikke
2
@ Ikke ... как один человек, работающий над несколькими проектами ... и постоянно забывай, что делать с несколькими проектами ... вызов управления - это 0,5 ресурса !!
vrdhn

Ответы:

51

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

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

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

bethlakshmi
источник
Очень хорошо поставлено! Выберите инструмент, который оптимизирует то, как вы хотите работать! В противном случае, используйте пробку!
Андрес Яан Так
79

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

l0b0
источник
6
Bugzilla, вероятно, можно установить на виртуальном сервере за довольно минимальную стоимость.
Захари К
2
Trac также не берет много для обслуживания. У меня был экземпляр Trac, работающий около 2 лет подряд, и мне никогда не приходилось поддерживать ничего, кроме добавления новых проектов.
whatsisname
2
Я знаю, что оба они просты в обслуживании, дело скорее в том, что это «ненулевые расходы», т. Е. Не бесплатно. Может быть, несколько часов в год, если вы хотите установить исправления безопасности, или несколько дней, если вам нужно перейти со старой версии или ваше оборудование умирает.
10
Расходы на установку не равны нулю, но при правильном использовании они будут намного меньше, чем выгоды от их установки.
BillThor
2
Не забудьте BitBucket для тех пользователей hg там.
Шолзингер
41

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

оборота HLGEM
источник
Я могу полностью относиться к этому. Буквально вчера я потерял свой блокнот, где записал некоторые ошибки, которые нужно было исправить. Теперь мне придется потратить еще два часа на прохождение проблемной зоны. Я собираюсь скачать Bugzilla или что-то в этом роде.
3
Хорошая точка зрения. Исследования психики говорят, что люди могут хранить ~ 7 предметов в своей краткосрочной памяти. Если у вас в списке задач более 7 предметов, отслеживание ошибок - хорошая идея. Если вы все равно их записываете, вы можете делать это масштабируемым и систематическим образом (это не намного больше усилий).
ДБКК
27

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

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

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

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

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

Tyanna
источник
+1 за упоминание отслеживания «билета». Было бы глупо хранить только ошибки в такой системе, если вы можете использовать ее также как личный список
задач,
Серьезно, вы должны привязать отслеживание ошибок к вашей системе контроля версий. Тогда все изменения имеют вескую причину. И у вас должен быть какой-то RCS. Не использовать оба - все равно что приходить на работу без штанов.
Тим Виллискрофт
Да, не называйте это "ошибкой" отслеживания. Мы называем это «отслеживанием задач», поскольку ошибка - это задача, но задача не обязательно является ошибкой.
Carson63000
16

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

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

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

JohnFx
источник
13

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

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

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

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

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

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

Кен Хендерсон
источник
8

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

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

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

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

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

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

Ричард Харрисон
источник
4

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

Захари К
источник
2

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

Джефф
источник
1

Да.

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

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

Идиоты
источник
1

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

Джимми Коллинз
источник
0

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

Карл Билефельдт
источник
0

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

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

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

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

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

dukeofgaming
источник
0

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

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

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

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

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

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

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

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

Брюс Маклеод
источник
0

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

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

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

RBerteig
источник
-1

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

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

user18782
источник
-1

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

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

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

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

user18794
источник
-1

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

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

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

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

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

Earlz
источник
-1

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

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

user18806
источник
-1

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

basarat
источник
-1

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

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

Адам
источник
-1

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

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

Ли Ковальковски
источник
-1

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

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

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

Ингвальд
источник
-5

нет

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

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

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

Стивен А. Лоу
источник
[Я просто должен был что-то сказать, чтобы противостоять всем без ответов]
Труфа
2
Как вы помните, ошибка исправлена? Как вы помните, что вы не пропустили ошибку, прежде чем сделать релиз?
Earlz
2
Извините, чувак, похоже, что вы пытаетесь сделать точку, но это спорный вопрос.
Dukeofgaming
2
@Steven: когда-либо был продукт с 7-значным числом установок? Никакое количество TDD не помешает нескольким тысячам пользователей регистрировать ошибки, не говоря уже о нескольких миллионах. Они могут даже не быть настоящими ошибками, которые нужно исправлять с вашей стороны, но вам все равно придется просматривать их, закрывать дубликаты, указывать клиентам решения для оригинальных и т. Д. Если вы работаете в одиночной компании, вы либо приходится прибегать к ручке / бумаге, Excel, собственной БД - или вы просто используете какое-то программное обеспечение, созданное для этого.
ВОО
2
@ Стивен: Мои экстрасенсорные способности не в состоянии понять, что так далеко от необъявленных потребностей Джима (и в этом вопросе, конечно, нет ничего, что указывало бы на вашу интерпретацию)
ВОО