Никогда не понимал хейт со стороны некоторых разработчиков в сторону Scrum!
Особенно его много здесь, на Habr. Казалось бы, этот фреймворк придуман разработчиками для разработчиков в противовес классическим многовековым иерархичным ступенчатым подходам к организации труда. В основе Scrum лежат самоорганизация, эмпиризм, бережливое производство. Взрослый подход для взрослых людей. Что здесь может не нравится?
И опирается это всё на Agile манифест, который тоже был создан разработчиками для разработчиков: Роберт Мартин, Кент Бек, Роберт Фаулер и т.д. Знакомые фамилии?
Можно конечно сказать, что тут есть определенное ограничение: Agilе говорит нам, что «над продуктам должны работать мотивированные профессионалы». Так значит всю волну хейта поднимают только зелёные джуны, которых лишили няньки и заставили разделать командную ответственность?
Так вроде нет. Я видел массу случаев, когда молодые ребята активно участвуют во всех процессах, пытаясь понять итоговую ценность разрабатываемого функционала, пытаются найти решения исходя из ценности для пользователя.
Так что позиция «я хочу кодить, а не невотэтовотвсё» совершенно не зависит от опыта. А тогда от чего?
Давайте разбираться.
Довольно часто мне приходится наблюдать две крайние позиции:
Одни на встречах откровенно скучают, всегда без камер, не слушают коллег и говорят только если их о чём-то спрашивают. Им не нравится Scrum, всё происходящее в нём они считают каким-то цирком, не слишком вникая в суть. Для них главное — чёткие требования и успешное завершение только их части работ.
Вторые же активно вовлекаются в любое обсуждение по продукту, на каждом дейлике нагружают РО вопросами, активно участвуют во всех встречах и стремятся постоянно улучшать все процессы. Для них важна коммуникация с коллегами, совместный поиск решений, стремление к завершённости общих командных задач, а не только в сугубо рамках их компетенции.
Если вы думаете, что дело здесь в интровертах и т.д., прекращайте. У меня в командах были люди интровентивней не бывает. Но они могли, заикаясь, доказывать, что дизайн — гуано, а если продолжить делать проект по предлагаемой архитектуре, гуаном будет и всё остальное. Им было не всё равно, какой продукт получится в итоге. Так что причина здесь также явно не в этом.
Актуальная врезка о производителе керамики из XVIII-го века
Больше конкретики в различиях я увидел после прочтения одной интересной статьи о знаменитом английском мастере, которого звали Джозайя Уэджвуд. Он прошёл путь от обычного гончара до официального поставщика королевы Великобритании. Считается, что именно он возвёл производство керамики в ранг искусства.
Но нам важна не его биография, а то, что в статье красной нитью выделялось различие между отношением к своему делу обычных ремесленников и настоящих мастеров, которым и был Джозайя. Ремесленники XVIII века занимались изготовлением керамических изделий, следуя традиционным методам и техникам, которые передавались из поколения в поколение.
Их волновало выполнение конкретных задач, таких как формовка глины, обжиг и глазурование.
Их работа была высококачественной, но не выходила за рамки установленных стандартов.
Они чётко следовали традициям.
Использовали проверенные методы и рецепты, редко экспериментируя с новыми материалами или техниками.
Ограничивались только своими задачами, выполняли только ту часть работы, которая была поручена, не задумываясь о конечном результате.
Фокусировались только на своих непосредственных обязанностях, не стремясь особо понять потребности рынка или пользователей.
Позже нам понадобится этот список.
На этом фоне Джозайя Уэджвуд представлял собой настоящего Мастера, который владел не только ремеслом, но и стремился понять и улучшить каждый аспект своей работы. Он активно внедрял инновации, улучшал технологии и расширял свои знания, что позволило ему достичь выдающихся результатов.
Но с чего я вообще пишу про какого-то гончара из 18 века? Каким боком он относится к разработке в 21 веке?
Прямым.
Дело в том, что профессия разработчика — это тоже ремесло. И в этом ремесле бывают как ремесленники (при этом они профессионалы), так и те, кто стремится выйти за рамки — стать Мастером.
Еще раз подчеркну, что дело не в профессиональных компетенциях. Любой опытный ремесленник — профессионал своего дела. Я говорю о желании выйти за пределы этих компетенций, которое и создаёт Мастеров с большой буквы.
Давайте ещё раз посмотрим на особенности подхода к работе между ремесленником и мастером и сравним их качества
Пройдёмся по списку снова.
№1. Фокус на выполнении конкретных задач (формовка глины, обжиг, глазурование), без учета предыдущих и последующих шагов.
Ремесленники видели свою работу как ряд отдельных процессов. Каждый этап работы был важен, но рассматривался отдельно от остальных. Например, ремесленник, ответственный за формовку, редко думал о процессе обжига или глазурования. Его цель состояла в том, чтобы сосредоточиться исключительно на своей части работы.
Мастера видели процесс создания изделия в целостности. Джозайя Уэджвуд, например, учитывал каждый этап — от формовки до обжига — как часть единого процесса, который влиял на качество и уникальность конечного продукта. Он внедрял стандарты и инновации, улучшая каждый аспект производства.
№2. Работа высококачественная, но не выходящая за рамки установленных стандартов
Ремесленники обычно следовали установленным нормам качества, которые были определены традициями и опытом предыдущих поколений. Их задача заключалась в том, чтобы создавать продукцию, которая соответствовала этим стандартам, но не стремиться превзойти их.
Мастера, напротив, стремились не просто соответствовать, но и задавать новые стандарты. Уэджвуд, например, изобрел новые типы керамики, такие как знаменитый «кремовый фаянс» и «ясписовая керамика», которые отличались высоким качеством и уникальными свойствами. Он постоянно искал способы улучшить материалы и методы производства, устанавливая новые уровни качества.
№3. Чёткое следование традициям
Традиции были основой ремесленников. Считалось, что проверенные методы, которые использовались веками, не требуют изменения. Они не рассматривали возможность отступления от привычных схем и не были заинтересованы в создании чего-то радикально нового.
Мастера проявляли уважение к традициям, но не боялись их переосмысливать и развивать. Уэджвуд, например, активно внедрял научные исследования в производство, что позволяло ему улучшать технологии, сохраняя традиции, но придавая им новые смыслы. А внедрение системы массового производства или стандартов качества на своих фабриках? Это же поступок, который идёт перпендикулярно традициям.
№4. Использование проверенных методов и рецептов, редкие эксперименты с новыми материалами или техниками
Подход ремесленников был основан на накопленном опыте и рутинных практиках. Эксперименты считались рискованными и могли привести к потере ресурсов. Ремесленники редко пробовали что-то новое, опасаясь возможных неудач.
Все мастера же были новаторами. Джозайя Уэджвуд активно экспериментировал с химическими составами глин и глазурей, что позволило ему создавать изделия, которые превосходили по качеству и долговечности существующие аналоги. Сотрудничал с художниками, учеными и инженерами, что позволяло ему постоянно улучшать свои изделия и производственные процессы.
№5. Выполнение только той части работы, которая ему поручена, без мысли о конечном результате
Ремесленники часто видели свою работу как отдельный элемент большого процесса, не задумываясь о том, как их вклад повлияет на конечный продукт. Их цель заключалась в качественном выполнении порученной задачи, а не в достижении общего успеха.
Мастера же всегда имели в виду конечную цель — создать выдающийся продукт, который будет не только функциональным, но и эстетически превосходным. Уэджвуд, например, думал о каждом изделии как о части бренда, репутации и маркетинговой стратегии. Он рассматривал каждый этап как важный для достижения идеального результата.
№6. Фокус на непосредственных обязанностях без стремления понять потребности рынка или пользователей
Ремесленники редко интересовались тем, кто и как будет использовать их продукцию. Основной фокус был на выполнении производственного задания, а не на анализе потребностей покупателей.
Мастера, вроде Уэджвуда, были первыми, кто интегрировал маркетинговый подход в ремесленное дело. Он изучал рынок, потребности своих клиентов и стремился удовлетворить их запросы, работая над созданием модных и востребованных изделий. Он внедрил идею позиционирования и продвижения своих изделий среди аристократии, что повысило спрос и позволило ему не только следовать рынку, но и формировать его.
А теперь давайте проведём небольшие параллели и поищем отличия между двумя типами разработчиков.
Первые работают по чётко определенному сценарию, выполняя конкретные задачи без глубокого понимания или интереса к конечному продукту. Их главная цель – выполнить свою часть работы, не углубляясь в детали. | Вторые стремятся понять весь процесс разработки и конечную цель продукта. Они активно участвуют в планировании и обсуждениях, предлагают улучшения, исходя из понимания потребностей пользователей. |
Первые в основном фокусируются на выполнении задач, не думая о том, как их работа повлияет на пользователя. Их интерес ограничивается выполнением задания и получением обратной связи о качестве кода. | Для вторых важно понять, как их продукт изменит жизнь пользователя, и как их решения могут улучшить пользовательский опыт. Они думают о конечной цели и стараются предвидеть проблемы и возможности, которые могут возникнуть. |
Первые предпочитают минимальные взаимодействия с командой. Они могут избегать общения, если оно не связано напрямую с их задачами. Их коммуникация ограничена техническими вопросами и отчетностью. | Вторые же активно участвуют в командных обсуждениях, открыто делятся идеями и проблемами. Они понимают важность обмена знаниями и считают, что сотрудничество ведет к лучшим решениям. |
Первые обучаются только необходимым для выполнения текущих задач навыкам и технологиям. Они редко выходят за рамки своей узкого специализации. | Вторые стремятся к постоянному саморазвитию, изучают новые технологии и методологии. Они понимают, что развитие навыков и знаний повышает их ценность для команды и проекта. |
Первые часто сопротивляются изменениям и предпочитают работать в стабильной, предсказуемой среде. | Вторые готовы адаптироваться к изменениям и новым вызовам. Они видят изменения как возможность для роста и улучшения продукта. |
Первые решают проблемы, строго следуя инструкциям и алгоритмам, которые уже существуют, и любят не искать новых способов решения. | Вторые стремятся найти наилучшие решения, анализируя ситуацию с различных углов. Часто предлагают инновационные подходы и не боятся экспериментировать. |
Кто по вашему мнению первые? А кто вторые?
Мне кажется, что вторые — Мастера. Соответственно, первые… Впрочем, вы и сами знаете.
Как вы думаете, за кем будущее в разработке? Учитывая, что у нас сейчас массовые увольнения в заграничном IT, «страшное» наступление роботов в виде ИИ и огромный поток джунов в нашем родном айти. В ближайшее время придётся (возможно) конкурировать за работу с кучей народу и такой же кучей нейросеток. А нейросеть уже может выполнять не всю, но часть работы ремесленника: и сценарии, и задачи, и минимальное взаимодействие с командой.
На мой взгляд, главное отличие первых и вторых заключается в вовлечённости. Это и есть ключ к мастерству в любом деле.
В разработке, где каждая строчка кода может повлиять на будущее продукта, вовлечённость становится не просто важной, а определяющей для достижения выдающихся результатов. Для настоящих мастеров, стремящихся к самовыражению через результаты своей деятельности и глубокому пониманию своей работы, вовлечённость в процесс — не просто желание, а необходимое условие для творческого труда. Или кто-то ещё не считает процесс разработки творчеством?
Призываю авторитетов для развеивания сомнений:
Роберт Мартин («Дядя Боб», автор книги «Чистый код»): «Профессионалы программисты думают о пользователе, а не о себе. Они пишут код так, чтобы им могли пользоваться другие люди»
Ричард Столлман (основатель движения за свободное ПО): «Программирование — это не просто выполнение задач. Это процесс решения проблем и воплощения идей»
Мартин Фаулер ( автор книги «Рефакторинг. Улучшение проекта существующего кода»): «Цель разработки — создание системы, которая удовлетворяет потребности пользователей, а не написание кода ради самого кода»
Дональд Кнут (ученый-исследователь в области информатики и программирования, автор «Искусство программирования»): «Программирование — это не просто написание кода. Это искусство создавать полезные и красивые решения для реальных проблем»
Брайан Керниган (соавтор языка программирования C): «Первая цель любого проекта — чтобы он был полезен, вторая — чтобы он работал корректно, третья — чтобы он был элегантен»
Стив Джобс (сооснователь Apple): «Вы должны начать с клиента и работать назад к технологии. Не стоит начинать с технологии и пытаться выяснить, где она может вписаться»
Когда разработчик полностью погружается в проект, он не просто выполняет задания, а становится соавтором идеи. Вовлечённость позволяет ему увидеть не только код, но и то, как его работа вписывается в общую картину. Это глубокое понимание цели проекта и его значения для конечного пользователя придаёт каждому действию дополнительный смысл. Такие разработчики понимают, что их труд — это не просто механическая работа, а часть большого творческого процесса, который может изменить жизнь пользователей.
Вовлечённость не только усиливает качество работы, но и делает сам процесс разработки более увлекательным. Когда разработчик чувствует свою причастность к проекту, он начинает видеть результаты своей работы не как набор законченных задач, а как живой, развивающийся продукт. Это чувство связи с созданием порождает стремление к совершенству и желание сделать продукт лучше, чем он есть. Таким образом, вовлечённость становится источником вдохновения и мотивации, который питает творческую энергию и приводит к созданию действительно выдающихся решений.
Без вовлечённости разработчик может легко стать просто исполнителем (считай кодером), который выполняет указания, не задумываясь о конечной цели. Такой подход превращает работу в рутину, где каждое действие лишено личного смысла. В этом случае труд становится механическим процессом, который может быть автоматизирован или заменен искусственным интеллектом. Вовлечённость, наоборот, позволяет найти смысл и ценность в каждом аспекте своей работы, превращая её в процесс, полный личного удовлетворения и творчества.
Сравните это с художником, который рисует картину. Если он просто следует за шаблоном, его работа может остаться на уровне техники. Но когда он вкладывает свою душу и эмоции в каждую деталь, картина приобретает жизнь и выражает что-то уникальное. В разработке ПО вовлечённость играет ту же роль: она позволяет разработчику создавать не просто функциональные решения, а инновационные продукты, которые действительно меняют этот мир.
Да, возможно, звучит немного приторно, но это моё мнение. И если вы сейчас ощутили прилив вдохновения, то эти слова точно не были написаны здесь зря.
Когда я читал книгу «Поток» (автор: Михай Чиксентмихайи), то не раз вспоминал состояние энтузиазма и поглощённости процессом, которое я наблюдаю в командах с хорошо отлаженными процессами. Да, бывают провалы, бывает подгорание, но когда есть вовлечённость, интерес к деятельности, то все вопросы решаются легко и быстро, как раскладка пазла.
Таким образом, вовлечённость становится ключом к мастерству в разработке. Опять же, это моё мнение, и оно вполне может отличаться от вашего. Возможно, кто-то видит в командной деятельности аналог Макдональдса, где все — всего лишь легко заменяемые винтики в общем механизме. Но для меня это определённый вид искусства, где каждый элемент имеет значение, а каждое действие обосновано глубинным пониманием цели.
Вовлечённость — это не выбор, а необходимость, которая делает труд значимым и вдохновляющим. Где каждый становится создателем, который не только реализует идеи, но и вносит свой личный вклад в их развитие, создавая продукты, которые способны если не менять мир, то по крайней мере делать его лучше)
А где здесь Scrum?
Теперь, наверно, у вас возник вопрос: «Окей, всё это конечно здорово, но с какого боку здесь Scrum?»
Давайте разберёмся в сути данного фреймворка. По сути, Scrum — это коммуникационный каркас, который представляет собой идеальную среду для мастеров ("мотивированных профессионалов", как написано в Agile манифесте), которые действительно погружены в процесс создания ценности и относятся к нему как к искусству.
К искусству, в котором они могут реализовать свои амбиции, и непрерывно улучшать свои профессиональные навыки в широком спектре деятельности.
Что Scrum даёт Мастерам?
№1. Влияние на процесс и продукт
Мастера не просто хотят выполнять задачи — они стремятся влиять на процесс и результаты (помните пункт 3 выше?). И Scrum предоставляет им такую возможность.
Они могут не только реализовывать текущие требования, но и предлагать улучшения, видя, как их идеи становятся частью продукта. Когда я работаю с командами, то наблюдаю, как сами разработчики совместно решают, как им делать свою работу: спорят, обсуждают, приходят к консенсусу. Команда сама определяет объём задач, взятых в спринт и критерии приемки. Это ощущение контроля и возможности вносить свой вклад в направление развитие продукта является для Мастеров важным элементом их профессиональной мотивации.
№2. Коллективная ответственность
За всё, что делает команда, отвечает только вся команда целиком. И каждый в ответе друг перед другом. А это означает, что успехи и неудачи в решении любой задачи воспринимаются как общие достижения или провал.
Такой подход создает сильное чувство единства и взаимной поддержки внутри команды. Команда становится более сплочённой, никто не остается наедине со «своими проблемами». И каждый начинает активно вносить свой вклад в общий успех, понимая, что его работа влияет на всех.
№3. Постоянное совершенствование и рост
Работа по Scrum объединяет команду, создавая среду для активного сотрудничества и шаринга знаний. Для Мастеров это возможность не просто работать в команде, а шанс учиться у коллег и делиться своими знаниями. Присутствуя, как scrum-мастер на общих командных обсуждениях проблемных вопросов или новых идей, или совместных ретроспектив, я вижу, как разработчики вовлекаются: обсуждают, спорят, но никто не остаётся в стороне. Это то самое «пространство для развития успешных практик» о котором пишут в стандартных (скучных) статьях про Scrum.
№4. Вдохновение от обратной связи
Для профессионалов, которые ценят постоянное совершенствование и стремятся понять, как их работа влияет на конечный результат, регулярная обратная связь является важнейшим источником вдохновения.
Scrum позволяет получать регулярную качественную обратную связь непосредственно от пользователей продукта, благодаря чему можно своевременно вносить изменения, непрерывно улучшая.
Это не просто возможность корректировать ошибки, но и шанс видеть, как идеи и усилия воплощаются в жизнь и как они воспринимаются реальными пользователями. Такой обмен мнениями позволяет мастерам продолжать развиваться и адаптироваться, создавая решения, которые действительно решают проблемы и улучшают пользовательский опыт.
Когда человек стремится стать Мастером в своем деле, он ищет возможности для глубокого погружения и самовыражения. Работа по Scrum даёт возможность раскрыть весь потенциал, влиять на процесс, развиваться и получать регулярную обратную связь.
А если у вас иначе, то может просто перестанете называть «это» Scrum?
Вывод
Не все разработчики готовы принять этот вызов и выйти за рамки простого исполнителя. Те, кто не стремится к самосовершенствованию и не видит ценности в такой рабочей среде, рискуют оказаться в тени технологического прогресса.
Разработчики, которые удовлетворяются выполнением задач по чётким инструкциям, могут скоро оказаться на обочине инноваций. Эти ремесленники, не стремящиеся к глубинному пониманию и улучшению продукта, рискуют стать ненужными в условиях растущей автоматизации. ИИ, развиваясь с каждым годом, всё больше берёт на себя рутинные и стандартизированные задачи, которые раньше выполнялись людьми.
Вот я нашел статью на habr, где собраны мнения по данной теме от компетентных специалистов:
Если не хотите тратить время на чтение и просмотр вложенных видео, то вот вам краткое итоговое резюме: нейронки уже готовы заменить разработчиков (не только джунов, но и мидлов)! Дайте ему сценарий и он состряпает вам код. Главное, чтобы всё было заранее разложено по полочкам, ведь ИИ умеет только кодить, а не вотэтовотвсё — выполнять поставленные конкретные задачи без глубокого понимания или интереса к конечному продукту.
И чем это отличается от работы «кодера»? Да ничем. Если взять первый пункт «выполняют конкретные задачи», то ИИ задают промпт и он идёт «по чётко определенному сценарию». Верно? Верно. ИИ не спорит, не даёт обратную, не предлагаёт новых идей (пока не спросят). Просто решает поставленную задачу в рамках заданных условий. И не сильно беспокоится за итоговый результат. Верно? Верно.
Так что единственное, что пока остается на стороне «кожаных мешков» — это умение коммуницировать друг с другом, подходить к вопросу творчески и совместно искать оптимальные пути решения задач и развития программных продуктов.
