Завершая серию статей о стоимости качества подходим к практической части, а именно, как это посчитать? Для того, чтобы были конкретные данные, на основании которых можно было бы принимать какие-либо управленческие решения. Напомню о предыдущих статьях и для начала рекомендую их прочесть: «Стоимость качества. Часть 1 – Что это такое?», «Стоимость качества. Часть 2.1 – Зачем это надо?», «Стоимость качества. Часть 2.2 – Кому это надо?».
Так как сбор и интерпретация данных относится к дисциплине метрик, то здесь стоит обратить внимание на классический треугольник успешности и полезности измерений:
- Люди – должны быть обучены данной дисциплине, по крайней мере понимать зачем все это. И, естественно, должны иметь возможность (санкционированное время, желание, инструментарий и т.п.)
- Процессы – должны быть. Все рабочие процессы, например: как мы готовим тестовую документацию и тестируем, жизненный цикл дефекта, жизненный цикл задач и т.п. должны быть в том или ином виде описаны-оговорены и донесены до исполнителей
- Инструментарий – собственно те технические средства, которые помогают людям делать их процессы – тайм трекеры, баг трекеры, таск трекеры и т.п. Именно они, при корректной интеграции в процессы работы и при соответствующей настройке, позволяют и собирать данные, и обрабатывать, и презентовать.
В этой статье поговорим именно об инструментарии.
Для начала обратимся к такой дисциплине как Scope Management – управление объемом работ по проекту. В первую очередь это правило 100%, т.е. список работ по проекту должен отражать абсолютно ВСЕ работы и им должно быть место в расписании работ, плановые и фактические трудозатраты по ним должны быть оценены и отрапортованы. ВСЕ – в т.ч. инспекции документов, устранение дефектов, совещания, и даже участие в интервью по набору персонала на проект…
Хорошо помогают шаблоны списков работ (WBS – work breakdown structure).
Ключевым моментом является такая декомпозиция списка работ, где были бы выделены отдельные задачи (берем для примера разработчика), и, соответственно временнАя отчетность на:
- Инспекцию спецификаций (COQ)
- Разработку архитектуры
- Юнит тесты (COQ)
- Кодирование
- Инспекцию кода (COQ)
- Устранение дефектов после тестирования (COPQ)
- Разворачивание продукта в тестовом окружении
- Устранение дефектов по гарантийным обязательствам (COPQ)
- Устранение дефектов после инспекции кода (COPQ)
- И т.п.
В скобках указаны интересующие нас категории – COQ, COPQ. На самом деле, отнесение некоторых задач в какую-то категорию – это ваше решение, например, юнит тесты можно отнести и в разработку. Общие же рекомендации что есть что приведены в первой статье «Стоимость качества. Часть 1 – Что это такое?».
Как далеко идти с декомпозицией – решать вам в зависимости от того, что нужно и что вообще имеет смысл. Например, устранение дефектов после тестирования можно отнести как в общую для всех разработчиков задачу «Устранение дефектов», так и разделять, например, по модулям – «Устранение дефектов по модулю №1» и т.д.
Таким образом, если у вас есть такие компоненты:
- Корректная декомпозиция работ
- Таск-тайм трекер, который позволяет отразить и декомпозицию, и отчетность о затраченном времени
- Обучающие меры для сотрудников – как пользоваться таск-тайм трекером
То сбор данных по соответствующим категориям у вас настроен, и что немаловажно, интегрирован в рабочие процессы. И вы легко можете получать информацию о стоимости качества.
Конечно же, возникают некоторые тонкости в организации и процессов работы, и инструментария. Давайте посмотрим на примеры.
Что такое дефект и как его учитывать? Обычно, если тестировщик находит дефект, то он (дефект) попадает в систему управления дефектами как отдельная запись с описанием, серьезностью и другими параметрами. Но ведь дефекты, найденные, например, на инспекции кода, по существу, ничем не отличаются от дефектов, найденных тестировщиком. И они обычно никак не учитываются, в лучшем случае фиксируется время, потраченное на инспекцию кода. Но возникает резонный вопрос – а зачем это надо вообще? Если уж вы решили определять стоимость качества, то нужно, как минимум фиксировать время на инспекцию кода и время на исправление дефектов, найденных при инспекции. Если вам это не нужно – то не делайте, это будет пустая трата времени и раздражающий фактор для сотрудников. Если вы хотите таки фиксировать не только время на инспекцию, то можно осторожно попробовать использовать систему управления дефектами – например на каждый факт инспекции внести одну запись, к которой приложить список дефектов в коде. По крайней мере необходимость исправить код не потеряется и у вас будут данные о результатах инспекции.
Интенсивная работа с требованиями. А что если требования обсуждаются настолько интерактивно между заказчиком, аналитиком, разработчиками, тестировщиками, что четкая разница между формализацией требований, их инспекцией (обсуждениями) и устранением дефектов (рекомендации, выданные при обсуждениях) не видна? Или же не имеет смысла это разделять. Тут, наверное, лучший вариант – без фанатизма, просто отнести такой вариант работы в задачу «Разработка требований», т.е. к COQ или COPQ не относить вообще. Если же такого интерактива нет, а есть четкое разделение на формализацию, инспекции, и исправление дефектов, и, внимание!, вам действительно надо выделять COQ и COPQ, то предлагаю такой же подход, как и в предыдущем примере – с использованием системы управления дефектами.
Завершая цикл хочу сказать, что серьезно «заводиться» со стоимостью качества и метриками стоит лишь в том случае, если у вас есть:
- Великая цель – зачем это делать и кому от этого будет лучше
- Подготовка по теме – как это работает
- Здравый смысл – в разумной реализации Великой цели
Надеюсь, что это было вам полезно.
Оригинал статьи здесь.
