Все статьи

Людмила Баварова

Agile-коуч. Практик Scrum, Kanban и SAFe®.

Быстрый старт в SAFe® #3 – Динамика Agile-команды

Дата: 11.01.2024

Третья статья серии «Быстрый старт в SAFe®». В этом обзоре Scaled Agile Framework® (SAFe®) изучаем взаимодействие внутри Agile-команды: различные Agile-подходы, роли, практики, а также распространенные инструменты и как их использовать в повседневной работе вашей команды.

Agile-команды в SAFe®

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

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

Кросс-функциональные

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

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

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

Организованы вокруг ценности

Все участники Agile-команды разделяют общую цель: командную работу по поставке ценности.

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

Объединены в Agile Release Train (ART)

Agile-команды выпускают ценность как часть ART (Agile Release Train) в сотрудничестве с другими Agile-командами. В больших организациях часто несколько Agile-команд участвуют в поставке ценности пользователю. Чаще всего Agile-команды работают как часть ART. Они планируются, выравнивают свои планы и управляют своими зависимостями, координируясь с другими Agile-командами в ART.

Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.

Долгосрочные

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

Самоорганизующиеся

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

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

Итерации — это стандартный временной отрезок фиксированной длительности, в течение которого Agile-команды и ART по отдельности и совместно обеспечивают прирост потребительской ценности, работая над достижением PI-целей.

Используют различные Agile-методы и практики

Вы узнаете о методах и практиках позже в этом модуле.

Выпускают ценность инкрементально

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

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

Agile – для всех, а не только для команд ИТ-разработки.

Кто есть кто в вашей Agile-команде?​

В Agile-командах в SAFe есть две выделенные важные роли: Владелец продукта и Scrum-мастер.

Вы можете взять на себя одну из этих ролей. Если вы приняли это решение, то вам необходимо пройти курсы SAFe Product Owner/Product Manager или SAFe Scrum Master в ближайшее время. Ну, а пока изучите информацию в этой статье — она поможет вам понять важность роли, которую вы берете на себя и некоторые ваши обязанности.

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

Владелец продукта

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

Владелец продукта (Product Owner, PO) – участник Agile-команды и представитель покупателя. Для большинства компаний, двигающихся в сторону Agile, это новая важная роль, обычно переходящая в полную занятость в формате — один PO работает с одной Agile-командой (или, максимум, с двумя командами).

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

Бэклог Команды — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.

Системный Архитектор отвечает за определение и донесение общей технической и архитектурной концепции Решений, разрабатываемых несколькими ART.

Scrum-мастер

Скрам-мастер/Коуч Команды (Scrum Master/Team Coach, SM/TC) — это лидер и коуч Agile-команды, который помогает в реализации командных процессов, мероприятий и поставке ценности.

Scrum-мастер – уникальная роль в Agile-команде. Он помогает создать атмосферу гармонии в команде. Для Agile-команды Scrum-мастер — лидер, коуч и фасилитатор.

Профессиональные Сообщества (Communities of Practice, CoPs) — это группы людей, обладающих общими интересами в определенной технической области или в области бизнеса. Они регулярно сотрудничают, чтобы обмениваться информацией, совершенствовать свои навыки, а также укреплять общие знания в предметной области.

Отличия Владельца продукта и Scrum-мастера

Владелец продукта:

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

Scrum-мастер:

  • Создает эффективную среду для команды, взаимодействуя с заинтересованными лицами.
  • Направляет команды, в следовании Agile-практикам.
  • Фастилитирует все события команды.
  • Помогает команде сфокусироваться на достижении ее целей.

Рабочие соглашения команды

Высокоэффективные команды двигаются в одном направлении.

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

Командные подходы

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

Три Agile-метода: Scrum, Kanban и экстремальное программирование (XP) имеют много общего. Все они предназначены для частой и быстрой поставки ценности клиенту, оптимизацию и устранение потерь и формирование зрелых команд.

