Архитектура в Agile

Собрание прошло успешно, хотя и несколько сумбурно — по всей компании
пришлось собирать стулья, чтобы усадить всех желающих. В этот раз объявление
о собрании было опубликовано на http://habrahabr.ru, оно вышло там «на главную»
и получился «хабраэффект» зарегистрировалось более ста восьмидесяти человек.
Даже с пессимистичной оценкой вероятности прихода в 50 %, получалось, что
будет около сотни человек и в нижний зал они не поместятся, а новый зал был еще
не готов (висел только один экран из двух, проекторов не было ни одного, штор не
было, кондиционеры не работали и было только 20 новых стульев). Пришлось
выкручиваться — забрали все стулья, принесли переносной проектор, открыли окна
и выключили солнце (собрание было слава-богу вечером). По оценкам числа
оставшихся стульев и вместимости подоконников, участников было более сотни.
В общем, были неудобства, к следующим встречам планируем сделать и
кондиционеры, и два работающих проектора, и озвучивание зала микрофонами с
колонками.
Далее приведем краткое резюме обсуждение, и как обычно — майндмап-конспект
и видео.
Сумбур также усугубился, что основной модератор дискуссии — Асхат Уразбаев, к
сожалению, заболел, и ведением дискуссий пришлось заняться Андрею Бибичеву
с Никитой Филипповым, и им было нелегко управляться с опытными спорщиками
из зала.
Содержание






1 Архитектор в Agile: Кто он и зачем?
2 Конспект-майндмап
 2.1 Видео
3 Архитектура в Agile
4 Видео
5 Выбор тем для следующей встречи AgileRussia
6 Примечания
Архитектор в Agile: Кто он и зачем?
Сначала дискуссий крутилась вокруг самого определения «[Software] Архитектора».
Он виделся одновременно как


шейпер возможностей: задающий ограничения на техническое решение с
одной стороны, и указывающий возможные решения (СУБД-библиотекифреймворки-протоколы-интеграция) с другой.
фасилитатор, который


помощник команды в выборе технологий и в нахождении оптимальных
решений;
«разводящий» конфликты на стыках
 Бизнеса и технологии, хотя является не бизнес-аналитиком, а
скорее представителем технической команды;
 Функциональных и нефункциональных требований (по сути,
опять «business vs. технологии»);
 Концептуального видения и командно-тактического.
Судя по репликам из зала, представление об архитекторе плавало от практически
«верхнеуровнего» бизнес-аналитика, рисующего ARIS/BPMN-диаграммы (ну или
хотя
бы
набрасывающего
очень
крупноблочную
архитектуру),
до
«микроархитектора» занимающегося иерархией классов и вообще структурами
данных.
С другой стороны — его то нагружали функциями управления (или по крайней мере,
координации команды), то отсаживали отдельно, в элитную «башню мудрецов».
Но все сходились, что архитектор должен быть всесторонне опытным




и в разработке;
и в руководстве;
и в коммуникации;
понимать предметные области бизнеса (ну или хотя бы, успешно общаться с
бизнес-аналитиками и быстро въезжать в новые темы);
Какова же специфика архитектора именно в Agile[1], в agile-координатах
ответственности и команды?
И вообще, когда (в Agile) появляется:


Необходимость в архитекторе? — от размера команды это, похоже,
напрямую не зависит, а зависит именно от размера проекта.
И какая на нем будет личная ответственность, выпадающая «за сферу»
коллективной ответственности команды?
Кстати, практически сразу выдвинулся представитель, скажем так, RUP-подхода,
Дима Безуглый, заявлявший




о неизбежном интеллектуальном неравенстве членов команды;
о принципиально индивидуальном процессе творчества («мысли рождаются
в одной голове»);
что минимум потерь будет, если выбор компромиссов доверят только
ответственным экспертам;
о том, что целостность архитектуры при всех бушующих изменениях, можно
поддерживать только если эта архитектура полностью погружена в одну (ну,
по крайней мере минимум) голов, а не размазана слухами по всей
команде(ам).
Оппонировали
ему
с
позиций
Agile-ценностей,
о
максимальной
кроссфункциональности[2], и с позиций, что ответственность в Agile может быть
только коллективной, а значит, роль Архитектора — менторская, он должен давать
советы и наблюдать за командой, чтобы она не попала в технологический тупик,
стараясь передать при этом свои знания (понятная метафора — обучение детей,
когда без самостоятельности и ответственности обучаемых, эффективность будет
весьма низка), впрочем, об этом ниже будет подробней.
Соответственно точки обсуждения были:


