ПРОБЛЕМЫ АРХИТЕКТУРЫ В ГИБКИХ МЕТОДОЛОГИЯХ РАЗРАБОТКИ ПО

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

Жизненный цикл разработки программного обеспечения обычно состоит из нескольких основных стадий. Первая стадия жизненного цикла, стадия анализа требований, направлена на выявление и обсуждение основных требований, предъявляемых к конечному продукту. Помимо основной цели этой стадии, заключающейся в определении и закреплении детальных требований к системе, ставится цель убедиться в том, что все участники разработки правильно поняли поставленные перед ними задачи и имеют представление о том, как это будет реализовано на практике. За стадией сбора требований, обычно идет этап проектирования архитектуры разрабатываемого ПО. На этом этапе программисты и системных архитекторы прорабатывают высокоуровневый дизайн системы, ориентируясь на разработанные на предыдущей стадии требования. Вслед за стадией проектирования уже непосредственно идут стадии разработки, тестирования, документирования и доставки готового продукта.

Стоит отметить, что все перечисленные выше стадии жизненного цикла в том или ином виде и в той или иной последовательности применяются в любой модели разработки ПО. Но обычно отличаются их длительность и порядок, включая условия перехода из одной стадии в другую. Самое точное совпадение всех этапов будет при применении жестких методологий разработки, таких как каскадная («водопадная») модель разработки, инкрементная модель, спиральная модель и другие, потому что жесткие методологии достаточно сильно стандартизованы и опираются на применение готовых методов. Такой подход в силу своей предсказуемости хорош для внешних заказчиков, которые по каким-то причинам не могут или не хотят тесно участвовать в процессе разработки. Но во многих ситуациях перегруженность такого стандартизованного процесса препятствует эффективности и не позволяет в полной мере использовать творческий потенциал сотрудников.

Недостатки жестких подходов разработки обусловили появление компромиссного подхода, называемого agile или гибкой (быстрой) разработкой. Этот подход ориентируется на итеративную разработку, обычно короткими циклами по несколько недель, с изменяющимися в процессе требованиями. Гибкий подход максимально полагается на самоорганизующуюся совместную деятельность команд с учетом личностных качеств исполнителей, а так же на привлечение заказчика к разработке на протяжении всего срока развития проекта. Благодаря этому применение гибких методологий возможно даже тогда, когда не удается достаточно точно описать требования к проекту в силу неопределенности реальных пользовательских потребностей.

Но одной из часто встречающихся проблем для продуктов, разрабатываемых по гибкой методологии, являются проблемы связанные с архитектурой. «При agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов, а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта» [1].

Проблема архитектуры для команд, работающих по гибким методологиям еще и в том, что часто очень многие архитектурные решения ложатся на плечи разработчиков, а не архитектора, так как зачастую постоянного архитектора в таких командах просто нет. Но,  во-первых,  опыта разработчиков недостаточно для принятия правильных решений, а во-вторых, многие разработчики опираются на принцип гибкой методологии, который гласит, что «простота — искусство минимизации лишней работы — крайне необходима» [2], при этом забывая о другом основном принципе: «постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта» [2]. Такой подход к простоте дает плохой старт для дальнейшего развития системы и, к сожалению, плохо работает  с нефункциональными требованиями, а их естественно нельзя игнорирования. Всё это периодически приводит в глобальным изменениям системы посреди итерации и накоплению критичных дефектов, в том числе и области безопасности ПО.

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

Конечно, гибкой команде не подойдет стандартный подход к разработке архитектуры всего проекта заранее по многим причинам, самой главной из которых является всеми известный принцип гибкой разработки, который и стоит в ее основе «изменение требований приветствуется, даже на поздних стадиях разработки» [2]. Хорошо продуманная архитектура, естественно, упрощает изменение направления развития проекта по мере того, как потребности клиента меняются или становятся более понятными, но не может заранее покрыть все возможные сценарии изменений. К тому же слишком много архитектуры может затруднить адаптацию новых решений и препятствовать дальнейшей гибкости.

Так что, вероятно, для таких команд нужно ввести понятие «гибкого архитектора». Например, в Scrum нет особого момента для разработки архитектуры программного обеспечения. Поэтому все дизайнерские решения, которые принимаются во время итерации (спринта), создают архитектуру программного обеспечения и воплощаются в части рабочего программного обеспечения. Спецификации архитектуры, проектные документы, процесс согласования и т.д. могут быть важны, но только тогда, когда они приближают команду к ее цели. Эти артефакты являются лишь средством достижения цели, а не самими задачами, поэтому им никогда не следует уделять первоочередное внимание и ставить выше рабочего кода. Как известно, только рабочее программное обеспечение является основным показателем прогресса при гибкой разработке. Если слишком много времени будет потрачено на документирование архитектуры вместо создания рабочего кода, то это будет уходом от гибких принципов. Так что гибкая архитектура должна обеспечивать правильный баланс между проектированием и разработкой программного обеспечения.

«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд» [2]. Этот принцип и связанное с ним значение Agile-манифеста, говорит о том, что большая архитектура, созданная командой архитекторов, не будет столь же эффективной, как внедрение архитектора в команду, чтобы он работал с разработчиками на протяжении всего проекта. Творческое сотрудничество с участием тех, кто фактически будет использовать готовый продукт, приведет к архитектуре, которая соответствует потребностям команды, а также требованиям заказчика.

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

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

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

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

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

В целом во всех аспектах архитектура должна рассматриваться как любая другая часть гибкого процесса:

• она должна начинаться с опытного архитектора;
• учитывать лучшие отраслевые практики, совмещая их с требованиями и стандартами организации;
• использовать ретроспективу и отзывы команды для внесения корректировок в уже разработанную архитектуру, чтобы обеспечить удовлетворение всех потребностей заказчика;
• на протяжении всего проекта она должна систематически анализироваться на соответствие стандартам качества, безопасности и другим объективным показателям;
• на протяжении всего проекта разработчики и архитектор должны работать вместе;

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

Список литературы:

1. Гибкая методология разработки // Википедия: свободная энциклопедия [электронный ресурс] — Режим доступа. — URL: https://ru.wikipedia.org/wiki/Гибкая_методология_разработки (дата обращения 25.11.2018)
2. Основополагающие принципы Agile-манифеста [электронный ресурс] — Режим доступа. — URL: https://agilemanifesto.org/iso/ru/principles.html (дата обращения 25.11.2018)
3. Жесткие и гибкие методологии разработки // PM Notes [электронный ресурс] — Режим доступа. — URL: http://pm-notes.ru/watflexmeth (дата обращения 25.11.2018)