Рассмотрение (ревью) · Конспекты по бизнес-анализу

Что это#

Ревью (reviews) оценивают содержание рабочего продукта: отдельного результата, части набора результатов или незавершённой работы. Руководство BABOK® говорит, что ревью нужно подстраивать под потребности организации и что бизнес-аналитик участвует в каждом из них. Элементы техники — цели ревью, используемая техника и участники.

Типы ревью, от самого формального к наименее формальному:

Инспекция — формальный поиск дефектов по чек-листу под руководством обученного модератора.
Формальный сквозной просмотр (walkthrough), или командное ревью, — автор проводит группу по продукту; находки записываются.
Ревью по одному вопросу (техническое ревью) — сосредоточено на одном аспекте, например на соответствии стандарту.
Неформальный сквозной просмотр — автор показывает черновик нескольким коллегам, чтобы быстро получить отзывы.
Проверка за столом (desk check) — один рецензент изучает продукт самостоятельно.
Рассылка по кругу (pass-around) — продукт получают несколько рецензентов и присылают свои комментарии.
Ad hoc — неформальная просьба посмотреть свежим взглядом.

Верификация и валидация. Вигерс и Битти разделяют два вопроса. Верификация (verification) выясняет, правильно ли записаны требования: полны ли они, однозначны, непротиворечивы, проверяемы. Валидация (validation) выясняет, те ли это требования: служат ли они бизнес-целям и реальным потребностям заказчика. Руководство BABOK разносит их по задачам 7.2 «Верификация требований» и 7.3 «Валидация требований», и ревью поддерживают обе.

Формальная инспекция. Маглинец возводит инспекции к работе Майкла Фагана в IBM и к стандарту IEEE 1028 на ревью программного обеспечения. Главные правила: руководители не инспектируют работу своей команды, инспекцию ведёт независимый обученный модератор, а автор участвует всегда. Регистратор записывает находки, а инспекторы до встречи готовятся индивидуально по чек-листу. Инспекция заканчивается одним из трёх решений: принять как есть или с небольшими правками, принять после проверки доработки или провести повторную инспекцию.

Когда применять#

Учебные таблицы Watermark Learning связывают ревью с задачами планирования 3.1, 3.3 и 3.5, с задачами 4.3 «Подтверждение результатов выявления», 4.4 «Предоставление информации бизнес-анализа», 5.5 «Утверждение требований» и 7.2–7.3. Проводите ревью всего, на основе чего другие будут строить, что будут утверждать или на что будут полагаться.

Сколько ревью достаточно? Леффингуэлл и Уидриг соизмеряют усилия с ответами на два вопроса: каковы социальные или экономические последствия сбоя и сколько проверки нужно, чтобы их предотвратить. Они разделяют глубину (насколько тщательно проверяется элемент) и покрытие (сколько элементов проверяется). Элементы с низким риском можно проверять облегчёнными методами или выборочно, но пропущенные элементы и причины пропуска нужно записать. Всё, что касается безопасности людей, всегда проверяется полностью.

Сильные стороны, по учебным таблицам: дефекты находят рано; рецензенты начинают болеть за результат; проверку за столом и рассылку по кругу легко встроить в график участников. Ограничения: инспекции и формальные сквозные просмотры отнимают много времени; при неформальных ревью выше риск пропустить дефекты; трудно убедиться, что проверка за столом или рассылка по кругу действительно состоялись; комментарии, присланные по электронной почте, трудно свести воедино.

Как это делать#

Задайте цели. Найти дефекты, подтвердить соответствие целям или подготовиться к утверждению? Укажите, что в ревью не входит, например оформление.
Выберите тип по риску и последствиям: инспекция — для критичных правил, сквозной просмотр — для сложной логики, рассылка по кругу — для содержания с низким риском.
Подберите рецензентов из тех, кто будет пользоваться продуктом: разработчиков, тестировщиков и бизнес-представителей, которым принадлежит потребность. Для формальных ревью добавьте модератора и регистратора.
Подготовьте пакет: небольшую часть продукта, цели, чек-лист, справочные материалы и срок.
Готовьтесь индивидуально. Рецензенты читают и отмечают замечания до встречи.
Ищите, а не исправляйте. На встрече записывайте каждую находку; решайте проблемы потом.
Набросайте идеи тестов. Вигерс и Битти советуют планировать тесты прямо во время ревью: попытка написать тест вскрывает неоднозначность и пробелы. Маглинец предлагает матрицу «требования — тестовые сценарии», чтобы у каждого требования был хотя бы один сценарий, а каждый сценарий опирался на требования.
Примите решение по итогам, выполните доработку и проверьте её.
Дополняйте чек-лист типами дефектов, которые находите снова и снова.

Пример#

«Мастерская», вымышленная сеть из 12 веломастерских, проводит формальный сквозной просмотр требований к уведомлениям. Одно из них звучит так: «Система должна уведомлять клиента, когда ремонт задерживается».

Каждый рецензент понимает его по-своему. Сотрудники стойки приёма спрашивают: «Задерживается по сравнению с чем?» Механик спрашивает: «Кто решает, что ремонт задерживается?» Руководитель разработки спрашивает: «По SMS или по почте, и как быстро?» Вигерс и Битти описывают похожий случай: требование, которое выглядело полным, распалось на противоречащие друг другу толкования, как только рецензенты начали его обсуждать.

Новая формулировка: «Когда механик переносит ожидаемую дату завершения на более позднюю, система в течение 5 минут отправляет клиенту SMS с новой датой». Тестировщик сразу набрасывает для него тест. Тексты справочных страниц проходят рассылку по кругу, правила конфиденциальности — инспекцию.

Экономический довод Вигерс и Битти приводят по исследованию Келли, Шерифа и Хопса (Kelly, Sherif, Hops, 1992): дефект, найденный на этапе требований, исправляли примерно за 30 минут, а такой же дефект, найденный при системном тестировании, — за 5–17 часов.

Частые ошибки#

Слишком много материала за раз → отправляйте небольшими частями.
Нет индивидуальной подготовки → требуйте прочитать материал до встречи.
Исправления прямо на встрече → записывайте находки; дорабатывайте после.
Руководители инспектируют работу своей команды → люди защищаются, а не ищут дефекты.
Комментарии разбросаны по письмам → ведите один журнал находок.
Только верификация → проводите и валидацию с бизнес-представителями, которым принадлежит потребность.
Уверенность, что проверка за столом состоялась → просите показать находки или подтвердить проверку.

Чек-лист#

Для каждого рассматриваемого требования:

Есть уникальный ID, и требование говорит об одном
Допускает только одно разумное толкование
Проверяемо; есть идея теста
Трассируется к бизнес-цели или потребности заинтересованной стороны
Осуществимо в рамках известных ограничений
Не противоречит другим требованиям
Описывает потребность, а не дизайн
Открытые вопросы отмечены и записаны

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.37 «Рассмотрение (ревью)».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Разд. 10.37.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 17 (валидация требований).
D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 29, 33 (верификация и валидация; масштабирование усилий).
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 6 (инспекции по М. Фагану; IEEE 1028; тестовые сценарии).