Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск

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

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

Видео



Архитектура в 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-партии».

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

Видео


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

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

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


Примечания

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



Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».