Поскольку SAFe – это система, основанная на понятии потока, многие SAFe-команды комбинируют методы. Например, команда может взять из Scrum работу итерациями и наличие Scrum-мастера, использовать Kanban-доску и использовать практику ограничения работы в прогрессе (WIP-лимиты), чтобы обеспечивать течение потока, а также использовать практики парного программирования из экстремального программирования.

Незавершенная Работа (Work In Process, WIP) представляет собой общее количество активных рабочих элементов в системе.

Scrum

Большинство SAFe-команд используют Scrum как основной работающий метод на уровне команд. При этом они следуют определенным базовым практикам Scrum, как описано в этом разделе.

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

Скрам – это легковесный командный фреймворк, который способствует быстрой итеративной поставке ценности. Скрам изменил способ работы команд, определив специализированные роли, командные встречи и артефакты.

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

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

Extreme Programming (XP)

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

Экстремальное программирование (XP) – один из самых мощных оригинальных Agile-методов. На рисунке ниже показаны методы XP при использовании в качестве автономного метода. SAFe использует многие приемы XP, включая рефакторинг, разработку через тестирование (TDD), парное программирование и коллективное владение. Эти методы ориентированы на обеспечение встроенного качества.

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

Разработка через Тестирование (Test-Driven Development, TDD) — это образ мышления и практика, при которой сначала создаются и исполняются тесты, а затем реализуется код компоненты или системы, удовлетворяющие тестам.

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

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

Совместное владение

Совместное владение кодом означает, что каждый член команды несет ответственность за все командные артефакты. Любой член команды может изменять артефакты и в равной степени отвечает за качество.

Эта практика совместного владения применима к любой работе, выполняемой командами.

Парное программирование

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

Через некоторое время они меняются ролями. Парное программирование повышает качество.

Члены команды, выполняющие разные роли, часто объединяются в пары при разработке решения, например, разработчик и тестировщик. Обратите внимание, что работа в паре – это не только работа по кодированию. Многие бизнес-команды используют эту практику для повышения качества.

Kanban

Kanban (Канбан) в переводе с японского означает вывеска или сигнал.

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

Большинство команд SAFe применяют Scrum в качестве базового метода работы на командном уровне, однако SAFe, как система, основанная на потоках, использует метод Kanban на каждом уровне для визуализации работы, ограничения  работы (WIP-лимиты) и улучшения потока.

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

SAFe_JS_3_13_kanban_board
  • To Do (Надо сделать) – этот столбец содержит приоритетные элементы бэклога, которые готовы к работе команды.
  • Doing (В работе) – столбец «Выполнение» или «Работа в процессе» (Work In Process, WIP) содержит работу, которую активно выполняет команда. Команда ограничивает количество элементов, которые могут находиться в процессе одновременно.
  • Done (Готово) – когда команда завершает работу, они перемещают карточки в столбец «Готово».

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

Пользовательские истории для поставки ценности

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

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

При этом пользовательские истории:

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

Пользовательские истории формируются в определенном формате, чтобы включать в себя мнение потребителя и выгоду для потребителя. Еще больше об историях вы можете узнать из статьи: Что такое пользовательская история в SAFe®?

Пользовательские истории и энейблеры

SAFe предлагает использовать два типа историй: пользовательские и Enabler-истории.

Энейблеры (Enablers) содержат действия, которые обеспечивают выполнение будущих бизнес-требований. В них не обязательно использовать «голос пользователя» (как при написании пользовательских историй).

Написание хороших историй

Хорошие истории содержат четкое описание небольшой функциональности, ценной для пользователя. Написание историй с использованием критериев I.N.V.E.S.T поможет вам и вашей команде определить реальную цель историй, расставить приоритеты для достижения максимальной ценности и оптимизировать поток поставки.

Примеры пользовательских историй

Критерии приемки

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

Тест — проверьте, насколько хорошо вы усвоили материал

Нажмите кнопку «Начать» для прохождения теста

Имя и фамилия
Email
SAFe® для команд
Тренинг SAFe® for Teams дает навыки работы в Agile-команде, которая в рамках Agile Release Train (ART) совместно с другими Agile-командами и заинтересованными лицами разрабатывает единое решение. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Practitioner (SP).

Поделиться

VK
Telegram