В общем, не знаю, что там Кент Бек, а поинт о том, что каждый специалист должен заниматься максимально продуктивно и мотивированно своим делом , имея рамки специализации - это, имхо, очень сильный принцип.  Умеешь хорошо писать код - занимайся, Линукс тебе другие настроят.  (или сетевую часть :) )  Индустрия просто делает commodity проекты, во многом.  Правильная композиция шаблонов все решает.

Ненавижу этот принцип и специализацию в принципе. Мне больше нравится думать про неё как про неизбежное зло — покуда мы как, гм, человечество, не умеем решать задачу, нам нужны специалисты. Когда научились — специалисты стали бесполезны. Если специалисты очень любят свою специальность и не хотят смотреть по сторонам, им придётся смириться с тем, что однажды их услуги станут неактуальны. Луддиты не дадут соврать!

Специализация хорошо, но на уровне команды.
Есть команда которая пилит "Сайт о булочках", а есть команда которая пилит "докер с кубернетесом". Внутри команды может быть по разному. Но точно не должно быть позиции "я тут программист вообщето и моя хата с краю, сервер не умею не хочу не буду"

Чем более кросфункциональная и мультиинструментальная получается команда тем круче

Конечно в рамках своего контекста, продукта, области знаний и т д

Ну вот, у меня есть убеждение, что не стоит тратить драгоценнейшее время разработчика на определенные вещи. Важен фокус на задаче. Тогда будут outstanding результаты.  Когда кодер лезет в админство он отдаляет себя от этих результатов, хотя и выигрывает время.

Но это я так, с RnD парты кричу :)

В этом мире не все везде и всегда. А кое что иногда и местами.
Конечно если у нас код пишут 5 человек, а надо админить 1000 серверов, то на админство надо 10 чел. А и вот эти 5 не успеют код писать если будут админить сервера. И нужна отдельная команда под админство. А бывает что серверных делов не много, и кто то из команды не обламается и порешает эти вопросы, чтобы не нанимать лишнего админа.

А быват что и команды админов нет, и внутри команды ад и разруха. Всем все пофиг. И все ищут причины как что куда спихнуть. Перепихнуть. И главное не выходить из зоны комфорта. Тут только посочувствовать можно )

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

скрам гайд не говорит, что не должно быть специализаций. Прочитайте первоисточник

и я не говорю )
он говорит о том что команда должна быть кросфункциональна, должна уметь решать все встречающиеся на пути задачи, и внутри не должно быть никаких названий должностей кроме Разработчик, ПО и СМ

другие linux настроят, да. Amazon, например 😉

не-не, я как раз и говорю про ситуацию, когда требуется ПОСТОЯННО решать эти задачи.  Я не возражаю, против того, чтобы 1 раз пропатчить KDE руками DEVа , условно говоря

Да, отличный пример

специалисты — это хорошо. Например, навык создания крутого UI требует массы времени, а сама деятельность занимает много времени. Поэтому экономить эффективнее не людей, а коммуникацию. Отсюда UX/UI, PO+арт.директор, фронтэндер+UI.

Кроссфункциональность в Scrum - это когда " все разрабы разрабят всё", а не когда "все разрабы и тестеры и разрабы и админы"

это никак не отменяет специализации внутри команды, против которой вы евангелируете

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

почему и не «я программист фронтэнда, не хочу разбираться в ваших серверных кишках». Люди дешевле, меньше ругаются на несовершенство мира, их гораздо больше => нанимать гораздо проще и дешевле.