Собрание прошло успешно, хотя и несколько сумбурно — по всей компании пришлось собирать стулья,
+
чтобы усадить всех желающих. В этот раз объявление о собрании было опубликовано на http://habrahabr.ru, оно вышло там «на главную» и получился «хабраэффект» зарегистрировалось более ста восьмидесяти человек.
+
+
Даже с пессимистичной оценкой вероятности прихода в 50 %, получалось, что будет около сотни человек и в нижний зал они не поместятся, а новый зал был еще не готов (висел только один экран из двух, проекторов не было ни одного, штор не было, кондиционеры не работали и было только 20 новых стульев). Пришлось выкручиваться — забрали все стулья, принесли переносной проектор, открыли окна и выключили солнце (собрание было слава-богу вечером). По оценкам числа оставшихся стульев и вместимости подоконников, участников было более сотни.
+
+
В общем, были неудобства, к следующим встречам планируем сделать и кондиционеры, и два работающих проектора, и озвучивание зала микрофонами с колонками.
+
+
Далее приведем краткое резюме обсуждение, и как обычно — майндмап-конспект и видео.
+
+
Сумбур также усугубился, что основной модератор дискуссии — Асхат Уразбаев, к сожалению, заболел,
+
и ведением дискуссий пришлось заняться Андрею Бибичеву с Никитой Филипповым, и им было нелегко
+
управляться с опытными спорщиками из зала.
== Архитектор в Agile: Кто он и зачем? ==
== Архитектор в Agile: Кто он и зачем? ==
+
Сначала дискуссий крутилась вокруг самого определения «[Software] Архитектора».
+
Он виделся одновременно как
+
* шейпер возможностей: задающий ограничения на техническое решение с одной стороны, и указывающий возможные решения (СУБД-библиотеки-фреймворки-протоколы-интеграция) с другой.
+
* фасилитатор, который
+
** помощник команды в выборе технологий и в нахождении оптимальных решений;
+
** «разводящий» конфликты на стыках
+
*** Бизнеса и технологии, хотя является не бизнес-аналитиком, а скорее представителем технической команды;
+
*** Функциональных и нефункциональных требований (по сути, опять «business vs. технологии»);
+
*** Концептуального видения и командно-тактического.
−
[[Файл:Архитектор в Agile.mm]]
+
Судя по репликам из зала, представление об архитекторе плавало от практически «верхнеуровнего» бизнес-аналитика, рисующего ARIS/BPMN-диаграммы (ну или хотя бы набрасывающего очень крупноблочную архитектуру), до
+
«микроархитектора» занимающегося иерархией классов и вообще структурами данных.
+
+
С другой стороны — его то нагружали функциями управления (или по крайней мере, координации команды),
+
то отсаживали отдельно, в элитную «башню мудрецов».
+
+
Но все сходились, что архитектор должен быть всесторонне опытным
+
* и в разработке;
+
* и в руководстве;
+
* и в коммуникации;
+
* понимать предметные области бизнеса (ну или хотя бы, успешно общаться с бизнес-аналитиками и быстро въезжать в новые темы);
+
+
Какова же специфика архитектора именно в Agile<ref>В RUP-то роль архитектора прописана явно, а вот в Agile есть спектр мнений, включая то, что выделенный архитектор — не нужен</ref>, в agile-координатах ответственности и команды?
+
+
И вообще, когда (в Agile) появляется:
+
* Необходимость в архитекторе? — от размера команды это, похоже, напрямую не зависит, а зависит именно от размера проекта.
+
* И какая на нем будет личная ответственность, выпадающая «за сферу» коллективной ответственности команды?
+
+
Кстати, практически сразу выдвинулся представитель, скажем так, RUP-подхода,
* о неизбежном интеллектуальном неравенстве членов команды;
+
* о принципиально индивидуальном процессе творчества («мысли рождаются в одной голове»);
+
* что минимум потерь будет, если выбор компромиссов доверят только ответственным экспертам;
+
* о том, что целостность архитектуры при всех бушующих изменениях, можно поддерживать только если эта архитектура полностью погружена в одну (ну, по крайней мере минимум) голов, а не размазана слухами по всей команде(ам).
+
+
Оппонировали ему с позиций Agile-ценностей, о максимальной кроссфункциональности<ref>Поднимите руки у кого есть совместное владение кодом? — лес рук…</ref>,
+
и с позиций, что ответственность в Agile может быть только коллективной, а значит, роль Архитектора — менторская, он должен давать советы и наблюдать за командой, чтобы она не попала в технологический тупик, стараясь передать при этом свои знания
+
(понятная метафора — обучение детей, когда без самостоятельности и ответственности обучаемых,
+
эффективность будет весьма низка), впрочем, об этом ниже будет подробней.
+
+
Соответственно точки обсуждения были:
+
* возможно ли коллективное творчество?
+
* нужна ли индивидуальная ответственность избранных?
+
+
Аргументировали не только личным опытом и представлениями, а также к свежим метологическим статьям,
+
как таких зубров, как Мартин Фаулер, так и менее известным [http://www.infoq.com/news/2008/01/agile-architect Are You An Agile Architect?]
+
+
В качестве «прорезающего» примера, рассматривали случай больших проектов, когда приходится использовать практики маштабирования (''Scrum-of-Scrum'')<ref>Забавный момент — ключевые спорщики, Никита и Дима, в разное время оба были ''партнерами'' Асхата по внедрению ''Scrum-of-Scrum''. Звучит это несколько пикантно.</ref>.
+
+
Путь «кроссфункциональщиков» — общие архитектурные решения принимаются на SoS-митингах, куда команды делегируют своих представителей, причем возможно каждый раз разных (это зависит скорее от актуальной функциональности, чем от «крутизны»).
+
+
RUP-оппозиция контратаковала:
+
;Ошибка Резидента Брукса: единственная ошибка в которой (якобы) признался Фредерик Брукс — «нельзя делать информацию доступной для всех команд».
+
;Core Team: Как дополнение/оппозиция для классических Feature Team, отвечает за «стержневые» библиотеки («ядра») проекта[ов].
+
;[http://www.opengroup.org/architecture/togaf7-doc/arch/p4/board/ab.htm Architecture Board]: Выделенный Совет Архитекторов (не «Архитектурная Доска», как думают привыкшие к пробковым SCRUM-доскам), жестко следящий за целостностью проекта, получающий от ''Feature Teams'' списки пожелания и проблем текущей архитектуры и пытающийся найти компромиссное решение (реализуемое ''core team'').
+
;Architecture Description: увязка нефункциональных требований (производительность, безопасность, юзабилити), и интересов всех стейкхолдеров (включая пользователей, заказчиков, команду и т.п.).
+
+
+
Контр-контр-атака аджайлистов (Андрей Бибичев, Павел Афанасенков):
+
* Максимальная мотивация — дать самостоятельность, дать право принимать важные решения, это круче чем деньги. А регуляция, бюрократия, регламенты — все это убивают.
+
* Разные люди в роли архитектора — убирается предвзятость, ''biases'', устраняются перекосы в приоритетах требований.
+
* «Патернализм» избранных архитекторов убивает обучение (вышеупомянутый кейс с обучением детей), а рулит маевтика;
+
* Архитектор близок к техлиду, а лидерство суть руление коммуникацией, фасилитация общения, иногда даже принуждение;
+
* Персональная ответственность — это миф (иначе, ибо ставки архитектурных ошибок высоки, нужно увольнять после пары ошибок, а безошибочных людей не бывает);
+
* Да, цена ошибок велика, но персонализация решений — не серебряная пуля, ничего не гарантирует и вообще далека от оптимальность. И вообще, когда цена ошибок велика, нужно применять стандартные методы — управление рисками, привлечение экспертов.
+
* Но с Бруксом можно согласится — архитектор должен следить за концептуальной целостностью. Следить, но не запрещать.
+
* Резюме — с архитектором можно жить, он полезен, но мешать он не должен ни в коем случае.
;VDD: Value Driven Development (по большому счету это маркетинговый bullshit, но тоже затесался за компанию).
+
Для тех, кто заинтересовался более подробно, рекомендуем
+
* [[Тренинг Андрея Бибичева по «DDD» (2010-03-03)]].
+
* [[AgileDays-2009 (Technical excelence)#Обзор Feature-Driven Development и Domain-Driven Design|«Обзор Feature-Driven Development и Domain-Driven Design» на AgileDays-2009]]
+
* «Проектирование больших ИС в Agile» на SECR-2009: [http://www.slideshare.net/biBIGine/agile-2382913 статья], [http://www.slideshare.net/biBIGine/agile-2382889 слайды].
Собрание прошло успешно, хотя и несколько сумбурно — по всей компании пришлось собирать стулья,
чтобы усадить всех желающих. В этот раз объявление о собрании было опубликовано на http://habrahabr.ru, оно вышло там «на главную» и получился «хабраэффект» зарегистрировалось более ста восьмидесяти человек.
Даже с пессимистичной оценкой вероятности прихода в 50 %, получалось, что будет около сотни человек и в нижний зал они не поместятся, а новый зал был еще не готов (висел только один экран из двух, проекторов не было ни одного, штор не было, кондиционеры не работали и было только 20 новых стульев). Пришлось выкручиваться — забрали все стулья, принесли переносной проектор, открыли окна и выключили солнце (собрание было слава-богу вечером). По оценкам числа оставшихся стульев и вместимости подоконников, участников было более сотни.
В общем, были неудобства, к следующим встречам планируем сделать и кондиционеры, и два работающих проектора, и озвучивание зала микрофонами с колонками.
Далее приведем краткое резюме обсуждение, и как обычно — майндмап-конспект и видео.
Сумбур также усугубился, что основной модератор дискуссии — Асхат Уразбаев, к сожалению, заболел,
и ведением дискуссий пришлось заняться Андрею Бибичеву с Никитой Филипповым, и им было нелегко
управляться с опытными спорщиками из зала.
Сначала дискуссий крутилась вокруг самого определения «[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, отвечает за «стержневые» библиотеки («ядра») проекта[ов].
Выделенный Совет Архитекторов (не «Архитектурная Доска», как думают привыкшие к пробковым SCRUM-доскам), жестко следящий за целостностью проекта, получающий от Feature Teams списки пожелания и проблем текущей архитектуры и пытающийся найти компромиссное решение (реализуемое core team).
Architecture Description
увязка нефункциональных требований (производительность, безопасность, юзабилити), и интересов всех стейкхолдеров (включая пользователей, заказчиков, команду и т.п.).
Контр-контр-атака аджайлистов (Андрей Бибичев, Павел Афанасенков):
Максимальная мотивация — дать самостоятельность, дать право принимать важные решения, это круче чем деньги. А регуляция, бюрократия, регламенты — все это убивают.
Разные люди в роли архитектора — убирается предвзятость, biases, устраняются перекосы в приоритетах требований.
«Патернализм» избранных архитекторов убивает обучение (вышеупомянутый кейс с обучением детей), а рулит маевтика;
Архитектор близок к техлиду, а лидерство суть руление коммуникацией, фасилитация общения, иногда даже принуждение;
Персональная ответственность — это миф (иначе, ибо ставки архитектурных ошибок высоки, нужно увольнять после пары ошибок, а безошибочных людей не бывает);
Да, цена ошибок велика, но персонализация решений — не серебряная пуля, ничего не гарантирует и вообще далека от оптимальность. И вообще, когда цена ошибок велика, нужно применять стандартные методы — управление рисками, привлечение экспертов.
Но с Бруксом можно согласится — архитектор должен следить за концептуальной целостностью. Следить, но не запрещать.
Резюме — с архитектором можно жить, он полезен, но мешать он не должен ни в коем случае.
«Проектирование больших ИС в Agile» на SECR-2009: статья, слайды.
Видео
Выбор тем для следующей встречи AgileRussia
Демократичный процесс выбора темы для следующей встречи сообщества.
Спойлер — победила темы «Инструменты в/для Agile».
Примечания
↑В RUP-то роль архитектора прописана явно, а вот в Agile есть спектр мнений, включая то, что выделенный архитектор — не нужен
↑Поднимите руки у кого есть совместное владение кодом? — лес рук…
↑Забавный момент — ключевые спорщики, Никита и Дима, в разное время оба были партнерами Асхата по внедрению Scrum-of-Scrum. Звучит это несколько пикантно.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
