Що трапилося з малюнком «Хірургічного колективу» з «Міфічного місяця людини»?

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

Хірургічний колектив

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

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

Чому так?

• Тоді хірургічна команда була навіть незвичною?
• Або це було випробувано і не вдалося?
  • Якщо так, то як це не вдалося?
  • Якщо ні, то чому б ми не побачили цю схему, реалізовану в сучасних програмних проектах?

"Міфічний чоловік-місяць" вийшов у той рік, коли я розпочав навчання в коледжі, і, використовуючи нинішню просторічність, ОБОВ'ЯЗКОВО! :-) Те, що вам потрібно зрозуміти, - це різниця в тому, як програмне забезпечення було розроблено ТОГО проти ЗАРАЗ. Назад в день (тм) майже все кодування було зроблено спочатку на папері, потім було натиснуто на клавіші (ви здогадалися) на перфокарти, потім було прочитано, складено, зв’язано, виконано, отримано результати, і процес повторився. Час процесора було дорогимі обмежений ресурс, і ви не хотіли його витрачати. Дітто і так само дисковий простір, час накопичувача тощо тощо. Витратити ідеально хороший час процесора на компіляції, що призвело до (шоку і жаху!) ​​Помилок було ... ну, марною тратою ідеально хорошого часу на процесор. І це було в 1975 р. У той час, коли Фред Брукс розробляв свої ідеї, а час CPU від середини до кінця 1960-х був ще більшедорога, пам'ять / диск / все, що було навіть БІЛЬШЕ обмежене, тощо, і т.д. подання робочих місць, очікування (іноді години) результатів. Людина розробника Rockstar Dude повинна була писати КОД. Його легіон гуртів / діловодів / молодших розробників повинен був робити мирські речі.

Проблема полягала в тому, що протягом двох років виходу книги Брукса основні ідеї, що стояли за Хірургічним колективом, розпадалися:

1. CRT-термінали та дискові файли почали замінювати клавіші та колоди карт. Час роботи на комп’ютері стало менш дорогим, кілька комп'ютерів стали доступними, а час виконання роботи різко скоротився. Коли я потрапив до коледжу (університет Майамі, Оксфорд, штат Огайо, клас 79 років, спасибі за запитання) добреОбертання роботи склало близько години. Протягом тижня фіналу - чотири години, а може, іноді і шість. (Ми змагалися за час процесора з купою комерційних компаній та університетів - і комерційні користувачі отримали першочергове значення). Протягом мого старшого року, коли в Майамі вийшли зі свого "спільного комп'ютера", влаштували власний IBM 370/145 в кампусі, і у мене був гарний міні-міні HP, на якому я працював, і він працював як станція RJE, і ми могли перетворити мейнфрейм. робочі місця протягом п'яти хвилин або менше. Тепер варто запустити свій код у HP, надіслати його від HP до мейнфрейму, згорнути великі пальці / викурити сигарету та отримати висновок задовго до того, як ви зможете закінчити перевірку свого коду.

2. Основна передумова хірургічного колективу - ідея, що ви (або "менеджмент", Боже, допоможіть нам усім) можете ідентифікувати чувак The Rockstar Surgical Developer Dude. Насправді я сумніваюся, що це можливо. Там є Rockstar розробників, кожен знає , що це - дослідження показали відмінності в продуктивності між кращими і гіршими розробниками цілих 2000% - але , визначивши , що людина без них писати код в протягом тривалого періоду часушвидше за все неможливо. Єдиний спосіб дізнатися, чи є хтось розробником Rockstar, це змусити їх насправді розробити код - але якщо вони НЕ чувак Rockstar хірургічного розробника, вони будуть робити захоплюючі речі, такі як письмовий стіл - перевірка його коду, клацання клавіш на картки та ін. клацаючи ящики з перфорованими картками до відділу вступу на роботу, потім стоячи навколо, чекаючи результатів, щоб вони змогли повернути їх до містера Rockstar Surgical Developer Dude, замість того, щоб навчитися кодувати єдиний спосіб, який справді працює - написавши код, налагоджуючи код, і т. д. Back In The Day (тм) не було жодних конкурсів програмування, не було переповнення стека, у вас не було ПК, на якому ви могли б переходити писати код, коли вам здалося, не було алгоритмів книг для ідіотів - єдиний спосіб навчитися програмуванню - це піти в школу і поступити на щось, де вам доведеться трохи програмувати. Але програмуванняяк насправді, це не сприймалося серйозно, і вважалося, що це щось, чого люди не хочуть робити . На моєму першому курсі коледжу (SAN151 - Вступ до системного аналізу, доктор Том Шабер - дякую, Том :-) нам інструктор сказав, що "... ми просто повинні зіткнутися з тим, що нам доведеться витратити пару років як програмісти, перш ніж ми могли стати системними аналітиками ". «Два роки?», Подумав я. "Я ТІЛЬКИ ЗДОРОВ'Я ЗРОБИТИ ЦЕ ДВІ РОКИ?!?". Мене серйозно роздуло. На щастя, він помилявся, і я з тих пір кодував майже все. :-)

3. Хірургічний колектив припускає, що програмісти є відносно рідкісним ресурсом. Насправді це пройшло ще кілька років, але з появою ПК на початку 80-х програмування стало чимось, до чого може втягнутися будь-який вундер. Ціна комп'ютерів почала падати, ціна інструментів розвитку почала падати, і все було град Турбо Паскаль - за сьогоднішніми мірками це було не так багато, але в той час це був повний Pascal IDE приблизно на 40 баксів, що було абсолютно горіхом! Тепер будь-хто може вступити в програмування - якщо ви могли дозволити собі комп’ютер, і коли IBM вирішила поставити PCjr (так, мій перший ПК був однією з найбільших помилок IBM :-) у продажу за 500 доларів, щоб позбутися цих індичок, готівки -спішні вундеркинди скрізь пропускали свої орендні платежі на місяць ("Ага, е, я знаю, але я, е ... зламав мою вувулу, і мені довелося перенести операцію і .. .уа ... так, на наступному тижні, жодних проблем, спасибі, чоловіче ...), і висмоктав їх за цінами продажу. Тоді витратили більше, ніж ми заплатили за комп’ютер на додатки, щоб зробити його корисним. ("Так, чоловіче, наступного тижня, точно, напевно ..." :-).

Мене дуже сумно - це те, що навіть сьогодні, якщо ви запитаєте людей, чи читали вони коли-небудь "Міфічний чоловік-місяць" чи розуміють його основний урок ("Якщо додавати ресурси до пізнього проекту, це стане пізніше"), вони дають вам пусту погляд - а потім приступайте до тих самих помилок, які були допущені Усі ці роки перед розробкою ОС / 360. Все старе знову нове ...: -}

Є деякі аспекти цієї концепції, які іноді реалізуються сьогодні, є й інші аспекти, яких уникають .

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

Крос-функціональні команди також є найважливішим елементом Agile, але також поширеним поза межами Agile.

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

Аналогічно, роль системного адміністратора (не частина хірургічної команди Міллса, а частина типової міжфункціональної команди останніх років) застаріла такими поняттями, як DevOps (поглинаючи роль Sysadmin в ролі інженера-програмного забезпечення) , Платформа як послуга, Інфраструктура як послуга та Утилітні обчислення (виконуючи роль Sysadmin "чужою проблемою") або Інфраструктура як код (перетворення системного адміністрування в інженерію програмного забезпечення).

Одним із аспектів, якого ми намагаємось сьогодні уникнути, є те, що не менше двох людей розуміють систему. Тільки хірург гарантовано зрозуміє систему повністю, пілот може, а може і не. Це дає коефіцієнт шини від 1 до 2. Якщо хірург захворіє, проект помер. Період. Відповідна відповідь на це - Колективне володіння кодом, що є абсолютно протилежною цій моделі: ніхто не несе відповідальності за будь-яку частину системи. Натомість всі відповідають за все як групу .

Нарешті, є деякі припущення, викладені в цій концепції, які застаріли. Наприклад, навіть якщо це не вказано прямо, команда створена таким чином, що лише одна людина в колективі (хірург) насправді має комп'ютер. Це, звичайно, тому, що на той момент, коли була написана стаття, навіть думка про те, що вся команда матиме один комп’ютер для себе, не кажучи вже про одну людину в команді, була розтяжкою. (Навіть у 1980 році, коли був випущений Smalltalk, однією з речей, що сприяли його відмові, було те, що система була створена таким чином, що кожен розробник і кожен користувач мав власний комп'ютер - зовсім немислимий на той час.)

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

Це було раніше, освіта в коледжі була чимось унікальним, і інженери були серед небагатьох обраних. Комп'ютери були дорогими, а команди працювали над проектами з визначеним бізнес-інтересом. Вони були не дуже поширеними.

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

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

(Пов'язаний економічний термін - "захворювання витрат на сферу послуг".)

Ці схеми мені дуже звучать як програмування Mob:

Вся група (QA, розробники і навіть власник продукту, якщо це потрібно) працюють одночасно над однією проблемою. Немає стояння, висока комунікація, безпосередньо розгорнута в прямому ефірі.

З http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Основна концепція моб програмування проста: вся команда працює разом як команда разом над одним завданням. Тобто: одна команда - одна (активна) клавіатура - один екран (звичайно, проектор). Це так само, як робити програмування для повнокольорових пар.

Побачити це в дії тут: https://www.youtube.com/watch?v=dVqUcNKVbYg

Ця модель команди знову згадується у програмі Rapid Development - приборкання диких програм програм Стіва МакКоннелла на сторінці 305. Там її називають командою головного програміста.

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

Інші посилання:

Бейкер, Ф. Террі. "Головний командний програміст з управління виробничим програмуванням", IBM Systems Journal, vol. 11, ні. 1, 1972, стор 56-73.

Бейкер, Ф. Террі та Харлан Д. Міллс. "Команди головного програміста". Дані, Том 19, Число 12 (грудень 1973 р.), Стор 58-61.

Я здогадуюсь, що більшість невеликих самоорганізуються команд так чи інакше схиляються до фактичної хірургічної моделі.

Останні дві команди, на яких я був, складалися з трьох-чотирьох людей, як правило, один старший (хірург), проміжний (пілот) та пара юніорів / спеціалістів. Деякі ролі в хірургічній команді, про які згадував Брукс, сьогодні виконуються майстрами Scrum та сисадмінами або постачальниками послуг хмари. Пам'ятайте, що контроль над джерелами ледь не існував у той час, не кажучи вже про щось таке потужне, як git.

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

З HP вийшов папір, який запропонував щось подібне:

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

Папір був у дні, що відбулися до веб-сторінок, і час від часу видавався як смішний. Щороку його виховували, коментар переходив дещо більше від "настільки смішного свого смішного" до "можливо, ми повинні це робити".

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

Цікаво, наскільки потреба в хірургічній команді стала надмірною через зростання Інтернету, інтегрованих середовищ розробки та наборів для розробки програмного забезпечення , які можуть зайняти багато функціональних можливостей, які Фред Брукс приписує хірургічній команді, включаючи:

• Хірург: програміст
• Копілот : парні програмісти , співробітники, інтернет-спільноти, такі як StackExchange або IRC
• Адміністратор: роль, яку зазвичай займає менеджер програмного забезпечення
• Редактор: IDE, що інтегрують генератори документації, такі як Javadoc або Doxygen; документація з наборів для розробки програмного забезпечення
• Секретар: клієнт електронної пошти, інструменти для управління проектами, такі як трекер видачі та запити на виклик, компанії-чати та списки розсилки
• Службовець програми: IDE, що зберігає інформацію про дизайн проекту, з доданою здатністю до коду рефактора; документація та приклади з наборів для розробки програмного забезпечення
• Toolmith: вся спільнота з відкритим кодом
• Тестер: негайно тестові набори та бібліотеки для тестування. Але звичайно необхідний окремий процес забезпечення якості для виробничого коду.
• Мовний юрист: онлайн-документація, StackExchange

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

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

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

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

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

Як програміст, який часто виконував ролі DevOps і Build Master, я відчував, що часто опиняюся на посаді хірургічної команди. Помилка ... хлопець у команді. Як майстер збірки я оглянув весь код і був першим рядком, коли він не вдався. Часто я би сам це виправляв.
Я часто був тим, хто пише ці системи метрик і вимірює гарячі точки в коді, частини, які частіше виходять з ладу, що залучають найбільше звітів про помилки і т. Д. Я не просто публікував результати команді, я б також їх аналізував, знаходив виклик, що викликав проблему та запропоновані рішення та архітектурні зміни для вирішення цього питання.

Як DevOps, я б автоматизував величезну кількість процесів і накладних витрат. Я б досліджував технології та інструменти, які б полегшили життя команді, всій команді, починаючи від розробників, ІТ-тестувальників ІТ, аж до управління. Моя роль полягала в розумінні процесу, так; але, тримаючи мої погляди на команду (власне людей), що використовує (страждає через) цей процес, я зміг перегнати його до того, щоб зробити його повністю прозорим, все одно отримуючи низку корисних даних, щоб отримати об'єктивне уявлення про це завжди невловима "велика картина".

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

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