Всем привет!

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


  1. gleb_l
    19.09.2022 17:39
    -1

    Ну почему НА проекте, а не В?


  1. laatoo
    19.09.2022 18:05
    +3

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


    1. ruomserg
      20.09.2022 07:50

      В статье же нигде не написано, что нужно возить разработчиков и тестеров мордой по столу если не выполняются целевые проценты, или премии лишать? Написано — анализировать и принимать управленческие решения. Для анализа и управления, нормальные метрики и нормальные (если только немного волюнтаристские — почему 90%, а не 93.5?) управленческие цели.


  1. SigSauer
    20.09.2022 22:30

    Как управлять качеством разработки - закладывайте 30% от оценки разработки на тестирование и еще 30% резерв на отладку, и собирайте метрики.
    А это точно управление качеством? )
    В PMBoK например аж 7 основных инструментов контроля качества. Используете?