Чому команда розробки повинна бути маленькою?
У ScrumGuide зазначено, що команда обмежена розміром від 3 до 9 осіб. У багатьох виникає питання: чи не занадто це мало? Хіба робота не піде швидше, якщо людей більше? У деяких випадках це дійсно так. Наприклад, якщо вам потрібно закинути 10000 листів в 10000 поштових скриньок. Але при розробці програмних продуктів все працює трохи не так.
У цій статті ми розповімо, звідки виникло обмеження на кількість осіб в команді і чому, працюючи по Scrum, краще розділяти великий проект на підпроекти, ніж вести один великий проект цілим відділом.
Роботодавців, як нікого іншого, хвилює питання ефективності і розподілу ресурсів.
У другій половині XX століття проводилося чимало досліджень з цього приводу. Перші прогнози трудовитрат на дослідження проходили в IBM, і пізніше Лоуренс Патнем переклав отримані графіки на розробку ПЗ. Також відома книга Фреда Брукса –«Містичний людино-місяць». Автор вивів свій закон: «Якщо проект не вкладається у терміни, то додавання робочої сили затримає його ще більше».
Дослідження Лоуренса Патнэма і Вейра Майерса розглядало близько 500 програмних проектів середньої величини. Автори прийшли до висновку, що команди з 9 і 20-ма учасниками вимагають в чотири рази більше людино-місяців, ніж команда з 3-7 учасників. Розмір проекту при цьому не змінювався.
Більш легка самоорганізація
Scrum-процес спрямований на те, щоб створити команду, яка самоорганізується, яка здатна постачати цінний продукт. Команда сама вирішує, як виконувати поставлене завдання.
Щоб самоорганізація працювала, кожен у команді повинна синхронізуватися з іншими учасниками. Розробники повинні знати, що робить колега, щоб вчасно запропонувати свою допомогу або обмінятися досвідом.
Для самоорганізації та взаємодопомоги також потрібно, щоб члени команди добре один одного знали і постійно спілкувалися. Якщо ви знаєте своїх колег, їхні навички і звички, ви будете краще орієнтуватися, до кого і коли звертатися. Ви також будете знати, коли за допомогою цієї доречно звернутися –наскільки завантажений колега і наскільки його пріоритетні завдання. У свою чергу, інші учасники теж будуть знати, з якими питаннями йти до вас.
Це допомагає розробці та самовідчуттю членів команди.
Команда з 5 чоловік вимагає 10 ланцюжків відносин між її учасниками. Значення зростає експоненціально. Для команди з 6 чоловік потрібно вже 14 зв’язків, а для 8 осіб -28.
Коли команда стає більше, великий колектив ділиться на підгрупи за ступенем спілкування або за особистим симпатіям. Це ускладнює роботу над спільною метою.
Якщо всередині команди (із загальною метою) є групи або підгрупи, вони змушені координуватися один з одним додатково. У результаті навіть велика команда ділиться на дрібні, так чому б відразу не встановити такий поділ?
Менше часу даремно
Scrum допомагає скоротити накладні витрати за рахунок маленьких команд. Відбувається оптимізація часу, що витрачається на зустрічі. Зборів між невеликою групою людей йдуть результативніше і швидше.
Нам потрібно прийти до великого результату за менший час.
Залученість невеликої групи вище, кожен може брати участь, не витрачаючи на це цілий день.
Наприклад. У нашій scrum-команді 5 розробників. Зазвичай вони завершують по 4 користувальницькі історії за спринт. До обговорення виноситься 20 історій. За 4 години, які відводяться на планування, команда встигне докладно розібрати кожну задачу.
Тепер уявімо, що наша команда вміщує в себе 9 розробників. Вони також встигають зробити за 4 історії. Потрібно обговорити 36 історій за ті ж 4 години. Чи постраждає якість розбору, або доведеться збільшити час обговорення.
Цю закономірність можна відстежити не тільки планування, але і на інших зустрічах.
Зниження кількості документації
Якщо команда не дуже велика, то, як ми з’ясували вище, люди можуть зберігати зв’язку один з одним. Це призводить до того, що документацію щодо проекту можна вести через власні історії і інші типи карток.
Принципи Agile свідчать:
- Люди і взаємодія важливіше процесів та інструментів
- Працюючий продукт важливіше вичерпної документації
Команда приходить до розуміють деталей продукту в процесі розмови з Product Owner’ом, вона може малювати схеми, використовувати стікери і дошку –все, щоб вникнути в завдання. Це скорочує час на ведення документів, які не несуть ніякої цінності. Крім цього, особисте обговорення знижує ризик нерозуміння.
Якщо команда велика, документацію доведеться вести більш ретельно або витрачати час на передачу інформації, граючи в зламаний телефон. Ті, кого не стосується конкретна історія (а у великій команді цей відсоток вище), взагалі не будуть вникати.
Особиста відповідальність і залученість
У невеликій команді внесок кожної людини вище. В команді з п’яти розробників кожен вносить 1/5 цінність продукту. В команді з 20 осіб на кожного припадає лише 1/20. Чим більша ймовірність, що без тебе проект впорається, тим нижче мотивація і більше приводів побайдикувати.
Можливість бачити, що наш труд приніс успіх, сильно мотивує, а з мотивацією працювати легше.
Якою ж має бути команда
Коли ви запускаєте нову команду, почніть з мінімально можливого розміру для вашої області. Переконайтеся, що в команді достатньо навичок для всіх сфер, які постійно потрібні в розробці продукту. Поодинокі питання краще вирішуються через запрошеного експерта або t-shaped члена вашої команди.
Коли команда проведе кілька спринтів і зрозуміє, що їй критично необхідні нові працівники, додайте ще одну людину. Але пам’ятайте, що додавання нового співробітника не збільшує швидкість роботи пропорційно. І не піддавайтеся бажанням розширити штат за 9 осіб, зазначених у ScrumGuide.
Якщо у вас вже велика команда, проведіть експеримент. Розділіться на дві-три групи на кілька спринтів навколо частин продукту і подивіться, як збільшаться темпи вашої роботи.