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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

И если каждый клиент говорит «нам действительно нужна функция X»: тогда это будет следующим.

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

Пункт 5 из The Joel Test: 12 Steps to Better Code делает убедительный аргумент (, на мой взгляд,), что рекомендуется исправить ошибки перед написанием нового кода.