Основні закони створення команд розробників

В EDISON часто звертаються інженери, які бажають додати співробітників в команду. Хочеться швиденько склепати задачку», скориставшись десятком додаткових розробників. Працює такий підхід? На жаль, не завжди. У програмуванні, як у фізиці, є закони.


Зібрати розумну команду — справжнє мистецтво

Закон Брукса
Жодне обговорення команд розробників не проходить без згадки даного принципу:

«Додаючи людських ресурсів, ми затримуємо закінчення програмного проекту» (Брукс, 1975).
Незліченні команди розробників підтвердили постулат. Закони Брукса і Конвея складають базу.

Приєднуючи нової людини, команда витрачає зусилля на введення в курс справи, на пояснення використовуваних трюків і пристрої. Учасники витрачають час на інформування і синхронізацію з новобранцем, на навчання праці в команді та передачу знань. Робота сповільнюється.

Свіжий персонал потребує допомоги не тільки в перший тиждень. Частина авторів (наприклад, Коплиен і Харрісон) припускають річний інтервал до отримання від новачка продуктивності. Не варто надавати твердженням зайвого значення з-за впливу різних факторів. Розумно припустити, що частина співробітників обійдеться без допомоги в перші три місяці.

Команда може сповільнити роботу задовго до появи нової людини. Співробітник не виникає просто так. Іноді менеджери по персоналу діють в приватних інтересах, запитуючи більше ресурсів. Посадові інструкції потрібно написати, перевірити, видати, передати у відділ кадрів, послати рекрутським агентствам. Буде потрібно час на затвердження процесів.

Резюме слід обдумати і написати або відмову, або виклик на співбесіду. У разі схвалення кандидата складається контракт і відправляється пропозицію про прийняття в команду.

Процедури проходять до отримання людиною права написати рядок коду. Навіть якщо відділ кадрів керує більшістю процесів, лідери команди і прості члени обов'язково будуть відволікатися. Час на реальну роботу і розвиток скоротиться.

Закон Брукса не означає повну відмову від розширення команд. Але зростання об'єднання рідко відбувається швидко. Якщо команда вирішила розширюватися, буде використовуватися частина продуктивності для нарощування потужності.

Річард Шерідан зробив сміливу заяву:

Я радий повідомити, що закон Брукса може бути порушений. Вся наша діяльність сфокусована на тому, щоб зламати твердження. Поділ людей на пари, переміщення між парами, автоматизація тестування, управління кодом, наймання, заснований не на героїв, постійні переговори, відкрита робоча середовище і видимі артефакти — все, щоб спростувати твердження Брукса (Шерідан, 2013).
У книзі автор підносить середовище розробки ЗА відмінну від реальної для більшості розробників і менеджерів. Корпорація Menlo не скупиться у питаннях побудови, участі та зміцнення власної культури та спільноти. Поки компанії не випробують підхід на практиці, не виникне достатню кількість прикладів для вивчення, важко сказати, чи варто копіювати зразки Шерідана.

Методи, описані автором, заслуговують довіри. Відмінно, якщо закон Брукса буде порушений.

Закон Конвея
Організації, що проектують системи,… виробляють їх, копіюючи структури комунікації, що склалися в цих організаціях,
— Конвей, 1968
Люди та їх організація відіграють значну роль у визначенні архітектури, прийнятої розробниками.

Уявімо створення урядом нової системи соціального забезпечення. Потрібні бази даних, інтерфейси, бізнес-логіка. Знадобляться розробники і тестувальники, дорогий менеджмент, встановлення вимог і інше.

У підсумку результат знаходить видимі обриси: визначені ролі користувачів, workflow, форми даних, звіти. У цей момент, погодьтеся, створення меншою або принципово відрізняється системи вже неможливо.

Поглянемо на систему після 10-ти років функціонування. Спостерігається зворотний закон Конвея:

Підприємства, що використовують програмні системи… обмежені структурами комунікації, які копіюють цю систему.
Закон Конвея повідомляє про можливе копіюванні проблем підприємства в інтерфейсі: у шарах, або в APL, або в модулях, або де-небудь ще.

Закон Конвея необхідно враховувати при організації команд і софтверних систем. Спроби зламати принцип свідомо або через незнання створять сили протидії проекту. Виглядає, як бажання розколоти деревину поперек волокон. Розумніше поважати і використовувати закон Конвея.

Число Данбара. Природні орієнтири
«Екстраполяція на людей стосунків серед мавп дає уявлення про розміри соціальних груп. Близько 150 особин — межа соціальних відносин людини. Кількість удостоїлося назви «Числа Данбара»,
— Данбар, 2010
Частий питання від груп розробників: «Наскільки великою має бути команда?» Робота антрополога Робіна Данбара дає цікаві ідеї при спробі відповісти на питання.

