2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
DESCRIPTION
TRANSCRIPT
Максим Юнусов
Архитектура в Agile проекте
E-mail: [email protected]
Skype: myunusov
ИТ-субботник Омск
6 апреля 2013
Докладчик
Java разработчик и архитектор компании Luxoft
Консультант по анализу и проектированию ПО
Тренер
– Курсы по программированию на языке Java
– Курсы подготовки архитекторов
– Курсы по различным методологиям и практикам разработки ПО
– Курсы по продуктам и методологии Rational
Исторический экскурс
Архитектура в классическом пониманииАрхитектураАрхитектура -
это базовая организация системы,
воплощенная в ее компонентах, их отношениях между собой и с окружением,
а также принципы, определяющие проектирование и развитие системы
[IEEE 1471]
Ключевой принцип RUP («Дух RUP»)
создавать архитектурный каркас как можно раньше
Agile-манифест разработки ПО
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
http://agilemanifesto.org/iso/ru/
Архитектура в “раннем” Agile
Большое и Подробное Предварительное Большое и Подробное Предварительное ПроектированиеПроектирование
«Отлить в граните»
Архитектура в “раннем” Agile (продолжение) Рефакторинг
Реактивный подход
«Решим эти проблемы позже» (“fix-it-later”)
Вносите в проект лишь такие изменения, которые могут указать дорогу к возможностям его улучшения
[Оуэр (Auer) и Бек (Beck) (Auer и Beck, 1996)]
Миф о рефакторинге
Рефакторинг сделает вам архитектуру
Исправление архитектурных проблем на поздних фазах проекта (после написания кода) стоит в сотни раз дороже, чем на этапе первичного конструирования системы
Проблемы
неизбежная неразбериха на старте
катастрофические «авралы» с массовым рефакторингом и переделками практически на каждой очередной итерации
реюз – безусловное зло
низкое качество продукта («работает, и ладно»)
«эффект автобуса»
Принципы дизайна
S (SRP) Принцип единственной обязанности
O (OCP) Принцип открытости/закрытости
L (LSP) Принцип подстановки Лискоу
I (ISP) Принцип разделения интерфейса
D (DIP) Принцип инверсии зависимостей
Архитектура в “развитом” Agile
термин "архитектураархитектура" передает идею основных элементов системы, тех ее частей, которые трудно изменитькоторые трудно изменить. Они являются фундаментом, на котором можно построить все остальное
[Статья "Проектирования больше нет?", Мартин Фаулер 2004 г.]
loan архитектура ?инкрементальная архитектура ?
Процесс
Архитектурные взаимодействия в Agile проектах
[James Madison http://www.infoq.com/articles/agile-architecture]
Предварительное планирование
Доска задач и баклог
Участие в спринте
Работающая система
Предварительное планирование
принимает основные решения по аппаратному и программному обеспечению
определяет важные шаблоны проектирования на высоком на детальном уровне
определяет основные возможности для повторного использования компонентов и сервисов
создает высокоуровневые диаграммы
описывает атрибуты качества
определяет каналы взаимодействия встречаясь с заинтересованными лицами (stakeholders), чтобы понять их проблемы и показать им основное техническое направление
Описывает атрибуты качества
Атрибуты качества представляют формальное выражение факторов качества ПО
Внешние факторы Внутренние факторы
Могут быть обнаружены пользователями
Понятны только для профессионалов
Факторы качества по Бертрану Мейеру
Качества ценные в Agile
Модульность Тестируемость
Простота Ясность
VS
Определяет важные шаблоны проектирования на высоком и на детальном уровне
базируясь на нефункциональных требованиях и архитектурных мотивах
Примеры
– Паттерны DDD
– DSL
– Onion
– MVP
– DCI
Определяет основные возможности для повторного использования компонентов и сервисов
«Горизонтальное» разделение труда
Ключевые механизмы
Архитектурный «довесок» к Scrum (stand-up) митингу
Принимает основные решения по аппаратному и программному обеспечению (hardware and software)
в основном используя существующие корпоративные стандарты
приводит “доказательства правильности концепции” (proofs-of-concept) при необходимости использования новых продуктов
“работает только простое”
Создает высокоуровневые диаграммы
UML sketch
Групповое ревью (Inspection, team review)
С некоторой периодичностью вся команда собирается перед проектором и оценивает новые архитектурные решения
–Повышается эффективность ревью за счет количества рецензентов
–Способствует передаче знаний и взаимному обучению
–Обеспечивает приятие архитектурных решений всей командой (commit от каждого разработчика)
"Коллективный архитектор"
Доска задач и баклог
Архитектор должен посещать ранние сессии по определению задач на доске (storyboarding) и добавлять архитектурные user story, которые задают фундамент или определяют архитектурное направление
Архитектор должен посещать последующие сессии по определению задач на доске между спринтами, чтобы вносить архитектурные user story, которые «настраивают» архитектуру или корректируют нежелательные отклонения
Архитектор должен работать с product owner-ом, чтобы приоритезировать эти истории и построить их в соответствии с бизнес функциональностью в спринтах
Архитектурный баклог
Ключевые механизмыЧасть задач может быть не выполнена, рекомендуется их приоритезация
Участие в спринте
Доверяй команде
Ad-hoc ревью
Участие в реализации оправданно, если спринт сошел с верного пути в архитектурном или другом смысле