Багато речей у скрамі змінити не можна — наприклад, набір ролей або зустрічей. Але розмір команди може варіюватися, а тому викликає питання. Від чого він залежить і яка команда буде ефективною для вас?

Скільки людей має бути в команді розробки?

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

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

У формуванні команди розробки найважливіші — чинники, в яких враховані її потреби, а не довільні цифри:

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

Коли команда вже сформована, в гру вступають інші, не менш важливі фактори її успіху:

Запрошуємо на сертифікаційний тренінг Management 3.0

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

У перших книгах зі скраму й XP вказано розмір команди 7 +/- 2, за числом Мілера (див. статтю Вікіпедії) — кількістю цілих чисел, яку людина здатна втримати в короткочасній пам’яті. Доцільність такого підходу турбує, адже неясно, як здатність запам’ятовувати пов’язана з розміром команди. До того ж, із новішого дослідження (The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?) виходить, що щойно об’єкти уваги людини ускладнюються, ця людина стає здатною запам’ятати не більше 4-х елементів. Так що тут потрібні надійніші джерела.

Багато коучів приводять історичні приклади зі Стародавнього Риму або більш ранніх часів, коли в підрозділах армії було по 8 чоловік. Інші звертають увагу на бонобо, які добувають їжу групами по 6-7 мавп. Але жоден з цих прикладів не має прямого відношення до команди за роботою, так що їх релевантність щодо скраму обмежена.

Запрошуємо на сертифікаційний тренінг PAL-E

Зв’язки між учасниками групи

Зазвичай їх описують рівнянням 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, JS 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-90 тисяч. Проєкти були розділені на блоки за кількістю залучених людей: 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, підготував великі масиви даних про практики аджайл-команд. А саме:

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

Про розмір скрам-команди, визначення готового і інші важливі речі можна дізнатися на тренінгу PSPO

Власний досвід

Я виявив на практиці ще один фактор, який впливає на вибір розміру команд: великі команди витрачають більше часу на формування, нормування і взагалі на шлях до оптимальної продуктивності. Чому? Потрібно побудувати більше відносин. Як ми переконалися раніше, в команді з 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.