Сообщений в теме: 83

[LeshaL]

Баг-репорт может не являться таском или реквестом на изменение кода.

Наверное, можно придумать такую ситуацию - но я не сумел. Пример подскажете?

Known issue, которое будет описано в Release Notes.
Пример1 (абстрактный), ваш код использует чью-то библиотеку, в которой есть проблема. Возможности сделать workaround нету. Единственный вариант - написать реквест производителю сторонней библиотеки и ждать пока починят. Ваши пользователи будут видеть, что вы в курсе проблемы и причины, почему она не починена.
Пример2 (из жизни). Один наш продукт не работает в случае если на машине запущен tomcat сервер. Идет конфликт по захвату портов, используемых при SSL соединении. Есть баг по этому поводу. По хорошему, надо разрешить конфигурировать порты в нашем продукте, но врядли это будут делать по определенным причинам (в томкате это можно поменять, но дефолтный порт один и тотже). Описание бага есть в Release Notes в специальной секции. И мы довольны, что нам не надо ничего делать и пользователи в курсе как разрулить проблему, если у них томкат или какой другой зверь захватит этот порт.

[DrVal]

Я уже приводил несколько.

Реквест на изменение кода появляется (явно или неявно) в тот момент, когда принято решение фиксить конкретный баг, а не в момент его заведения.

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

Баг-репорт может не являться таском или реквестом на изменение кода.

Наверное, можно придумать такую ситуацию - но я не сумел. Пример подскажете?

[Case]

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

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

[DrVal]

Все правильно, вот мы и добрались до сути разногласий :-) Хотя я больше говорил про реквесты на изменения кода, а не абстракные таски.

Оставим только таск на анализ проблемы (хотя это скорее активность).

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

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

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

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


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

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

[Case]

Активность это набор действий исполнители по разрешению Задачи.

Вы никак не доказываете почему северити и приоритет два РАЗНЫХ понятия.

[DrVal]

Хорошо, применимо ли понятие приоритета к баг-репорту напрямую?
Если да, то как?

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

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


В общем, я последую примеру Алексея :-)

Активность это набор действий исполнители по разрешению Задачи.

Вы никак не доказываете почему северити и приоритет два РАЗНЫХ понятия.

[Case]

То есть северити это признак проблемы, а приоритет признак issue который описывает эту проблему? :)

Вы верно говорите, только приоритет таска (всё-таки сошлись что баг это таск?) должен совпадать с приоритетом проблемы, иначе либо приоритет либо важность понятие надуманное.

[DrVal]

Я не берусь рассуждать, должны ли они совпадать в теории.

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

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

Я не предлагаю усложнять систему без необходимости, просто иногда простота начинает мешать процессам.

Разумнный предел в этом случае до 9 факторов, на основании которых определяется приоритет. В этом случае становится проще договорится, т.к. бизнес не спорит с девелопментом о северити, он просто говорит Do it!

Теперь уж точно все по этой теме :-)

То есть северити это признак проблемы, а приоритет признак issue который описывает эту проблему? :)

Вы верно говорите, только приоритет таска (всё-таки сошлись что баг это таск?) должен совпадать с приоритетом проблемы, иначе либо приоритет либо важность понятие надуманное.

[Case]

Да нет :)

Срочность тут точно не причём. Срочность в терминах проектного управления задаётся через addressed build - то есть билд в котором должны починить. Остаётся "Важность" - так вот она имеет однозначное соответствие: называть можно как угодно, но это приоритет.

Теперь про большие проекты, которыми все в данной ветке пытаются мне пояснить почему нужно два признака. Что такое большой проект? Много кода, много девелоперов? 3 годичная итерация? :) Где это надо-то?

[DrVal]

Слава, в моем понимании приоритет - это именно срочность, т.к. влияет на очередность выполнения задач.
А важность - это один из факторов, на основании которого выставляется приоритет.
addressed build или milestone определяет деад-лайн, т.е. относится к стратегическому планированию, приоритет - к тактическому.

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

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

