Повышение языка и региональных параметров в вашей команде

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Примечание.

Новые возможности гибкой разработки? Дополнительные сведения см. в разделе "Гибкие региональные параметры" и "Масштабирование гибкой" в крупные команды.

Включение автономности

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

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

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

Создание выравнивания

По мере планирования роста набора инструментов Agile рассмотрите следующие области. Эти области являются ключевыми для создания корпоративного выравнивания при разработке автономности команды.

Область

Создание выравнивания

Поддержка автономности

Визуальное представление продукта

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

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

Структура команды

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

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

Частота разработки

Гибкие организации должны выпускать продукты и обновления компонентов через регулярные интервалы. Создание регулярных выпусков и графиков спринта способствует ритму бизнеса.
Каждая спринт --a time boxed итерация постоянной длительности между двумя и четырьмя неделями— включает планирование, выполнение, предоставление ценности, отражение и участие в непрерывном улучшении.

Все команды управляют своей работой в рамках заданного спринта. Команда предоставляет входные данные в длину спринта, который лучше всего подходит для них.
Команда выбирает методы Agile, которые работают для них, Scrum, Kanban или сочетание обоих. Команда также берет на себя ответственность за запуск и выполнение собственных наборов методов непрерывного улучшения.
Некоторые команды могут выполняться в более коротких спринтах. Например, если организация задает 2-недельный спринт, некоторые команды могут работать в 1-недельных спринтах, но по-прежнему соответствуют расписанию организации.

Частота обмена данными

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

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

Качество

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

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

Управление рисками, отслеживание работы

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

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

Структура команд

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

Диаграмма с горизонтальными и вертикальными командами.

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

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

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

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

Настройка средств Agile для масштабирования

По мере роста организации вы можете масштабировать средства Agile следующими способами.

  • Добавьте команды и отфильтрованные представления невыполненной работы: вы добавляете команды в службу поддержки автономности и предоставляете им средства, которые они могут настроить и управлять ими, поддерживающими работу. К этим средствам относятся невыполненные работы продуктов, доски Kanban, невыполненные спринты, панели задач и другие.

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

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

  • Управление портфелями: путем настройки иерархии команд и невыполненных работ и активации невыполненной работы портфеля. Команды функций, ориентированные на подмножество невыполненной работы продукта, могут оставаться сосредоточены только на их невыполненной работы. Руководители портфеля, которые хотят просматривать и упорядочивать невыполненные операции по отслеживанию хода выполнения и зависимостей, могут управлять невыполненными портфелями функций и эпических операций.

    Если вам нужны другие невыполненные работы с портфелем, например сценарии или инициативы, их также можно добавить.

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

  • Группировать или классифицировать работу. Существует несколько способов группирования работы, которую вы хотите отслеживать. Невыполненные работы фильтруют рабочие элементы на основе назначений области группы. И невыполненные работы портфеля позволяют группировать элементы невыполненной работы в разделе "Функции" и "Эпические".

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

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

Масштабирование с помощью команд и не проектов

Часто организации смотрят на добавление проекта для каждого проекта разработки программного обеспечения.

Рекомендуется добавлять команды для масштабирования средств, а не добавлять проекты по следующим причинам:

  • Видимость: проще просматривать ход выполнения во всех командах.
  • Отслеживание и аудит. Проще связать рабочие элементы с другими объектами для отслеживания и аудита.
  • Удобство обслуживания: вы минимизируете обслуживание групп безопасности и обновления процессов.

Дополнительные сведения см. в разделе "О проектах" и масштабировании организации.

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

Если вы готовы перейти из одной команды в две команды или настроить несколько команд, см. статью "Добавить команды". Чтобы добавить администратора команды или настроить ресурсы группы, см. статью "Управление командами" и настройку средств группы.

Дополнительные сведения см. в следующих статьях:

Ресурсы отрасли гибкой культуры