Как эффективно привлекать коллег для оценки ПО - 3 простых правила
Оценка коллегами – широко распространенная практика в мире разработок программного обеспечения. Бесспорно, принцип «одна голова – хорошо, а две – лучше» улучшает ваш продукт. Главный вопрос состоит в том, стоит ли улучшение той цены, которую вы за него платите. В критичной с точки зрения безопасности области, такой как аэрокосмическая отрасль, этот вопрос имеет непреходящее значение. DO-178C вынуждает нас проводить проверки почти каждого отдельного элемента, создаваемого в течение всего жизненного цикла проекта, на что уходят до 30 % трудозатрат проекта. Поэтому расходование времени на оценки коллегами эффективным и действенным образом имеет существенное значение.
Однако намерение, лежащее в основе оценки коллегами, иногда размывается, в особенности, в отношении большого и сложного аэрокосмического проекта. Процесс проверки либо выполняется ради процесса с фокусировкой на выдачу формальных записей проверки, либо процесс становится неэффективным, если люди начинают зарываться слишком глубоко в аспекты, не оказывающие влияния на окончательное качество продукта.
Учтите следующие простые советы, чтобы сохранить баланс, делая свой процесс проверки по DO-178C более ценным, и чтобы ответственно контролировать время, потраченное на циклы проверки:
Совет № 1. Воспитывайте правильное отношение
Видели ли вы когда-нибудь нечто подобное тому, что я называю «проверкой с галочками», когда все вопросы отмечаются как «удовлетворяющие требованиям» без всякой реальной проверки? Спорю, что видели. Особенно когда сроки поджимают, а начальство торопит. Другой случай отношения выглядит как «Исправьте так, как я говорю», когда у рецензента гораздо больше власти или опыта, чем у автора.
Чтобы избежать неправильного отношения, всегда помните следующее простое утверждение: «Проверка – это независимое определяющее качество мнение относительно соответствия и качества результатов вашей работы, ни больше, ни меньше.» Каждое отдельное слово в этом утверждении имеет значение.
· Проверка должна быть независимой. Рецензент и автор должны обсуждать результаты проверки и приводить аргументы, пока не достигнут согласия, а не так, чтобы один из них безапелляционно навязывал свое мнение. · Проверка всегда направлена на оценку качества. Вы никогда не сможете подтвердить свои взгляды 100 % строгим математическим доказательством. Всегда есть место для субъективности. · Проверка направлена на то, чтобы подтвердить или опровергнуть, что проверяемый результат работы соответствует стандартам и процедурам и выполняет требования, согласно которым он разрабатывался. Проверка не является ни мозговым штурмом, ни научным заседанием, ни учебными курсами.
Совет № 2. Создайте правильный контрольный лист
Предполагается, что оценка коллегами повысит качество продукта. Однако «качество» – очень аморфное слово. Каждый чувствует, что понимает, что это такое, но почти никто не может выразить этого кратким и количественным образом. В мире DO-178C нам посчастливилось иметь более-менее строгое руководство по определению качества продукта.
1. Во-первых, работа продукта должна быть безопасной. 2. Во-вторых, и в дополнение к первому, продукт и процесс должны соответствовать стандартам. 3. В-третьих, и в дополнение к первому и второму, продукт должен выполнять заданные функции и не должен делать ничего непредусмотренного. 4. В-четвертых, и в дополнение ко всему вышесказанному, продукт должен быть приспособлен к техническому обслуживанию в течение 30+ лет.
Всегда сверяйте контрольный лист любой проверки с этими принципами. Обеспечьте, чтобы ваш контрольный лист был достаточно конкретным. Он должен содержать вопросы касательно того, насколько точно эти принципы соблюдаются в рассматриваемом продукте работы, а не того, не соблюдаются ли эти принципы поверхностно. С другой стороны, контрольный лист не должен быть слишком избыточным. Сконцентрируйтесь только на том, что жизненно важно. Получение контрольного листа со 150 вопросами для простого модульного теста является признаком того, что вы делаете что-то не то. Никогда не пренебрегайте обратной связью, получаемой от участников проверки. Пересмотрите контрольный лист, если рецензент приходит в замешательство по поводу того, какой вопрос выбрать при отнесении найденного факта, или если слишком много найденных фактов попадают в категорию «другое».
Совет № 3. Создайте правильный процесс
Убедитесь, что в проверке участвуют только имеющие к этому отношение участники и что их вовлеченность не является ни чрезмерной, ни недостаточной. Для примера с модульным тестом наличие двух инспекторов, одного модератора и одного посредника будет чрезмерным. Однако такой группы может оказаться недостаточно для проверки архитектуры программного обеспечения.
Порядок прохождения процесса проверки также очень важен. Обеспечьте группу подходящей инфраструктурой, чтобы содействовать обмену данными между участниками, и управлением записями проверки, чтобы это стало любимой частью культуры проекта, а не раздражающей формальной деятельностью. Обычно системы управления конфигурацией расширяются программными вставками оценки коллегами, чтобы сделать этот процесс быстрым, прозрачным и логичным. Вложение в комплект удобных инструментов для проверок – мудрое решение. Чего вам не хочется иметь, так это «ручного» процесса и потока записей с титульными листами проверки, которые выглядят как «книга истории проекта».
Следование этим трем советам дает мощный инструмент для анализа проекта вдобавок к приданию процессу проверки большей адекватности. Правильные контрольные листы обеспечивают вам хорошо структурированную таксономию данных. Правильное отношение и нужные участники обеспечивают уверенность, что данные, относящиеся к таким контрольным листам, точные и репрезентативные. Статистический анализ поможет вам выяснить слабые или плохо определенные аспекты своего проекта, помимо самого процесса проверки.
DO-178C требует проверок, и никто не сможет обойтись без этого. Это ваш выбор – сделать это исключительно для соответствия требованиям или извлечь из этого реальную пользу. Эти три совета помогут вам принять мудрое решение и максимизировать соотношение издержки/отдача, исходя из проверок.