Цель root-cause-анализа — оптимизировать процесс разработки. Понять, почему произошла проблема, что нужно поменять, чтобы этой проблемы не было.

Рассмотрим ситуацию. В приложении обнаружена ошибка. Действия ненадежного программиста примитивны: изучить отчет об ошибке, исправить путем ввода инструкций, поставить альфа-версию на тестирование.

Процесс исправления ошибки надежным программистом более полон. На основании отчета об ошибке, надежный программист производит анализ причин.

Проблема

Указать ссылку на тикет в Джире.

Анализируемая версия

Указать идентификатор комита в репозитории, путь к репозиторию, путь к коммиту.

Причины проблемы

Описать, в чем была причина проблемы. Например:

Исключение происходило из-за того, что в классе User в качестве идентификатора использовался тип int, который на 32-битной платформе слишком короткий. А с сервера приходили идентификаторы, которые помещаются только в long.

Описана ли подобная ситуация в стандарте кода?

Описана ли подобная ситуация в стандарте архитектуры?

Описана ли подобная ситуация в стандарте тестирования?

Оптимизиация

Указать предложения по оптимизации.

Как поменять процедуры, правила, стандарты, чтобы подобные ошибки не повторялись?

  1. Почему произошла эта ошибка? Как можно улучшить процесс, чтобы такой класс ошибок не повторялся?
  2. Почему эта ошибка не покрыта автоматическими тестами? Как можно улучшить стандарт тестирования, чтобы подобные и другие ошибки не повторялись?
  3. Как можно исправить стандарты архитектуры и кодирования, чтобы подобная и другие ошибки не повторялись?

На основании отчета об анализе проблем, надежный программист пополняет стандарты надежного программирования, обновляет тестовый план, автоматизирует тестирование, исправляет ошибку, проверяет автоматическими тестами, поставляет надежную версию на тестирование.

Например:

  1. В стандарт кода и код-ревью добавить проверку на нативные типы, чтобы везде использовать NSInteger вместо int. В формулировке: “Запрещено использовать нативные типы вместо Objective-C макро-определений”.
  2. Добавить новую модель ошибки в стандарт написания юнит-тестов.
  3. Вести документацию на протокол взаимодействия с АПИ сервера.

Процедуру root-cause-анализа можно продемонстрировать диаграммой:

Процесс root-cause-анализа

Таким образом, надежный программист постоянно учится, извлекает опыт даже из ошибок, берет полную ответственность за результат, и поставляет надежный, протестированный продукт.