В Agile Environment, который отвечает за архитектуру программного обеспечения.

В гибкой команде, кто отвечает за принятие архитектурных и проектных решений высокого уровня, которые влияют на всю систему, а не только на работу, выполняемую в текущем спринте?

Может быть, владелец продукта, Scrum Master, команда Scrum или кто-то еще?

«Архитектура программного обеспечения выполняется всей командой. Эта практика не устраняет необходимость в архитекторе программного обеспечения, это просто означает, что архитектор вносит вклад в обсуждение с более широкой и, вероятно, более опытной перспективой, тем не менее все члены команды вносят свой вклад в архитектура программного обеспечения. "

• Источник: http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

Архитекторы, конечно, но, возможно, не традиционные архитекторы.

Я не имею в виду главного хирурга-архитектора, который все обдумывает, а потом оставляет обезьян, чтобы все печатать. Я имею в виду опытного ведущего программиста, который понимает соотношение затрат и выгод, возникающих при принятии трудных решений, и советует командам, что делать.

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

• Конечно, принимать правильные архитектурные решения, но также
• Знать, как эффективно давать советы, чтобы другие чувствовали себя комфортно, а также
• Медленно делегируйте архитектурные решения командам

Этот последний пункт запутывает многих людей. Когда агилисты с благими намерениями говорят что-то вроде «Команда владеет архитектурой», они имеют это «право», но я считаю, что этот совет почти полностью бессмыслен в его применении. Если бы вы доверяли командам взять на себя ответственность за свою собственную архитектуру, то вы бы не задавали вопрос в первую очередь, а теперь ?! Поэтому я предполагаю, что вы задаете вопрос, потому что есть некоторая озабоченность

• Никто не возьмет на себя ответственность, и у нас будет плохая архитектура, или
• Не те люди возьмут на себя ответственность, и у нас будет плохая архитектура, или
• Кто бы ни взял на себя ответственность, станет козлом отпущения, и вы надеетесь избежать этого

Если вам нужно, чтобы кто-то взял на себя ответственность, передайте ее тому, кто хочет ее принять. Шутки в сторону. Этот человек по крайней мере заботится. Дайте этому человеку ресурсы, необходимые ему для выполнения работы, и помогите ему, когда ему это нужно. Вероятно, не имеет значения, насколько компетентен человек, потому что, если ему все равно, тогда они попытаются узнать то, что ему нужно изучить. Естественно, такой человек нуждается в поддержке в виде хороших книг для чтения и сообщества сверстников и наставников, к которым они могут обратиться за помощью и советом.

Если вы беспокоитесь о том, что не тот человек берет на себя ответственность, то я надеюсь, что вы знаете, кто такой «правильный человек», и будете бороться за то, чтобы установить его как архитектора. Такая книга, как «Новые стратегические продажи» , поможет вам освоить методы продаж, чтобы это произошло.

Если вам просто нужен козел отпущения, тихонько подтолкните других, чтобы возложить ответственность на тех, кого вы хотели бы разрушить или нанести ущерб. По крайней мере, быть честным об этом.

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

Я думаю о великом архитекторе как о ком-то, кто помогает мне понять, как лучше проектировать мои системы, кто будет терпеливо консультировать меня, когда я буду просить об этом, и который иногда будет мешать мне принимать очень плохое решение. Такой архитектор действует как лидер в прямом смысле этого слова: тот, за кем добровольно следуют другие .

Я знаю, что это было много.

Ссылки

Миллер, Новая стратегическая продажа . Эта книга включает модель для понимания, почему вы не смогли закрыть конкретную продажу. Я нахожу это неоценимым в понимании того, почему коллеги не будут делать явно замечательную вещь, которую я предлагаю.

Вайнберг, став техническим лидером . Эта книга помогла мне научиться выполнять не-архитектурную часть работы эффективного архитектора.

Appelo, Делегация и Покер Делегации . Не стоит недооценивать, насколько сложно делегировать и насколько мы отстой. Учитесь делать это эффективнее и комфортнее.

Лучшая архитектура , требования и проекты возникают из самоорганизующихся команд

- Agile Manifesto

Таким образом, команда самоорганизуется, чтобы принимать архитектурные решения так, как считает нужным. Нет строгого и быстрого правила, оно может варьироваться от консенсуса до «совета» самых старших членов, до назначения одного конкретного члена в качестве органа архитектуры, до разрешения архитектору выбирать, есть ли член с таким названием должности. ,

Я чувствую, что ответ на вопрос «кто отвечает за принятие архитектурных и дизайнерских решений высокого уровня?» Зависит от размера и количества команд.

Для одной или двух команд по 3-7 человек в каждой команде самоорганизованная команда может руководить старшими членами.

