В современном мире программирование связано с высокой стрессовой нагрузкой — намного большей, чем на моей памяти было в 90-х и начале 2000-х, когда я только начинал свой путь в этой сфере. В те времена безумие начиналось в преддверии дедлайнов, но в остальное время всё шло более-менее размеренно. Сегодня же психологическая нагрузка и давление уже являются неотъемлемыми спутниками разработки ПО.
Поэтому, естественно, в целях сохранения здоровья и повышения продуктивности мне хочется с этим давлением как-то разобраться. В итоге я немного поразмышлял, почему в последние пару десятилетий всё стало настолько печально (по крайней мере, для меня).
Не думаю, что дело в тесном соперничестве, перестройке рынков или даже строгих дедлайнах — всё это существовало всегда. Дело в том, что я с подачи руководства оказался вынужден работать спринтами (обычно по 1-2 недели) вместо того, чтобы проводить больше времени за крупными проектами. И эта смена режима привела к ряду неприятных последствий.
Почему работа спринтами является более стрессовой? Разве это не всё те же дедлайны, но только слегка укороченные? Не избавляет ли это вас от необходимости сверхурочного труда в конце проекта? Такой ход мысли кажется логичным, но фактически в нём упускается ряд важных деталей из деятельности современных разработчиков ПО. И дальше я опишу, как, на мой взгляд, спринты нам вредят.
▍ 1. Спринты никогда не кончаются
Одна из проблем спринтов заключается в том, что они никогда не кончаются. Это не просто укороченные дедлайны, которые мы эпизодически встречаем в процессе решения задачи. Они повторяются друг за другом бесконечно. Если брать каскадную модель разработки «Водопад» (Waterfall), то она строится вокруг классических дедлайнов и реальных событий, которые требуют акцентированного внимания. В рамках неё вы какое-то время усердно работаете над реализацией чего-либо, пока этот процесс в итоге не завершается. В таком случае повышенная нагрузка сопровождает более низкую.
Спринты же, напротив, являются фиктивными дедлайнами, созданными ради процесса. И в связи со своей искусственностью они лишены естественных перерывов или промежутков отдыха. При таком режиме просто некогда полноценно передохнуть и навести в голове порядок.
Если составить сравнительный график изменения уровня стресса программиста при работе по традиционной модели «Водопад» и по модели Scrum, то получится что-то типа:
Несмотря на то, что работа по каскадной модели вызывает более высокие скачки стресса, в случае спринтов мы оказываемся под его пусть и более умеренным, но постоянным и длительным давлением. И хотя никакой вид стресса не назовёшь комфортным, наш организм лучше приспособлен переживать его краткосрочное влияние. В действительности кратковременный стресс вполне может оказаться здоровым и даже сделать нас сильнее. Можно сравнить это с тем, как при регулярном посещении тренажёрного зала мы раз за разом нагружаем мышцы, в результате чего они укрепляются — главное давать им достаточный отдых между этими нагрузками. А вот длительный стресс оказывается уже более коварным. Его продолжительное влияние оказывает на наше тело наиболее разрушительное воздействие.
… К положительным аспектам стресса можно отнести его краткосрочность и то, что он помогает преодолеть некие трудности, о которых вы знаете, что они вам по силам.
А вот длительное пребывание в стрессе может реально навредить вашему физическому и психическому здоровью. Проведённое учёными исследование показало корреляцию между стрессом и хроническими проблемами вроде высокого кровяного давления, ожирения, депрессии и прочего.
— What Does Stress Do to the Body? WebMD
▍ 2. Спринты предопределены
Если команда разработки может в ходе коллективного обсуждения решить поставлять код каждые две недели в соответствии с выстроенным ей же процессом — который она сочтёт разумным, и который будет подходить под обстоятельства — то это одно. Но спринты в Scrum работают иначе — каждый их аспект, и даже роли участников, предопределены. Вы можете подумать, что построение собственного процесса не создало бы большой разницы, но исследование говорит другое. Автономия — возможность организовывать собственную работу — существенно влияет на то, как эта работа воспринимается исполнителем.
Рассмотрим, к примеру, исследование, в котором мужских особей мышей разделили на две группы: одних заставляли бежать в течение определённого времени, а другим позволяли преодолевать те же дистанции в своём ритме. И несмотря на то, что обе группы пробежали одинаковые расстояния, мыши, которых бежать принуждали, демонстрировали более выраженные показатели стресса, страха и дискомфорта (бедняги!).
Мы зафиксировали обширную активацию 140 участков у мышей, которые добровольно бежали в колесе и принудительно по бревну. При этом бег в колесе уникально активизирует работу 32 участков, а бег по бревну — 83. В отличие от добровольного бега в колесе, принудительный бег по бревну активизирует участки , связанные со стрессом, страхом и болью.
И это вполне разумно, не так ли? Никто не любит, когда ему говорят, что делать — это портит весь процесс. Это лишает нас внутренней мотивации и, что ещё хуже, вредит способности подстраиваться, экспериментировать и совершенствоваться. Даже самые трудные условия можно преодолеть, когда есть надежда на изменения к лучшему. Принудительное же подчинение лишает вас контроля и той самой надежды. Программистов, работающих по модели Scrum, можно сравнить с теми мышами, которых принудительно заставили бежать по брёвнам амбиций их начальников — круг за кругом.
Если вам интересно подробнее узнать о пользе автономности на рабочем месте, то у Дэниела Х. Пинка на эту тему есть хорошая книга «Drive».
▍ 3. В спринтах упускаются ключевые вспомогательные процессы
Ещё одним стрессовым аспектом спринтов является то, что ты зачастую чувствуешь недостаточную готовность к очередной задаче. Причина в том, что в этой модели не отводится время на должную подготовку. А ведь задача заключается далеко не в одном только печатном наборе решения. Как мудро отметили ДеМарко и Листер:
Если вам поставили задачу, то сколько времени вы выделите конкретно под её выполнение? Определённо не 100%. В решение также необходимо заложить тщательное обдумывание, изучение новых методов, поиск возможности избежать некоторых вторичных задач, чтения, обучения и банального отлынивания.
— Peopleware, Том ДеМарко и Тимоти Листер
Когда начинается спринт, предполагается, что время на подготовку уже прошло, и остаётся только реализация. В Scrum считается, что вы можете просто «выдать готовое решение» вроде сборки какой-нибудь мебели из IKEA — просто достать мануал из бэклога и сделать всё по инструкции. В реальности же получается так, будто вас выбросили в джунглях, без карты и провианта, дав две недели на поиск способа возвращения. Каждый раз вы начинаете с нуля, и часы тикают.
Вы можете рассчитывать на получение каких-то полезных советов по решению поставленной задачи на планёрках или в процессе груминга. Но дело в том, что даже в самой продуманной среде планирования эти совещания редко могут дать больше, чем поверхностное руководство. Реальное предметное понимание приходит, только когда начинается фактическая работа. Подготовку нельзя отделить от реализации — продумывание и выполнение неизбежно переплетаются. Пытаясь их разделить, мы создаём стресс.
▍ Scrumfall: реальная, более печальная картина
Как многие из вас знают, большинство реализаций Scrum представляют смесь моделей «Waterfall» и «Scrum». В результате где-то на фоне всегда маячит масштабный дедлайн в стиле «Waterfall». Бизнес просто не может иначе. (Нам нужно выводить товары на рынок!» «Нам нужно информировать клиентов о будущих продуктах!» «Нам нужно давать обещания на конференциях!» «Такова реальность!»)
И когда этот крупный дедлайн неизбежно наступает, работы, проделанной за предшествующие спринты, редко оказывается достаточно для реализации обещанного. Давление нарастает, процессы Scrum приостанавливаются, и вы остаётесь один на один со своим собственным Agile-маршем смерти, который выглядит, примерно так:
В этом сценарии вы получаете худшее из обоих миров, когда уровни стресса высоки изначально, и приближение старшего релиза их только повышает.
▍ Завершение
Спринты лишены перерывов, сильно ограничивают автономию и не дают достаточно времени на подготовку. Не удивительно, что современные разработчики выглядят более подавленными. Методика Scrum плохо сочетается с самой сутью их работы, и изменить они это не в силах. Единственным решением является восстановление в сфере разработки ПО автономии и профессионализма.
Позвольте разработчикам контролировать как своё мастерство, так и рабочий процесс. Относитесь к ним с уважением как к равным, а не как к заменяемым шестерёнкам в машине. Но достижение таких условий наверняка потребует от инженеров усилий на самом фундаментальном уровне, где им придётся либо создавать более этические организации, либо уходить во фриланс.
Автор: Bright_Translate
