Гитте Оттосен, главный консультант и совладелец Key2Quality, обсуждает на портале TechBeacon применение модели VOICE для согласования вопросов качества и ценности ПО.

Первый принцип Манифеста Agile гласит: «Наш главный приоритет — удовлетворить клиента путем ранней и непрерывной доставки ценного ПО». По прошествии 20 лет можно подумать, что это устоявшаяся практика в agile-командах. Но действительно ли команды знают, зачем они строят то, что строят? Знают ли они, какие изменения они собираются сделать для людей, получающих их решение, или какую ценность оно будет иметь для конечных пользователей?

По моему опыту, многие команды до сих пор не имеют такого фокуса. Они говорят о качестве, например: «Нам нужно обеспечить хорошее качество нашего решения», «Наш клиент ожидает высокого качества» и т. п. Но у них нет четкого представления о том, что означает «хорошее качество», кроме, скажем, отсутствия ошибок 1-й или 2-й степени тяжести и максимум 19 ошибок 3-й степени при запуске в производство.

Другими словами, по-прежнему существует необходимость обсуждения в команде и с заинтересованными сторонами, что такое качество, хотя ответ, вероятно, не очевиден для всех, и вы не обязательно видите одну и ту же картину.

Но никогда не поздно начать это обсуждение. Вот как модель VOICE может вам в этом помочь.

Что такое качество?

Существует несколько официальных определений качества. Например, в стандарте ISO 25010 перечислено несколько различных атрибутов качества, в зависимости от того, говорите ли вы о качестве продукции или о качестве использования. Но Джеральд Вайнберг дал очень простое определение качества, позже уточненное Джеймсом Бахом и Майклом Болтоном: «Качество — это ценность для определенного человека в определенное время».

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

Когда у вас есть представление о том, кто они, тогда вы можете начать обсуждать, что такое для них ценность. Это приводит нас к модели VOICE.

Модель VOICE

Впервые представленная в книге Рика Марселиса «Качество для команд DevOps», модель VOICE (value, objectives, indicators, confidence, experience — ценность, цели, индикаторы, уверенность, опыт) является преемницей модели GQM (goal, question, metric — цель, вопрос, метрика). Она дает вам подход к проведению важного разговора с важными людьми о том, чего они ожидают, как сделать цели измеримыми в виде задач и как использовать их в качестве указателей для определения того, предоставляете ли вы ту ценность, которую ожидают получить заинтересованные стороны.

Цель модели VOICE — создать уверенность в том, что преследуемая бизнес-ценность может быть достигнута. Вот как она выглядит:

Источник: Sogeti

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

Как использовать модель VOICE

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

Например, ваша цель может звучать так: «Мы хотим предоставить нашему торговому персоналу более эффективный способ регистрации В2В-заказов» или «Мы хотим предоставить нашим клиентам возможность оплачивать свои заказы с помощью кредитной карты».

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

Для первой цели задачи могут быть следующими:

  • регистрация заказа должна быть возможна только с помощью клавиатуры (что более эффективно);
  • для всех полей в окне заказа должны быть установлены правила валидации.

Для второй цели:

  • должна быть возможность оплаты следующими кредитными картами: Visa, Mastercard и American Express;
  • платеж должен включать метод проверки кредитной карты;
  • оплата кредитной картой не должна занимать более чем в два раза больше времени, чем другие платежи.

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

Несколько рекомендаций, связанных с индикаторами:

  • их не должно быть слишком много; максимум пять — десять (предпочтительно меньше);
  • показатели никогда не должны быть статичным набором; пересматривайте их регулярно, возможно, каждые три месяца или около того, чтобы убедиться, что вы правильно расставили акценты.

Можно привести несколько примеров показателей, которые могут обеспечить коммуникацию вокруг выполнения целей:

  • показатели, связанные с ИТ:
    • коэффициент прохождения/непрохождения тестов (организуйте тесты таким образом, чтобы на их основе можно было определить достижение цели, например, набор тестов, обрабатывающих правила проверки для первой цели, и один, охватывающий навигацию. Для второй цели рассмотрите возможность организации тестовых кейсов для каждого типа кредитной карты);
    • сниженные риски качества по сравнению с выявленными рисками качества (как уже упоминалось, используйте цели в качестве вводных для анализа рисков качества, что позволит установить связь с каждой из них).
  • показатели, связанные с проблемами:
    • количество выявленных в ходе тестирования аномалий, сгруппированных по целям;
    • среднее время на расследование и устранение проблем по сравнению с согласованным уровнем.

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

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

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

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