Trinity Cathedral/Charlie Comella Community Garden uses different garden beds to divide their work. Each bed grows one or more types of plant that are combined to produce the meals for the community.
… Ваш продукт пользуется успехом на рынке, и все больше и больше людей используют его. Новые пользовательские сегменты возникают со спросом на новые функции. Скрам-команде по-прежнему необходимо доставлять продукт в соответствии с темпом рынка. Все команды стремятся к тому, чтобы иметь возможность доставить любой Элемент Бэклога Продукта (PBI), но команды собираются внедрить новый домен и поэтому начинают приближаться к пределам того, что могут освоить.
✥ ✥ ✥
Когда бизнес не может удовлетворять растущее число пользовательских сегментов, разделив продукты, а скорее должен разрабатывать единый продукт, который обслуживает все рынки, во многих случаях одна Скрам-команда не может быстро развить необходимое глубокое понимание всех этих клиентских сегментов.
Скрам-команда должна иметь возможность самостоятельно увеличивать ценность для клиентов. Теперь, когда есть много пользовательских сегментов, вы можете добавить больше людей, которые привносят в команду достаточно знаний о предметной области, чтобы все сегменты оставались понятными. Известно, что большие команды медленнее, потому что страдает командная динамика. Кроме того, сложность понимания множества деталей продукта может привести к демотивации.
Каждая часть продукта создает ценность для пользовательского сегмента. Каждой компонентной команде нужны конкретные подробные знания о предметной области своей части. Классическое решение — dīvide et imperā: рассматривайте продукт как совокупность нескольких продуктов, по одному для каждого пользовательского сегмента, и каждый со своим Владельцем Продукта и Бэклогом Продукта, чтобы каждая организация могла самостоятельно работать со своим сегментом клиентов. Но Владельцы Продукта и их Скрам-команды затем будут локально оптимизировать свои части, вместо оптимизации всего продукта ([3]). Крайне важно оптимизировать дизайн для экономии объема работ.
Когда вы разрабатываете один продукт с несколькими Владельцами Продукта, каждый из которых работает с отдельным Бэклогом Продукта, становится все труднее координировать изменения, которые затрагивают их, и все труднее отдавать приоритет PBI с наивысшей ценностью. Это происходит так как (1) Команды Разработки специализированы на пользовательских сегментах, поэтому каждая команда, скорее всего, не сможет реагировать на потребности в других областях, и (2) разные специализации имеют доминирующее количество в разныхСпринтах. Поэтому, стратегия, основанная на использовании сначала PBI с наивысшей ценностью, будет перегружать некоторые команды, оставляя другие команды свободными. Как побочный эффект, не все PBI с наивысшей ценностью могут быть выбраны вСпринт, что вынуждает Владельца Продукта выбирать PBI с более низкой ценностью, чтобы обеспечить занятость команд.
Организация Скрам-команд вокруг архитектурных компонент может выглядеть хорошим решением, но функционал для клиента часто требует сквозного среза между компонентами, а не просто изолированного компонента. Структура с компонентными командами приводит к последовательной разработке, всем видами задержек, работе над менее ценными PBI, отсутствию прозрачности процесса разработки и ненужным координационным ролям. Подобные проблемы возникают, когда вы организовываете команды вокруг одной функции, такой как тестирование, архитектура или анализ. Смотри Cross-Functional Team.
Каждый Спринт, Скрам-команды должны поставлять Инкремент Продукта. Поэтому Скрам-командам необходимо интегрировать свою работу и управлять своими зависимостями. Когда команд много, сложно управлять зависимостями между архитектурными компонентами. Часто, вводится ненужную в других отношениях роль, такая как менеджер проекта или внешний “владелец фичи”, для управления, координации и планирования многокомнатных зависимостей.
Поэтому:
Масштабируйте ваш продукт вокруг Областей ценности (Value Areas). Область ценности это ценная часть продукта, которая отвечает потребностям пользовательского сегмента, но не имеет никакой полезной ценности или идентичности отдельно от продукта. При этом способе организации, каждый набор Команд Разработки должен понимать только подмножество пользовательских сегментов, в то время как каждая команда по-прежнему способна предоставлять ценные PBI в Инкремент Продукта.
Большой продукт может в конечном итоге иметь множество Областей Ценности; когда это происходит, Владелец Продукта не может самостоятельно управлять Бэклогом Продукта из-за огромного объема работы и необходимости детального понимания пользовательских сегментов. В этой ситуации Владелец Продуктаформирует Команду Владельца Продукта для управления Бэклогом Продукта сквозь Области Ценности. Член Команды Владельца Продукта обычно специализируется на одной Области Ценности и помогает Владельцу Продукта. Член Команды Владельца Продукта не владеет продуктом ни в каком смысле; тот, кто владеет продуктом, иногда называется Главным Владельцем Продукта.
Крупная энергетическая компания имеет следующие Области ценности: I-Join, I-Pay и We-Support. Каждая Область Ценности существует, потому что она специально предназначена для области ценности клиента и требует определенных подробных знаний.
Область I-Join — это поиск и добавление новых клиентов. Область I-Pay обрабатывает все функции выставления счетов, а область We-Support заботится обо всем, что касается службы поддержки и жалоб.
Каждая Область Ценности состоит из четырех-шести Команд Разработки, работающих вместе в едином Спринте, чтобы добавить фичи для клиента в общий продукт.
Каждая Область Ценности имеет одну или несколько Команд Разработки, которые работают вместе в Спринте. Команда Разработки обычно работает в одной Области Ценности. Команды Разработки сами организуют и координируют свою работу без каких-либо специальных координационных ролей. Все Команды Разработки работают с одним Бэклогом Продукта и имеют одного Владельца Продукта. Каждая команда индивидуально интегрирует ценные PBI в единый Инкремент Продукта каждый Спринт.
✥ ✥ ✥
Организация вокруг Областей Ценности снижает функциональные зависимости между Командами Разработки, когда большинство пользовательских сегментов включают связанные блоки функциональности. Остальные зависимости передаются на уровень реализации, и команды должны быть внимательны к риску того, что этот паттерн может усложнить технические зависимости между командами. Инструменты управления кодом могут помочь в разрешении зависимостей при разработке, равно как и непрерывная интеграция и другие гибкие инженерные практики (не инструменты, которые поддерживают или координируют взаимодействие команды). Команды Разработки также должны решать такие общие проблемы, как архитектурная целостность или целостное восприятие продукта пользователем. Участники Команд Разработки могут объединяться в сообщества, чтобы справиться с этими проблемами и создать знания во всех Областях Ценности: смотри Birds of a Feather.
Так как Команды Разработки начинают специализироваться в одной Области Ценности, они теряют глубокое понимание всех Областей Ценности. Но Команды Разработки все еще работают над ценными (с точки зрения пользователей) PBI, держа в фокусе весь продукт.
Командам Разработки в Области Ценности нужно координировать свою работу. Вы хотите, чтобы команды замечали, когда возникает потребность в координации, а затем вовремя координировались с нужными людьми. Поэтому, механизмы децентрализованной и неформальной координации лучше, чем централизованные организованные встречи. Вы можете начать со Scrum of Scrums, общего подхода к командной координации.
Когда появится новая бизнес-возможность, которая, как вы ожидаете, потребует значительной пропускной способности в ближайшем будущем, добавьте существующую высокопроизводительную Команду Разработки для работы над бизнес-возможностью. Команда Разработки быстро узнает возможных рисках и бизнес-потенциале. Когда бизнес-возможность оказывается успешной, новая команда становится командой поддержки, которая помогает другим командам быстрее освоиться в этом новом домене. Недостатком является то, что трудно найти существующую доступную команду, имеющую высокую производительность и компетентности в домене нового бизнеса.
Области Ценности являются временным решением на непредвиденные скачки спроса на знания. Можно избежать таких сюрпризов, регулярно используя Set-Based Design. В долгосрочной перспективе команды должны стремиться снова стать кросс-функциональными командами во всех областях.
… Ваш продукт пользуется успехом на рынке, и все больше и больше людей используют его. Новые пользовательские сегменты возникают со спросом на новые функции. Скрам-команде по-прежнему необходимо доставлять продукт в соответствии с темпом рынка. Все команды стремятся к тому, чтобы иметь возможность доставить любой Элемент Бэклога Продукта (PBI), но команды собираются внедрить новый домен и поэтому начинают приближаться к пределам того, что могут освоить.
✥ ✥ ✥
Когда бизнес не может удовлетворять растущее число пользовательских сегментов, разделив продукты, а скорее должен разрабатывать единый продукт, который обслуживает все рынки, во многих случаях одна Скрам-команда не может быстро развить необходимое глубокое понимание всех этих клиентских сегментов.
Скрам-команда должна иметь возможность самостоятельно увеличивать ценность для клиентов. Теперь, когда есть много пользовательских сегментов, вы можете добавить больше людей, которые привносят в команду достаточно знаний о предметной области, чтобы все сегменты оставались понятными. Известно, что большие команды медленнее, потому что страдает командная динамика. Кроме того, сложность понимания множества деталей продукта может привести к демотивации.
Каждая часть продукта создает ценность для пользовательского сегмента. Каждой компонентной команде нужны конкретные подробные знания о предметной области своей части. Классическое решение — dīvide et imperā: рассматривайте продукт как совокупность нескольких продуктов, по одному для каждого пользовательского сегмента, и каждый со своим Владельцем Продукта и Бэклогом Продукта, чтобы каждая организация могла самостоятельно работать со своим сегментом клиентов. Но Владельцы Продукта и их Скрам-команды затем будут локально оптимизировать свои части, вместо оптимизации всего продукта ([3]). Крайне важно оптимизировать дизайн для экономии объема работ.
Когда вы разрабатываете один продукт с несколькими Владельцами Продукта, каждый из которых работает с отдельным Бэклогом Продукта, становится все труднее координировать изменения, которые затрагивают их, и все труднее отдавать приоритет PBI с наивысшей ценностью. Это происходит так как (1) Команды Разработки специализированы на пользовательских сегментах, поэтому каждая команда, скорее всего, не сможет реагировать на потребности в других областях, и (2) разные специализации имеют доминирующее количество в разныхСпринтах. Поэтому, стратегия, основанная на использовании сначала PBI с наивысшей ценностью, будет перегружать некоторые команды, оставляя другие команды свободными. Как побочный эффект, не все PBI с наивысшей ценностью могут быть выбраны вСпринт, что вынуждает Владельца Продукта выбирать PBI с более низкой ценностью, чтобы обеспечить занятость команд.
Организация Скрам-команд вокруг архитектурных компонент может выглядеть хорошим решением, но функционал для клиента часто требует сквозного среза между компонентами, а не просто изолированного компонента. Структура с компонентными командами приводит к последовательной разработке, всем видами задержек, работе над менее ценными PBI, отсутствию прозрачности процесса разработки и ненужным координационным ролям. Подобные проблемы возникают, когда вы организовываете команды вокруг одной функции, такой как тестирование, архитектура или анализ. Смотри Cross-Functional Team.
Каждый Спринт, Скрам-команды должны поставлять Инкремент Продукта. Поэтому Скрам-командам необходимо интегрировать свою работу и управлять своими зависимостями. Когда команд много, сложно управлять зависимостями между архитектурными компонентами. Часто, вводится ненужную в других отношениях роль, такая как менеджер проекта или внешний “владелец фичи”, для управления, координации и планирования многокомнатных зависимостей.
Поэтому:
Масштабируйте ваш продукт вокруг Областей ценности (Value Areas). Область ценности это ценная часть продукта, которая отвечает потребностям пользовательского сегмента, но не имеет никакой полезной ценности или идентичности отдельно от продукта. При этом способе организации, каждый набор Команд Разработки должен понимать только подмножество пользовательских сегментов, в то время как каждая команда по-прежнему способна предоставлять ценные PBI в Инкремент Продукта.
Большой продукт может в конечном итоге иметь множество Областей Ценности; когда это происходит, Владелец Продукта не может самостоятельно управлять Бэклогом Продукта из-за огромного объема работы и необходимости детального понимания пользовательских сегментов. В этой ситуации Владелец Продуктаформирует Команду Владельца Продукта для управления Бэклогом Продукта сквозь Области Ценности. Член Команды Владельца Продукта обычно специализируется на одной Области Ценности и помогает Владельцу Продукта. Член Команды Владельца Продукта не владеет продуктом ни в каком смысле; тот, кто владеет продуктом, иногда называется Главным Владельцем Продукта.
Крупная энергетическая компания имеет следующие Области ценности: I-Join, I-Pay и We-Support. Каждая Область Ценности существует, потому что она специально предназначена для области ценности клиента и требует определенных подробных знаний.
Область I-Join — это поиск и добавление новых клиентов. Область I-Pay обрабатывает все функции выставления счетов, а область We-Support заботится обо всем, что касается службы поддержки и жалоб.
Каждая Область Ценности состоит из четырех-шести Команд Разработки, работающих вместе в едином Спринте, чтобы добавить фичи для клиента в общий продукт.
Каждая Область Ценности имеет одну или несколько Команд Разработки, которые работают вместе в Спринте. Команда Разработки обычно работает в одной Области Ценности. Команды Разработки сами организуют и координируют свою работу без каких-либо специальных координационных ролей. Все Команды Разработки работают с одним Бэклогом Продукта и имеют одного Владельца Продукта. Каждая команда индивидуально интегрирует ценные PBI в единый Инкремент Продукта каждый Спринт.
✥ ✥ ✥
Организация вокруг Областей Ценности снижает функциональные зависимости между Командами Разработки, когда большинство пользовательских сегментов включают связанные блоки функциональности. Остальные зависимости передаются на уровень реализации, и команды должны быть внимательны к риску того, что этот паттерн может усложнить технические зависимости между командами. Инструменты управления кодом могут помочь в разрешении зависимостей при разработке, равно как и непрерывная интеграция и другие гибкие инженерные практики (не инструменты, которые поддерживают или координируют взаимодействие команды). Команды Разработки также должны решать такие общие проблемы, как архитектурная целостность или целостное восприятие продукта пользователем. Участники Команд Разработки могут объединяться в сообщества, чтобы справиться с этими проблемами и создать знания во всех Областях Ценности: смотри Birds of a Feather.
Так как Команды Разработки начинают специализироваться в одной Области Ценности, они теряют глубокое понимание всех Областей Ценности. Но Команды Разработки все еще работают над ценными (с точки зрения пользователей) PBI, держа в фокусе весь продукт.
Командам Разработки в Области Ценности нужно координировать свою работу. Вы хотите, чтобы команды замечали, когда возникает потребность в координации, а затем вовремя координировались с нужными людьми. Поэтому, механизмы децентрализованной и неформальной координации лучше, чем централизованные организованные встречи. Вы можете начать со Scrum of Scrums, общего подхода к командной координации.
Когда появится новая бизнес-возможность, которая, как вы ожидаете, потребует значительной пропускной способности в ближайшем будущем, добавьте существующую высокопроизводительную Команду Разработки для работы над бизнес-возможностью. Команда Разработки быстро узнает возможных рисках и бизнес-потенциале. Когда бизнес-возможность оказывается успешной, новая команда становится командой поддержки, которая помогает другим командам быстрее освоиться в этом новом домене. Недостатком является то, что трудно найти существующую доступную команду, имеющую высокую производительность и компетентности в домене нового бизнеса.
Области Ценности являются временным решением на непредвиденные скачки спроса на знания. Можно избежать таких сюрпризов, регулярно используя Set-Based Design. В долгосрочной перспективе команды должны стремиться снова стать кросс-функциональными командами во всех областях.