Автор надає переконливі доводи, що 150 є верхньою межею для организациилюдей. Данбар помітив вказане число у військових формуваннях з часів Стародавнього Риму, в неолітичних поселеннях, громади амішів і в сучасних науково-дослідницьких групах.

Спільноти понад 150 членів менш згуртовані, потребують підвищеного контролю поведінки та ієрархії. У дослідженнях та аналізі підкреслюються основні моменти у формуванні груп. Параметр грамотніше назвати «Числом Данбара». Характеристики застосовні до різних груп, що входять до складу великих формувань. Менші команди міцніше і за припущенням спираються на числа з множником 3.
Дотримуючись тези, у більшості людей коло близьких друзів від 3 до 5 осіб. Наступний рівень приятелів від 10 осіб до 13-15 (при певних зусиллях). Чергова група містить від 30 до 50 — типовий бойовий взвод. Популяція в 150 представляє мінімальний незалежний блок у військовій компанії і точку створення на підприємствах окремих угруповань.

Данбар передбачає існування формування у 500 і 1500. Автор підтримує Платона у визначенні ідеального розміру для демократії в 5300 одиниць. Можна провести цікаві паралелі між розмірами військових блоків.

Організація Розмір
Пожежна дружина 4 або менше людина
Секція/Загін 8-12 учасників (кілька пожежних дружин)
Взвод 15-30 службовців (2 загону)
Рота 80-250 солдатів (кілька взводів)
Батальйон 300-800 бійців
Список не є кінцевим. Не варто забувати про відмінності між країнами. Навіть про особливості флангів однієї військової організації. Але в широкому сенсі розміри блоків слідують висновків Данбара.

Магічна сімка Міллера (гаманець Міллера)
Прийнято вважати мудрим вибором розмір команди з 7 чоловік (± 2). Практичного сенсу в твердженні немає. Доказ тези про оптимальній кількості членів команди в 5-9 осіб відсутні.

Прихильники розміру апелюють до знаменитої статті Міллера 1956 року «Магічне число сім плюс-мінус два: деякі обмеження нашої здатності обробки інформації». На практиці більшість посилаються праця не читали.

У статті Міллер стверджує, що 7 є найважливішим числом для опису потужності оброблювальних можливостей людського мозку. Обрана цифра визначає максимальну кількість «шматків» інформації для одночасної обробки розумовим центром. Автор приходить до висновку про неоднозначність трактування частого повторення числа 7:

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

У висновку автор говорить: «Я відчуваю, що моя розповідь тут повинен зупинитися, т. к. він вже став досить цікавим». З публікації статті Міллера минуло понад 50 років. На загальну думку, діапазон команди 5-9 осіб задовільний для управління змінами. Знизу інтервалу виправдана необхідність проведення тестів та виконання вимог до команди фахівців. На верхній межі діапазону складно здійснювати повний контроль системи. Тому кількість співробітників від 5 до 9 чоловік має сенс.

Описане кількість не скасовує існування команд більшого розміру в залежності від обставин.

Розмір команди в методології Scrum
Стаття Міллера про обсяги обробки інформації людським мозком може застосовуватися до визначення розміру команди розробників ПЗ? Звернемося до методології Scrum. У підручнику йдеться: «Команда в Scrum повинна бути сім плюс або мінус два людини» (Димер та ін, 2008). Одночасно в керівництві по Scrum за 2011 стверджується: «Команди з дев'яти членів викликають дуже багато проблем в координації. Великі команди розробників помітно ускладнюють весь процес» (Сазерленд і Швабер, 2013).

Навчальний посібник говорить:

Ролі власника продукту та керівника команди Scrum не включені в підрахунок, крім випадків, коли вони включаються в роботу для скорочення відставання в черговому спринті,
— Сазерленд і Швабер, 2013
Паралельно введення керівника команди Scrum передбачає, що власник продукту знаходиться поза команди.

Інші джерела дають різні рекомендації по визначенню членів групи і «просто беруть участь».

Команди в діапазоні 4-8 чоловік видно повсюдно. Статтею Міллера раціонально обґрунтувати вибір розмірів груп з 7 ± 2. Досвід підтверджує оптимальний межа чисельності. Кількість може бути більше заявленого в джерелах по Scrum.

