Значение архитектуры для Agile разработки
В отличие от некоторых обсуждений, которые мы наблюдаем в сообществе разработчиков ПО, Agile разработка не является принятием Scrum или любого другого процесса, инструментария или методологии в качестве культа «карго», хотя мы, разумеется, следим за этим и считаем это проблемой. В основе гибкости (agility) лежит быстрое реагирование, обучение и достаточность. Гибкость отображается в надежности и качестве программного обеспечения. По определению, ненадежность и низкий уровень качества разработки препятствует и уменьшает ее гибкость. В манифесте указано, что “постоянное внимание, уделяемое техническому совершенству и качественному проектированию, увеличивает гибкость процесса”, предлагая архитектуре четкую роль в контексте Agile среды. Наш друг и коллега Дженс Колдвей утверждает, что архитектура – это то, что делает вас быстрее. Даже при наличии всего мирового Agile арсенала, именно архитектура, которая препятствует внесению запланированных вами изменений из-за своей непродуманности и несоответствия своим целям, в итоге сведет на нет и хороший процесс, и качественную архитектуру. Архитектура скорее будет играть против команды разработки и потока требований, чем на стороне команды и увеличения ее понимания целей системы и их реализации. Когда дело доходит до Agile, прагматичным разработчикам архитектуры нужно сосредоточиться на одном простом вопросе: какие элементы архитектуры блокируют гибкость команды? Не смотря на очевидную простоту вопроса, экспертам по техническому совершенству и проектированию придется пересмотреть целую кипу мнений, в очередной раз, подтверждая всю сложность этого ответа. Модульность в конфликте с моделью предметной области, нецелесообразная связность и нестойкое взаимодействие компонентов – все это значительно понижает уровень понимания разработчика и продлевает время компоновки программы и сроки ее выпуска, препятствуя процессу тестирования, внося мелкие изменения и экспериментируя. Любая форма ненужной необратимости в проектировании и бессмысленный, неструктурированный технический долг скорее всего повысят стоимость разработки и отрицательно отразятся на ее жизнеобеспечении, а соответственно и на гибкости. Что нужно архитектуре от процесса?Откуда появляется архитектура? Приносит ли ее аист? Или она приходит по электронной почте? А, может быть, она выпрыгивает уже в готовом виде из головы всезнающего и всевидящего разработчика? Или все-таки она появляется по счастливой случайности, как по мановению волшебной палочки? Давайте на минутку остановимся и осознаем, что архитектура – это проявление человеческих знаний. Разработка программного обеспечения – это наукоемкий труд, который влечет за собой процесс обучения — обучения методологиям, обучения пониманию желаний заказчика, обучения общению с разработчиками требований к продуктам, обучению наиболее эффективных способов разработки решений от практических методик до подбора вариантов, обучения совместной работе и так далее. Вкратце, знания приходят в процессе обучения, а обучение требует времени — а это именно то, что структурирует процесс. Точка минимального знания — или максимального незнания — находится в начале пути любой разработки, как для цельного продукта, так и для его релиза. Учитывая этот факт, будет неразумно и безответственно заранее принимать все важные решения. С другой стороны, в конце проекта, мы получаем наибольшее количество знаний, но и наименьшую возможность применения их на практике. Короче говоря, от процесса архитектуре нужно пространство и время на обучение, что само по себе не приемлет спешки в начале работы. Ни в коем случае нельзя рассматривать процесс, как готовый продукт, в самом начале его создания, если вы хотите, чтобы этот процесс можно было считать эмпирической деятельностью, в рамках которой каждое архитектурное решение рассматривается в качестве гипотезы, требующей проверки и отчетности, переданной для следующего решения. Проектные команды получают оплату не за удовлетворение требований процесса, а за доставку работающего программного обеспечения! Подобный подход, основанный на обратной связи и обучении, также удовлетворяет потоку требований. Важно отметить, что даже в тот момент, когда, казалось бы, требования уже определены и утверждены, поток требований не иссякает, поскольку рынки и политики постоянно генерируют поток изменений в требованиях. В программном обеспечении, как и в жизни, понимание зачастую приходит к нам во время попыток классифицировать вещи и рассуждать о них. Кроме того, в программном обеспечении, как и в жизни, мы часто осознаем во время обучения, что многие наши категории создают ошибочные и острые особенности и дихотомии, которые скрывают от нас то, что мы так стремимся понять. То же самое происходит с архитектурой и гибкостью. То, что вы можете построить, находится в прямой зависимости от того, как вы будете это строить; а то, как вы будете это строить, напрямую зависит и ограничивается его специфическими конструктивными особенностями. Эта тесная взаимосвязь между архитектурой и процессом означает, что разработчики архитектуры должны мыслить за пределами структурных граней и технологий на предмет того, каким образом процесс системной разработки разворачивается во времени. Подход комплексного планирования не лучшим образом будет содействовать программному обеспечению, его разработчикам или организациям вокруг них; Agile процесс реагирует на поток открытий и изменений, которые окружают любую систему. Прагматичным разработчикам архитектуры придется взять на себя роль по распознаванию и устранению любых препятствий на пути потока, которые могут сбивать с толку разработчиков и заинтересованные лица, заставляя их идти в обход архитектуры, вместо того, чтобы работать вместе с ней. -- Оригинал статьи: http://www.infoq.com/articles/architecture-and-agility-good-friends Авторы: Frank Buschmann, Kevlin Henney
Литература1 J. Rumbaugh, I. Jacobsen, and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1998. 2 J. Spolsky, “Architecture Astronauts Take Over,” 1 May 2008. 3 G. Booch, “On Design,” blog, Mar. 2006. 4 M. Fowler, “Who Needs an Architect?,” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13. 5 P. Dyson and A. Longshaw, Architecting Enterprise Solutions, John Wiley & Sons, 2004. 6 R. Faber, “Architects as Service Providers,”IEEE Software, vol. 27, no. 2, 2010, pp.33–40.
|
Еще интересные статьи на эту тему:
|
