Как стать автором
Обновить
116.36
AGIMA
Крупнейший интегратор digital-решений

Чек-лист: как управлять качеством разработки на проекте

Время на прочтение3 мин
Количество просмотров6.8K

Всем привет!

Меня зовут Иван Антипин, я занимаю должность технического директора в компании AGIMA. 18 и 19 августа на конференции AGIMA Partners’ Weekend я рассказывал, как мы в AGIMA управляем сроками и качеством в разработке. Я не могу поделиться своим докладом с конференции, но очень хочу поделиться чек-листом, который мы используем на каждом проекте. 

Составляйте план-график производства с рисками

1. Всегда закладывайте время на тестирование — обычно 20–30% от оценки разработки.​

2. Всегда закладывайте время на отладку после тестирования​ — обычно 20–30% от оценки разработки.​

3. Делайте это прозрачно для менеджера, чтобы не дублировать риски и сроки.

Собирайте метрики качества и принимайте решение на основе этих данных.

Базовые метрики качества

Название метрики

Суть метрики

Цель сбора

Способ сбора

Целевое значение

Комментарий

Кол-во заведенных дефектов за отчетный период в разрезе статуса/критичности/компонента

Сколько дефектов завела команда за отчетный период

Косвенный показатель эффективности

В Jira делаем выборку по заведенным багам за отчетный период

n/a

Полезная метрика для анализа дефектов, определения проблемных зон, критичности и статуса дефектов

Кол-во багов в час разработки

Сколько дефектов приходится на задачу/час разработки

Показатель эффективности разработки

Кол-во дефектов в задачах/Время оценки задач на разработку

n/a

Здесь необходимо выбрать одну из 2-х метрик. Для фиксовых проектов подходит кол-во багов в час разработки, для остальных — плотность дефектов на задачу.

Плотность дефектов на задачу

Кол-во заведенных дефектов в задачах/Кол-во протестированных задач

% пропущенных дефектов в прод и найденных командой тестеров

Сколько дефектов мы пропускаем на прод и по какой причине

Понять причины пропуска дефектов в прод

Дефектов выявлено нами на проде/Общее кол-во дефектов за отчетный период

n/a

Показатель должен быть не более 5%

Для сбора метрики необходимо добавить в Jira для дефектов атрибут Prodaction bug со значениями None, Yes. Атрибут обязательный и проставляется после создания дефекта.

Кол-во дефектов, найденных на бизнес-тесте в разрезе критичности

Сколько дефектов мы пропускаем на бизнес-тест и по какой причине

Понять причины пропуска дефектов в бизнес-тест

Дефектов выявлено нами или клиентом на бизнес-тесте

n/a

Показатель должен стремиться к 0

Для сбора метрики необходимо добавить в Jira для дефектов атрибут Business test bug со значениями None, Yes. Атрибут обязательный и проставляется после закрытия дефекта.

% ошибок недостатка требований

Сколько дефектов с бизнес-теста пропущены по причине недостатка требований

Сколько дефектов с бизнес-теста пропущены по причине недостатка требований

Дефектов на бизнес-тесте с ошибкой требований/Всего заведено дефектов с бизнес-теста

n/a

Некоторые дефекты от клиента могут появляться из-за отсутствия требований на нашей стороне, часто такие дефекты можно рассматривать как доработки/хотелки. Для сбора метрики необходимо добавить в Jira для дефектов атрибут Lack of requirements со значениями None, Yes. Атрибут обязательный и проставляется после закрытия дефекта.

% отмененных дефектов

Сколько дефектов заведено командой и отменено с резолюцией/статусом Cancelled

Определение количества реджектов

Дефектов отменено/Всего заведено дефектов за отчетный период

n/a

Допустимое значение — 5%

% багов с регресса (коэффициент регрессии)

Сколько дефектов мы пропускаем на регресс и почему

Определить причины пропуска дефектов на регресс

Дефектов выявлено при регрессе/Всего заведено дефектов за отчетный период

n/a

Оптимальное значение — 5%

Для сбора метрики необходимо добавить в Jira для дефектов атрибут Regression bug со значениями No, Yes. Атрибут обязательный и проставляется после создания дефекта.

% переоткрытых дефектов

Сколько раз в среднем переоткрывается дефект

Определить качество фикса дефектов

Кол-во переоткрытых/Всего заведено дефектов

n/a

Для сбора метрики необходимо добавить в Jira для дефектов атрибут Reopened со значениями 1, 2, 3, 4, 5. Атрибут обязательный и проставляется после перевода дефекта в доработку. При каждом переводе дефекта на дебаг значение атрибута увеличивается на +1.

% исправленных дефектов

Сколько дефектов команда разработки успевает исправить и сколько команда тестирования может проверить

Понять темп работы команды в части фикса и ретеста дефектов

Кол-во исправленных дефектов/Кол-во заведенных дефектов за отчетный период

n/a

Минимальное значение — 90%

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

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

А вот каким был AGIMA Partners' Weekend 2022 — мы не устаем о нем вспоминать.

Кстати, уже можно зарегистрироваться на конференцию в 2023 году, вот тут ссылка.

Теги:
Хабы:
Всего голосов 26: ↑21 и ↓5+16
Комментарии9

Публикации

Информация

Сайт
www.agima.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Кристина Ляпцева