Архитектурные взаимодействия в Agile проектах
| January 27, 2012 | Posted by admin under Практики, Статьи |
Автор: James Madison
http://www.infoq.com/articles/agile-architecture
Agile разработка начинается еще до того, как достигнуто полное понимание результата. Планы и дизайн уточняются по мере получения новых знаний. Agile разработка нацелена на то, чтобы доверять мнению тех, кто стоит ближе к проблеме. Поддерживается постоянное взаимодействие с заказчиками.Архитектура задает технологии, создает шаблоны проектирования, улучшает качество, и взаимодействует со всеми заинтересованными сторонами.Комбинация этих двух областей – это Agile архитектура, подход, который использует Agile методы для продвижения в сторону хорошей архитектуры. Для успешной Agile архитектуры требуется архитектор, который понимает суть Agile разработки, взаимодействует с командой в хорошо определенных точках, влияет на нее, используя навыки полученные из опыта работы архитектором в проектах с другими методологиями, и выполняет функции архитектора, независимые от проектной методологии.
Точки архитектурного взаимодействия
На Рисунке 1 показан гибрид scrum-а[1], экстремального программирования (Extreme Programming)[2] и последовательного управления проектом (sequential project management) – то, что я нашел эффективным для проведения работ по архитектуре в 14 Agile проектах, на протяжении последних восьми лет.
Рисунок 1. Гибридная схема для работ по Agile архитектуре. Вовлеченность архитектора в ход проекта помогает достигать проектных целей. Таблица 1, ниже, объясняет элементы схемы: точки взаимодействия (зеленым), критически важные навыки (золотым) и функции архитектора (красным).
Таблица 1 кратко описывает элементы Рисунка 1. Архитектурные функции – это те, которые обычно выполняет архитектор в проекте, хотя список не исчерпывающий.
Таблица 2 показывает, как архитектурные функции пересекаются с точками взаимодействия, и показывает основные проблемы архитектора на этом пересечении.Взятые вместе, три категории и четыре их пункта, составляют схему, полезную для понимания и выполнения Agile архитектуры. Эта схема может быть расширена за счет добавления большего числа категорий или пунктов, базируясь на других приоритетах и предпочтениях.
Предварительное планирование
В Agile проекте каждая функция архитектора начинается с предварительного планирования, как это в основном происходит и в других проектах, не зависимо от методологии. Архитектор:
- принимает основные решения по аппаратному и программному обеспечению (hardware and software), в основном используя существующие корпоративные стандарты, и возможно приводит “доказательства правильности концепции” (proofs-of-concept) при необходимости использования новых продуктов;
- определяет важные шаблоны проектирования на высоком[3] на детальном[4] уровне;
- определяет основные возможности для повторного использования компонентов и сервисов;
- создает высокоуровневые диаграммы;
- описывает атрибуты качества[5], технические и бизнес, и определяет их допустимый уровень[6]; и
- определяет каналы взаимодействия встречаясь с заинтересованными лицами (stakeholders), чтобы понять их проблемы и показать им основное техническое направление.
Хотя большинство из этих пунктов не отличается от работ в не-Agile подходах, предварительные работы по архитектуре для Agile разработки содержат небольшое, но важное отличие.Архитектура скорее должна включать набор опций, чем специфическое решение.Такой подход основывается на Agile допущении, что эмпирические знания, собранные всеми участниками при построении системы, сделают лучшие опции более очевидными[7].Результат будет успешным, если архитектор не ограничивается одним решением слишком рано, и особенно это важно при Agile разработке. Использование итераций, создание работающей системы после каждой итерации, поощрение взаимодействия, имеет обратный эффект, который дает всем участникам значительные возможности, чтобы найти лучшие решения позже, если они не смогли понять их раньше[8].
Например, в проекте хранилища данных возник вопрос: поставлять данные непосредственно в другое место или строить промежуточное хранилище. Прямая передача данных (direct feed) оказалась более сложной, что приводило к снижению надежности и эффективности работы. Однако промежуточное хранилище использовало больше места, что приводило к росту стоимости жизни системы.Архитекторы отметили следующее: 1) любой из этих вариантов отвечает целям бизнеса, 2) мы не может определить, какой дизайн лучше, 3) мы уверены, что команда сможет принять правильное решение в пределах архитектурных границ.По мере развития проекта ответ стал очевиден, команда его легко определила и архитекторы подписались под ним.Определение диапазонов и границ более соответствует Agile подходу, чем определение специфических решений, но архитекторы должны все же определить эти диапазоны и границы заранее.
Доска задач и баклог
Предварительное планирование быстро переходит в определение задач на доске (storyboarding) и в построение баклогов продукта и отдельного спринта, причем архитектор является основным заинтересованным лицом (stakeholder).Архитектор должен посещать ранние сессии по определению задач на доске (storyboarding) и добавлять архитектурные user story, которые задают фундамент или определяют архитектурное направление.Он или она должны также посещать последующие сессии по определению задач на доске между спринтами, чтобы вносить архитектурные user story, которые “настраивают” архитектуру или корректируют нежелательные отклонения. Архитектор должен работать с product owner-ом, чтобы приоритезировать эти истории и построить их в соответствии с бизнес функциональностью в спринтах.
Архитектор часто становится движущей силой на сессиях по определению задач на доске, поскольку у него или нее есть всеобъемлющие знания о бизнесе и технологиях.Я обнаружил, что хороший архитектор может определить требования на доске задач, исходя из бизнеса, объяснить технические ограничения людям из бизнеса, объяснить потребности бизнеса в технических терминах команде.Когда архитектор делает это, он или она может помочь всем сторонам достичь успеха, плавно интегрируя архитектурные user story в доску задач и в баклог.
Например, программа хранилища данных стремилась достичь высокого уровня интеграции корпоративных данных.Архитекторы выступали за использование размерного моделирования (dimensional modeling) как основного подхода [прим. переводчиков: см. http://www.interface.ru/public/wh/wh_.htm ]. Они также выступали за использование bus matrix [прим. перевод: см. http://en.wikipedia.org/wiki/Enterprise_bus_matrix] как основного инструмента для организации работы с данными, потому что bus matrix поддерживает декомпозицию и итеративность[9].Бизнес (и большинство технических специалистов) никогда не использовали bus matrix, поэтому архитекторы должны были проявить содействие на первой сессии по определению задач на доске.На третью сессию product owner-ы распечатали свои user story в формах bus matrix.К пятой сессии команда выразила обеспокоенность, что успех оценивается только по компонентам bus matrix. Поэтому, мы должны были немного отступить и отметить менее заметную работу, такую как повторно используемые компоненты, решение вопросов качества данных и внедрение новых инструментов. Подход получил свой собственный толчок, но стартовал он благодаря содействию со стороны архитекторов.
Участие в спринте
Написание кода – это мощный способ убедиться в том, что архитектор полностью понимает создаваемую архитектуру[10]. Но мы будем допускать, что организация получает большую ценность от того, что использует архитекторов сразу на нескольких проектах, хотя при этом снижается их способность вникнуть во все детали одного проекта.К счастью, agile предлагает решение—доверяй команде. Для этого нужно,чтобы архитектор взаимодействовал с командой во время спринта, понимая цели и помогая решить возникающие проблемы дизайна[11].Чтобы справиться одновременно с несколькими проектами, архитектор должен оставить специфику команде. Пока ревью архитектуры работающей системы показывает высокое качество архитектуры, архитектор может оставлять детали членам проектной команды, будучи уверенным, что их общие знания и глубокое знание задачи будут направлять работу над системой в нужное русло. Поэтому, реальное участие в реализации оправданно, если спринт сошел с верного пути в архитектурном или другом смысле.В такое время архитектор становится полноправным членом команды, размещается вместе с ней, и полностью подчиняется задачам команды.
Например, существует давний вопрос по архитектуре хранилищ данных: использовать нормализованное или размерное моделирование, и до какой степени[12]. В одном из agile проектов хранилища данных архитекторы решили этот вопрос так: для максимальной функциональности нужна реализация обеих моделей в их полной форме. После нескольких спринтов скорость проекта не соответствовала требуемым срокам – общая проблема, независимо от методологии.Чтобы посмотреть, помогут ли архитектурные изменения увеличить скорость проекта, в начале четвертого спринта я поучаствовал в проекте как полноправный член команды.На основе этого полноправного участия в проекте, а также вдохновенных замечаний от семи экспертов их двух команд, стало очевидно, что протаскивание всех данных через нормализованную модель, с тем чтобы положить их в размерную модель, не нужно для удовлетворения бизнес целям (для этого конкретного проекта, а не в общем). Мы планировали нормализованный уровень целый год, а потом, на базе нового понимания, мы убрали его в течение 30 дней. Для этого были нужны обсуждения с менеджментом и архитектурным руководством, но изменение было сделано в следующем спринте и дало проекту значительное увеличение скорости.
Работающая система
После каждого спринта команда и product owner должны представить работающую систему на ревью спринта, чтобы все заинтересованные лица, одним из которых является архитектор, могли увидеть общий прогресс и дать свои комментарии.Ревью спринта обычно длится всего несколько часов, с множеством стейкхолдеров, соперничающих за время разговора, поэтому архитектору стоит начать ревью работающей системы за несколько дней до официального ревью.Некоторые аспекты все еще могут быть в работе, но при обычных подходах к окончанию спринта система должна быть достаточно стабильной для того, чтобы сделать ревью, которое имеет смысл. Хорошо управляемые Agile проекты требуют итеративную поставку документации вместе с работающей системой, включая архитектурную документацию. Незадокументированный код и системная функциональность не должны рассматриваться как рабочая система. Ревью этой документации, когда она появляется в каждом спринте – это полезная форма архитектурного ревью.Что более важно, архитектор должен делать ревью работающей системы, заглядывая глубоко в код и в системную функциональность.
Например, за последние десять лет я накопил 700 скриптов, которые автоматизируют архитектурный анализ платформы хранилища данных или системы обработки данных. Когда мои команды выпускают работающую систему, я запускаю свои скрипты.За минуты я получаю отчеты, которые подробно описывают здоровье платформы, схему, модель данных, качество данных и другие аспекты архитектуры. Выявленные проблемы могут быть решены в текущем спринте или поставлены в очередь в баклог. Для ускорения процесса я предлагаю командам свои скрипты, чтобы они сами смогли сделать автоматизированный анализ архитектуры без меня.Безусловно, у них есть и свои ценные скрипты, которыми они проверяют что-то важное, что пропустил я. Вместе мы повышаем архитектурное качество системы, когда мы стараемся обойти друг друга в автоматизации проверки архитектуры.
Навыки Agile архитектора
Участие в этом взаимодействии в качестве архитектора – это бурный опыт.Все заняты, разработчики могут смотреть на архитектора со скептицизмом, и кажется что всегда есть приоритет бизнес целей, который оправдывает отход от хорошей архитектуры. Для уменьшения волнений нужно много тонких навыков, которые приходят только с опытом, но следующие четыре возглавляют список.
Декомпозиция в форме спринтов
Agile разработка требует, чтобы product owner сделал декомпозицию user story до такого уровня, когда они достаточно малы, чтобы их можно было сделать за спринт, но вместе с тем достаточно значительны, чтобы можно было показать ценность для бизнеса. Подобно этому техническая команда разделяет user story так, чтобы их можно было эффективно собрать во время билда. Вклад архитектора в декомпозицию заключается в том. чтобы определить границы архитектурной значимости и работать вместе с product owner-ом и технической командой, чтобы убедиться, что общая декомпозиция работы соответствует этим границам. Архитектурно значимая граница существует между любыми двумя наборами бизнес или технической функциональности, чьи аппаратное обеспечение и ПО, шаблоны дизайна или атрибуты качества нетривиально разные.Рассмотрим два примера на Рисунке 2.
Рисунок 2. Все участвуют в декомпозиции user story к форме, которую можно сделать за спринт. Архитектор участвует, используя границы архитектурной значимости, как показано в этих примерах. Числа соответствуют спринтам или частям спринтов, в зависимости от объема работы.
В первом примере нам нужно построить корпоративный веб сервис для данных третьей стороны, используя сервис ориентированную архитектуру (service-oriented architecture, SOA). Проектная команда использовала подход с девятью спринтами, структурированный вокруг трех основных областей технической функциональности: интерфейс сервиса, уровень сохраняемости (persistence layer) и получение внешних данных.В первых двух спринтах команда опубликовала интерфейс сервиса.Вызов сервиса возвращал только одну жестко прописанную запись, но транзакция была через абсолютно функциональный вызов сервиса с хорошо определенным контрактом.Архитектурно это задействовало Java, стандарты веб сервисов, XML, шаблоны вызова, и дало клиентской системе результат для построения экранов, которые можно было показать бизнесу. Во второй группе спринтов команда сделала так, что сервис мог возвращать около 100 записей из локальной базы, но пока не от внешнего поставщика.Это определило базу данных, модель данных и объектно-ориентированный слой для работы базой, и дало больше кейсов, которые можно было показать на бизнес ревью. В третьей группе спринтов команда сделала запросы сервера к внешнему поставщику данных.Это включило в себя решение вопросов межсетевой защиты, формата данных внешнего поставщика данных, и требований к времени задержки. С самого начала растущая функциональность сервиса показывала меру прогресса основываясь на работающей системе, позволяя команде сфокусироваться на более узком наборе технических вопросов, и в то же время давая бизнесу видимый результат.
Во втором примере мы должны были поставить большое хранилище данных. С точки зрения бизнеса поставляемые компоненты можно было бы легко декомпозировать на уровне субъектов данных, которые красиво отображались в структуру таблиц. Но с технической точки зрения атрибуты внутри таблицы могут иметь значительные архитектурные различия.Например, премии и потери – это основная страховая информация, которую получают прямо из систем-источников, но пересчитанные премии и обнаруженные потери требуют сложных вычислений, которые сами по себе представляют собой системы[13].С точки зрения бизнеса, премии – это одна категория, а потери – это другая. С точки зрения архитектуры, основные атрибуты данных – это одна категория, а атрибуты определяемые по сложным вычислениям – это другая категория.Чтобы сбалансировать эти различия, команда разделила работы по сложности, что позволило быстро поставить основные атрибуты и постепенно добавлять более сложные атрибуты.
В каждом из этих примеров, и в общем[14], команде нужно уделять как можно больше внимания тому, чтобы сделать декомпозицию в соответствии с требованиями бизнеса. Но для эффективной поставки проекта архитектурные границы должны иногда преобладать, потому что перепрыгивание через архитектурные границы может принести слишком много одновременных проблем, вызывая риск для проекта.Если бы мы попытались декомпозировать задачу по данным в примере с SOA, так как мы это сделали с хранилищем данных, команде пришлось бы обратиться ко многим новым технологиям сразу. Это бы привело к большим проблемам, даже если бы для бизнеса было предпочтительней увидеть живые данные намного раньше, чем он их увидел.
Аналогично, если бы в примере с хранилищем данных мы сделали декомпозицию по технологическим уровням, это бы замедлило поставку основных атрибутов до скорости сложных.Это бы привело к серьезной недопоставке, даже если бы бизнес предпочел увидеть сложные атрибуты так быстро, как это возможно. То, что нельзя использовать декомпозицию из одного примера в другом примере, говорит о том, что характер декомпозиции должен соответствовать природе поставляемой системы.
Взаимодействие с Product Owner-ом
Путь от декомпозированной проблемы к работающей системе лежит через product owner-а, и архитектору необходимо показать ценность архитектурных работ product owner-у. Наиболее критические аспекты этого относятся к созданию и рефакторингу дизайна системы, и к определению ценности атрибутов качества в терминах бизнеса.Каждая из этих задач требует времени команды, которой еще надо закончить с бизнес функциональностью.Если product owner не понимает ценность архитектурных работ, то эта работа будет постоянно получать низкий приоритет в баклоге, что в результате выльется в плохую архитектуру.
К счастью почти все работы по дизайну имеют непосредственное отношение к атрибутам качества, и почти все улучшения атрибутов качества переводятся в ценность для бизнеса.Сопровождаемость (maintainability) системы позволяет делать бизнес функциональность на более поздних спринтах быстрее, быстрее внедрять в жизнь желаемые улучшения, что в свою очередь дает более высокую скорость выхода на рынок.Масштабируемость позволяет поддерживать высокую производительность, даже когда система проходит через пик активности во время маркетинговой компании, что предотвращает потерю бизнеса в критические моменты.И так далее. Естественно связь хорошей архитектуры с ценностью для бизнеса не уникальна для Agile разработки.Но власть, которую Agile разработка дает product owner-у, делает особенно важной необходимость объяснять значение хорошей архитектуры часто. Особенно важна эта пропаганда на первых нескольких спринтах, когда нужно построить базовые для архитектуры компоненты, которые сложно изменить впоследсвтии[15], и эта работа невидима для пользователей.
Например, мы делали интранет приложение, в котором предполагалось иметь около 300 экранов ввода. Мы могли бы сделать столько экранов, сколько возможно на первых нескольких спринтах, чтобы показать быстрый прогресс и вселить уверенность в заинтересованных лиц. Тем не менее мы убедили product owner-а позволить команде построить гибкий дизайн ввода полей, который бы можно было широко использовать на всех экранах.Это привело к тому, что на первых спринтах было мало экранов, но зато повысилась сопровождаемость системы. Ближе к концу проекта это позволило значительно повысить скорость создания экранов, что было бы невозможно, если бы мы не объяснили product owner-у важность ранних архитектурных работ, и не получили бы согласие на эти работы.
Архитектурный баклог
Как все заинтересованные лица, архитектор хочет добавить в систему функциональность намного быстрее, чем это позволяет скорость разработки. поэтому часть функциональности (в этом случае – архитектурной) должна быть помещена в баклог. Как это обычно делается, работы размещаются в порядке приоритетов, и если недостаточно денег или времени для работы, она может не быть выполнена. Вы можете возразить. что это приведет к нарушению архитектуры. Конечно, если архитектурные работы получают настолько низкий приоритет, что они никогда не будут сделаны, то архитектура деградирует. Но правильное использование принципов баклога и правильное отстаивание интересов при общении с product owner-ом приводит к тому, что значимые работы по архитектуре будут сделаны, а менее значимые потенциально могут и не быть выполнены до конца проекта.
Чтобы иметь четкое представление об архитектуре и чтобы определять приоритет работ, нужен отдельный архитектурный баклог для отслеживания архитектурных работ.Согласно большинству литературы, есть только один баклог.На практике, мне показалось полезным поддерживать несколько физических баклогов, каждый из которых сфокусирован на своей цели, но все они вместе составляют один логический баклог.Баклог того, что выходит за рамки проекта (out-of-scope backlog) определяет то, что не является целью проекта, баклог пожеланий (wish list backlog) перечисляет работы, которые вероятно никогда не будут сделаны. и т.д.Такая модульность помогает оставлять понятным основной баклог, и не терять при этом перспективу. То же самое с архитектурным баклогом. Он поддерживается архитектором, сообщается product owner-у и команде в подходящее время и в подходящем месте. Пункты из этого лога передвигаются в основной баклог в зависимости от решения product owner-а, под влиянием архитектора. Я считаю, что очень полезно дать пунктам вес и оценку, которая показывает степень архитектурного качества проекта. Такая оценка дает понятный механизм для подталкивания product owner-а, чтобы можно было передвигать истории из архитектурного в основной баклог, и сделать их.
Инкрементальная архитектура предприятия
Подход к архитектуре, который я пропагандирую, базируется на инкрементном подходе к построению ПО. В основном этот подход касается проектных бизнес целей, но максимальную ценность для крупной организации можно получить поддерживая этот подход для всей архитектуры предприятия.
Использование четырех функций, которыми мы себя здесь ограничили, я определяю архитектуру предприятия как процесс, который обеспечивает то, что архитекторы:
- используют стандартные средства аппаратного и программного обеспечения,
- используют одни шаблоны проектирования и язык,
- делают оценку по одним и тем же атрибутам качества, используя те же определения и одну и ту же шкалу,
- делают все это внутри систем и на межсиситемной основе,
- взаимодействуют друг с другом и со своими product owner-ами.
Межсистемное требование базируется на наблюдении, что системное взаимодействие потенциально вводит новый уровень шаблонов дизайна[16] и может сместить все атрибуты качества. Например, две системы могут масштабироваться индивидуально,но не масштабироваться, когда они взаимодействуют. В основном это определение архитектуры предприятия не зависит от agile, но с точки зрения agile, основные аспекты – это взаимодействие и сотрудничество между архитекторами, архитекторами и технической командой и product owner-ами.
Взаимодействие между архитекторами лучше всего достигается, когда есть централизованные практики и формальные процессы архитектуры предприятия. Высшее руководство должно создавать эти практики, убедится, что они помогают и измеряют взаимодействия между архитекторами. Руководство должно финансировать их в той мере, в какой оно заинтересовано в достижении хорошей архитектуры предприятия. Однажды сформировавшись, эти практики должны устанавливать формальные процессы и инструменты, такие как архитектурный руководящий комитет (steering committee), который публикует формальные архитектурные оценки, процесс совместного ревью (peer review) который проверяет наличие проблем и внедряет действенные улучшения, и управление растущим набором стандартов, которые появляются во время работ над проектами.Но во все времена, должны доминировать следующие два ключевые agile соображения. Во-первых, это сообщество взаимодействующих лиц, а не просто процесс или коллекция артефактов.Во-вторых, сила этого процесса не в его формальной власти, а в законах, которые он порождает из архитектурной экспертизы и прямого участия в проектной работе.
Взаимодействие с agile командой и product owner-ами лучше всего достигается за счет физической децентрализации архитекторов и за счет того, что они обсуждают проблемы архитектуры предприятия в моменты взаимодействия.Централизованные активности, которые я предлагаю, являются важными, но не основными в работе архитектора. Архитектор должен проводить столько времени, сколько это целесообразно, вместе с командой и product owner-ом, чтобы максимизировать возможности для прямого общения.Когда архитектор защищает аспекты архитектуры для проектной работы, он или она должны использовать доводы архитектуры предприятия. Например, когда архитектор защищает определенный набор ПО и аппаратного обеспечения, нужно основывать это не только на нуждах проекта, но также на направленности архитектуры предприятия – подобно шаблонам дизайна и атрибутам качества.Это особенно важно для вопросов межсистемного взаимодействия. Архитектор может понять динамику межсистемного взаимодействия, в отличие от команды и product owner-а, поэтому архитектор ответственен за то, чтобы сделать видимыми скрытые проблемы или определить более широкие возможности, которых не увидят другие. Основной целью для всех, включая архитектора,остается бизнес функциональность, для которой проект был профинансирован, и краткосрочные проблемы, которые возникают во время проекта.Но хорошее видение целей архитектуры предприятия и эффективное включение хорошей архитектуры на каждом спринте на каждом проекте, ведут к постоянному совершенствованию архитектуры предприятия.
Например, в 2009 году моя компания получила промышленную награду за “Создание Agile бизнес интеллектуальной инфраструктуры.”[17] Компания профинансировала проект по бизнес причинам в 2008 году, тогда как архитектура была задумана в 2006 – за два года до любой возможности реализовать ее. Проблема была в том, что исследователи, работавшие над архитектурой, использовали платформу, изолированную от основного хранилища данных, что привело к высокой избыточности данных и неправильным процедурам. В то же время, основное хранилище данных использовало технологии, которые не отвечали нуждам исследователей, и имело слишком большие ограничения для исследовательских работ.
На основе многолетней работы с двумя отделами и понимания их уникальной культуры и окружения, архитекторы предложили золотую середину: слой, который использовал технологии исследовательской платформы вместе с процедурами и централизованными данными хранилища данных, которые были адаптированы, чтобы сбалансировать исследовательские гибкость, сопровождаемость и эффективность. Архитектурное решение лежало на полке два года. Когда проекту предоставилась возможность продвинуть архитектурное решение, архитекторы использовали это. Успех был признан организацией и индустрией, а повторное использование сделало архитектуру привлекательной для будущих проектов.
Agile и архитектура не противостоят друг другу. Agile разработка дает архитектору повторяющуюся возможность работать вместе с бизнес и технической командой, чтобы непрерывно вести системы к хорошей архитектуре. Это создает проблемы, некоторые из которых связаны с трудностью достижения хорошей архитектуры, независимо от методологии, некоторые возникают из-за необходимости двигаться к далеко идущим результатам, используя серию краткосрочных мероприятий. Упрощая agile методы подобно тому, как это было описано здесь и имея влияние в критических точках взаимодействия, квалифицированный архитектор сможет адаптироваться к agile разработке, оставаясь при этом сфокусированным на архитектурных работах. Это будет гарантировать, что поведение большинства отдельных систем и общей архитектуры предприятия соответствует сегодняшним нуждам бизнеса, и технически устойчиво на годы – это архитектурная ценность, независимо от методологии поставки.
Об авторе
James Madison – старший архитектор в крупной страховой компании и основной инструктор на agile тренингах в отделе архитектуры предприятия. Его agile проекты включают Web, клиент-ориентированную, сервис ориентированную архитектуру, хранилища данных, и не традиционные для agile проекты, такие как построение инфраструктуры и миграция платформы. Madison имеет степень магистра по computer science, Rensselaer Polytechnic Institute. Контакты: madjim@bigfoot.com.
[1] K. Schwaber, Agile Project Management with Scrum, Microsoft, 2004
[2] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley Professional, 2004
[3] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002
[4] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1995.
[5] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley Professional, 2003, pp. 71–98
[6] R. Kazman, M. Klein, and P. Clements, ATAM: Method for Architecture Evaluation, tech. report CMU/SEI- 2000-TR-004, ESC-TR-2000-004, Software Eng. Inst., Carnegie Mellon Univ., 2000.
[7] M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley Professional, 2003, pp. 38–45, 103–111.
[8] K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2002, pp. 23–30
[9] R. Kimball and M. Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling,” John Wiley & Sons, 2002, pp. 78–88
[10] V. Subramaniam and A. Hunt, Practices of an Agile Developer: Working in the Real World, Pragmatic Bookshelf, 2006, pp. 155–157
[11] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11:13
[12] M. Ross and R. Kimball, “Differences of Opinion,” Intelligent Enterprise, 6 Mar. 2004
[13] J. Madison, Very Large Calculation Systems, Casualty Actuarial Soc., 2009
[14] J. Shore and S. Warden, The Art of Agile Development, O’Reilly, 2008, pp. 214.
[15] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11:13
[16] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison-Wesley Professional, 2003
[17] “Best Practices in Business Intelligence: Creating an Agile BI Infrastructure,” Computerworld, 2009;
http://www.computer.org/portal/web/computingnow/softwareThis article first appeared in IEEE Software magazine. IEEE Software‘s mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.
Pingback: Software Architecture in Practice (2nd Edition) | Software Architecture In Practice()