Для 3 или более групп повышенная сложность приводит к необходимости создания команды по архитектуре, которая может видеть, выполняют ли различные подгруппы работу, которая будет взаимодействовать с другими командами. По моему опыту, эта точка достигается, когда примерно 8 команд или около 50 человек.

На их сайте есть несколько замечательных ресурсов от команды Scaled Agile Framework (SAFe).

По сути, это помогает вам гибко масштабировать всю вашу организацию, выходя за рамки одного выпуска и планирования портфеля и программы. Их документация содержит предложения о том, как привлечь корпоративных и системных архитекторов к процессу внедрения архитектурных эпосов в выпуск.

Отредактируйте для ясности, чтобы ответить на вопрос более непосредственно:

В масштабируемой гибкой среде существует несколько уровней владения архитектурой. Гибкая группа внедрения будет владеть низкоуровневой развивающейся архитектурой, проводя рефакторинг по мере необходимости, чтобы продолжить реализацию своих резервов. Архитектурные решения более высокого уровня (поддерживаемые операционные системы, браузеры, платформы, библиотеки) находятся под ответственностью вашей системы и корпоративных архитекторов. Они подготовят бизнес-кейсы для случаев, когда эти изменения должны произойти, и порекомендуют, чтобы эти архитектурные изменения были добавлены в последовательность выпуска для групп внедрения.

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

Я думаю, что большинство других ответов думают об этом с точки зрения нахождения внутри проекта.

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

Согласно TOGAF, отдел архитектуры предприятия разрабатывает планы высокого уровня для бизнеса и вместе с ним по созданию и замене ИТ-среды. Архитектор предприятия определит архитектурные принципы и подпишет их на самых высоких уровнях организации и поможет создать архитектуру и требования высокого уровня для каждого проекта. Каждый проект инициируется для обеспечения архитектурного строительного блока в этой архитектуре высокого уровня.

Таким образом, на уровне проекта Solution Architect создаст архитектуру проекта (возможно, итеративно) и получит подтверждение от Enterprise Architect.

Теперь сосредоточиться на гибком проекте. Гибкий проект имеет требования. Они не в форме массивного «Документа о требованиях», а являются эпическими и историческими. Эти эпосы все еще требуют планирования. Вы не отправляете команду разработчиков на несколько спринтов в неизвестность. На высоком уровне вы знаете, что должна делать система, с какими другими системами она должна взаимодействовать и какие аппаратные / операционные системы / языковые ограничения существуют в организации, и это направляет и ограничивает архитектурные решения, открытые для Solution Architect. Например, если вы привержены .NET и SQL-серверу, вам придется сделать оченьубедительный аргумент в пользу внедрения сайта электронной коммерции на основе Magento с использованием PHP и MySQL из-за затрат, связанных с поддержкой двух БД, двух языков, двух веб-серверов и т. д. В качестве альтернативы, один проект может выбрать использование совершенно другой библиотеки или другого вида и чувствовать, и это может иметь последствия для всех других проектов в полете. Важно иметь надзор за Enterprise Architect, чтобы предотвратить возникновение такого рода «архитектурных долгов».

Зависит от организационной структуры организации и от того, находится ли продукт в портфеле. Более крупные ролевые организации могут назначать старших архитекторов для руководства этими видами деятельности.

Как правило, старший архитектор облегчает и направляет проектные решения, поскольку они не только влияют на отставание продукта, но могут повлиять на несколько продуктов в портфеле продуктов.

Небольшие, гибкие компании могут полагаться на разработчиков, которые являются системными экспертами, чтобы руководить командой разработчиков для согласования архитектурного дизайна.

В конечном счете, архитектурные решения должны быть согласованы с группой доставки, которая работает над продуктом. Опытные архитекторы и технические специалисты будут больше сосредоточены на том, чтобы облегчить обсуждение того, как должен выглядеть дизайн, а не навязывать дизайн.

Я думаю, что большинство ответов уже подчеркивают, что команда ни один человек не должен принимать эти решения.

Что они не трогают, так это еще один Agile принцип:

Простота - искусство максимизировать количество не выполненной работы - очень важно.

Размышления о высокоуровневых архитектурах и проектных решениях часто не принимаются во внимание с простотой, что может привести к напрасной трате усилий и добавлению ненужной сложности, которая может усложнить расширение.

Думайте «садоводство» над «архитектурой» - создайте культуру живого, растущего дизайна

Во время вашей текущей итерации вы должны принимать архитектурные и дизайнерские решения для ваших текущих потребностей. Вместо того, чтобы смотреть в будущее, которое может никогда не стать, сосредоточьтесь только на том, что вам нужно сейчас. Вероятно, YAGNI - хорошо продуманная архитектура, пусть команда справится с этим понемногу.

Другие читает:

• https://less.works/less/technical-excellence/architecture-design.html