Адам Сміт проти розробників fullstack - і продуктивність у DevOps?

Адам Сміт, розподіл праці може зробити вас в 240 разів ефективнішими (на прикладі фабрики штифтів, що виробляє шпильки за 18 кроків).

Чому тоді ролі на багато кваліфікованих кадрів настільки затребувані, якщо це насправді знижує продуктивність - чи Сміт просто помилявся, чому тоді?

Пошуки "fullstack developer" все ще є тенденцією в Google, проте, очевидно, повільніше, ніж два роки тому:

=====

Підводячи підсумок, розробник повного стека зможе виконати практично всю ланцюжок цінностей (виправте мене, якщо я помиляюся):

• Обговоріть із замовниками та уточнюйте працездатні вимоги щодо його частини роботи
• Вирішіть, яку архітектуру, інструменти та компоненти виберіть - просто подаруйте йому зошит
• Напишіть код для frontend, backkend, ingration, який є сумісним пристроєм і не потребує великих тестувань, або включає його
• Дані профілю та масштабування, використовуйте Cloud AI / ML API для розширених функцій
• Запишіть необхідний код IaC та розгортання
• Будьте дзвінки у випадку помилок або процесів продажу
• Будьте в курсі безпечного дизайну, загальної латки, міграції та модернізації
• Таблиця графіків рахунків ретельно розглянутий спосіб полегшення виставлення рахунків роботодавцю
• ... я щось забув?

UPD - " нам потрібна продуктивність спеціалізації, але ми не хочемо острівного світогляду" екстремального розподілу праці ". (Хлопці DevOps, " DevOps, Адам Сміт та легенда генераліста " , 2013-2016)

Існує два види роботи:

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

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

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

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

Адам Сміт не потребував розгляду питання про передачу інформації з одного етапу на інший. Це важлива частина будь-якого значного ІТ-проекту. Таким чином, розробник fullstack має суттєві переваги, які:

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

Детальніше про важливість передачі інформації в ІТ-проектах читайте у « Міфічному місяці людини» Фреда Брука .

Відповідь ІМХО має багато спільного з масштабом та наявністю ресурсів.

Я вважаю, що теорія Адама Сміта може бути застосована лише у великому масштабі - цілі країни / економіки в оригінальному контексті, або, в контексті розвитку ШВ - великі команди розвитку.

У великій команді дійсно ефективніше наймати більш спеціалізовані кадрові ресурси:

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

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

У менших за розміром або навіть одноосібних командах (як правило, стартапах або навіть ізольованих менших командах у більших організаціях) використовувати такі ресурси неефективно або навіть неможливо: і все-таки виконати роботу:

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

Я вважаю себе розробником fullstack на основі наступного поєднання обов'язків:

Програмування переднього та заднього кінців

Я можу до певної міри змінювати інтерфейс користувача: писати html, css (як веб-розробник), а з іншого боку в деякому розширенні надавати в інтерфейс дані з бази даних, надавати їх у сервісі тощо.

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

Навпроти

На мою точку зору, навпаки, були б суворі ролі хлопців із інтерфейсу та хлопців із зворотного боку.

Висновки

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

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

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

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

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

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

Важливим моментом для розуміння є те, що розподіл праці не завжди означає різну людину за крок.

Я взяв би свою власну історію на заводі автомобілів, я був на ланцюзі складання сидінь, щоб отримати повноцінне сидіння з подушкою безпеки, шкірою, підголівниками і т. Д. Ланцюг був розбитий на 9 ступенів. Ми працювали 9 ланцюгів. Кожна людина робила лише один етап за один раз, але щогодини ми переходили на наступний етап, щоб уникнути занадто багато повторень. Робочий день був довгим 8 годин, тому ми не потрапляли на кожен етап щодня.

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

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

Взагалі кажучи, коли я чую розробника FullStack, я думаю, що більше людей, здатних одночасно кодувати ефективні бек-енди та приємний інтерфейс, протиставляючи Front і Back Dev.