Закон Паркінсона і Закон Хофштадтера
Робота заповнює весь час, виділений для її виконання,
— закон Паркінсона
Завжди потрібно більше часу, ніж ви очікуєте, навіть якщо ви знаєте закон Хофштадтера,
— закон Хофштадтера, 1980
Спробуємо відповісти на питання: «чи Пам'ятаєте ви навчання у Вузі? В який момент реалізовувалися завдання?» Більшість читачів виконували роботу за кілька днів до дедлайну. Частина займалася проектом в ніч перед здачею.

І переважна більшість вкладалося в строк.

Вчені підтверджують: люди погано справляються з оцінкою періоду, потрібного на виконання роботи, але досягають успіху з рішенням задачі до чітко обумовленою датою (наприклад, Buehler, Гріффін і Peetz, 2010).

При надлишку часу на проект відбувається надмірне розширення обсягу робіт виконавцем.

На розробку програмного забезпечення впливають закони Паркінсона і Хофштадтера. Вибираючи дату дедлайну, неминуче виникне недооцінка необхідного часу. В результаті терміни та обсяг робіт збільшаться. Проведене дослідження (Бюлер, Гріффін і Питз, 2010) свідчить: оптимізм щодо дати виконання завдання дає можливість здійснити роботу раніше, ніж при песимістичній оцінці термінів. Але загальний час виконання проекту оптимістом виявиться довше, ніж у песиміста. Термін дедлайну може бути важливіше передбачуваного часу завершення проекту (Арили і Wertenbroch, 2002).

Закон Голла. Парнас і Александер
Складна робоча система незмінно виходить з простої робочої системи. Складна система, розроблена з нуля, ніколи не працює. І ніякі покращення не змусять її працювати. Починати слід з простою робочої системи,
— закон Голла, 1986
Закон перегукується зі словами Девіда Парнасу:

«Як правило, системи не працюють добре, поки вони не були використані, і не раз, у «бойових» умовах».

Автори підкреслюють різні аспекти одного явища, званого Крістофером Александером «органічним зростанням».

При створенні ПЗ, застосовуючи техніку під назвою «ходячий скелет», рекомендується зробити простий, базовий робочий шматок коду. «Скелет», хоч і з певним ризиком, але проштовхують систему вперед. Створивши базу, команда додає «плоть» — шар функціоналу.

Принцип може застосовуватися до груп, ЗА:

«Ефективна складна команда незмінно виникає з простого продуктивного аналога. Складна команда, зібрана з нуля, результативно функціонувати не може. І ніякі зміни не змусять її працювати. Справу слід починати з вже сработавшейся командою».

Можна провести паралель між складної і великої командою. Закон натякає на спосіб створення великих груп, на гнучку методологію масштабування об'єднань.

Очевидна зв'язок з законом Конвея: побудова «ходячого скелета» базується на кістяк команди. Для створення великого і складного формування використовується рівноцінний скелет-кістяк.

При побудові спочатку масштабної структури Закон Конвея пророкує велику і складну архітектуру. Закон Голла говорить про появу неробочої системи і для витримування термінів радить команді почати з меншого.

Закони Келлі
Слід додати кілька корисних постулатів від автора статті.

Масштаб завжди буде збільшуватися пропорційно наявним ресурсам,
— перший закон Келлі
Всередині кожного великого проекту в області розробки є маленький побічний проект поза основного завдання
— другий закон Келлі
Надмірно масштабна команда для виправдання власного розміру видасть більший обсяг роботи, громіздкі рішення і мудровану архітектуру. Легше додати, видалити проти волі, учасника групи.

Зберігаючи розмір команди невеликим хоча б на початковому етапі, є ймовірність знайти просте і лаконічне рішення. Старт з великою командою буде гарантувати громіздку реалізацію.

Висновок
Числа Данбара визначають ліміт розміру ефективної команди. Спираючись на закон Конвея, можна говорити про потенційний межі системи. Єдиний спосіб обійти аксіому — розділити велику систему на компактні групи. Команди не народжуються повністю сформованими і ефективними. Закон Конвея працює в сукупності з тезою Голла. Групи повинні поступово зростати. Постулат Брукса передбачає, що команди не можуть розширитися занадто швидко. Закон Паркінсона означає зайнятість надмірно великих команд підтриманням власного існування.

Другий постулат Келлі підказує рішення: уникайте великого, зосередьтеся на малому.

Краще не протистояти законам, а знайти підхід і працювати з положеннями. Спроби знайти спосіб поводження з законами можуть бути комерційно вигідними, якщо використовувати їх хоча б для обґрунтування прийнятих рішень перед вищестоящими начальниками.

Стаття є уривком з нової книги Аллана Келлі «Xanpan книга 2: засіб виробництва». Буде доступна в кінці 2015 року.



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.