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

[Alfa]

Постараюсь ответить на поставленные вопросы, пока не стали обсуждать "кто круче Jira" и "сколько critical багов должно быть"

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

Поля "важность" и "приоритет" -- два атрибута бага (дефекта) несущие определенную разную информацию о нем, а именно степень влияния дефекта на возможность использовать ПО и приоритет его исправления.

Как определить какое из этих полей все же надо использовать?

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

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

Достаточно одно из них, но какое?

Зависит от того какая информация о дефекте вам нужна. См. выше.

[SALar]

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

В частности, одним из разработчиков TracStudio был предложен совершенно другой подход:
1) на северити и приорити забить совсем и выкинуть их из формы
2) управлять багами нужно на основании атрибута имеющего два состояния "сделать в этом релизе" / "не делать в этом релизе"
Для очень многих проектов этот подход наилучший. Но это не значит, что он подойдет лично вам.


PS. Jira не рулит. Согласен с Алексеем.

PSS. И добавлю свои пять копеек: "А полноценный толстый клиент у нее есть?" Если нет - то вообще говорить не о чем.

[Case]

У мпеня странное ощущение потери связи с реальностью. Остаётся понять у кого:у меня или у всех вокруг :)

Да, можно увешать баг-таск-риквест любым количеством атрибутов. Коллеги, пересмотрите то что вы пишите: "надо и то и то и то"... "но с чем работать решать вам"... "а потом вдруг у вас будет N багов!" - какие-то странные аргументы, как будто мы с вами не тестированием занимаемся, а теорию непознанного строим. Какие-то теории "а что будет если...", "возможно когда-то потом нам будет нужно, а пока пользуйтесь чем угодно, но заполняйте и то и то...". Да зачем? :)

Это просто баги. В них нет никакой самоценности. Их может быть много или мало. Идём от применения сущности баг. Любой баг - это таск на исправление, если его ассайнер в девелопменте и таск на ретест, если его ассайнер в тестировании. Для того, чтобы понимать в какой последовательности чинить или ретестить - надо иметь приоритет. На одном девелопере не бывает 100 багов, на одном тестере не бывает 100 фиксов. Если бывает - то это чинится не на уровне приоритетов в багтрекере :)

[Case]

PSS. И добавлю свои пять копеек: "А полноценный толстый клиент у нее есть?" Если нет - то вообще говорить не о чем.

А зачем? Браузер по умолчанию есть на любой машине и даже на многих КПК и телефонах. Отсюда вполне понятное требование к любой системе это как раз наличие веб-интерфейса. Но требовать десктоп-интерфейс?.. Зачем?

Я уже молчу что это требование непонятное ещё и с точки зрения стоимости разработки: надо все-все-все операционки и платформы саппортить, иначе следующим вопросом будет "есть ли десктоп-клиент под Мак" :)

[Boltick]

PSS. И добавлю свои пять копеек: "А полноценный толстый клиент у нее есть?" Если нет - то вообще говорить не о чем.

Скажу честно, где-то год назад видел вот ссылка...

Но вопрос не в джире, а в приоритетах и северитях... :)

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

[rlabs]

Severity и Priority - это две отдельные активности.

Это вообще-то не активности, а характеристики issue. А что и как вы на основе этих характеристик настроите зависит уже от вас.

Поправлюсь: установка Severity и Priority - две разные активности. Во всяком случае в тех процессах, в которых я работал. Да, последний параметр может зависеть от первого, и называться по-другому.

[Case]

rlabs, мне тоже приходилось, я ж не спорю что так не бывает - именно что бывает и не редко. Вопрос только насколько он нужен? А вот торговли вокруг "мажор+визибилити2" или "минор+визибилити8"?! видеть приходилось. Аналогично и про "северити" и про "импакты" :)

[Alfa]

Да зачем? :)
...
Идём от применения сущности баг.

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

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

В целом не всегда так. Можно иметь срок (milestone/веха), к которому некое множество набор багов должно быть исправлено, а остальные потом. При этом порядок может быть совершенно не важен. Важно, что к релизу такому-то надо сделать.
Например у нас поле приоритет есть, но оно фактически не используется, как для багов так и для задач. Почти во всех случаях у него одно и тоже значение, но есть milestone, который указывает к какому сроку надо сделать.
Т.е. практически так, как описал SALar. Правда я думаю это придумали еще до trackstudio, например такой подход используется в XP и Scrum.

[Alfa]

А вот торговли вокруг "мажор+визибилити2" или "минор+визибилити8"?! видеть приходилось. Аналогично и про "северити" и про "импакты" :)

Может это тоже лечить не убиранием поля в баг трекере?

Если бывает - то это чинится не на уровне приоритетов в багтрекере :)

[rlabs]

(столкнулся с юзабилити-проблемой веб-форм, извините :-)

[rlabs]

rlabs, мне тоже приходилось, я ж не спорю что так не бывает - именно что бывает и не редко. Вопрос только насколько он нужен? А вот торговли вокруг "мажор+визибилити2" или "минор+визибилити8"?! видеть приходилось. Аналогично и про "северити" и про "импакты" :)

Хорошо. Давайте разберемся.
Берем типового тестировщика. Его задача - узнать, как себя ведет продукт. Он в большинстве случаев взаимодействует с ним "снаружи", то есть без особых технических подробностей. Исходя из знания продукта и особенностей его применения, он оценивает важность обнаруженной проблемы. По большому счету, можно ограничиться тремя степенями: а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно), б) функциональная проблема (участок функционала работает неправильно), в) шоустопер (кусок функциональности отвалился).

Теперь проследим путь багрепорта. Мне никогда не приходилось встречаться с продуктами класса "выстрелил и забыл" (один релиз) или "тяни кота за хвост" (веб-приложение, регулярно обновляемое без всяких планов, просто по факту появления нового билда). Так что, за типовой пример принимаем продукт с несколькими релизами. Цель релиза всегда установлена. Я достаточно просто делю релизы на maintenance (подправить немножко продукт, выпустить сервис-пак) и feature (новые возможности, с большой вероятностью будет продаваться отдельно от предыдущего).

Предположим, у нас maintenance релиз. Цель - сделать продукт немножко лучше, и не сделать его хуже. И вот у нас есть, гм, ну, скажем, "менеджер релиза" (здесь реально пересекаются роли configuration manager, release manager, product owner). Я сейчас буду цепляться за упомянутую мной выше схему трех параметров, но, в общем, она хорошо применима. Итак, у нас есть параметры: важность (severity), частота повторения (насколько часто на эту проблему будет наталкиваться "типовой" пользователь), и риск внесения новых проблем. Ответственное лицо смотрит на баг-репорт с важностью "функциональная проблема". Важности достаточно высокая. Анализ на regression (извините, не знаю, как нормально перевести) показывает, что проблема существовала всегда (просто предыдущие раунды тестирования её не выявили). Быстрый анализ записей саппорта показывает, что никто из пользователей за все это время не столкнулся с проблемой. Анализ кода показывает, что для исправления ошибки нужно переписать некоторую подсистему целиком, и это инвалидирует, допустим, 40% функциональности продукта. Какая в этом случае будет оценка приоритетности? Да никакая, можно выставить статус "исправим в следующей пятилетке". Получаем баг-репорт с высокой важностью и низким приоритетом.

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

[barancev]

Знал же, что нельзя влазить в эту тему :)

Не рулит. Именно потому, что подаёт себя как "средство управления проектами", мешая всё в какой-то безумный компот -- баги, таски, северити, приоритеты, всё едино.

Так в этом весь компот и вся прелесть, Леш.

Может быть, может быть... Я наверное просто не догоняю :)

Баг-репорт нисколько не таск. Это прямо из названия видно: баг-репорт -- это рапорт, донос, констатация наличия проблемы. Для устранения проблемы может потребоваться серия изменений, которые должны сделать разные люди в разных местах, так что придётся сделать несколько тасков. Северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска.

А если идти всё-таки не от названия, а от понятия таск в проектном управлении? :)

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

Давай сначала про таск.
По сути (да и по названию :)) таск -- это задание, которое менеджер даёт одному из исполнителей. Когда он его выполнил -- таск закрывается. Дискретность тасков может быть различной. В "аджильном" стиле таски получаются обычно типа "реализовать фичу X", то есть сделать всё -- спроектировать, написать код, протестировать, задокументировать, включить в релиз-нотес упоминание. В более жёстких процессах, когда для реализации какой-то функциональности задействуется много людей из разных подразделений (разработчики, тестировщики, текрайтеры, админы, "сетевики", "безопасники", поддержка, ...), вместо таска "реализовать фичу X" получится целая серия тасков, которые могут быть связаны зависимостями (разработчику -- писать код, тестировщику -- готовить стенд, текрайтеру -- писать, админу -- заказывать доп. оборудование, сетевикам -- ковырять новую дырку в файрволах, безопасникам -- обеспечить защиту этой дырки, ...).

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

Резюмируя, можно отметить, что для "аджильного" стиля трекинговую систему действительно можно использовать как средство планирования, особенно если туда вносить не только дефекты, но и вообще любые запросы на изменение. Для "неаджильного" стиля трекинговая система уже сильно ограничивает свободу действий, потому что линейный неветвящийся жизненный цикл её артефактов плохо соотносится с реальной жизнью. Ситуацию ещё может как-то спасти использование трекеров, которые поддерживают иерархию тасков (читай -- TrackStudio), но планировать там всё равно неудобно, MS Project рулит.

[LeshaL]

Может и не повиснут, но вот пример из жизни... Проект конечно не лучший с позиции качества, но он был на самом деле:
на проекте - 70 разработчиков, 15 тестеров, длительность всего проект - 2 года. В первом релизе, расчитанном на пол года, выходило порядка 250 ЮзКейсов. Для прохождения было более 2000 тест кейсов. За один прогон всех тест кейсов открывалось примерно 200-300 багов, девелоперы выдавали еженедельные билды с фиксом порядка 100-150 багов, при условии, что не все были задействованы на багфиксы (многие имплементили новые фичи). Получалось, что на каждом разработчике постоянно висело порядка 20-30 багов. Многим везло и у них накапливалось больше 30-ти :)
Согласен, что все это звучит жутко, но такое было... Конечно в итоге, когда имплементация нового заканчивалась, то процесс фикса багов шел быстрее открытия новых... НО всеже, в этой ситуации очень сложно пользоваться одним лишь приоритетом, или я что-то не так понял?

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

