Комментарии 9
Представьте себе ситуацию: пятница, вечер, пять минут до конца рабочего дня.
Представил. Увольняюсь, в общем. Я что вам, станок ЧПУ с реле-таймером?
То есть, заранее неизвестна дата релиза? Мда...
А вообще, чем приоритет был плох? Не выпускать в прод с багами high и выше, напрмер. Не понятно. То есть, зачем два поля - count и его огрубленный вариант priority?
Ну и count, это что-то, что не вычисляют, а считают "раз, два, три..". Лучше бы назвать score, impact или как-то так.
почему же неизвестна? Про это я ни слова не писал)
Релизы у нас ежедневные, с понедельника по пятницу каждый день)
Приоритет не плох, и мы же до сих пор им пользуемся. Просто теперь, когда у меня есть конкретная цифра, сравнить два хай бага, и решить какой из них более хай - куда проще!)
а на счет названия поля - ну тут возможно и соглашусь, но это уже вкусовщина)
ну что же вы, не стоит из-за таких пустяков увольняться:D
Работал я как-то на проекте, на котором положили пальто на бизнес процес, и к багам прикрутили кроме приоритета такойже параметр, потому что там все баги были критикал. А вот если бы ребята вникли в бизнес процесс, то и все стало бы проще. И релизы бы не собирались на коленке в пятницу, а планировались бы на несколько итераций.
Лично мое мнение: когда проект скатывается в комок грязи, им становится сложнее управлять.
Круто, поздравляю, вы изобрели велосипед! А можно было просто научиться использовать 2 стандартных показателя priority & severity.
Релиз без сюрпризов: как мы уменьшили количество багов в проде