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

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

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

Последней практикой, которую мы рассмотрим, будет фиксированная сорокачасовая рабочая неделя. Это гарантия защиты команды от перегрузок, одного из видов потерь в бережливом производстве. Следует четко понимать, что количество отработанных часов не равно количеству сделанного функционала, как и в любой интеллектуальной и инженерной деятельности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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