Создание scrum-команды оптимального размера для продукта может быть сложной задачей. Вот несколько советов, которые помогут
Согласно спецификации, предоставленной ScrumAlliance, скрам-команда состоит из 5-9 членов команды, которые могут выполнять разные функциональные роли. Это общая рекомендация, а не правило. Многие организации изо всех сил пытаются найти правильное количество участников схватки.
С таким количеством идейных лидеров, которые десятилетиями практиковали скрам, мы можем найти множество различных аргументов. Правда в том, что универсального ответа не существует, так как правильный размер схватки необходимо определить в зависимости от типа работы. Основываясь на своем опыте работы с несколькими консалтинговыми и продуктовыми компаниями, я попытаюсь изложить свою точку зрения на различные аспекты определения размера схватки.
Скрам-команды проекта
Проект против продукта — это самое фундаментальное отличие в принятии решений. «Согласно PMI, проект — это временная попытка создать ценность с помощью уникального продукта, услуги или результата. Поскольку это временное усилие, размер схватки обычно представляет собой минимальное количество людей, необходимое для завершения работы в запланированные сроки. Именно так большинство консалтинговых компаний создают свои scrum-команды.
Бюджет и выставление счетов также играют роль в определении размера scrum для контрактных проектов. На мой взгляд, концепция scrum даже не применима к краткосрочным проектным командам, но это модное слово, используемое такими командами для обозначения agile.
Скрам-команды продукта
Когда мы говорим о продуктовых командах, необходимо учитывать множество факторов. Здесь мы говорим о статических скрам-командах, которые должны дольше оставаться вместе. Я видел несколько вариантов скрам-команд по продукту в разных компаниях. Некоторые примеры включают в себя наличие нескольких небольших групп scrum (3–4 человека) для продукта, scrum-команды среднего и крупного размера на основе модулей, большие scrum-команды, владеющие несколькими более мелкими компонентами, и т. д. Давайте обсудим причины, лежащие в основе некоторых из этих вариантов.
Малая Scrum-команда (3–4)
Некоторым компаниям нравится, когда небольшие, сфокусированные команды работают над определенными функциями. Если в продукте запланировано две или три функции, они делят команду на две или три небольшие скрам-команды. Другой пример, когда создается небольшая команда scrum, — это разработка небольших утилит, сервисов (API) или компонентов (например, виджетов UX, библиотек, общих компонентов и т. д.).
Это кажется эффективным способом доставки продукта, но не соответствует сути Scrum. Несколько общих замечаний о небольших скрам-командах:
- Небольшая команда scrum может пойти на компромисс в отношении определенных ролей/навыков, таких как владелец продукта, инженер-испытатель или навыки автоматизации/развертывания.
- Небольшой скрам-команде может не хватать опыта для проверки качества, такой как экспертная оценка и/или расширенная проверка/тестирование.
- Существует меньше обмена знаниями и, следовательно, нет резервных копий для кого-либо.
- В конечном итоге это создает ситуацию «автобусного фактора», поскольку каждый человек знает только о своем вкладе.
- Небольшие команды могут вызывать стресс, если в команде есть хотя бы один сложный человек.
- Если команда временная, то ответственность за работу меньше.
- Поддержка после разработки может быть сложной, поскольку люди переназначаются.
- Нет времени на личностный рост или обучение членов команды.
- Даже небольшое утомление или незапланированное отсутствие могут дестабилизировать все планирование.
- Церемонии Scrum кажутся менее значимыми из-за отсутствия достаточного количества голосов.
Если отдельных участников больше, чем людей с титулами «менеджеров» (например, скрам-мастер, инженер-менеджер, владелец продукта или менеджер по продукту), то это не является здоровым балансом для команды.
Большие Scrum-команды (8–10)
Большинство групп приложений, ориентированных на пользователей, создают более крупные команды scrum, особенно если они пытаются создать автономные команды. Заполнение ролей для каждого архитектурного уровня и связанных с ним функций, таких как разработчик внешнего интерфейса, администратор баз данных, сценарии развертывания и т. д., в сумме делает команду достаточно большой.
В некоторых компаниях, например, в бизнесе корпоративных программных продуктов, команды делятся на функциональные модули. Вы можете услышать такие команды, как управление заказами, создание учетной записи в Интернете или учет пациентов. Здесь размер команды зависит от глубины бэклога и дорожной карты продукта. Вот несколько моментов, на которые стоит обратить внимание крупным скрам-командам:
- Большие команды обычно представляют собой статические команды, запланированные на более длительный срок.
- Чем больше людей, тем больше приток идей и мозговой штурм.
- Доступно больше опыта, поскольку нет дублирования ролей.
- Для каждого набора навыков могут быть резервные копии, что делает команду более стабильной.
- Перекрестное обучение команды возможно путем распространения знаний.
- Совместное владение продуктом может быть установлено при большем сотрудничестве.
- Церемонии Scrum занимают больше времени с большим количеством людей.
Итак, каков вердикт об оптимальном размере Scrum — маленьком или большом?
Конечно, простого ответа нет, но я хотел бы повторить некоторые фундаментальные моменты, которые нельзя игнорировать при создании схватки для продуктовых команд. Это вещи, которые могут помочь вам подобрать оптимальное количество для скрам-команды.
Видение продукта
Руководящая группа должна проанализировать дорожную карту продукта, включая обязательства клиента и бюджет, чтобы определить размер команды, которая может обеспечить постоянный поток работы в течение длительного времени. Как упоминалось выше, если это более крупный продукт, можно создать несколько команд scrum на основе таких факторов, как функциональные требования, функции или зависимости.
Если продукт или решение невелики, все же следует приложить усилия для создания команды стандартного размера, которая может владеть несколькими результатами работы. Цель должна состоять в том, чтобы создать сплоченную группу, владеющую продуктом в целом, а если она слишком велика для управления, то разделить ее на более мелкие группы.
Самодостаточность
Другим важным соображением должно быть заполнение всех необходимых ролей, чтобы не было внешней зависимости или дублирования в повседневной работе. Команда должна обладать всеми навыками, необходимыми для выполнения вертикальной части работы. Это означает, что команда может выполнять все виды работ, от разработки внешнего интерфейса до проектирования БД и создания сценариев развертывания. Люди, не носящие несколько шляп, обеспечивают более высокую производительность и высокое качество результатов.
Качество выше скорости
В команде должно быть достаточно людей, чтобы просматривать и проверять работу друг друга. Это гарантирует, что ни одна из мер качества не будет пропущена из-за нехватки ресурсов. Большое внимание уделяется каждому результату работы, будь то проверка кода, проверка или валидация. Ни один из этих шагов не следует рассматривать как накладные расходы, поскольку на этот раз инвестиции в качество приводят к созданию более качественных продуктов.
Стабильность выше эффективности
Совместная команда с распределенными знаниями может со временем стать гораздо более сильной и стабильной командой. Такая команда состоит из нескольких экспертов, что позволяет легко масштабировать ее в случае необходимости. Поэтому важно обеспечить перекрестное обучение достаточного количества людей по каждому аспекту результата. Это может незначительно сказаться на эффективности, но в долгосрочной перспективе это должно окупиться. Незначительные изменения в команде из-за увольнения или перевода не повлияют на скорость команды.
Стремитесь к равновесию
Постарайтесь создать сбалансированную команду с точки зрения набора навыков и опыта. Сочетание должно быть таким, чтобы можно было создавать резервные копии для каждого аспекта разработки. Это гарантирует отсутствие «критической» зависимости ни от кого, и никто не перегружен обязанностями. Баланс — это ключ к созданию устойчивой команды, которая не испытывает постоянного стресса из-за работы.
Взгляд автора
Как только вы подумаете об упомянутых выше моментах, вы получите оптимальный размер для вашей схватки.
Я рекомендую всегда использовать более высокую сторону рекомендуемого размера пены (больше пяти). Если работы над одним продуктом недостаточно для стандартного скрама, лучше работать над несколькими продуктами, чем создавать небольшую скрам-команду, которая обречена на трудности. Это позволит команде оставаться целой благодаря разнообразной работе, большему количеству возможностей для роста, большей связи и достаточному плану на случай непредвиденных обстоятельств. Ведь скрам-команда — это люди!
Последние мысли
Каждая команда и каждый продукт разные, и успех каждой схватки зависит от членов команды. Чем больше вы вкладываете в команду, тем лучше она становится, и все вложения окупаются с точки зрения качества вашего продукта.
Если вы попытаетесь сэкономить с меньшим размером команды, это не окупится в долгосрочной перспективе. У команды не хватает времени на передышку с дополнительными обязанностями, она чувствует большее давление и теряет мотивацию. Основным принципом успеха Scrum является акцент на людях, сотрудничестве и взаимодействии между людьми. Вот почему любое время, проведенное с командой стандартного размера в обсуждениях или церемониях схватки, — это инвестиция, которая так или иначе окупается. Если у вас есть другие мысли на эту тему, буду рад услышать их в комментариях.
Спасибо за прочтение!
