Ошибки против повышения по сравнению с новой функцией

При планировании и определении приоритетов того, что должно быть включено в выпуск, вы различаете ошибки, улучшения функций и новые функции?

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

РЕДАКТОР: Некоторые замечательные ответы - спасибо. Хотя у меня было предвзятое мнение, что вам все равно нужно обрабатывать ошибки, функции, улучшения и просто выбирать работу, основанную на стоимости/преимущества каждого из них, я считаю, что реальность такова, что это зависит от вашей ситуации.

Ответ 1

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

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

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

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

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

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

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

Ответ 2

Мы спрашиваем наших пользователей. У нас есть нишевый продукт и небольшая пользовательская база.

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

Итак, мы спрашиваем их, что они хотели бы.

Они предлагают исправления, запрашивают новые функции.

Мы рассказываем им о дорожной карте разработки: потому что у нас есть вещи, которые мы хотим сделать с продуктом, из-за изменения времени, дизайнерских идей. Изменения в правилах.

И если каждый клиент говорит "нам действительно нужна функция X": тогда он появится далее.

Если они скажут "вам, ребята, нужно исправить ошибку, где я нажимаю там, и она не делает бла": тогда эта ошибка исправляется.

Коммерческое программное обеспечение: клиенты, голосующие за изменения. Разумеется, мы принимаем их выбор по рекомендации: у компании есть другие вещи, о которых мы думаем.

Ответ 3

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

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

Ответ 4

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

Ответ 5

различать, да.

ошибки имеют приоритет, да.

все критические/нормальные приоритеты и выше ошибки сначала, да.

да, правило 80/20.

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

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

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

Надеюсь, что это поможет!

Ответ 6

Вы должны смотреть на это с точки зрения того, что такое ошибка. Ошибка show-stopper всегда является приоритетом номер один. Если люди не могут войти в систему или критические данные не могут быть введены или скорректированы и т.д., То это должно иметь приоритет над почти всем.

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

Ответ 7

Пункт 5 Тест Joel: 12 шагов к лучшему коду делает убедительный аргумент (на мой взгляд), что это хорошая идея исправить ошибки перед написанием нового кода.

Ответ 8

Для ошибок это довольно просто: если вы исправите его, исправьте его, прежде чем писать код. Зачем? Чем больше добавляется код, тем сложнее будет найденная ошибка.

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

Ответ 9

Ошибка? У нас нет ошибок. Это недокументированные функции.

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

Ответ 10

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