Как выбрать размер Скрам команды - Болг BrainRain 2018

Как выбрать размер Скрам команды

Скрам и Аджайл Сертификации от scrum.org

Многие вещи в Скраме изменить нельзя — например, набор ролей или встреч. но размер команды может варьироваться, а потому вызывает вопросы. От чего он зависит и какая команда будет эффективной для вас?

Сколько людей должно быть в Команде разработки?

Сколько разработчиков у вас в одной команде (то есть сколько людей, кроме Скрам Мастера и Владельца Продукта)? В Руководстве по Скраму рекомендации немногочисленны: от 3 до 9 человек, и нет никакой аргументации именно такого количества.

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

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

  • Достаточно широкий набор навыков для разработки продукта — кроссфункциональность.
  • Участники команды работают только в одной команде.
  • Стабильность работы — человек участвует в команде достаточно долгий период времени (см. Impact of Agile Quantified)
  • Разнообразие мышления (и подготовки) — достаточно широкий спектр идей, происхождений, верований, гендеров и жизненного опыта полезны для креативности и разнообразия подходов.

Когда команда уже сформирована, в игру вступают и другие (не менее важные) факторы ее успеха:

Размер команды в цифрах

В первых книгах по Скраму и XP указан размер команды 7+/-2, по числу Миллера (см. статью Википедии) — количеству целых чисел, которое человек способен удержать в кратковременной памяти. Целесообразность такого подхода тревожит, ведь неясно, как способность запоминать связана с размером команды. К тому же, и более нового исследования (The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?) следует, что как только объекты внимания человека усложняются, этот человек становится способным запомнить не более 4 элементов. Так что тут нужны источники понадежнее.

Многие коучи приводят исторические примеры из Древнего Рима или более ранних времен, когда в подразделении армии было по 8 человек. Другие обращают внимание на бонобо, которые добывают пропитание группами по 6-7 обезьян. Но ни один из этих примеров не имеет прямого отношения к команде за ра ботой, так что их релевантность относительно Скрама ограничена.

Связи между участниками группы

 

Скрам и Аджайл Сертификации от scrum.org

 

Их принято описывать уравнением N (N – 1) / 2.

По сути, это уравнение показывает, сколько взаимоотношений будет существовать в командах разных размеров. N = количество людей в команде. Так что в первом примере N=5 дает нам 10 взаимоотношений. 10 разных сочетаний участников команд с другими участниками команд в их взаимодействии и отношениях. Во втором примере n=7, и у нас 21 отношений, а при n=9 отношений уже 36.  Каждая пара людей — одно из этих отношений, а словом отношение мы обозначаем то, как они сотрудничают. В эффективных командах отношения должны быть хорошими между всеми участниками.

Почему это важно? Каждый человек добавляет в команду продуктивности, но каждый и увеличивает коммуникационную нагрузку. Чтобы увеличить команду от 5 до 7 человек, нам придется увеличить коммуникационную нагрузку почти вдвое.

Но сколько именно уходить ресурсов на то, чтобы поддерживать эти отношения? По моим ситуативным наблюдениям за командами сайтов клиентов могу сказать, что в командах по 7-8 человек у каждого от 90 минут в день уходит на коммуникацию с другими участниками команды (это было неформальное наблюдение, и я не включал в него перерывы на обед и парное программирование). Некоторые из этих взаимодействий — разговоры о работе, но их, как правило, не меньше, чем просто общения. Что неплохо, ведь только в коллективе, который объединен работой и общением, способность справляться с вызовами действительно высока. (см. раздел о кулере в Five Steps Towards Creating High-Performance Teams.) Но в целом, отношения между участниками команды и временные затраты на них стоит учитывать при расчете размера команды, потому что это повлияет на продуктивность.

Общее практическое правило таково: люди обычно продуктивно работают по 3-5 часов каждый день. Так что с ростом команды мы либо теряем продуктивность, либо, что чаще, начинаем отдаляться друг от друга в социальном плане. Для эффективности команды нам нужны сильные отношения, но с ростом группы становится все меньше времени их строить (Mueller, J. S. Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes (2011), doi:10.1016/j.obhdp.2011.08.004).

Что говорят исследователи

Американская Социологическая Ассоциация опубликовала исследование Хэкмена и Видмера “Влияние размера и типа задания на эффективность группы и реакции ее членов” (Effects of size and task type on group performance and member reactions).

Как выбрать размер Скрам команды

 

