Как архитекторы могут работать с самоорганизующимися командами Scrum?

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

Например, команда может захотеть использовать библиотеку X или хотеть использовать REST вместо SOAP, но советник не одобряет это.

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

Руководство Scrum может сказать следующее:

Самоорганизация: никто (даже Scrum Master) не говорит команде разработчиков, как превратить бэклог продукта в приращения потенциально высвобождаемой функциональности.

Это разумно? Команда EA должна быть расформирована? Должны ли команды отказаться или просто подчиниться?

Команда разработчиков состоит из 3–9 человек с межфункциональными навыками, которые выполняют реальную работу.

Scrum Master должен пригласить «Enterprise Architect» стать частью команды проекта. Тогда общение между архитектором и программистами было бы превосходным.

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

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

Архитекторы не говорят разработчикам, как превратить отставание в приращения (спринты), они говорят, какие технологии можно и нельзя использовать. Вы смешиваете две разные проблемы.

Решение - ничего не менять. Если ваши команды разочарованы тем, что архитекторы слишком ограничены или слишком властны, это кадровая проблема, которая не имеет никакого отношения к SCRUM и должна рассматриваться деловыми заинтересованными сторонами как вопрос удовлетворенности сотрудников и, если возможно, итогового результата. («Нам требуется x%больше времени для разработки функций, yпотому что архитектор не zпозволит нам использовать Turbo Pascal».)

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

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

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

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

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

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

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

Группа Scaled Agile Framework говорит об этом очень хорошо. Большинство из нас имеют дело на командном уровне, но при расширении мы должны признать, что есть роли, которые нужно играть и на уровне программ и портфелей. Архитектурные решения должны приниматься во всей организации, и это должно учитывать то, что происходит на более низких уровнях организации. Нет ничего плохого в архитектурных решениях!

В связи с этим недавняя книга Дина Леффингвелла о гибких требованиях к программному обеспечению - хорошее прочтение на эту тему, я читала ее сама.

У нас также есть несколько гибких команд (некоторые делают Kanban, некоторые Scrum) и архитекторов. Архитекторы отвечают за инфраструктуру, которая охватывает все наши продукты (вспомогательные библиотеки, аутентификация, инфраструктура сборки) и т. Д. Они принимают технические решения, но также реализуют вещи, в основном компоненты инфраструктуры.

Это работает хорошо, и обычно нет конфликта. Я считаю, что один важный момент:

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

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

Я не вижу здесь никакого конфликта. Из того, что я понимаю, все, что должен делать советник (как мне кажется, это напыщенное название) - это QA. Все должны знать об этом.

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

Некоторые из этих требований устанавливаются политикой компании. И они устанавливают основные правила:

• Команда должна будет соблюдать их, как и любое другое требование. Тогда оспаривание политики просто выходит за рамки проекта и должно рассматриваться отдельно.
• Работа EA заключается в том, чтобы обеспечить соблюдение этих требований, а не навязывать им личную фантазию. Им не нравится Х, тогда это их личное мнение. Ни больше ни меньше. Относитесь к этому как к любому другому мнению. Однако, если советник может показать, что использование X нарушает существующее требование, тогда они вполне могут запретить использование X, а если они знают работоспособную альтернативу, а команда не знает, то это их право применять ее.

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

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

Архитекторы, выдающие заказы и проверяющие технические решения, являются культурным недостатком. Они считают себя «боссом», а не просто поддерживают общую цель / видение и держат отдельные команды на одной странице. Гибкие методологии основаны на общении и контактах. Когда ваши архитекторы не участвуют до тех пор, пока не будут приняты решения, они проваливаются в Agile.

Мартин, я думаю, у тебя может быть неправильное представление о том, как самоорганизующаяся команда функционирует в своей среде.

Вы процитировали Руководство по Скраму: «Никто (даже Скрам Мастер) не рассказывает команде разработчиков, как превратить бэклог продукта в Приращения потенциально высвобождаемой функциональности».

Это не лицензия для команды Scrum делать все, что она хочет (до тех пор, пока она обеспечивает), независимо от технологических и бизнес-потребностей компании в целом и потребностей других команд.

Конечно, заинтересованные стороны могут злоупотреблять своим влиянием. Это одна из задач сотрудничества, и она, безусловно, не ограничивается советником. Но сотрудничество не заканчивается на границе команды.

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

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