[LeshaL]

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

В принципе, согласен, что если есть куча багов с высокой важностью, это показатель, что что-то идет не так. Наличие же кучи багов с высоким приоритетом вовсе не означает, что в продукте все плохо. Вполне возможно, что есть критерий по кол-ву Р1,Р2 багов = 0 к релизу (у нас так заведенено, например). В какой-то момент (к примеру после feature freeze) спецальные люди просматривают трэкер и поднимают приоритет тем реквестам, которые надо до релиза починить. На основе чего они выставляют приоритет - зависит от ситуации.
Что касается ситуации когда критический баг имеет средненький приоритет, то они встречаются. Дурацкий пример. Представьте, что вы разрабатывается очередную версию продукта, и добавляете в нее супер-нужную функциональность, которую очень ждут богатые клиенты. При этом вы поддерживаете работоспособнось продукта на Win95 (есть один старый клиент, не заинтересованный в новой версии). И при тестировании новой супер-нужной функциональности оказывается, что она не работает на Win95, продукт крашится. Дефект, несомненно должен иметь severity=critical, т.к. severity вещь объективная - продукт крашится, воркэраундов нету - однозначно критический баг. Но с точки зрения текущего релиза и бизнес-нужд, починка такого бага может стоить очень дорого и по трудозатратам и по времени, а выгоды никакой. Приоритет будет у дефекта маленький, специально для того, чтобы его не чинить в этом релизе (а может быть вообще никогда). Но закрыть такой баг нельзя - т.к. по хорошему его надо описать как known issue, чтобы те кто еще до сих пор пользуется Win95, не раскатывали губу на новую супер-нужную функциональность.

[LeshaL]

Severity и Priority - это две отдельные активности.

Это вообще-то не активности, а характеристики issue. А что и как вы на основе этих характеристик настроите зависит уже от вас.

Поправлюсь: установка Severity и Priority - две разные активности. Во всяком случае в тех процессах, в которых я работал. Да, последний параметр может зависеть от первого, и называться по-другому.

+ 1. Так же работал в условиях, когда severity оценивается человеком ниписавшим реквест. Потом может меняться любым участником процесса, с объяснением причин понижения\повышения важности. Изменять значение поля "приоритет" мог только сержантско-лейтенантский состав: group, team лидеры, специальные evaluator-ы(не знаю как перевести) и тд. Рядовые девелоперы и тестеры менять значение поля приоритет не могли. Но приоритет регулировал порядок в котором надо фиксить\верифицировать дефекты. Далее в расчет берется важность. Т.о. получается такой всем понятный и простой порядок для совершения действий:
1. P1
1.1. Critical
1.2. High
1.3. Medium
1.4. Low
2. P2
1.1. Critical
1.2. High
1.3. Medium
1.4. Low
и так далее к более низким приоритетам.

[LeshaL]

А вот торговли вокруг "мажор+визибилити2" или "минор+визибилити8"?! видеть приходилось. Аналогично и про "северити" и про "импакты" :)

Может это тоже лечить не убиранием поля в баг трекере?

Да-да, лечить надо в другом месте. Позвольте вспомнить Булгакова "... разруха не в клозетах, а в головах."

[LeshaL]

PSS. И добавлю свои пять копеек: "А полноценный толстый клиент у нее есть?" Если нет - то вообще говорить не о чем.

Скажу честно, где-то год назад видел вот ссылка...

Но вопрос не в джире, а в приоритетах и северитях... :)

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

По мне, так очевидно, что надо иметь два этих поля.
Вот тут они очень хорошо расписаны https://bugzilla.moz...s.html#priority
По идее, если дефект-трэкер торчит наружу, то поле severity, должно быть показано и может меняться, т.к. это величина объективная и привязана к работоспособности продукта. Приоритет же наружу показывать смысла особого нет, да и может быть вредно даже. Это внутренний процесс работы команды, определяющий порядок в котором надо принимать во внимание записи в трэкере.
При этом чем больше команда, тем нужнее разделение на два поля. Я уже выше писал, что они совместно определяюют простой и очевидный порядок. Как вычислить приоритет должна болеть голова у специальных людем, типа qa\test\developer лидеров и РМ-ов. Пусть они составляют сложные запросы и определяют насколько важно исправлять тот или иной недочет или добавлять какие-то фичи.

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

[Case]

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

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

Получаем баг-репорт с высокой важностью и низким приоритетом.

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

Есть отдельная объективная оценка проблемы, есть оценка приоритетности в контексте текущих работ.

Почему это не одно и тоже?

[Case]

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

25 человек в команде. Только приоритет.

[Case]

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

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

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