Перейти к содержимому

Фотография

Принципиальная разница между Severity & Priority


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 83

#41 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 26 июня 2008 - 10:56

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


"смешались в кучу кони, люди..." Мне кажется, что за деревьями лес уже и не виден.
Что мешает настроить jira так, как вам нужно? добавить нужные поля, установить свой воркфлоу...
Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность - добавляйте. Если внесет путаницу - не множьте сущности без необходимости :)
  • 0

#42 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 26 июня 2008 - 12:06

Да никакая, можно выставить статус "исправим в следующей пятилетке".

Это называется дефферед и не имеет отношения к приоритету бага. Это статус, а не приоритет.


Ага, я понял, в чем дело. У нас всех разные трекеры и разные workflow. Отсюда разное понимание.
У меня, я тут подумал, вообще приоритета нет как отдельного поля. А статус есть.
  • 0

#43 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 26 июня 2008 - 19:26

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

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

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

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

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

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

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#44 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 27 июня 2008 - 07:22

Аджильность тут вообще не при чём, Леша - ты же понимаешь.

Понимаю. Специально в кавычки взял. Не придирайся к словам :)
Просто надо было как-то обозвать те два подхода к формированию набора тасков, которые я описал.

По сути (да и по названию :)) таск -- это задание, которое менеджер даёт одному из исполнителей.

Ну блин! :) А я про что? А баг он просто так появыляется как-то на ком-то? :)) Тот же таск - тот же.

Да, баг-репорт (а вовсе не баг!!! раз уж ты придираешься к словам, я тоже буду :) ) можно при определённых условиях интерпретировать как таск -- если нас устраивает линейный воркфлоу. Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#45 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 27 июня 2008 - 09:35

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

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

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

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

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

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


Описанная система не отвечает на вопрос: что делать в случае, когда багов сотни? Да, вы получите более тщательную разбивку по весам, но в каждом весе опять будет несколько десятков багов.
  • 0

#46 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 11:21

Да не придираюсь я к словам, чего ты :)

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

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#47 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 11:23

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

То есть вместо того чтобы полагаться на одно решение, вносим фактор ошибки многих решений. Бр-р-р.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#48 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 27 июня 2008 - 11:29

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


Так весов может быть хоть тысяча или даже десять тысяч. Параметры, влияющие на вес тоже могут быть самыми разными: состояние счета клиента, время до дидлайна, группа автора сообщения и время его работы в организации и т.п.
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#49 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 27 июня 2008 - 12:28

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

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


Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

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

В качестве примера - посмотрите приоритеты багов по JIRA 3.12.x. Там critical-ом оказалась "Unclear error message when bulk moving issues whose reporter cannot create issues", а что-нибудь типа "Moving portlet up reults in IndexOutOfBoundsException" оказалось minor.

Ситуация, когда все подряд назначают "своим" багам приоритет повыше, конкурируя за время команды похожа на "трагедию общих ресурсов":
http://www.seed.slb....nge/tragedy.htm

===
Термин трагедия общих ресурсов появился в 1968 году в статье Гаррета Хардина. Он считает, что проблемы, попадающие под эту категорию, технически решения не имеют. Они требуют изменения поведения и привычек человека.
...
Проблема в том, что большинство из нас действует лишь в собственных интересах, желая получить немедленный эффект. Но потери от влияния этих действий на климат планеты мгновенно не ощущаются. Я могу ездить на большом автомобиле, потому что мне так удобно. Дискомфорт от повышения уровня моря или количества штормов может появиться лишь через несколько десятилетий. Я не вижу прямой взаимосвязи между своими действиями и этими последствиями. Фактически, если бы на большой машине ездил один человек, то негативных последствий не было бы. Так же и пастух, который добавляет одну овцу к стаду – преимущества очевидны и мгновенны, в то время как потери пространны и растянуты по времени. Когда все пастухи поступают так, то в результате в проигрыше оказываются они вместе.

Решение требует взаимодействия людей, вместе принимающих решение об изменении поведения всех, включая себя.
===
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#50 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 12:49

Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

Максим, странно что это именно вы спрашиваете :) Железка тут не при чём. Есть мнение моё как тестера. С ним можно соглашаться или нет. Это решается трекингом через тех, кто имеет право влиять на моё решение.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#51 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 27 июня 2008 - 12:57

Добрый день,

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

А то как и что применять - это уже дело каждого, как сказал Jackie:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.


Вот.
Спасибо всем.
  • 0
Алексей Булат
Про Тестинг

#52 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 30 июня 2008 - 07:22

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

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?

Слава, этот спор аналогичен спору про ресурсы и роли. "Баг-репорт" и "таск" -- это две роли. Я не спорю, что один и тот же артефакт может выступать в двух разных ролях, хотите совмещать -- пожалуйста. Мой тезис заключается в том, что атрибут "критичность" относится к роли "баг-репорт", а атрибут "приоритет" -- к роли "таск". Исходя из этого тезиса, мне кажется, что физическое совмещение этих атрибутов в одном поле накладывает серьёзное ограничение на удобство использования системы.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#53 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 30 июня 2008 - 12:28

Леша :) Ты согласен что достаточно одного атрибута?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#54 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 30 июня 2008 - 16:38

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :acute:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#55 darm

darm

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Иван

Отправлено 08 июля 2008 - 21:22

Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?


Именно, что одного параметра достаточно, если у каждого члена команды есть более-менее четкое представление, что важно, а что не очень, и такое "кажется" происходит редко. А вот если приложение большое, народу много, процессы поставлены не очень, клиенты психованные или ещё что там - тогда возникает необходимость в человеке, который будет приоритеты расставлять. Ну а вся эта система со сложным вычислением весов, конечно, забавная, но избыточная уже, наверное. Если у тестера оказался кривой билд и не работает вообще, он занёс шоустоппер с заголовком капслоком, а у остальных всё отлично, это и само быстро всплывёт - впрочем, скорее всего, ещё до занесения в трекер.
  • 0

#56 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 09 июля 2008 - 10:00

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :mega_shok:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.


Леша, ты играешся в слова :acute:
Маппинг между статусами один-к-одному?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#57 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 09 июля 2008 - 14:38

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :mega_shok:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.


Леша, ты играешся в слова :acute:
Маппинг между статусами один-к-одному?

Именно потому и два, что не один к одному.
Я выхожу из дискуссии. Твою точку зрения, Слава, я понял.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#58 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 17 сентября 2008 - 20:52

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


Одна из целей тестирования - получение информации от свойствах ПО.
Создание баг-репорт - это фиксирование полученной информации.

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

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

Пример.
В середине проекта нам нужно получть демо-версию для презентации нового GUI заказчикам.
Меняется ли от этого северити заведенных багов? Нет.
Меняестя ли приоритет? Да, нам нужно выбрать определенные баги в GUI и пофиксить их до презентации.


Понятно, что в конечном итоге все сводится к фиксим - не фиксим.
Но решение принимается на основании анализа различных факторов. Северити - один из них.

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

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

Да не придираюсь я к словам, чего ты :)

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

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?


  • 0

#59 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 17 сентября 2008 - 22:04

Уточню.

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

От этого его сущность не меняется.

Да, баг-репорт (а вовсе не баг!!! раз уж ты придираешься к словам, я тоже буду :) ) можно при определённых условиях интерпретировать как таск -- если нас устраивает линейный воркфлоу. Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?


  • 0

#60 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 19 сентября 2008 - 12:28

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

Наверное, можно придумать такую ситуацию - но я не сумел. Пример подскажете?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных