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

12

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

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

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

введите описание изображения здесь

=====

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

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

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

Петр Мурышкин
источник
1
Мастер на все руки - мастер на все руки (ну, может быть, некоторые).
Петах

Ответы:

12

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

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

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

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

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

Иржи Клауда
источник
Особенно учитывая, что существует множество решений и примеров, а также множество инструментов и компонентов - все они бесплатны, но сложны и разнообразны.
Петр
6

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

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

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

птенцы
источник
Ладно; но я не вижу, что бы производитель полных стеков не сделал бы булавки сам?
Петр
1
@PeterMuryshkin: Не сравнивайте разработчика полного стека с производителем пин-кода. Возможно, вы можете сравнить создатель make-файла с производителем булавок. Разработчик полного стека должен сравниваться с шеф-поваром. Кухня может прекрасно работать без шеф-повара, как команда разработчиков может прекрасно работать без разработчика полного стека. Но шеф-повар может лучше улучшить рабочий процесс на кухне, потому что он понимает все, от супа до приготовления и того, как кухня должна содержаться в чистоте. Подобно тому, как разработчик с полным стеком может улучшить рабочий процесс команды разработчиков
slebetman
1
@PeterMuryshkin Теперь о том, почему шеф-повар является боссом кухни, а полный стэк не часто является лидером команды разработчиков, это вопрос для другого дня
slebetman
1
В физическом производстве виджет, который вы создаете за один этап, является практически полным и относительно свободным от метаданных. В разработке программного обеспечения метаданные являются более объемными и жизненно важными.
птенцы
4

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

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

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

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

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

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

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

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

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

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

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

Напротив

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

Выводы

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

Мико
источник
1
Спасибо за внимание, тем не менее, это не точный ответ на мой вопрос, но приветствуется уточнение термина «разработчик fullstack»
Петр
3

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

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

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

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

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

Стюарт Эйнсворт
источник
3

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

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

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

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

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

Tensibai
источник
Ницца! Я никогда не думал об этом, но ты абсолютно прав! разделение труда - это просто разделение труда на дополнительные этапы.
Джереми Дэвис