Как мы используем систему учёта дефектов для ведения product backlog’а

Как мы используем систему учёта дефектов для ведения product backlog’а

Есть ещё одна непростая задача. С одной стороны, Excel очень хороший формат для product backlog’а. С другой стороны, вам всё равно нужна система учёта дефектов, и Excel здесь явно не тянет. Мы используем Jira.

Итак, как мы переносим задачи из Jira в планирование спринта? Не можем же мы просто их проигнорировать и сосредоточиться только лишь на историях.

Мы пробовали следующие подходы:

1. Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет).

2. Product owner создаёт истории, соответствующие задачам из Jira. Например, «Исправить самые критические ошибки отчётности в админке, Jira-124, Jira-126, и Jira-180».

3. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50%), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в Jira.

4. Заносим product backlog в Jira (просто переносим из Excelе). Считаем баги обычными историями.

Мы ещё не определились, какой подход для нас самый лучший; в действительности он может отличаться в разных командах и меняться от спринта к спринту. Я больше склоняюсь к первому подходу: он прост и понятен.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Снижение плотности дефектов

Из книги автора

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


Счетчики дефектов

Из книги автора

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


Программы для ведения статистики подключения

Из книги автора

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


Программы для ведения статистики подключения

Из книги автора

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


4. Группы ключевых процессов для уровня 5: оптимизирующий уровень Предотвращение дефектов

Из книги автора

4. Группы ключевых процессов для уровня 5: оптимизирующий уровень Предотвращение дефектов Цель 1. Планирование работ по предотвращению дефектов.Цель 2. Поиск и выявление общих причин возникновения дефектов.Цель 3. Определение приоритетов для общих причин возникновения


Скалярное произведение (Inner product)

Из книги автора

Скалярное произведение (Inner product) template ‹class InputIterator1, class InputIterator2, class T›T inner_product(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2, T init);template ‹class InputIterator1, class InputIterator2, class T, class BinaryOperation1, class BinaryOperation2›T inner_product(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2, T init, BinaryOperation1 binary_op1, BinaryOperation2 binary_op2);inner_product


17.11. Устранение JPEG-дефектов

Из книги автора

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


Как мы ориентируем product backlog на бизнес

Из книги автора

Как мы ориентируем product backlog на бизнес Если product owner - технарь, то он вполне может добавить историю вроде «Добавить индексы в таблицу Events». Зачем ему это нужно? Да потому, что реальной целью этой истории, скорее всего, будет «ускорение поиска событий в панели управления».И


Подход третий: Несколько product owner’ов - несколько backlog’ов

Из книги автора

Подход третий: Несколько product owner’ов - несколько backlog’ов Похоже на второй вариант, по отдельному product backlog на команду, только ещё и с отдельным product owner’ом на каждую команду. Мы не пробовали так делать, и, скорее всего, пробовать не будем.Если два product backlog’а касаются одного и