Адам Смит против разработчиков полного стека - и производительность в DevOps?

По Адаму Смиту, разделение труда может сделать вас в 240 раз эффективнее (на примере завода по производству булавок, производящего штифты за 18 шагов).

Почему же так востребованы мульти-квалифицированные роли, если это действительно снижает производительность - или Смит был просто неправ, почему тогда?

Поиски «разработчика полного пакета» все еще сохраняются в Google, однако, по-видимому, медленнее, чем два года назад:

=====

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

• Обсудить с клиентами и уточнить гибкие требования для его части работы
• Решите, какую архитектуру, инструменты и компоненты подберите - просто дайте ему ноутбук
• Напишите код для внешнего интерфейса, внутреннего интерфейса, загрузки, который совместим между устройствами и не требует большого тестирования или включает его
• Данные профиля и scape, используйте API Cloud AI / ML для расширенных функций
• Запишите необходимый код IaC и разверните
• Быть на связи в случае ошибки или процессов продаж
• Помните о безопасности дизайна, общего исправления, миграции и модернизации
• График учета счетов в строгом порядке, чтобы облегчить выставление счетов работодателю
• ... я что-то забыл?

UPD - « нам нужна продуктивность специализации, но мы не хотим изолированного мировоззрения« крайнее разделение труда ». (DevOps Guys, « DevOps, Адам Смит и легенда универсалиста » , 2013-2016)

Есть два вида работ:

1. Эксплуатация - четко определенная работа, которая может быть легко разделена на четко определенные этапы, где каждый этап может быть изучен и освоен самостоятельно, и передача между этапами не требует связи.

2. Разведка - Неопределенная работа, которая требует обучения и экспериментов для выполнения каждого этапа, а передача между этапами требует огромного количества информации обо всем изучении и статусе проекта.

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

Но мы видели, что на более поздних этапах непрерывного совершенствования, которые являются частично эксплуататорской работой, применение CI / CD может принести аналогичный прирост производительности, который может быть каким-то образом прослежен до Адама Смита кем-то очень творческим.

Адаму Смиту не нужно было думать о передаче информации с одного этапа на другой. Это важная часть любого значимого ИТ-проекта. Таким образом, разработчик полного стека имеет значительные преимущества, которые:

• им не нужно ни с кем разговаривать в другом отделе, чтобы добиться цели
• им не нужно ждать, пока эти люди обойдут это
• гораздо меньше шансов, что что-то будет потеряно при переводе между одним слоем и другим

Для получения дополнительной информации о важности передачи информации в ИТ-проектах см. Мифический человеко-месяц Фреда Брука .

ИМХО, ответ во многом связан с масштабом и доступностью ресурсов.

Я полагаю, что теория Адама Смита может быть применена только в больших масштабах - целые страны / экономики в первоначальном контексте или, в контексте разработки ЕО, - большими группами разработчиков.

В большой команде, действительно, более эффективно нанимать более специализированные человеческие ресурсы:

• они не рок-звезды - часто считаются признаком опасности в таких крупных организациях
• их обычно легче найти, дешевле, чем у тех, у кого более широкий спектр знаний
• они, как правило, не повышают риски истощения - например, они не будут несчастны, потому что они используют только часть своих навыков.
• В (возможно, странном) сравнении с девопсией принцип «крупный рогатый скот против домашних животных» может быть применен в таких крупных организациях и по совершенно схожим причинам. Эти специализированные ресурсы, с точки зрения бизнеса, буквально просто на душу населения в пулах человеческих ресурсов, размеры которых могут быть быстро скорректированы по мере необходимости, как правило, путем найма / увольнения.

Да, и такие группы могут быть функциональными, только если они дополняются высококачественными ресурсами архитектора, которые были бы необходимы для разделения продукта на более мелкие специализированные задачи, которые могут быть решены с помощью специализированных ресурсов.

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

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

Я считаю себя разработчиком полного стека на основе следующего сочетания обязанностей:

Программирование переднего и заднего конца

Я могу вносить изменения в пользовательский интерфейс до некоторой степени: писать html, css (как веб-разработчик) и, с другой стороны, в некоторой степени предоставлять данные для пользовательского интерфейса из базы данных, предоставлять их в службе и т. Д.

Я оставляю тестирование, архитектуру и прочее в стороне, к рабочему описанию могут быть добавлены встречи с клиентами.

Напротив

На мой взгляд, противоположностью были бы строгие роли ребят из UI и бэк-энда.

Выводы

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

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

Во-первых, пример с заводской булавкой (насколько я знаю) был просто гипотетическим; хотя большинство современных производственных предприятий могут проследить свои корни в этом разделении труда, мне неизвестны какие-либо исследования, которые действительно проверили эту гипотезу с научной точки зрения.

Во-вторых, Смит в основном занимался производством материальных благ; Есть определенные ощутимые результаты, связанные с производством материалов, которые не имеют аналогичных аналогов при разработке программного обеспечения. Например, при изготовлении булавок физические размеры важны как функциональное требование; нет очевидного сравнения с этим в программном обеспечении. Это важно, потому что материальные объекты могут быть воспроизведены путем точного повторения; разработка программного обеспечения никогда не бывает одной и той же проблемой дважды. Разработчики разрабатывают общие методы для получения предсказуемых результатов, но вы никогда не пишете одну и ту же проблему дважды. Любой компонент, разработанный в стеке, имеет сложности в отличие от физических компонентов, и эти сложности имеют взаимодействия, выходящие за пределы ощутимых измерений (рост, вес, длина и т. Д.). Указатель булавки не заботится о том, как работает кусачка, пока проволока обрезается в соответствии со спецификацией. В разработке программного обеспечения,границы никогда не бывают такими ясными .

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

Я думаю, что работа Смита в области разработки программного обеспечения относится к области переключения контекста (или многозадачности ); если один разработчик отвечает за все области разработки, требуется время, чтобы перейти от ответственности к ответственности. В масштабе, сотрудничество между членами команды с различным опытом в одной и той же команде продукта может сбалансировать переключение контекста и сложные взаимодействия.

Важно понимать, что разделение труда не всегда означает другого человека на шаг.

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

Это именно разделение труда, когда вы выполняете только один шаг сборки в определенный момент времени, что не мешает вам выполнить полную сборку.

Как уже говорилось в других ответах, это немного отличается от разработки программного обеспечения, но я думаю, что это проливает свет на то, почему разработчик Full Stack не является взаимоисключающим с разделением труда, а кто-то, способный обрабатывать весь жизненный цикл приложения, не Требуется делать это все время.

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