Исследователи попросили группу людей выполнить несколько заданий — смесь производства (в этом случае написания текста), обсуждений и решения проблем. Участников исследования распределили по группам от 2 до 7 человек. По окончании каждого задания им задали вопросы, в том числе и те, что показаны на рисунке: “Была ли ваша группа слишком маленькой?”, “Была ли она слишком большой?”. Как видно из графика, группы из 4-5 человека вызвали меньше всего нареканий. Часто приводят число 4.6. Ключевые условия эксперимента были такими:

  • волонтеры были студентами бакалаврата (к сожалению, только мужского пола),
  • задания предусматривали когнитивную нагрузку, но не были связаны с программированием,
  • группы не работали вместе так долго, чтобы у них сформировалось реальное чувство “команды”.

И тем не менее, наблюдения авторов интересны.

Ко времени, когда Хэкмен написал книгу Leading Teams, общепринятой стала цифра 6 (см. Familiar Metric Management – Small is Beautiful-Once Again).

Как пишет Дженнифер Муллер в работе Is Your Team Too Big? Too Small? What’s the Right Number?:

“Если в компании важны координация и мотивация, и вы спрашиваете их о их актуальном и оптимальном размере команд, это сводится к команде из 6 человек… “Когда цифры выходят за пределы 5, мотивация снижается,” — утверждает Муллер. — “При количестве за пять человек начинают формироваться узкие группы. Также в больших группах растет количество людей, которые могут говорить одновременно в определенный момент.”

Но размер группы не должны определять только личные мнения участников команды; есть и объективная статистика. Патнем и Майерс изучили данные о 491 проектах в большой корпорации (ссылка). Количество строк кода в этих проектах достигало 35,000 – 90,000. Проекты были разделены на блоки по количеству людей, вовлеченных в проект: 1.5 – 3, 3-5, 5-7, 9-11, 15-20. В среднем, малым группам (3-5, 5-7) требовалось намного меньше времени (11.9 и 11.6 месяцев), чем крупным группам (17.1 и 16.29 месяцев) для проектов одинакового объема.

Если умножить эти показатели времени на количество месяцев, результаты шокируют еще больше:

 

Как выбрать размер Скрам команды

 

Так что команда из 9-11 человек работала в ~2.5-3.5 раза дольше команд из 5-7 и 3-5 человек над проектами одного и того же объема. Получилось, что команды из более 7 сотрудников были верным путем истратить деньги быстрее: размер команды увеличивался, а общая продуктивность снижалась.

Данные с реальных Аджайл-проектов

Ларри Маккероне, работая в Rally, Tasktop и AgileCraft, подготовил большие массивы данных о практиках Аджайл-команд. А именно:

 

Скрам и Аджайл Сертификации от scrum.org

 

По данным Ларри, команды из 1-3 человек более продуктивны, но качество дают меньше. Команды из 3-5 человек несколько более продуктивны, чем те, в которых их 5-9, хотя по-прежнему выдают чуть меньшее качество — разница невелика. Из заметок Ларри следует, что оптимальным числом нужно считать 3-9. Хотелось бы, чтобы в данных группы 5-9 были разделены на группы по 5-7 человек и 7-9, чтобы разницу в данных было видно четче.

Личный опыт

Я обнаружил на практике еще один фактор, который влияет на выбор размера команд: большие команды тратят больше времени на формирование, нормирование и вообще на путь к оптимальной продуктивности. Почему? Нужно выстроить больше отношений. Как мы убедились ранее, в команде из 5 человек нужно сформировать 10 отношений, в команде из 7 — 21 и так далее. Чем больше отношений, тем больше времени нужно, чтобы выстроить их и создать доверие.

При прочих равных параметрах (например, навыках выполнения работы, разнообразии подходов и т. д.) команды из 4-6 человек кажутся мне лучшим выбором. Они формируются быстрее, а продуктивность их может сравниться с большими командами. К тому же, команды по 5-6 человек обычно имеют достаточно взаимозаменяемых умений, чтобы восполнить потерю одного из участников, если он(а), например, выиграет в лотерее.

Я бы остановился на команде в 7 человек только в том случае, если бы это біло действительно необходимо, например, из-за набора навыков. Я больше не рекомендую работать командами по 8 человек, поскольку расходы на дополнительную нагрузку превышают прибыль от дополнительного сотрудника.

Команды от 9 человек я рекомендую разбивать на на две меньших. Мой опыт отражает опыт многих других Скрам-тренеров и коучей — отдельные команды по 4 и 5 человек сделают больше, чем изначальная большая команда.

Почему не 3 и меньше? В этом случае слишком мало разнообразных точек зрения, а еще трудно набрать достаточные навыки для выполнения работы. Будет очень мало сотрудничества, а это отразится на качестве (как видно по графику из Impact of Agile Quantified). И наконец, возникают очевидные проблемы разделения сил между одним человеком и рабочей парой, которые могут дополнительно осложнить продвижение.

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

 

Переведено и адаптировано командой BrainRain по статье Марка Левисона Choosing the Team Size in Scrum

 

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости