Технические экспертные оценки — мощный инструмент качества, но они немного сложны. Вот 8 критических факторов успеха и некоторые ловушки, которых следует избегать.

Я являюсь поклонником экспертных оценок и проверок программного обеспечения уже более 30 лет. Я видел преимущества и узнавал что-то новое из каждой проверки, в которой участвовал. Экспертная оценка — жизненно важный компонент культуры разработки программного обеспечения, ориентированной на качество.

Просто попросить коллегу просмотреть то, что вы создали, — отличное начало. Однако создание программы рецензирования и вплетение рецензий в культурную ткань организации требует времени. Новый процесс рецензирования хрупок, его легко нарушить неприятный опыт («мои рецензенты обращались со мной как с идиотом») или неэффективные результаты («мы потратили все это время впустую и не нашли ни одной серьезной ошибки»).

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

Критические факторы успеха

Вовлеченные люди и их отношение к качеству вносят наибольший вклад в успех программы проверки. Первый критический фактор заключается в том, что члены вашей команды предпочитают, чтобы находили дефекты коллеги, а не клиенты. К вашим «клиентам» относятся все, чья работа основана на ваших результатах, например тестировщик, который будет разрабатывать системные тесты на основе спецификации требований.

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

Даже заинтересованным членам команды будет сложно проводить проверки, если вы не получите согласие руководства. Обязательство — это не просто вопрос разрешения или фразы «Все делают обзоры». Вам не нужно разрешение! Обязательства руководства включают установление политик и целей; предоставление ресурсов, времени, обучения и признания; и выполнение решений группы по анализу. Вам абсолютно необходимо такое обязательство, если вы хотите создать и поддерживать эффективную программу пересмотра.

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

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

Группы, в которых я работал, сочли полезным установить цели для программы обзора. Одна команда взяла на себя обязательство проверить 100 % спецификаций требований, 60 % проектной документации, 75 % кода и так далее. Постановка числовых целей заставляла нас отслеживать количество созданных нами артефактов каждого типа, чтобы мы могли измерять прогресс в достижении наших целей. Мы достигли наших целей, и в процессе этого экспертная оценка стала рутинной практикой. Другая цель может состоять в том, чтобы уменьшить ваши уровни переработки с известной отправной точки до определенного более низкого процента от ваших общих усилий по разработке. Убедитесь, что цели проверки достижимы, измеримы и соответствуют целям вашей организации.

Затем найдите сторонника отзывов, возможно, себя, который лично ощутил преимущества. Чемпион выступает в роли местного защитника, опираясь на опыт, а не на теоретические знания. Чемпион по рецензированию, которого уважают другие члены команды — будь то технический коллега, менеджер или инженер по качеству — может сломить первоначальное сопротивление рецензированию. Высококвалифицированный разработчик, приглашающий на обзоры, посылает сигнал о том, что каждый может извлечь пользу из вклада своих коллег.

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

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

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

Обзор ловушек, которых следует избегать

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

Ловушка №1: участники не понимают процесса рецензирования. Одним из симптомов этой ловушки является то, что члены команды не используют точный и последовательный словарь для описания рецензирования различных типы. Еще одна подсказка заключается в том, что группы проверки не следуют последовательному процессу. Неадекватное поведение, например, критика автора вместо указания на проблемы с рецензируемым элементом, является явным признаком непонимания. Обучение и практический документированный процесс рецензирования имеют важное значение. Все потенциальные рецензенты должны понимать, что, почему, когда, как и кто рецензирует.

Ловушка №2: процесс проверки не соблюдается. Прежде чем предпринимать корректирующие действия, узнайте, почему процесс не соблюдается. После того, как вы диагностировали основные причины, выберите соответствующие действия, чтобы запустить программу проверки. Если процесс слишком сложен, специалисты-практики могут отказаться от него или вместо этого выполнять проверки каким-либо другим способом. Если ваши менеджеры не передали свои ожидания через политику, специалисты-практики будут проводить проверки только тогда, когда это удобно или важно для них лично.

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

Ловушка №3: ​​нужные люди не участвуют. К неподходящим участникам относятся менеджеры, пришедшие без приглашения автора, и наблюдатели, пришедшие без четкой цели. Хотя вы можете привлечь нескольких участников, которые в первую очередь будут учиться, сосредоточьтесь на приглашении рецензентов, которые найдут проблемы.

Некоторые обзоры будут ущербными, если не будут представлены ключевые точки зрения. Например, обзор спецификации требований требует мнения заказчика, чтобы оценить правильность и полноту и быстро устранить неясности и конфликты. Клиент может быть представлен реальными конечными пользователями или суррогатами, такими как сотрудники отдела маркетинга. Чтобы подчеркнуть потребность в подходящих участниках, ниже приведено электронное письмо, которое я получил от одного из моих клиентов-консультантов, описывающего ее опыт проверки спецификаций требований:

Обзоры были чрезвычайно полезными, особенно с учетом того, что пользователи были штатными и были очень заинтересованы в том, чтобы влиять на решения по проекту. Вклад пользователей в обзоры требований был высоко оценен всеми участниками. Мы отменили более одной проверки из-за отсутствия участия пользователей, и я помню одну проверку, когда мы неожиданно вызвали пользователя, потому что другие не появились. У той, которая пришла, не было времени на подготовку, и мы отложили начало встречи, ожидая ее появления, но тем не менее она дала очень ценные идеи и предложения. Участие пользователей в обзорах имело безоговорочный успех и привело к тому, что программное обеспечение стало более ценным для пользователей, а также к улучшению рабочих отношений между проектом и пользователями.

Ловушка № 4: собрания по обзору скатываются к решению проблем. Если обзор не был специально инициирован как сеанс мозгового штурма, группа должна сосредоточиться на поиске, а не на исправлении ошибок. Когда совещание по обзору переключается на поиск решений, процесс изучения продукта останавливается. Участники отключаются, если они не увлечены обсуждаемой проблемой. Когда рецензенты понимают, что время встречи почти истекло, они поспешно пролистывают оставшиеся страницы и объявляют рецензирование успешным. На самом деле материал, который они замалчивали, вероятно, содержит серьезные проблемы, которые будут преследовать команду разработчиков в будущем. Ошибка модератора является основной причиной этой проблемы.

Ловушка № 5: Рецензенты сосредотачиваются на стиле, а не на содержании. Журнал проблем, в котором перечислены только проблемы со стилем, предполагает, что рецензенты были отвлечены стилем, не были должным образом подготовлены или только поверхностный осмотр. Чтобы избежать этой ловушки, определите стандарты кодирования и примените стандартные шаблоны для других проектных документов. Стандарты кодирования касаются компоновки, соглашений об именах, комментариев, языковых конструкций, которых следует избегать, и других факторов, улучшающих читабельность и удобство сопровождения. В рамках оценки того, соответствует ли рабочий продукт критериям входа в инспекцию, попросите специалиста по проверке стандартов проверить, соответствует ли он соответствующему стандарту. Это помогает рецензентам сосредоточиться на важных логических, функциональных и семантических проблемах.

Что замедляет вас?

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

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

=================

Эта статья адаптирована из книги Рецензирование программного обеспечения: практическое руководство Карла Вигерс. Карл — главный консультант компании Process Impact. Его последняя книга Жемчужины разработки программного обеспечения: уроки пятидесятилетнего опыта работы с программным обеспечением. Карл является автором множества других книг, в том числе Требования к программному обеспечению, Подробнее о требованиях к программному обеспечению, Бездумный дизайн повседневных вещей. »,иКонсультации по успешному бизнес-анализу.

Для неограниченного чтения на Medium.com рассмотрите членство.