Персональные инструменты
CUSTIS
Сайт CUSTIS →
Вакансии
Блог команды
Архив событий
Архив публикаций
Навигация
Заглавная страница
Свежие правки
Случайная статья
Справка
Поиск
 
Инструменты
Ссылки сюда
Связанные правки
Спецстраницы
Версия для печати
Чистый HTML
→M$WORD
→OOffice

Архитектор в Agile (встреча AgileRussia.ru 2010-03-24)

Материал из CustisWiki

Версия от 20:11, 1 марта 2011; StasFomin (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск
Короткая ссылка: 2010-03-24-agile-architect

Собрание прошло успешно, хотя и несколько сумбурно — по всей компании пришлось собирать стулья, чтобы усадить всех желающих. В этот раз объявление о собрании было опубликовано на http://habrahabr.ru, оно вышло там «на главную» и получился «хабраэффект» зарегистрировалось более ста восьмидесяти человек.

Даже с пессимистичной оценкой вероятности прихода в 50 %, получалось, что будет около сотни человек и в нижний зал они не поместятся, а новый зал был еще не готов (висел только один экран из двух, проекторов не было ни одного, штор не было, кондиционеры не работали и было только 20 новых стульев). Пришлось выкручиваться — забрали все стулья, принесли переносной проектор, открыли окна и выключили солнце (собрание было слава-богу вечером). По оценкам числа оставшихся стульев и вместимости подоконников, участников было более сотни.

В общем, были неудобства, к следующим встречам планируем сделать и кондиционеры, и два работающих проектора, и озвучивание зала микрофонами с колонками.

Далее приведем краткое резюме обсуждение, и как обычно — майндмап-конспект и видео (видео можно скачать).

Сумбур также усугубился, что основной модератор дискуссии — Асхат Уразбаев, к сожалению, заболел, и ведением дискуссий пришлось заняться Андрею Бибичеву с Никитой Филипповым, и им было нелегко управляться с опытными спорщиками из зала.

Архитектор в 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, устраняются перекосы в приоритетах требований.
  • «Патернализм» избранных архитекторов убивает обучение (вышеупомянутый кейс с обучением детей), а рулит маевтика;
  • Архитектор близок к техлиду, а лидерство суть руление коммуникацией, фасилитация общения, иногда даже принуждение;
  • Персональная ответственность — это миф (иначе, ибо ставки архитектурных ошибок высоки, нужно увольнять после пары ошибок, а безошибочных людей не бывает);
  • Да, цена ошибок велика, но персонализация решений — не серебряная пуля, ничего не гарантирует и вообще далека от оптимальность. И вообще, когда цена ошибок велика, нужно применять стандартные методы — управление рисками, привлечение экспертов.
  • Но с Бруксом можно согласится — архитектор должен следить за концептуальной целостностью. Следить, но не запрещать.
  • Резюме — с архитектором можно жить, он полезен, но мешать он не должен ни в коем случае.

Конспект-майндмап

Видео

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/10577075?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

Скачать → на странице видео на vimeo, кнопка «Download»


Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/10577896?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

Скачать → на странице видео на vimeo, кнопка «Download»


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

Тут был достаточно беглый обзор новые веяния, сговорившихся иметь схожие до степени смешения аббревиатуры:

DDD
Domain Driven Design;
BDD
Behavior Driven Development;
TDD
Test Driven Development;
FDD
Feature Driven Development;;
VDD
Value Driven Development (по большому счету это маркетинговый bullshit, но тоже затесался за компанию).

Глупо пересказывать добротную лекцию, но замечу, что техники DDD и FDD в споре предыдущей части об Agile-архитекторе скорее лили воду на мельницу «RUP-партии».

А для тех, кто заинтересовался более подробно, рекомендуем

Видео

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/10578348?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

Скачать → на странице видео на vimeo, кнопка «Download»


Выбор тем для следующей встречи AgileRussia

Демократичный процесс выбора темы для следующей встречи сообщества.

Спойлер — победила тема «Инструменты в/для Agile».

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/10457833?byline=0&portrait=0" width="640" height="512" frameborder="0"></iframe>

Скачать → на странице видео на vimeo, кнопка «Download»


Примечания

  1. ↑ В RUP-то роль архитектора прописана явно, а вот в Agile есть спектр мнений, включая то, что выделенный архитектор — не нужен
  2. ↑ Поднимите руки у кого есть совместное владение кодом? — лес рук…
  3. ↑ Забавный момент — ключевые спорщики, Никита и Дима, в разное время оба были партнерами Асхата по внедрению Scrum-of-Scrum. Звучит это несколько пикантно.


Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.

Источник — «http://lib.custis.ru/index.php?title=Архитектор_в_Agile_(встреча_AgileRussia.ru_2010-03-24)&oldid=23310»