Які способи пом’якшити наслідки Міфічного місяця людини?

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

У своїй книзі " No Silver Bullet - Сутність та аварії інженерії програмного забезпечення" Фредерік Брукс визначає концепцію Міфічного місяця людини :

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

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

Що таке МММ

Спершу я хочу пояснити контекст Закону Брука. Яке припущення змусило його створити ще в 1975 році?

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

^{джерело: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

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

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

Але чи справді це має бути таким? Чи потрібно писати моноліти і тримати канали зв'язку n(n − 1) / 2там, де nкількість розробників?

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

Можливість пом'якшити MMM

У 2015 році PuppetLabs та IT Revolution опублікували результати звіту про стан DevOps за 2015 рік . У цьому звіті вони акцентували увагу на різниці між високопродуктивними організаціями та неефективними.

Високопродуктивні організації демонструють деякі несподівані властивості. Наприклад, вони мають найкращі проектні терміни, що відбулися в процесі розробки. Найкраща експлуатаційна стабільність та надійність в експлуатації. А також найкращий досвід безпеки та дотримання вимог.

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

Це графік цього звіту -

Хоча низькопродуктивні організації узгоджуються з припущеннями Міфічного чоловіка місяця. Високопродуктивні організації можуть масштабувати кількість розгортань / день / розробку лінійно за кількістю розробників.

Відмінна презентація на DevOpsDays London 2016 Джона Кіма розповідає про ці висновки.

Як це зробити

По-перше, як стати високоефективною організацією? Є кілька книг, які розповідають про це, недостатньо місця в цій відповіді, тому я просто посилаюся на них.

• Добре для великого: Чому деякі компанії роблять стрибок ..., а інші - не Джим Коллінз
• Край високої швидкості: як лідери ринку набувають оперативної майстерності, щоб перемогти конкуренцію Стівен Спір
• Нова економіка для промисловості, уряду, освіти У. Едвардса Демінга

Для програмних та ІТ-організацій одним з найважливіших факторів для досягнення високоефективної організації є: орієнтація на якість та швидкість .

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

Ніколи не вистачає часу, а технічна заборгованість просто стає все гіршою і гіршою.

Які ці речі викликають зростання технічної заборгованості?

• спадковий код
• ручна конфігурація середовищ
• ручне тестування
• ручне розгортання

Спадковий код Як визначено в « Ефективній роботі зі застарілим кодом » Майкла Пірса, це будь-який код, який не має автоматизованого тестування.

Будь-які скорочення використовуються для отримання коду до виробництва; операції обтяжені збереженням цього боргу назавжди. Тоді процес розгортання стає все довшим і довшим.

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

Одним із принципів DevOps є те, що надійність виходить із частішого розгортання.

Приклад

• Джон Дженкінс зі швидкістю 2011 : Амазонка робить 15 крок в день
• Кен Еннер на саміті AWS 2015 : Amazon роблять 136 тис. Розрядів на день

Ці дві презентації показують все, що Amazon зробив для скорочення часу, необхідного для розгортання коду для виробництва.

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

Це означає, що за певних умов, при правильній архітектурі, правильній технічній практиці, правильних культурних нормах, продуктивності розробників можуть масштабуватися у міру збільшення кількості розробників. І DevOps, безумовно, в середині всього цього.

Що я зробив (і це лише суб'єктивно):

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

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

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

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

Традиційні системи ІС мають проблему масштабування в цьому відношенні: ймовірність зривів / регресій / блокувань збільшує сповільнення швидкості інтеграції та запрошення менших команд вийти з ладу та перейти на дочірні відділення (тобто подальше уповільнення). Див. Як можна безперервно інтегрувати інтеграцію для дуже великих проектів / команд? . Це грає прямо вздовж концепції Міфічного чоловіка щомісяця.

Я пропоную рішення, відповідаючи на це запитання, високомасштабною системою ІС дозволить перейти до справжнього CI - інтеграції на базі однієї гілки / магістралі для більшої кількості команд (навіть з величезними розмірами).

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

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

Я вважаю, що все це є заспокійливим ефектом концепції Міфічного чоловіка.