возможно ли коллективное творчество?
нужна ли индивидуальная ответственность избранных?
Аргументировали не только личным опытом и представлениями, а также к свежим
метологическим статьям, как таких зубров, как Мартин Фаулер, так и менее
известным Are You An Agile Architect?
В качестве «прорезающего» примера, рассматривали случай больших проектов,
когда приходится использовать практики маштабирования (Scrum-of-Scrum)[3].
Путь «кроссфункциональщиков» — общие архитектурные решения принимаются на
SoS-митингах, куда команды делегируют своих представителей, причем возможно
каждый раз разных (это зависит скорее от актуальной функциональности, чем от
«крутизны»).
RUP-оппозиция контратаковала:
Ошибка Резидента Брукса
единственная ошибка в которой (якобы) признался Фредерик Брукс —
«нельзя делать информацию доступной для всех команд».
Core Team
Как дополнение/оппозиция для классических Feature Team, отвечает за
«стержневые» библиотеки («ядра») проекта[ов].
Architecture Board
Выделенный Совет Архитекторов (не «Архитектурная Доска», как думают
привыкшие к пробковым SCRUM-доскам), жестко следящий за
целостностью проекта, получающий от Feature Teams списки пожелания и
проблем текущей архитектуры и пытающийся найти компромиссное
решение (реализуемое core team).
Architecture Description
увязка нефункциональных требований (производительность, безопасность,
юзабилити), и интересов всех стейкхолдеров (включая пользователей,
заказчиков, команду и т.п.).
Контр-контр-атака аджайлистов (Андрей Бибичев, Павел Афанасенков):








Максимальная мотивация — дать самостоятельность, дать право принимать
важные решения, это круче чем деньги. А регуляция, бюрократия,
регламенты — все это убивают.
Разные люди в роли архитектора — убирается предвзятость, biases,
устраняются перекосы в приоритетах требований.
«Патернализм»
избранных
архитекторов
убивает
обучение
(вышеупомянутый кейс с обучением детей), а рулит маевтика;
Архитектор близок к техлиду, а лидерство суть руление коммуникацией,
фасилитация общения, иногда даже принуждение;
Персональная ответственность — это миф (иначе, ибо ставки архитектурных
ошибок высоки, нужно увольнять после пары ошибок, а безошибочных людей
не бывает);
Да, цена ошибок велика, но персонализация решений — не серебряная пуля,
ничего не гарантирует и вообще далека от оптимальность. И вообще, когда
цена ошибок велика, нужно применять стандартные методы — управление
рисками, привлечение экспертов.
Но с Бруксом можно согласится — архитектор должен следить за
концептуальной целостностью. Следить, но не запрещать.
Резюме — с архитектором можно жить, он полезен, но мешать он не должен
ни в коем случае.
Конспект-майндмап
[на всё окно][свернуть]
Видео
Архитектура в Agile
Тут был достаточно беглый обзор новые веяния, сговорившихся иметь схожие до
степени смешения аббревиатуры:
DDD
Domain Driven Design;
BDD
Behavior Driven Development;
TDD
Test Driven Development;
FDD
Test Driven Development;;
VDD
Value Driven Development (по большому счету это маркетинговый bullshit, но
тоже затесался за компанию).
Для тех, кто заинтересовался более подробно, рекомендуем



Тренинг Андрея Бибичева по «DDD» (2010-03-03).
«Обзор Feature-Driven Development и Domain-Driven Design» на AgileDays2009
«Проектирование больших ИС в Agile» на SECR-2009: статья, слайды.
Видео
Выбор тем для следующей встречи AgileRussia
Демократичный процесс выбора темы для следующей встречи сообщества.
Спойлер — победила темы «Инструменты в/для Agile».
Примечания
1. ↑ В RUP-то роль архитектора прописана явно, а вот в Agile есть спектр
мнений, включая то, что выделенный архитектор — не нужен
2. ↑ Поднимите руки у кого есть совместное владение кодом? — лес рук…
3. ↑ Забавный момент — ключевые спорщики, Никита и Дима, в разное время
оба были партнерами Асхата по внедрению Scrum-of-Scrum. Звучит это
несколько пикантно.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи,
запишите его в раздел «discussion».
Репликация: База Знаний «Заказных Информ Систем» → «Архитектор в Agile (встреча AgileRussia.ru 2010-03-24)»