Всем привет!
Меня зовут Иван Антипин, я занимаю должность технического директора в компании 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 году, вот тут ссылка.