Задачи и роль бизнес-аналитика в разных методологиях разработки — Agile, Waterfall, Scrum
Снова привет! Мы уже встречались в материале про карьерный рост бизнес-аналитиков. Я — Лариса Дансарунова, бизнес-аналитик с 9-летним опытом в IT-индустрии. Ментор на курсе «Бизнес-аналитик» в Практикуме и эксперт в «Эйч». Автор канала про бизнес-анализ и карьеру в IT IThumanWork. Сегодня расскажу больше о задачах бизнес-аналитика, а также — как меняется его роль в зависимости от методологии разработки ПО, которую используют в команде. И конечно — о самих методологиях и чем они различаются.
Как меняется роль бизнес-аналитика в разных методологиях разработки ПО
Бизнес-аналитик обеспечивает связь между бизнес-потребностями заказчика и технической реализацией проекта. Обычно бизнес-аналитик анализирует, интерпретирует и документирует требования заказчика, чтобы разработчики могли создать программное обеспечение, отвечающее бизнес-ожиданиям. Рассмотрю роль бизнес-аналитика в Agile и Waterfall, порассуждаю, как эта роль может изменяться в зависимости от методологии.
Бизнес-аналитик под «водопадом»
Методология Waterfall — «Водопад», представляет собой последовательный подход к разработке продуктов, при котором задачи выполняются шаг за шагом и строго в соответствии с изначальным планом. Термин был введён в 1970 году в статье директора Lockheed Software Technology Center Уинстона Уокера Ройса. Структура методологии «Водопад» построена на принципах диаграммы Ганта.
Этапы методологии Waterfall
Принципы каскадной методологии:
Документы обязательны — всё должно быть зафиксировано.
Этапы работ идут строго последовательно. Следующий не начнётся, пока не завершится предыдущий.
Нельзя вернуться на предыдущий этап — только, если пройти по всему циклу.
Если требования изменились, нужно переписать техническое задание — ТЗ.
ПО создается только на основе готового ТЗ. Во время разработки ТЗ редактировать нельзя, если требуется внести какие-то корректировки, сначала заканчиваем цикл, после создаём новую версию ТЗ.
В каскадной модели разработки бизнес-аналитик особенно важен на начальных этапах проекта: он практически в одиночку работает с заказчиком для выявления и документирования всех требований к будущей системе. При любой неточности, допущенной при сборе требований, придётся создавать новую версию ТЗ, и только после выпуска первой версии продукта. Когда разработчики приступают к работе, бизнес-потребности заказчика уже должны быть собраны и обработаны. Это значит, что аналитик готовит полное ТЗ по системе ещё до начала разработки. Для этого он ориентируется на ГОСТы или другие стандарты.
Основные типы документов, которые бизнес-аналитику необходимо подготовить | |
Спецификация требований — Requirements Specification | Подробное описание функций и характеристик продукта, который необходимо разработать. Документ обычно включает в себя описание функциональных и нефункциональных требований, внешних интерфейсов и т. д. |
Бизнес-требования — Business Requirements Document | Описание бизнес-проблемы, которую необходимо решить новым продуктом или функциональностью. В документе часто содержатся описания бизнес-процессов, целей и ЦА продукта. |
Техническое задание — Technical Specification | Создаётся на основании спецификации требований и содержит технические детали о реализации функций продукта, описание архитектуры, технологий, баз данных и другие технические аспекты. Иногда ТЗ создаёт системный аналитик. Все три первых типа документов могут быть объединены в одно объёмное ТЗ. |
Документация пользователя | Материалы для конечных пользователей продукта. Документ обычно содержит инструкции по использованию продукта, FAQ, справочные материалы и т. д. |
Отчёты и анализ деятельности | Аналитические документы о деятельности проекта, оценке рисков, прогнозировании стоимости, сроках реализации и т. д. |
Бизнес-аналитик в семействе Agile-практик
Agile — философия разработки ПО и других продуктов, позволяющая оперативно реагировать на изменения требований. Основана она на 4 ценностях и 12 принципах, которые пришли на смену строгим взглядам Водопада.
4 ценности agile-манифеста — «не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева»:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
12 принципов Agile:
Приоритет команды проекта — удовлетворение потребностей заказчика с помощью своевременной и регулярной поставки качественного продукта.
Изменение требований к продукту приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют обеспечить продукт конкурентными преимуществами.
Промежуточный рабочий продукт нужно показывать заказчику как можно чаще — с периодичностью от пары недель до пары месяцев.
Руководители и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Над проектом должны работать мотивированные специалисты. Нужно создать для них необходимые условия и обеспечить поддержку.
Личное общение — самый практичный и эффективный способ обмена информацией в команде.
Работающий продукт — основной показатель прогресса.
Процессы в Agile должны быть настроены так, чтобы проект развивался устойчиво. Заказчики, разработчики и пользователи должны быть готовы к тому, что изменения будут вноситься равномерно.
Постоянное внимание к техническому совершенству продукта и качеству проектирования повышает гибкость проекта.
Не стоит переусложнять проект — лишние процессы нужно свести к минимуму.
Лучшие продукты рождаются у команд, которые умеют организовать себя самостоятельно.
Команда должна постоянно искать способы работать эффективнее и корректировать свой стиль работы.
При гибком подходе к разработке — Agile — требования к системе разрабатываются итеративно в тесном взаимодействии с заказчиком. Бизнес-аналитик, как правило, работает над созданием User Stories — коротких описаний функциональности системы с точки зрения пользователя. Он также участвует в планировании спринтов и оценке задач.
Роль бизнес-аналитика при методологии Agile
В отличие от Waterfall, роль бизнес-аналитика немного меняется: при гибком подходе нужно формализовывать каждую итерацию. В этом случае появляются требования не ко всему продукту, а только к релизу или к части системы. На каждом из этапов бизнес-аналитик может быть ценным, например:
Планирование. Аналитик помогает с определением сроков и необходимым составом задач исходя из понимания ценности и приоритетности функциональности продукта.
Проектирование. Проводит необходимые исследования рынка или конкурентов и помогает спроектировать наиболее актуальное решение.
Создание прототипа. Помогает выдержать приоритеты и актуализирует описания решений, если что-то поменялось.
Тестирование. Проводит исследование на фокус-группе, обучает пользователей.
Обратная связь. Помогает собрать и проанализировать фидбек, а также сделать выводы.
Запуск. Актуализирует или полностью обновляет состав задач.
Особенности работы бизнес-аналитика в Agile | Примеры практик и инструментов бизнес-аналитика |
✅Акцент на постоянном взаимодействии с заказчиком ✅Гибкость и адаптивность к изменениям ✅Ориентация на работающий продукт ✅Совершенствование продукта на протяжении всего процесса разработки | ✅User stories ✅Backlog grooming ✅Прототипирование ✅Работа в малых инкрементах ✅Принципы Minimum Viable Product и Lean Startup |
Бизнес-аналитик и фреймворк Scrum
Покажу на конкретном примере гибкого фреймворка, насколько важен может быть бизнес-аналитик в команде. Обычно его обязанности — это:
проверка пользовательских историй, созданных владельцем продукта, на соответствие критериям приёмки. Все бизнес-правила должны быть учтены, а функциональность истории — соответствовать требованиям;
анализ потребностей клиентов для поиска возможных решений;
структурирование бэклога продукта на основе приоритетов, установленных владельцем продукта;
создание пользовательских историй в соответствии с требованиями и обеспечение их соответствия критериям приёмки;
предоставление и улучшение требований во время взаимодействия с владельцем продукта и заинтересованными сторонами — стейкхолдерами.
В Scrum-команде роль бизнес-аналитика может быть разнообразной в зависимости от контекста и потребностей. Основные модели включают в себя роль бизнес-аналитика как владельца продукта и как члена команды:
Владелец продукта. Бизнес-аналитик становится главным посредником между командой и стейкхолдерами, ответственным за понимание требований и определение приоритетов. Он создает карты пользовательских историй — User Story Map, бэклог продукта, участвует в планировании развития продукта или построении видения продукта — Product Vision, помогает команде разобраться в потребностях пользователей и стейкхолдеров.
Член команды. Бизнес-аналитик вносит отраслевую экспертизу по продукту, помогает разработчикам лучше понять пользователя, обсуждает и привносит новые идеи, решает возникающие процессные или бизнесовые проблемы, работает с QA-командой для проверки анализа и обеспечения соответствия требованиям, с командой дизайнеров — для улучшения пользовательского опыта или донесения ценности, помогает вести бэклог продукта.
Роль бизнес-аналитика при методологии Scrum
Сравнение методологий глазами бизнес-аналитика
Бизнес-аналитик может принимать участие в выборе методологии, а также активно сотрудничать с командой разработки и заказчиком для эффективной реализации проекта. Если сравнить приведённые выше методологии глазами бизнес-аналитика, то можно выявить следующие преимущества и недостатки.
Waterfall — «Водопад» | Agile | Scrum | |||
Плюсы | Минусы | Плюсы | Минусы | Плюсы | Минусы |
✅Жёсткое планирование и определённость требований изначально. ✅Хорошо подходит для проектов с чёткими и стабильными требованиями. | ❌Малая гибкость в изменении требований. ❌Большие сроки разработки. ❌Заказчик не включён в процесс. | ✅Гибкость и возможность быстрой адаптации к изменениям. ✅Активное взаимодействие с заказчиком и корректировка требований по ходу разработки. | ❌Не всегда подходит для проектов с жёсткими бюджетами и сроками. ❌Требует высокой вовлечённости заказчика и команды. | ✅Чёткое распределение ролей и обязанностей в команде. ✅Регулярные обновления и принятие корректив в ходе разработки. | ❌Может потребовать больших усилий на организацию команды и планирование. ❌Не всегда подходит для больших и сложных проектов. |
Если перед вами стоит выбор подходящей методологии для проекта с учётом особенностей работы бизнес-аналитика, рассмотрите следующие факторы:
степень изменчивости требований проекта;
уровень вовлечённости заказчика и его готовности к активному участию;
жёсткость сроков и ограничения бюджета;
размер и специфика проекта.
Выбор методологии разработки ПО в большой степени определяется спецификой проекта, и роль бизнес-аналитика должна соответствовать выбранной методологии. Умение адаптироваться к различным методологиям и использовать лучшие практики поможет бизнес-аналитику быть эффективным специалистом в различных проектах.
