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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Всем привет!

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

Источник: https://habr.com/ru/company/agima/blog/688286/


Интересные статьи

Интересные статьи

Я, как и многие Flutter разработчики, мигрировал из веб-разработки. По инерции хотелось использовать те же подходы к вёрстке и управлению состояниями. Если во втором случае можно было взять MobX или B...
Увольнение сотрудников дорого обходится компаниям. Стоимость замены ушедшего сотрудника зачастую очень высока. Исследования Центра Американского прогресса говорят, что компании обычно тратят около одн...
По данным IDC, в 2020 году объем российского ИТ-рынка составил 1,83 трлн рублей, что на 14% больше того же показателя годом ранее. И хотя в рублях это довольно большая су...
VUE.JS - это javascript фрэймворк, с версии 18.5 его добавили в ядро битрикса, поэтому можно его использовать из коробки.
Основанная в 1998 году компания «Битрикс» заявила о себе в 2001 году, запустив первый в России интернет-магазин программного обеспечения Softkey.ru.