Приоритеты средства отслеживания ошибки и политики [закрываются]

Я верю Моя жизнь, поскольку Экономист Кода Eric Sink принадлежит здесь. Его сущность: расположите по приоритетам ошибки согласно серьезности, частоте, стоимости и риску. Не исправляйте каждую ошибку, а скорее имейте список менее серьезных и фиксируйте их, как Вы продвигаетесь.

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

Наша система установления приоритетов всегда находится в контексте текущего повторения программного обеспечения и работ следующим образом.

• Приоритет 1 - Вся работа останавливается за исключением этого объекта, мы выпускаем фиксацию, как только это тестируется.
• Приоритет 2 - следующий выпуск не выйдет без этого разрешенного объекта.
• Приоритет 3 - Действительно желаемый в этом выпуске, но если у нас заканчивается время, мы продвинем его.
• Приоритет 4 - Мы действительно не ожидаем добираться до этого в этом выпуске, но если у Вас заканчиваются задачи, работа над ним.
• Приоритет 5 - не работают над ним.

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

В нашем месте:

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

Наши приоритеты:

• Присваивают Приоритет - это является самым высоким, и по умолчанию.
• Срочный! Срочный! - это предназначается для "отбрасывания все остальное" случаи, - немного глупый - имя было выбрано, чтобы заставить людей не злоупотребить им. Который на данный момент работал хорошо.
• Showstopper - этот блокирует кого-то от выполнения его работы эффективно, предотвращает демонстрацию некоторой функции, или подобный.
• Необходимый - необходимый для следующего выпуска этому присваивают. Функция мы обещали или являемся частью клиента specifc этап проекта
• Ожидаемый - что-то, что должно быть в следующем выпуске, но может быть отброшено.
• Фиксируют, если время - немного язык в проверке, потому что "мы делаем это, когда у нас есть много времени", является локальным эквивалентом, "не задерживают дыхание".

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

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

Мы используем FogBugz, btw.

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

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

Не совсем ответил на ваш вопрос, но подход оказался полезным для нас.

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

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

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

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

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

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

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

Для каждой входящей ошибки, запроса на улучшение или запланированной функции/новостройки мы присваиваем значение приоритета, серьезности и видимости (сокращенное P/S/V) от 1 до 5 (при этом 5 - самое высокое). Как правило, мы расставляем приоритеты, сортируя список дел по сумме трех значений (в общем, это система с нечеткой логикой). Работа над докладом об ошибке с P/S/V 2/5/4 будет вестись до начала новой задачи по разработке со значениями 5/5/3, но только после просьбы об улучшении со значениями 5/2/5.

Это (разумеется) неточная наука, и в системе всегда есть исключения. Иногда обработка запроса на улучшение более низкого уровня предпочтительнее, если он также будет работать вокруг ошибки более высокого уровня. Для всех задач с рангом X, ошибки с рангом X обычно решаются до повышения ранга X. Обычно мы также считаем, что все ранговые оценки имеют погрешность +/-1.

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

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