6 апреля 2013 г. в омском филиале Luxoft прошел пятый IT-субботник – открытая встреча для IT-специалистов. Максим Юнусов, тренер Luxoft Training по анализу и проектированию ПО, представил доклад «Архитектура в Agile проекте». В своем выступлении Максим рассказал об архитектуре в «раннем» и в «развитом» Agile, принципах дизайна, мифе о рефакторинге и факторах качества по Бертрану Мейеру, а также о качествах, ценных в Agile, и архитектурных взаимодействиях в Agile проектах.

1. ИТ-субботник
Омск
6 апреля 2013
Архитектура в Agile
проекте
Максим Юнусов
E-mail: myunusov@luxoft.com
Skype: myunusov

2. Докладчик
 Java разработчик и архитектор компании Luxoft
 Консультант по анализу и проектированию ПО
 Тренер
– Курсы по программированию на языке Java
– Курсы подготовки архитекторов
– Курсы по различным методологиям и практикам разработки
ПО
– Курсы по продуктам и методологии Rational

3. Исторический экскурс

4. Архитектура в классическом понимании
Архитектура -
это базовая организация системы,
воплощенная в ее компонентах, их отношениях между
собой и с окружением,
а также принципы, определяющие проектирование и
развитие системы
[IEEE 1471]
Ключевой принцип RUP («Дух RUP»)
создавать архитектурный каркас как можно раньше

5. Agile-манифест разработки ПО
 Люди и взаимодействие важнее процессов и инструментов
 Работающий продукт важнее исчерпывающей
документации
 Сотрудничество с заказчиком важнее согласования
условий контракта
 Готовность к изменениям важнее следования
первоначальному плану
http://agilemanifesto.org/iso/ru/

6. Архитектура в “раннем” Agile
 Большое и Подробное Предварительное
Проектирование
«Отлить в граните»

7. Архитектура в “раннем” Agile
(продолжение)
 Рефакторинг
 Реактивный подход
 «Решим эти проблемы позже» (“fix-it-later”)
Вносите в проект лишь такие изменения, которые могут
указать дорогу к возможностям его улучшения
[Оуэр (Auer) и Бек (Beck) (Auer и Beck, 1996)]

8. Миф о рефакторинге
 Рефакторинг сделает вам архитектуру
Исправление архитектурных проблем на поздних фазах
проекта (после написания кода) стоит в сотни раз
дороже, чем на этапе первичного конструирования
системы

9. Проблемы
 неизбежная неразбериха на старте
 катастрофические «авралы» с
массовым рефакторингом и
переделками практически на каждой
очередной итерации
 реюз – безусловное зло
 низкое качество продукта («работает, и
ладно»)
 «эффект автобуса»

10. Принципы дизайна
 S (SRP) Принцип единственной обязанности
 O (OCP) Принцип открытости/закрытости
 L (LSP) Принцип подстановки Лискоу
 I (ISP) Принцип разделения интерфейса
 D (DIP) Принцип инверсии зависимостей

11. Архитектура в “развитом” Agile
термин "архитектура" передает идею основных
архитектура
элементов системы, тех ее частей, которые трудно
изменить. Они являются фундаментом, на котором
изменить
можно построить все остальное
[Статья "Проектирования больше нет?", Мартин Фаулер 2004 г.]
loan архитектура ?
инкрементальная архитектура ?

12. Процесс

13. Архитектурные взаимодействия в Agile
проектах
 Предварительное
планирование
 Доска задач и баклог
 Участие в спринте
 Работающая система
[James Madison http://www.infoq.com/articles/agile-architecture]

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

15. Описывает атрибуты качества
Атрибуты качества представляют формальное выражение факторов
качества ПО
Внешние факторы Внутренние факторы
Могут быть обнаружены Понятны только для
пользователями профессионалов

16. Факторы качества по Бертрану Мейеру

17. Качества ценные в Agile
Модульность Тестируемость
Простота Ясность
VS

18. Определяет важные шаблоны
проектирования на высоком и на
детальном уровне
 базируясь на нефункциональных требованиях и
архитектурных мотивах
Примеры
– Паттерны DDD
– DSL
– Onion
– MVP
– DCI

19. Определяет основные возможности для
повторного использования компонентов
и сервисов
 «Горизонтальное» разделение труда
 Ключевые механизмы
 Архитектурный «довесок» к Scrum (stand-up) митингу

20. Принимает основные решения по
аппаратному и программному обеспечению
(hardware and software)
 в основном используя существующие корпоративные
стандарты
 приводит “доказательства правильности концепции”
(proofs-of-concept) при необходимости использования
новых продуктов
 “работает только простое”

21. Создает высокоуровневые диаграммы
UML sketch

22. Групповое ревью (Inspection, team review)
С некоторой периодичностью вся команда собирается перед
проектором и оценивает новые архитектурные решения
–Повышается эффективность ревью за счет количества
рецензентов
–Способствует передаче знаний и взаимному обучению
–Обеспечивает приятие архитектурных решений всей командой
(commit от каждого разработчика)
"Коллективный архитектор"

23. Доска задач и баклог
 Архитектор должен посещать ранние сессии по
определению задач на доске (storyboarding) и добавлять
архитектурные user story, которые задают фундамент
или определяют архитектурное направление
 Архитектор должен посещать последующие сессии по
определению задач на доске между спринтами, чтобы
вносить архитектурные user story, которые
«настраивают» архитектуру или корректируют
нежелательные отклонения
 Архитектор должен работать с product owner-ом, чтобы
приоритезировать эти истории и построить их в
соответствии с бизнес функциональностью в спринтах

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

25. Участие в спринте
 Доверяй команде
 Ad-hoc ревью
 Участие в реализации оправданно, если спринт сошел с
верного пути в архитектурном или другом смысле

27. Спасибо за внимание!
E-mail: myunusov@luxoft.com
Skype: myunusov