Введение
Тема критериев качества требований затрагивается во многих статьях и публикациях, но, к сожалению, часто сводится к перечислению критериев и определений к ним. Именно поэтому я бы хотела затронуть более практические аспекты.
Поговорим о том, что такое критерии качества требований, для чего понимать и уметь определять эти критерии, а также о том, как улучшить качество требований, создаваемых нами.
Дать определение качеству требований, как и измерить это качество, достаточно трудно. Для наших целей будем называть требования качественными, если они отражают потребности заинтересованных сторон и предоставляют достаточно информации для создания программного обеспечения, которое удовлетворяет целям продукта или проекта.
При этом, можно рассматривать критерии качества требований как на разных уровнях требований (бизнес требования, требования заинтересованных лиц, функциональные и нефункциональные требования), так и на разных элементах (качество отдельного артефакта, спецификации, пакета спецификаций). В любом из этих разрезов важно понимать, что критерии качества требований - это не просто блок теории с занятными мнемониками, но полезный инструмент, который можно и нужно использовать для улучшения эффективности работы как бизнес аналитика, так и команды в целом.
Почему критерии качества важны?
Согласно отчету Института управления проектами (PMI) за 2017 год, 14% ИТ-проектов терпят неудачу. Однако это число представляет только общий процент абсолютно провальных проектов. Респонденты рассказали что 31 процент проектов не достигли поставленных целей, 43 процента превысили первоначальный бюджет и 49 процентов не уложились в сроки (в различных комбинациях этих проблем) (https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en).
При этом, тот же отчет указывает, что респонденты считают причиной провала некачественно выявленные требования в 39% случаев (второе место среди всех причин). Но и среди других причин есть те, которые прямо или опосредованно связаны с БА активностями. Например, некорректное видение и цели проекта, неточные оценки, неопределенные риски и возможности, взаимозависимость задач и прочие.
Конечно же, необязательно быть пессимистами и смотреть на мир через призму потенциального провала. Но и на успешном проекте некачественные требования приводят к нежелательным последствиям, таким как:
Множество раундов разъяснений и уточнений;
Сложности в планировании;
Частые переделки;
Превышение времени и бюджета;
Сложности в поддержке требований;
Несчастная команда проекта;
Недовольный клиент;
Критерии качества требований дают возможность создать своеобразный чек-лист применимый к конкретному проекту, и позволяющий оценить и улучшить качество артефактов, а как следствие - "качество жизни" всей команды разработки.
Есть прекрасное развлекательное видео, которое просто и наглядно демонстрирует почему качественные требования так важны. На каждый "некорректный" пункт инструкции найдется критерий качества требований, который был нарушен.
Какие существуют критерии качества?
Конечно же, существует масса списков критериев качества требований, составленных различными авторами, и "заточенных" под разные методологии разработки и уровни требований. Вот лишь некоторые из них:
По BABOK:
(A Guide to the Business Analysis Body of Knowledge®, раздел 7.2.4)
Atomic (Атомарное)
Complete (Полное)
Consistent (Непротиворечивое)
Concise (Краткое)
Feasible (Выполнимое)
Unambiguous (Однозначное)
Testable (Тестируемое)
Prioritized (Ранжированное)
Understandable (Понятное)
По Вигерсу:
(Writing Quality Requirements, Karl E. Wiegers)
Correct (Верное)
Feasible (Выполнимое)
Necessary (Необходимое)
Prioritized (Приоритизированное)
Unambiguous (Однозначное)
Verifiable (Тестируемое)
INVEST (Bill Wake):
(INVEST in Good Stories, and SMART Tasks, Bill Wake)
Independent (Независимое)
Negotiable (Обсуждаемое)
Valuable (Полезное)
Estimable (Поддающееся оценке)
Small (Компактное)
Testable (Тестируемое)
Requirements Management Using IBM® Rational® RequisitePro®:
(Requirements Management Using IBM Rational RequisitePro, раздел 1.4)
Unambiguous (Однозначное)
Testable (verifiable) (Тестируемое)
Clear (concise, terse, simple, precise) (Четкое)
Correct (Верное)
Understandable (Понятное)
Feasible (realistic, possible) (Выполнимое)
Independent (Независимое)
Atomic (Атомарное)
Necessary (Необходимое)
Implementation-free (abstract) (Абстрактное)
Consistent (Согласующееся)
Nonredundant (Не избыточное)
Complete (Полное)
SMART (Bill Wake):
(INVEST in Good Stories, and SMART Tasks, Bill Wake)
Specific (Точно сформулированное)
Measurable (Измеримое)
Achievable (Выполнимое)
Relevant (Актуальное)
Time-boxed (Привязанное к сроку)
Сводная таблица критериев качества требований
В этой таблице я попыталась сопоставить критерии из разных списков. Конечно же, такое сопоставление неоднозначно, и со многими пунктами можно поспорить (например, сопоставление Prioritized и Valuable критериев). Принцип, которым руководствовалась я - это выбор критериев, для диагностики и улучшения которых можно использовать похожие методы.
SMART здесь стоит особняком, так как в отличие от остальных подходов, он скорее применим к бизнес-требованиям, и не принесет много пользы при попытке применить, например, к функциональным.
Очевидно, что различных критериев качества настолько много, что пытаться отследить и проконтролировать все их на конкретном проекте не представляется возможным.
Важно понять, какие критерии качества наиболее важны для команды, и определить, по каким из них требуются улучшения. Подробно об этом рассказал Станислав Рождественский в своем докладе на Analyst Days -10.
Мониторинг и выбор критериев
Как же на практике определить, на улучшении каких критериев следует сосредоточить свое внимание? На основании результатов брейн-сторминга, проводившегося в BA Community в DataArt, и в результате личных наблюдений, был сформирован такой список мероприятий для мониторинга качества требований:
Регулярно собирайте обратную связь от команды. Конечно, порой неприятно слушать критику в адрес артефактов, созданных с душой. Однако, именно негативная обратная связь является самой полезной и помогает определить где именно нужны улучшения. Помочь в этом может проведение регулярных демо-сессий требований (requirements review, requirements walkthrough session), на которых аналитик презентует готовые артефакты команде, обсуждаются возникающие вопросы и замечания. Кроме того, за обратной связью можно непосредственно обратиться к коллеге, который взял в работу конкретный блок требований: к тестировщику на этапе создания тест кейсов, к разработчику, на которого перевели данную задачу. Они, возможно, вникают в требования глубже, чем это происходит во время демо-сессии.
Отслеживайте время, затрачиваемое на разъяснение требований команде после того, как готовые требования переданы в работу. Так вы сможете определить, например, какие артефакты являются наиболее понятными именно для вашей команды, о назначении и применении каких стоит рассказать команде детальнее, а какие лучше не использовать совсем. Или понять, в чем пробелы допускаете вы, если в ходе таких разъяснений окажется, что требования, например, неполны или неоднозначны. Для этого, если позволяет процесс и вы очень педантичны, можно завести себе задачу в системе управления задачи (например, Jira) и заносить время туда. Однако в большинстве случаев достаточно просто ведения записей в блокноте.
Отслеживайте количество и частоту изменений в артефактах - частые изменения в требованиях не всегда означают, что заинтересованные лица "ветрены" и изменяют свои решения. Иногда они говорят о том, что инструменты выявления требований выбраны некорректно, или неверно применяются.
Отследите время, затраченное на поддержку требований - требования могут быть особенно тяжелы в поддержке, когда не выполняются критерии атомарности, независимости, краткости, а также если они не трассированы или трассированы некорректно.
Введите метки (labels) в системе управления задачами, которыми будете отмечать дефекты возникшие из-за неправильных / неправильно понятых требований, например, ambiguous_reqs, inconsistent_reqs, и тому подобные - это на достаточно продолжительном интервале времени поможет собрать статистику и понять наиболее уязвимые места. Только не вводите метки сразу по всем критериям - определите несколько наиболее важных на ваш взгляд, и добавляйте по мере необходимости.
Обратите внимание на разницу в оценочном и фактическом времени реализации - большой разрыв может говорить как о "незрелости" команды, так и о низком качестве вводных данных, на которые опиралась команда при оценке. Отследить такие задачи поможет система управления задачами, при условии, что команда фикрсирует время, затраченное на выполнение задач.
Например, в Jira есть раздел Time Tracking. В нем нас будут интересовать задачи, у которых время Logged превышает Estimated, скажем, на 20%. Найти их можно с помощью JQL запроса "workratio>120". Важно обсуждать эти расхождения своевременно и тактично, и определять эти понятия нужно в каждом конкретном случае - для кого-то нормально, если такой вопрос поднимут на ретроспективе спринта, а другой человек может воспринять это болезненно, и к нему лучше обратиться лично.
Попросите коллегу бизнес-аналитика провести "аудит" - взгляд со стороны может помочь увидеть те проблемы, которые мы сами уже привыкли не замечать.
Проведите "самодиагностику" - ниже я приведу таблицу с описанием "симптомов", которые могут говорить о проблемах с выполнением тех или иных критериев качества. Подобную таблицу можно составить исходя из определенных вами наиболее важных критериев. Кроме того, в сети можно найти готовые чек-листы, по которым можно проводить такой анализ.
Как улучшить качество требований?
Предположим, мы определились с наиболее важными критериями качества. Для наглядности можно дать им некоторую условную оценку и представить их на лепестковой диаграмме.
Скорее всего, если сосредоточить свои усилия на улучшении какого-то выбранного критерия, допустим - атомарности (Atomic), то спустя время мы увидим следующую картину:
По некоторым критериям будут также наблюдаться улучшения, хотя усилия на них направлены не были. Другие же начнут ухудшаться. В графике выше, например, когда мы добиваемся лучшей атомарности (Atomic), параллельно улучшается оценка краткости (Concise), но ухудшается оценка понятности (Understandable).
Это может быть связано с несколькими причинами:
Некоторые критерии взаимосвязаны. Дробление требований на более мелкие элементы для улучшения атомарности скорее всего автоматически приведет к большей краткости требований (прямая зависимость). При этом такое дробление может ухудшить понятность - элементы слишком малы и сложнее проследить зависимости, и в какой-то момент может просесть, например, тестируемость (обратная зависимость).
Ресурсы для работы над качеством требований ограничены. Бросая все усилия на улучшение одного аспекта, мы скорее всего упустим другие. Визуально ограниченные ресурсы можно представить как неизменную площадь внутри представленной лепестковой диаграммы.
Выходить из положения, соответственно, можно двумя способами: увеличить ресурсы на улучшение качества требований (что не всегда в наших силах), или же "заточить пилу", осваивая новые инструменты, техники и шаблоны. Например,
изучить нотации для моделирования (BPMN, IDEF0, UML);
попробовать использовать различные шаблоны для документирования требований, выбрать наиболее подходящие для конкретного применения;
детально изучить возможности используемой системы управления требованиями, при возможности - попробовать различные системы;
освоить инструменты для прототипирования и снабжать артефакты качественными прототипами;
поработать над синтаксисом требований, изучив различные подходы (например, EARS, Gherkin, рекомендации Вигерса к синтаксису)
пройдите курс по формальной логике :)
систематизируйте рекомендации по конкретным критериям, для "самодиагностики". Например так:
Когда остановиться?
На пути саморазвития, конечно же, останавливаться нельзя. Но говоря о работе над конкретным проектом, в какой-то момент усилия, предпринимаемые для улучшения качества требований будут приносить слишком низкую предельную полезность.
Думаю, тут также применим принцип Парето: 20% усилий приносят 80% результата. Поэтому не стоит пытаться довести до идеала все, что касается критериев качества, скорее нужно соблюдать принцип разумной достаточности, остановиться на том уровне качества требований, который хорошо работает для конкретного проекта или команды, и удерживать этот уровень.
Спасибо за статью. Особо полезной для меня оказалась таблица в конце о том, как улучшить качество требований