Всем привет!
Меня зовут Иван Антипин, я занимаю должность технического директора в компании 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 году, вот тут ссылка.
Комментарии (4)
laatoo
19.09.2022 18:05+3Кол-во заведенных дефектов и количество багов в час - это очень смешные метрики, конечно. В лучшем случае, они позволяют управлять заводимостью и не вредят качеству
ruomserg
20.09.2022 07:50В статье же нигде не написано, что нужно возить разработчиков и тестеров мордой по столу если не выполняются целевые проценты, или премии лишать? Написано — анализировать и принимать управленческие решения. Для анализа и управления, нормальные метрики и нормальные (если только немного волюнтаристские — почему 90%, а не 93.5?) управленческие цели.
SigSauer
20.09.2022 22:30Как управлять качеством разработки - закладывайте 30% от оценки разработки на тестирование и еще 30% резерв на отладку, и собирайте метрики.
А это точно управление качеством? )
В PMBoK например аж 7 основных инструментов контроля качества. Используете?
gleb_l
Ну почему НА проекте, а не В?