В продолжение темы про проекты и процессы в бизнес-анализе, сегодня рассмотрим особенности управления требованиями в Agile-походе. Читайте далее, как гибкая разработка требований уживаются со строгими ГОСТами на ТЗ и что сказано по этому поводу в профессиональном руководстве по бизнес-анализу BABOK®Guide.
Гибкое управление требованиями и BABOK®Guide
Обычно требования оформляются в виде технического задания (ТЗ) на разработку программного обеспечения. Однако, сегодня, когда мы живем в постоянно меняющемся мире, видение решение может изменяться по мере его реализации и практического использования. Именно поэтому гибкие методологии разработки ПО стали так актуальны и начали применяться не только в ИТ-сфере, но и в создании множества других продуктов. При этом возникает некоторое противоречие: с одной стороны, входными данными для создания решения являются требования к нему, а с другой стороны, они могут измениться в любой момент. Что делать бизнес-аналитику в этом случае и как в Agile-условиях выполнять свою основную миссию – снижение неопределенности на проекте, мы рассмотрим далее.
Согласно Agile Manifesto, что работающий продукт важнее исчерпывающей документации, а изменений требований приветствуется даже в конце разработки [1]. Однако, полностью отказаться от разработки и анализа требований невозможно, т.к. нельзя создать продукт, не имея представления о том, кто и зачем им будет пользоваться. Чтобы Agile-подход предлагает методологию гибкого моделирования (Agile Modelling), в рамках которой непрерывное документирование меняющихся, уточняющихся и дополняющихся требований ведется параллельно с выполнением остальных задач разработки программного обеспечения: кодирования, тестирования и развертывания. При этом вместо статической документации в виде однажды согласованного технического задания (ТЗ) требования определяются в форме исполняемых «пользовательских тестов» [2].
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Эту же идею продвигает BABOK®Guide, посвятив Agile-подходу целую главу из своих 5 ключевых перспектив. В частности, BABOK подчеркивает, что бизнес-аналитик непрерывно проводит анализ и поставляет результаты именно тогда, когда команда может их действительно использовать, чтобы таким образом обеспечить постоянную гибкость изменений. Поскольку объем (scope) Agile-проекта изменяется, основной техникой управления требованиями при этом становится ведение бэклога (backlog management) – приоритетного списка рабочих задач, которые необходимо выполнить в первую очередь. При этом приоритизация пунктов бэклога основана на принципе максимальной ценности для потребителя.
Поэтому, в Agile-проекте вместо подробного документирования всех требований на начальном этапе сперва определяются бизнес-потребности. Далее выявляются высокоуровневые требования, которые обычно описываются в виде пользовательских историй (user story) и представляют собой смысловую агрегацию функциональных требований. Пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей. Эти истории наполняют бэклог проекта, который постоянно приоритизируется по мере уточнения видения конечного продукта в рамках каждой итерации, например, цикла поставки (Sprint) в Scrum. Бэклог неотъемлемо связан с составом проекта (Project Scope), который описывает границы того, что нужно сделать. Рекомендуется также с самого начала и по мере продвижения проекта детализировать нефункциональные требования, чтобы спроектировать соответствующую архитектуру системы, которая обеспечит нужную производительность, удобство эксплуатации, информационную безопасность, доступность и прочие качественные характеристики продукта [3]. Чем представление требования в виде user story отличается от use case, читайте в нашей отдельной статье.
Реализация каждой пользовательской истории отслеживается через состояние (статус) входящих в нее задач по принципу канбан-доски, например, по стадиям жизненного цикла, от зарождения (появления в бэклоге) до приемки [4]:
- в бэклоге – пока не включена в конкретную итерацию;
- определена – подробности истории обсуждены и поняты, приемочные тесты написаны;
- разработка – в процессе реализации;
- завершена – полностью реализована;
- принята – пройдены приемочные тесты;
- заблокирована – невозможно продолжить разработку, пока не будут разрешены другие вопросы.
ТЗ по ГОСТу и 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-проектах аналитик детализирует требования по мере итераций, параллельно с этим разрабатывая программную документацию, обязательную для сдачи готового решения Заказчику.
Подробнее о том, чем User Story отличается от Use Case, мы рассматриваем здесь.
Таким образом, работа с требованиями по отечественным ГОСТам и зарубежным стандартам не противоречит принципам Agile, а органично дополняет их, позволяя сдерживать «текучесть» гибких подходов с помощью четких формальных рамок и объединяя преимущества обоих подходов. Однако, это предполагает высокую компетентность аналитика, в т.ч. способности сочетать «продуктовое мышление» с Agile-идеями, а также понимание сути регламентирующих документов и рекомендаций BABOK®Guide. Как внедрить продуктовое мышление и Agile-практики в классический бизнес-анализ, подружив требования с фичами, рассматривается в моем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика».
От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика
Код курса
POAP
Ближайшая дата курса
13 февраля, 2025
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
А особенности спецификации требований и управления ими с рекомендациями BABOK®Guide на практических примерах разбираются в курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Разработка ТЗ на информационную систему по ГОСТ и SRS
- Лучшее из BABOK®Guide: ТОП-10 задач и техник для аналитика
- Управление бизнес-анализом — курс для руководителей
Источники
- https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
- https://en.wikipedia.org/w/index.php?title=Agile_Modeling
- https://analytics.infozone.pro/requirements-analysis/agile-software-development/
- https://habr.com/ru/post/328822/
