Как управлять требованиями, балансируя между BABOK, Agile и ТЗ по ГОСТу

автор
Как управлять требованиями, балансируя между BABOK, Agile и ТЗ по ГОСТу

В продолжение темы про проекты и процессы в бизнес-анализе, сегодня рассмотрим особенности управления требованиями в Agile-походе. Читайте далее, как гибкая разработка требований уживаются со строгими ГОСТами на ТЗ и что сказано по этому поводу в профессиональном руководстве по бизнес-анализу BABOK®Guide.

Гибкое управление требованиями и BABOK®Guide

Обычно требования оформляются в виде технического задания (ТЗ) на разработку программного обеспечения. Однако, сегодня, когда мы живем в постоянно меняющемся мире, видение решение может изменяться по мере его реализации и практического использования. Именно поэтому гибкие методологии разработки ПО стали так актуальны и начали применяться не только в ИТ-сфере, но и в создании множества других продуктов. При этом возникает некоторое противоречие: с одной стороны, входными данными для создания решения являются требования к нему, а с другой стороны, они могут измениться в любой момент. Что делать бизнес-аналитику в этом случае и как в Agile-условиях выполнять свою основную миссию – снижение неопределенности на проекте, мы рассмотрим далее.

Согласно Agile Manifesto, что работающий продукт важнее исчерпывающей документации, а изменений требований приветствуется даже в конце разработки [1]. Однако, полностью отказаться от разработки и анализа требований невозможно, т.к. нельзя создать продукт, не имея представления о том, кто и зачем им будет пользоваться. Чтобы Agile-подход предлагает методологию гибкого моделирования (Agile Modelling), в рамках которой непрерывное документирование меняющихся, уточняющихся и дополняющихся требований ведется параллельно с выполнением остальных задач разработки программного обеспечения: кодирования, тестирования и развертывания. При этом вместо статической документации в виде однажды согласованного технического задания (ТЗ) требования определяются в форме исполняемых «пользовательских тестов» [2].

Эту же идею продвигает BABOK®Guide, посвятив Agile-подходу целую главу из своих 5 ключевых перспектив. В частности, BABOK подчеркивает, что бизнес-аналитик непрерывно проводит анализ и поставляет результаты именно тогда, когда команда может их действительно использовать, чтобы таким образом обеспечить постоянную гибкость изменений. Поскольку объем (scope) Agile-проекта изменяется, основной техникой управления требованиями при этом становится ведение бэклога (backlog management) – приоритетного списка рабочих задач, которые необходимо выполнить в первую очередь. При этом приоритезация пунктов бэклога основана на принципе максимальной ценности для потребителя.

Поэтому, в Agile-проекте вместо подробного документирования всех требований на начальном этапе сперва определяются бизнес-потребности. Далее выявляются высокоуровневые требования, которые обычно описываются в виде пользовательских историй (user story) и представляют собой смысловую агрегацию функциональных требований. Пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей. Эти истории наполняют бэклог проекта, который постоянно приоритезируется по мере уточнения видения конечного продукта в рамках каждой итерации, например, цикла поставки (Sprint) в Scrum. Бэклог неотъемлемо связан с составом проекта (Project Scope), который описывает границы того, что нужно сделать. Рекомендуется также с самого начала и по мере продвижения проекта детализировать нефункциональные требования, чтобы спроектировать соответствующую архитектуру системы, которая обеспечит нужную производительность, удобство эксплуатации, информационную безопасность, доступность и прочие качественные характеристики продукта [3].

Реализация каждой пользовательской истории отслеживается через состояние (статус) входящих в нее задач по принципу канбан-доски, например, по стадиям жизненного цикла, от зарождения (появления в бэклоге) до приемки [4]:

  • в бэклоге – пока не включена в конкретную итерацию;
  • определена – подробности истории обсуждены и поняты, приемочные тесты написаны;
  • разработка – в процессе реализации;
  • завершена – полностью реализована;
  • принята – пройдены приемочные тесты;
  • заблокирована – невозможно продолжить разработку, пока не будут разрешены другие вопросы.
user story, Agile, управление требованиями, анализ и разработка требований, курсы по бизнес-анализу
Жизненный цикл user story – управление требованиями в Agile-проектах

ТЗ по ГОСТу и Agile: vs или вместе?

При том что BABOK®Guide представляет собой профессиональный свод знаний, в отличие от отечественных ГОСТов и зарубежных стандартов по разработке ТЗ, он носит рекомендательный характер и претендует на жесткую регламентацию процедур по созданию программной документации. В России именно согласованное и неизменяемое ТЗ по ГОСТу в основном считается главным результатом деятельности аналитика. Такая категоричность не соответствует принципам Agile и особенностям современных проектов. Однако, работа по ГОСТам абсолютно не противоречит Agile-подходу, хотя и отходит от строгой «водопадной» последовательности.

Из отечественных стандартов требования к проектируемой системе в форме ТЗ регламентируют ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению». Оба стандарта содержат по 9 разделов с похожим назначением, но отличаются по специфике применения:

  • ГОСТ 34.602-89 описывает ТЗ на автоматизированную систему, в т.ч. программное и аппаратное обеспечение, пользователей и автоматизируемые процессы;
  • ГОСТ 19.201-78 ориентирован только на разработку ПО.

При том, что сегодня некоторые ИТ-специалисты считают эти ГОСТы устаревшими, большинство государственных Заказчиков в России требуют строгого соблюдение этих стандартов. Хотя эта программная документация и не является непосредственным входом для разработчика, она достаточно подробно описывает основные бизнес-потребности и ключевое назначение будущего продукта [4]. По сравнению с отечественными ГОСТами, зарубежный стандарт ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering» предполагает более детальное описание требований. Но, если на начальном этапе описывать требования к проектируемой системе согласно этому документу, может уйти слишком много времени и ресурсов, что задержит выпуск продукта. Это не соответствует принципам Agile, поэтому для свободной реализации изменений на любых стадиях проекта, аналитик ведет итерационную проработку требований.

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

BABOK, курсы по бизнес-анализу, обучение бизнес-аналитиков, по управлению требованиями и Agile, Agile, управление требованиями
Управление требованиями в Agile-проектах

 

Таким образом, работа с требованиями по отечественным ГОСТам и зарубежным стандартам не противоречит принципам Agile, а органично дополняет их, позволяя сдерживать «текучесть» гибких подходов с помощью четких формальных рамок и объединяя преимущества обоих подходов. Однако, это предполагает высокую компетентность аналитика, в т.ч. способности сочетать «продуктовое мышление» с Agile-идеями, а также понимание сути регламентирующих документов и рекомендаций BABOK®Guide.

Как использовать все это в практической деятельности бизнес-аналитика, вы узнаете на специализированных курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации аналитиков, менеджеров и ИТ-специалистов в Москве:

 

Источники

  1. https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
  2. https://en.wikipedia.org/w/index.php?title=Agile_Modeling
  3. https://analytics.infozone.pro/requirements-analysis/agile-software-development/
  4. https://habr.com/ru/post/328822/

 

Комментировать