Возможно что-то еще, лень думать.

Да нет :)

Срочность тут точно не причём. Срочность в терминах проектного управления задаётся через addressed build - то есть билд в котором должны починить. Остаётся "Важность" - так вот она имеет однозначное соответствие: называть можно как угодно, но это приоритет.

Теперь про большие проекты, которыми все в данной ветке пытаются мне пояснить почему нужно два признака. Что такое большой проект? Много кода, много девелоперов? 3 годичная итерация? :) Где это надо-то?

[Case]

Слава, в моем понимании приоритет - это именно срочность, т.к. влияет на очередность выполнения задач.
А важность - это один из факторов, на основании которого выставляется приоритет.
addressed build или milestone определяет деад-лайн, т.е. относится к стратегическому планированию, приоритет - к тактическому.

Ушли в дебри. Тактическое планирование проекта, это интересно, наверное :)

То есть вам, чтобы выставить приоритет нужна важность. Всё, теперь понятно. Кому она не нужна - у тех меньше мороки куда приткнуть важность :)

[DrVal]

Заметим, что у меня нет фразы про "тактическое планирование проекта", но к нему я вполне могу отнести распределение задач (day by day activity) в рамках проектного плана.

Оригинальная тема поста "Принципиальная разница между Severity & Priority".
Надеюсь, что хоть кому-нибудь мои ответы помогли понять, что это принципиально различные понятия.

Приоритет нужен для управления порядком выполнения заданий, т.е. определяет срочность. Имеет смысл в контексте проекта или межпроектном взаимодействии. Для меня он с понятиям "важность" или "серьезность" не связан напрямую, но эта связь может задаваться правилами (см. ниже).

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

Правила определения приоритетов задаются стандартами, процессами или "понятиями", принятыми в компании.
Я и не предлагал усложнять эти правила без необходимости :-)
Но если для изменения приоритета начинают менять северити, это признак того, что понятия пора разделять.

Ушли в дебри. Тактическое планирование проекта, это интересно, наверное :)

То есть вам, чтобы выставить приоритет нужна важность. Всё, теперь понятно. Кому она не нужна - у тех меньше мороки куда приткнуть важность :)

[vinogradoff]

Небольшой up древней темы.

 

Мини-опрос:

1. Вы хорошо понимаете, зачем и как использовать Severity и Priority?

2. Часто ли у вас или коллег по работе бывают споры из-за каких-то аспектов Severity/Priority (про конкретные дефекты и в целом про систему)?

[clipsa]

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

[vinogradoff]

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

Да, так везде и пишут в интернете :) Т.е. на 1-ый вопрос ответ - "да". А на второй?

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

[Freiman]

1. Да

2. Нет, так как более старшими товарищами была давным-давно сделана памятка, как определять первое и второе, и с опытом Гуру никто не спорит :)

[VinnieJohns]

Мои ответы будут как у Freiman'а:

1. Да

2. Нет, определения с примерами (особенно по приорити) даны в документе по рабочим процессам. Хотя, помню, мне кто-то где-то когда-то с пеной у рта доказывал, что всё наоборот: Severity отвечает за то, в каком порядке разработчики дефекты исправляют, а Priority - суть мера серьёзности дефекта =)

[Vasiliy]

1. Да.

2. В текущем процессе у нас только Приоритет)).

На предыдущей работы было два поля в трекере и иногда начинающие ПМы пользовались этим делом неправильно... Приходилось спорить:)

[Llanie]

1. Да. Придерживаемся той же идеологии, что и "везде в интернете". Кто не понимает, того учим.
2. Нет. В нескольких уже командах и проектах вижу, что обычно ставится только Severity и правки ведутся более-менее на усмотрение ведущего программиста (а они, как на подбор, умные и адекватные ). Если начинаются какие-то авралы или сроки сокращают, тогда ПМ размечает Priority.

[vinogradoff]

Ответы все еще нужны:)

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