Выбрав какую либо методологию для проекта, обычно, ее необходимо адаптировать, дополнить. Так, например, часто Scrum дополняют при помощи XP. Но даже в этом случае процесс формирования архитектуры определен слабо, что является одной из основных причин драматичного падения скорости разработки через несколько месяцев или провалу проекта.
В данном цикле статей, автор предлагает свое видение архитектурных процессов в рамках Scrum, которые вытачивались им на нескольких проектах (мобильные банки), в том числе на текущем (FreshCRM). Область применения подхода: business critical, mission critical и life critical проекты.
В статьях используются определения, термины и подходы архитектурной школы Carnegie Mellon Software Engineering Institute (SEI), равно как и авторов, связанных с этой школой. Так же предполагается, что команда не нарушает базовые принципы Scrum, такие как, например, самоорганизация. При этом, не обязательно, чтобы команда состояла из высококлассных специалистов, как требует Scrum. Достаточно наличие компетенций в команде, у Scrum Master или Architecture Owner-а (о нем позже).
Введение первую статью
Первая статья цикла касается основы разработки — требований. Предлагается категоризация, подход по их ведению, а также вариант по формализации. Формирование требований выходит за рамки данной статьи, хотя примеры подходов будут.
Определения
В рамках данной статьи под архитектурой понимаем определение данное в книге Software Architecture in Practice (SAP) «The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.» Самый нижний уровень, до которого еще речь идет об архитектуре — это концепты и сущности. Классы, методы, атрибуты и тд выходят за данное понятие.
Стейкхолдер — лицо получающее выгоду или убыток от успешной реализации проекта.
Типы архитектурных требований (АТ) и их формализация
Ниже рассмотрим типы требований к системе, которые по мнению SEI, оказывают влияние на архитектуру и необходимы/достаточны для принятия архитектурных решений. В SAP они упоминаются как architecture drivers. В зависимости от этих требований и их взаимовлияния подбираются те или иные архитектурные паттерны и тактики.
Высокоуровневые Функциональные Требования (ФТ)
В англоязычной литературе можно встретить под названием High-Level Functional Requirements.
Эти требования описывают то, что должна система делать, какой функционал предоставлять, но в общих, отдаленных чертах. Обычно, это тот уровень, которым оперирует заказчик. Например, личный кабинет покупателя, поиск и выбор товара, оплата с карты, личный кабинет продавца, ведение каталога товара, моментальное оповещение о заказе.
Описывать такие требования можно в виде коротких предложений или фраз. Как удобно, главное не терять суть. Однако, бывает полезно их описывать в виде очень глобальных пользовательских историй. Ибо, тогда людям, вовлеченным в формирование архитектуры будет видно не только что надо сделать, но также для кого и с какой целью. Т.е. трасиируемость требований. Это в свою очередь положительно влияет на качество архитектуры, на достижение ею целей стейкхолдеров. Также, это позволит в будущем извлекать более мелкие пользовательские истории. Они в свою очередь так же могут оказать влияние на архитектуру-обычно уточняющее.
Удобно их записать в Видении проекта еще на стадии инициации проекта (Sprint 0, Initiation Phase, Inception Phase) и поддерживать там. Одновременно в таск-трекере вести их как большие User Story, вехи, инициативы и тд в зависимости от выбранного формата ведения требований. Например, при совместном использовании Confluence и Jira от Atlassian в последнем удобно создать Epic, а в первом удобно создать видение проекта и интегрировать данные Epic-и.
Разумеется, часть из этих требований со временем может стать не актуальной или появятся новые. Особенно после очередного CusDev. Это может повлиять на архитектуру очень сильно, но обычно просто появлением еще одного компонента.
Нефункциональные требования / Атрибуты Качества (АК)
В англоязычной литературе можно встретить под названием Non-Functional Requirements или Quality Attributes.
Эти требования описывают то, какими качествами должна система обладать и до какой степени. Например, она должна быть доступна в 99.9999% времени, цикломатическая сложность метода должна быть меньше 7. Это те самые слова, которыми оперируют, говоря о качестве продукта: security, reliability, maintainability, и тд.
Таких атрибутов качеств системы очень много (свыше 170, согласно некоторым публикациям). Определение какими из них система должна обладать осложняется тем, что они «вложены» друг в друга. Так, например, невозможно сказать, что performance или reliability не «вложены» в usability. Поэтому часто используют корпоративные или индустриальные стандарты, такие как ISO 25010, в качестве справочника/чеклиста таких характеристик. Полезно бывает сесть с заказчиком и пройтись по данному ISO обсудив с ним и выбрав релевантные атрибуты качества. Этот список так же будет отправной точкой для Плана Качества (Quality Plan), но это отдельная история и, возможно, отдельный цикл статей.
АК часто мешают друг другу. Так, чтобы обеспечить надежность системы часто приходится жертвовать производительностью. Так же производительность в конфликте с сопровождаемостью (maintainability). Поэтому важна приоритезация таких АК, чтобы понимать, что для системы важнее и принимать соответствующие решения. Например, если важно покрыть Android приложение тестами (testability), то может скорее всего будет применен паттерн MVP. Если же такой потребности нет и приложение несложное, то, возможно будет лучше оставить MVVM.
Наконец, система в любом случае обладает этими качествами, но в какой-то степени. Например, у системы не может быть нулевой производительности или «полной». Более того, небольшое повышение какой-либо характеристики может означать существенное изменение в архитектуре и существенное увеличение бюджета. Поэтому из всех возможных АК выделяют только те, которые наиболее значимы для системы и стараются определить необходимый и достаточный уровень.
Одним из наиболее конкретных и строгих форматов ведения АК является так называемый «6 part scenario»:
| Поле | Значение |
|---|---|
| Source (источник) | Пользователь |
| Stimulus (триггер) | Запрос пользователя |
| Artifact (затрагиваемый артефакт) | Система |
| Environment (условия) | Run-time, без учета зависимости от сторонних сервисов |
| Response (реакция системы) | Пользователь может воспользоваться системой |
| Response measure (измерения) | 99, 999 % времени |
Их можно прикладывать как один из Acceptance Criteria к User Story или Epic. Так же они могут быть частью Definition of Done (Done Criteria). Так как обычно АК относятся к большой части системы или к ней целиком, то описывать их часто необходимо на уровне Epic.
Более простой и менее строгий формат написания — в одном предложении в Acceptance Criteria (например, скорость отклика системы должна быть 0.5 сек). Такой формат вполне допустим и достаточен, если из Done Criteria ясно следует, например, где, кем и при каких условиях будет проводиться тестирование этого приемочного критерия. Например, user story должна быть опубликована на staging environment и протестирована при 200 запросах/сек в течении 10 минут в таких-то условиях.
Ограничения (Constraints)
Ограничения в свою очередь подразделяют на бизнес-ограничения (Business Constraints) и технические (Technical Constraints). К какой бы категории они не относились, ограничениями является то, что никак нельзя изменить или отменить, причем даже как какой-то доли. Оно либо удовлетворено, либо нет. Это и есть их главное отличие от атрибутов качества, которые могут быть удовлетворены на какую-то X%.
Например, система должна поддерживать Windows 8.0 и выше; использовать .Net, ибо, закуплены лицензии и корпоративная культура базируется на нем. Ограничением может быть бюджет, штат, оргструктура, операционная система, ПО, инструменты разработки, библиотеки, hardware и другие.
Если ограничения имею отношение ко всей системе в целом, то их можно перечислить в Видении проекта. Если же к какой-то части системы, то, как и АК, в Acceptance Criteria соответствующей Epic. Формат обычно короткое предложение.
Видение проекта
Для наглядности, приведу оглавление видения текущего проекта. Видение проекта — это живой документ, в котором ведется общая базовая информация и из которой все берет начало. Конституция проекта, так сказать. Структура его формируется под конкретный проект.
- Цель
- Проблема и решение
- Стейкхолдеры и ранние последователи
- Высокоуровневые функциональные требования
- Атрибуты качества
- Ограничения
- Ключевые показатели
- Риски
В данном случае документ касается только части разработки. В других проектах, например, были пункты про маркетинг и продвижение, процессы и роли, ключевые партнеры и другое.
Резюме
Итак, в данной статье были рассмотрены типы архитектурно значимых требований, их формализация и примеры. Более детальную информацию о них можно найти в источниках в списке литературы. Процессы и роли будут рассмотрены в следующей статье.
Литература
[SG] Scrum Guide, Кен Швабер и Джефф Сазерленд, 2013
[SBoK] Scrum Body of Knowledge, Scrum Institute, 2016
[SAP] Software Architecture in Practice, Rick Kazman, Paul Clements, Len Bass, 2012
[DAD] Disciplined Agile Delivery, Scott Ambler and Mark Lines, 2012
5. ISO 25010.
Автор: asirazhi
