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

Плюсы и минусы гибкого анализа требований

 

Роль системного аналитика

Чтобы понять, зачем вводится отдельная роль системного аналитика, взглянем внимательнее на обязанности владельца продукта.

Функции владельца продукта

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

Ксения Колосова, руководитель проектов

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

 

UML

Классическим подходом к описанию требований в виде модели является UML, который позволяет описать буквально каждый аспект системы в визуальном виде. Однако такой подход не является гибким:

• UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность;

• UML-диаграммы быстро теряют актуальность при начале разработки;

• UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга;

• UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста;

• UML неявно подразумевает водопадную модель разработки.

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

Наталья Лукьянчикова, аналитик

 

Процесс ICONIX

Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX.

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

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

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

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

ICONIX – подмножество UML

Структура процесса ICONIX

Диаграмма вариантов использования

Здесь отображаются роли пользователей (персоны из карт историй) и варианты применения, которые фактически являются более тяжеловесным вариантом историй пользователей. Обратите внимание на стереотипы «Эпик» и «Тема», которыми обозначены два варианта использования.

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

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

Диаграмма предметной области

Диаграмма классов

Для примера разберем один из вариантов использования и опишем его более подробно в виде диаграммы робастности, на которой будут отражены:

• граничные объекты – интерфейс взаимодействия с пользователями;

• котроллеры – бизнес-логика и различные алгоритмы;

• сущности – данные приложения.

Можно заметить, что данная диаграмма очень похожа на шаблон проектирования Model-View-Controller.

Диаграмма робастности

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

Диаграмма робастности нужна, чтобы:

• осуществить проверку полноты вариантов использования;

• выявить дополнительные объекты;

• проработать архитектуру на высоком уровне.

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

Пропасть между анализом и архитектурой

После такого анализа можно описать подробности алгоритма или логики в диаграмме последовательности.

Диаграмма последовательности

 

Стратегия актуализации документации

Если рассматривать проектную документацию, в том числе требования, с позиций бережливого производства, то она является мудой – потерей при производстве (подробнее потери при производстве описаны в гл. 11). Аналогичный принцип действует и в гибких методологиях: прогресс измеряется не по документации, а по конечному продукту, который является ценностью для заказчика.

Фактически аналитик должен выбрать одну из трех стратегий актуализации требований.

Стратегии обновления требований

Несмотря на то что Аgile-процессы ставят готовый продукт выше документации, роль документации не исключается как таковая. Принятые решения, ограничения системы, описание бизнес-процессов должны быть зафиксированы и доступны любому участнику команды.

Наталья Лукьянчикова, аналитик

Если документация не обновляется полностью, с какого-то момента начинают накапливаться различия между моделью (требованиями) и кодом.

Рост количества различий между моделью и кодом

 

Роль аналитика в Scrum

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

Место аналитики в Scrum

Получается, что аналитик как бы опережает команду на один спринт. У такого подхода есть свои плюсы и минусы.

Преимущества и недостатки

 

Роль аналитика в канбане

Плюсы и минусы работы в Scrum в канбане меняются местами: здесь аналитик работает наравне со всеми членами команды в потоке задач. Обычно ему выделяют дополнительный столбец на доске.

Столбец «Аналитика» для соответствующего состояния

Аналитик также попадает под третье правило канбана по оптимизации процесса с целью сокращения времени жизни задачи. По этой причине и из-за отсутствия спринтов время жизни при введении дополнительного этапа для аналитики в канбане так сильно не растягивается.

 

Прототипы

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

Ксения Колосова, руководитель проектов

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

Различные варианты прототипов

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

Прототип для веб-страницы

В рамках Scrum прототипы рекомендуется делать к конкретным историям пользователей в сочетании с текстовым описанием и диаграммами.