8D (Eight Disciplines Problem Solving) — это мощный инструмент решения проблем, разработанный компанией Ford Motors, для его использования инженерами по качеству и не только. Его основная задача- это выявить, исправить и устранить корневые причины возникающих проблем с помощью проведения корректировочных действий. Сейчас метод 8D используется не только в автомобильной промышленности, но и во всех сферах, где внедрена СМК (система менеджмента качества). Мы используем метод 8D для анализа проблем, возникающий в процессе разработки ПО. Давайте рассмотрим на реальном примере использование этой методики для проблемы: «Тестирование отстает от разработки».
ВАЖНО
И главное, чтобы добиться значимого результата, а не тратить попусту время необходима заинтересованность и участие менеджеров всех уровней на всех этапах и осознание того, что мы не ищем виновных, а выявляем проблему в процессе.
8D. Этап 1. Формирование команды (Team Formation)
Необходимо сформировать команду, члены которой обладают всеми необходимыми знаниями по продукту и процессу, а также обладают полномочиями принятия решений и проведения требуемых мероприятий.
В нашем случае, это члены команды, участвующие в разработке продукта: ведущие разработчики, аналитик, тестировщики, менеджеры.
8D. Этап 2. Описание проблемы (Problem description)
Для детального описание проблемы существует множество различных подходов. Это та информация, которую можно получить на первом этапе без проведения какого-либо анализа или расследования проблемы. Одним из самых распространенных методов является 5W2H. Зачастую для прояснения проблемы не обязательно отвечать на все вопросы.
- WHO. Кто проблему обнаружил? Команда тестирования.
- WHAT. Что это за проблема? В текущей итерации больше половины ЮС (User Story) переданы на тест, но тестирование по ним не было начато в течении установленного времени (непосредственно выполнение кейсов, согласно разработанному плану).
- WHEN. Когда проблема была обнаружена? Проблема обнаружена в начале последней недели 2-х недельной итерации.
- WHERE. Где проблема была обнаружена? На одном из веб-продуктов.
- WHY. Почему это является проблемой? Это является проблемой, так как приводит к задержке релиза продукта и соответственно заказчик не получает требуемый функционал в срок.
- HOW. Как проблема была обнаружена? При анализе бэклога спринта и состояния канбан- доски.
- HOW MANY. На скольких продуктах возникла такая проблема? В данном случае данный пунк пуст, так как заказчик получает ПО единой сборкой.
8D. Этап 3. Сдерживающие мероприятия (Interim Containment Action)
Необходимо провести сдерживающие мероприятия, которые не дадут настоящей проблеме распространиться. В нашем случае: сорвать срок релиза итерации. В частном случае: проведенные мероприятия могут проблему устранить. Таким образом, этот шаг подразумевает под собой «Тушение пожаров».
Что было предпринято (Тестируют ВСЕ!):
- Разработчики и аналитик присоединились к тестированию итерации согласно разработанным тест-кейсам и чек-листам для каждой ЮС.
- Были привлечены тестировщики с других проектов
К сожалению, в 80% случаев этот шаг является последним, и корневая причина проблемы так и не будет найдена. Если эта же проблема возникнет в следующий раз и будут использованы аналогичные сдерживающие мероприятия, то это может привести к более серьезным проблемам: так как вся команда, участвующая в создании продукта, и тестировщики с других проектов привлекаются к тестированию, то это может привести к снижению темпов работы подразделения в целом и сорвать сроки релиза не только текущего продукта, но других, из которых были привлечены сотрудники. Поэтому помним, что проводимые на данном шаге мероприятия являются временными, выполнение которых актуально только до момента выявления корневой причины.
8D. Этап 4. Анализ корневой причины (ROOT Cause Analysis)
Для анализа корневых причин в общем случае мы используем совместно 2 метода: Диаграмму Исикавы (Fish Bone) и «5 Почему». В данному случае мы ограничились только последним. Проводим поиск корневой причины для возможной проблемы: в текущей итерации тестирование стало сильно отставать от разработки.
5 Почему (5WHY)
Цель этого шага: выявить корневую причину возникшей проблемы, путем повторения вопросов «Почему», ответ на первое почему формирует следующий вопрос почему и т.д. Для поиска корневой причины часто не обязательно отвечать на все 5 вопросов, иногда их может быть и меньше, а иногда и больше. Если анализ не привел к видимому результату, то предварительно следует использовать диаграмму Исикавы для поиска всех возможных корневой причины. Если же все усилия были напрасны, стоит изучить проблему под другим углом и попытаться найти другие причины, которые ранее не были учтены. Кроме того, можно привлечь стороннего человека, который не состоит в 8D-команде, т.е. использовать «взгляд со стороны».
Почему 1: Почему в текущей итерации тестирование стало сильно отставать от разработки?
Ответ 1: Нехватка времени у тестировщиков.
Почему 2: Почему возникла нехватка времени у тестировщиков?
Ответ 2: Потому что на проекте остался один тестировщик.
Почему 3: Почему один тестировщик перестал успевать тестировать ЮС?
Ответ 3: Так как кроме непосредственно тестирования другие активности занимают значительную часть рабочего времени.
Почему 3: Почему другие активности, не связанные с тестированием такие трудозатратные?
Ответ 4: Потому что очень много времени тратится на обработку обращений от тех. поддержки (Тех. Под.).
Почему 5: Почему много времени тратим на обработку обращений от Тех. Под.?
Ответ 5: Потому что до конца не стандартизирован процесс работы Тех. Под. с обращениями по нашему проекту и решили, что предоставленной документации будет достаточно.
Поздравляем! Мы нашли адекватную корневую причину: Тех. Под. не хватает документации для работы по проекту.
8D. Этап 5. Корректировочные действия (Corrective Action)
Формулируем список корректирующих действий, направленный на устранение выявленной корневой причины. Все предложенные корректирующие действия должны быть предварительно проанализированы, в том числе и с учетом риска появления новых проблем. Корректировочные действия в нашем случае:
- Проанализировать все поступившие обращения от Тех. Под.
- Проанализировать все баги, назначенные на команду тестирования тех. поддержкой.
- Выявить области продукта, с максимальным процентом обращений.
- Разработать инструкции /Карточки для Тех. Под. по работе с типичными сценариями, в случае возникновения ошибки- детального шаблона ее описания.
8D. Этап 6. Валидация корректировочных действий (Validate Corrective Actions)
На данном шаге необходимо удостовериться: внедрены ли корректировочные действия на текущем процессе/продукте и в их эффективности. При 100% эффективности эти корректирующие действия заменяют сдерживающие мероприятия этапа 3.
- Провести сравнение трудозатрат тестировщиков до и после разработки карточек для Тех. Под.
- Провести доработку карточек при необходимости.
8D. Этап 7. Определение и внедрение превентивных мер (Identify & Implement Preventive Action)
Этот шаг относится как к текущему проекту, так и другим. Добавляем в планируемые активности на другие проекты «Создание карточек для Тех. Под.».
- Тех. Под. работает по разработанным карточкам.
- В случае, если обращение, пришедшее от Тех. Под. не соответствует шаблону- задача возвращается на доработку.
8D. Этап 8. Признание вклада команды и ее участников (Team & Individual Recognition)
- Вся команда отлично поработала над решением общей проблемы.
- Вся команда с пониманием отнеслась к сдерживающим мероприятиям.
- Диалог был конструктивен.
- Проведенные мероприятия позволили исключить риск возникновение аналогичной проблемы в будущем на текущем и других проектах.
Используя 8D мы получаем:
- Более сплоченную команду, вовлеченную в процесс.
- Повышение качества процесса и выпускаемого продукта.
- Повышение командной ответственности за качество продукта.
- Повышение квалификации команды.
- Предотвращение возникновения проблем в будущем.
MindMap
Ментальная карта доступна тут