Все статьи
Быстрый старт в SAFe® #3 – Динамика Agile-команды
Дата: 11.01.2024
Третья статья серии «Быстрый старт в SAFe®». В этом обзоре Scaled Agile Framework® (SAFe®) изучаем взаимодействие внутри Agile-команды: различные Agile-подходы, роли, практики, а также распространенные инструменты и как их использовать в повседневной работе вашей команды.
Agile-команды в SAFe®
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Кросс-функциональные
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-команды и 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-командой (или, максимум, с двумя командами).
Владельцы продукта синхронизируются с менеджерами продукта и вносят свой вклад в создания видения и дорожной карты тем, что приносят обратную связь от команд.
Владельцы продукта ответственны за формирование, приоритезацию и поддержку бэклога команды в актуальном состоянии, с учетом вклада со стороны системного архитектора и других заинтересованных лиц.
Agile-команды используют истории для описания рабочих элементов бэклога. Вы узнаете об историях подробнее в конце этого модуля. В то время, как каждый может создать пользовательские истории, PO ответственны за их приоритезацию, дают пояснения командам и принимают результаты работы, когда согласны, что история приведена к состоянию «готова».
- Позвольте вашему владельцу продукта вести вас! Владельцы продукта предоставляют поддержку и культивируют культуру постоянного обучения.
- Вводите совместное владение бэклогом команды. В Agile команда необязательно определяет, что должно быть сделано. Но команда определяет то, как это будет делаться. Владелец продукта доверяет своей команде в выборе пути для достижении целей.
Продуктовый Менеджмент отвечает за определение и поддержку разработки востребованных, осуществимых, жизнеспособных и устойчивых продуктов, удовлетворяющих потребностям клиентов на всем жизненном цикле продукта.
Бэклог Команды — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.
Системный Архитектор отвечает за определение и донесение общей технической и архитектурной концепции Решений, разрабатываемых несколькими ART.
Scrum-мастер
Скрам-мастер/Коуч Команды (Scrum Master/Team Coach, SM/TC) — это лидер и коуч Agile-команды, который помогает в реализации командных процессов, мероприятий и поставке ценности.
Scrum-мастер – уникальная роль в Agile-команде. Он помогает создать атмосферу гармонии в команде. Для Agile-команды Scrum-мастер — лидер, коуч и фасилитатор.
- Scrum-мастер обучает и направляет команду по Agile и SAFe-практикам и дает команде возможность самостоятельно управлять своей работой, при этом наставляя членов команды в улучшении командной динамики, когда это необходимо.
- Scrum-мастер отвечает за создание высокоэффективной команды с использованием методов коучинга.
- Scrum-мастер помогает команде устранять препятствия, которые мешают команде или снижают ее продуктивность, чтобы они продолжали инкрементально выпускать ценность.
- Также Scrum-мастер помогает координировать зависимости между своей и другими командами.
- Scrum-мастера убеждаются, что все командные события проводятся, продуктивны и укладываются в отведенные временные рамках.
- Scrum-мастера также ответственны за взаимодействие и общение на командных событиях и убеждаются, что каждый участник команды (имеет возможность) вносит свой вклад.
Команде нужно время, чтобы сфокусироваться на своей работе. Scrum-мастер помогает командам в координации общения с другими командами и заинтересованными лицами, чтобы команда могла сфокусироваться на доставке ценности.
- Scrum-мастера ставят под сомнение старые правила, чтобы улучшить качество, предсказуемость, поток и скорость.
- Они помогают команде сфокусироваться на создании инкремента ценности каждую итерацию и достижении ежедневных целей, также как и цели итерации.
Scrum-мастер поддерживает усилия владельца продукта в управлении бэклогом и ведет команду, развивая здоровую командную динамику с фокусом на приоритеты и объем работы.
- Спросите вашего Scrum-мастера о профессиональных сообществах (Communities of Practice, CoPs) в вашей организации, которым может быть полезна ваша экспертность в какой-либо области или есть интерес к сотрудничеству с людьми из других команд.
- Положитесь на Scrum-мастера. Scrum-мастера могут помочь в устранении препятствий. Просите у них помощи!
Профессиональные Сообщества (Communities of Practice, CoPs) — это группы людей, обладающих общими интересами в определенной технической области или в области бизнеса. Они регулярно сотрудничают, чтобы обмениваться информацией, совершенствовать свои навыки, а также укреплять общие знания в предметной области.
Отличия Владельца продукта и Scrum-мастера
Владелец продукта:
- Представляет бизнес и покупателей.
- Синхронизируется с менеджерами продукта и предоставляет обратную связь от команд.
- Поясняет работу и определяет, когда работа достигает состояния «готово».
- Приоритезирует бэклог команды и создает Истории.
Scrum-мастер:
- Создает эффективную среду для команды, взаимодействуя с заинтересованными лицами.
- Направляет команды, в следовании Agile-практикам.
- Фастилитирует все события команды.
- Помогает команде сфокусироваться на достижении ее целей.
Рабочие соглашения команды
Высокоэффективные команды двигаются в одном направлении.
В новых реалиях с распространением удаленной работы очень помогает иметь рабочие соглашения, которые ясно определяют ожидания в команде. Команда разрабатывает их, определяя как они хотят работать друг с другом. Организации и команды имеют свои версии рабочих соглашений, с которыми им удобнее всего работать.
- Помни, все голоса в Agile-команде равноценны!
- Говори о препятствиях сразу же как они появились.
- Приходи вовремя и включай камеру на командных событиях.
- Высказывай свои мысли и будь добрым.
- Выбирай общение вместо электронных писем.
Командные подходы
Для поставки ценности Agile-команды используют методы, практики и инструменты. Кто-то использует что-то одно, другие предпочитают сочетать практики из разных методов.
Три Agile-метода: Scrum, Kanban и экстремальное программирование (XP) имеют много общего. Все они предназначены для частой и быстрой поставки ценности клиенту, оптимизацию и устранение потерь и формирование зрелых команд.
Поскольку SAFe – это система, основанная на понятии потока, многие SAFe-команды комбинируют методы. Например, команда может взять из Scrum работу итерациями и наличие Scrum-мастера, использовать Kanban-доску и использовать практику ограничения работы в прогрессе (WIP-лимиты), чтобы обеспечивать течение потока, а также использовать практики парного программирования из экстремального программирования.
Незавершенная Работа (Work In Process, WIP) представляет собой общее количество активных рабочих элементов в системе.
Scrum
Большинство SAFe-команд используют Scrum как основной работающий метод на уровне команд. При этом они следуют определенным базовым практикам Scrum, как описано в этом разделе.
Целостный подход или, как он еще называется, подход «регби», когда команда вместе старается пройти всю дистанцию, передавая мяч друг другу, более конкурентноспособен сегодня.
Скрам – это легковесный командный фреймворк, который способствует быстрой итеративной поставке ценности. Скрам изменил способ работы команд, определив специализированные роли, командные встречи и артефакты.
- Разработчики.
- Владелец продукта.
- Scrum-мастер.
- Ежедневный стендап – каждый день команда обсуждает, как они продвигаются к своим итерационным целям.
- Планирование итерации – команда планирует ближайшую итерацию и ставит цели с учетом своих возможностей (ёмкости).
- Обзор итерации – команда анализирует результаты итерации, оценивает прогресс и корректирует приоритеты.
- Ретроспектива итерации – после обзора команда встречается, чтобы ретроспективно оценить работу в последней итерации и определяет возможности для улучшения работы.
- Бэклог команды – содержит истории, которые Agile-команды используют для выполнения работы.
- Инкремент – команды обеспечивают прирост ценности в конце каждой итерации за счет регулярной поставки ценности.
Скрам-команды поставляют ценность итеративно и поэтапно. Они используют итерации, обычно двухнедельные, для определения, создания, проверки и анализа результатов.
Самоорганизованные и самоуправляемые команды сами определяют, как использовать командные события для организации работы наилучшим образом и постоянно совершенствуются для достижения лучших результатов.
- Уточнение бэклога – многие Scrum-команды также проводят встречи по уточнению элементов бэклога, хотя формально в фреймворке Scrum такого события нет.
- Разные термины — единый смысл. Scrum использует термин «спринт», а SAFe – «итерация» для названия выбранного временного интервала цикла работы. Аналогично, термины «ежедневный стендап» и «ежедневный Scrum» относятся к одному и тому же ежедневному командному мероприятию.
- «Танцуют все!» Все члены Agile-команды участвуют в 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-лимиты, что помогает командам улучшить свой рабочий процесс и быть более эффективными.
- To Do (Надо сделать) – этот столбец содержит приоритетные элементы бэклога, которые готовы к работе команды.
- Doing (В работе) – столбец «Выполнение» или «Работа в процессе» (Work In Process, WIP) содержит работу, которую активно выполняет команда. Команда ограничивает количество элементов, которые могут находиться в процессе одновременно.
- Done (Готово) – когда команда завершает работу, они перемещают карточки в столбец «Готово».
На доске Канбан вы всегда можете увидеть статус работы.
Истории расположены в приоритетном порядке, поэтому члены команды знают, над чем работать дальше. Также легко определить слишком большое количество элементов, находящихся в работе одновременно, что замедляет поставку ценности.
Легко обнаружить передачу, зависимости и узкие места, где команда должна замедлить или остановить работу. Сведение к минимуму передачи информации, работы и прочих взаимодействий улучшает поток.
В Канбан члены команды берут в работу каждую следующую историю в очереди, когда у них высвобождается емкость для этой работы, вместо того, чтобы кто-то назначал им задачи в любой момент времени. Это помогает поддерживать устойчивый рабочий ритм и контролировать объем элементов, находящихся в работе в единицу времени (незавершенная работа).
Канбан-доски команды выглядят по-разному. Это потому, что команды настраивают свои канбан-доски таким образом, чтобы они отражали фактический ход работы. Посмотрите следующие примеры Канбан-досок, которые могут использовать команды разработки программного обеспечения и команды производства медиа.
- WIP-лимиты – это один из способов улучшить поток в Канбане (ограничить незавершенную работу). Команда решает, сколько элементов может быть в WIP или столбце «Выполнение».
- Канбан-доски – любая Agile-команда, включая Скрам-команду, может использовать Канбан-доску. Настраивайте Канбан-доску так, чтобы она отображала рабочий процесс конкретной команды.
- Критерии готовности (Definition of Done) – команды могут создать и использовать критерии готовности для своих колонок на Канбан-доске. Поддерживайте свою Канбан-доску в актуальном состоянии. Обсуждайте ход работы, чтобы предупредить возникновение потерь, возникающих из-за несвоевременного информирования о проблемах.
Пользовательские истории для поставки ценности
Пользовательские истории — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.
Пользовательские истории предоставляют ровно столько информации, сколько нужно как бизнесу, так и техническим специалистам, чтобы понять цель.
При этом пользовательские истории:
- Представляют собой часть работы, которая может быть выполнена за одну итерацию.
- Написаны с точки зрения потребителя/пользователя.
Пользовательские истории формируются в определенном формате, чтобы включать в себя мнение потребителя и выгоду для потребителя. Еще больше об историях вы можете узнать из статьи: Что такое пользовательская история в SAFe®?
Пользовательские истории и энейблеры
SAFe предлагает использовать два типа историй: пользовательские и Enabler-истории.
Написание хороших историй
Хорошие истории содержат четкое описание небольшой функциональности, ценной для пользователя. Написание историй с использованием критериев I.N.V.E.S.T поможет вам и вашей команде определить реальную цель историй, расставить приоритеты для достижения максимальной ценности и оптимизировать поток поставки.
История — это заявлением о намерении, а не финальный контракт. Она содержит ровно столько информации, сколько необходимо бизнесу и разработке для общего понимания цели. Глубокая детализация истории откладывается до момента её реализации.
Каждая история описывает и определяет важный для пользователя кусочек функциональности системы. Чтобы гарантировать ценность истории для пользователя она описывается с его точки зрения. Например:
Как покупатель (роль пользователя), я хочу попадать в корзину с покупками с любой страницы сайта (действие), чтобы быстрее завершать покупку (цель/бизнес-ценность).
При планирования итерации команда производит оценку истории, в первую очередь, чтобы убедиться в общем одинаковом её понимании. История достаточно маленькая, чтобы её можно было оценить и команда имеет достаточно опыта для того, чтобы её оценить.
Тестируемость — это ключевая характеристика любой пользовательской истории. Если мы не знаем, как мы будем тестировать историю, значит, мы не понимаем её достаточно хорошо, чтобы приступать к разработке. Критерии приёмки истории в явном виде говорят о том, как история будет протестирована и могут быть использованы командой для разработки приёмочных тестов.
Примеры пользовательских историй
Критерии приемки
- Водитель получает предупреждение об аварии.
- Предупреждение информирует водителя о другом маршруте, который сэкономит время.
Тест — проверьте, насколько хорошо вы усвоили материал
