В современном мире программирование связано с высокой стрессовой нагрузкой — намного большей, чем на моей памяти было в 90-х и начале 2000-х, когда я только начинал свой путь в этой сфере. В те времена безумие начиналось в преддверии дедлайнов, но в остальное время всё шло более-менее размеренно. Сегодня же психологическая нагрузка и давление уже являются неотъемлемыми спутниками разработки ПО.
Поэтому, естественно, в целях сохранения здоровья и повышения продуктивности мне хочется с этим давлением как-то разобраться. В итоге я немного поразмышлял, почему в последние пару десятилетий всё стало настолько печально (по крайней мере, для меня).
Не думаю, что дело в тесном соперничестве, перестройке рынков или даже строгих дедлайнах — всё это существовало всегда. Дело в том, что я с подачи руководства оказался вынужден работать спринтами (обычно по 1-2 недели) вместо того, чтобы проводить больше времени за крупными проектами. И эта смена режима привела к ряду неприятных последствий.
Почему работа спринтами является более стрессовой? Разве это не всё те же дедлайны, но только слегка укороченные? Не избавляет ли это вас от необходимости сверхурочного труда в конце проекта? Такой ход мысли кажется логичным, но фактически в нём упускается ряд важных деталей из деятельности современных разработчиков ПО. И дальше я опишу, как, на мой взгляд, спринты нам вредят.
▍ 1. Спринты никогда не кончаются
Одна из проблем спринтов заключается в том, что они никогда не кончаются. Это не просто укороченные дедлайны, которые мы эпизодически встречаем в процессе решения задачи. Они повторяются друг за другом бесконечно. Если брать каскадную модель разработки «Водопад» (Waterfall), то она строится вокруг классических дедлайнов и реальных событий, которые требуют акцентированного внимания. В рамках неё вы какое-то время усердно работаете над реализацией чего-либо, пока этот процесс в итоге не завершается. В таком случае повышенная нагрузка сопровождает более низкую.
Спринты же, напротив, являются фиктивными дедлайнами, созданными ради процесса. И в связи со своей искусственностью они лишены естественных перерывов или промежутков отдыха. При таком режиме просто некогда полноценно передохнуть и навести в голове порядок.
Если составить сравнительный график изменения уровня стресса программиста при работе по традиционной модели «Водопад» и по модели Scrum, то получится что-то типа:
Несмотря на то, что работа по каскадной модели вызывает более высокие скачки стресса, в случае спринтов мы оказываемся под его пусть и более умеренным, но постоянным и длительным давлением. И хотя никакой вид стресса не назовёшь комфортным, наш организм лучше приспособлен переживать его краткосрочное влияние. В действительности кратковременный стресс вполне может оказаться здоровым и даже сделать нас сильнее. Можно сравнить это с тем, как при регулярном посещении тренажёрного зала мы раз за разом нагружаем мышцы, в результате чего они укрепляются — главное давать им достаточный отдых между этими нагрузками. А вот длительный стресс оказывается уже более коварным. Его продолжительное влияние оказывает на наше тело наиболее разрушительное воздействие.
… К положительным аспектам стресса можно отнести его краткосрочность и то, что он помогает преодолеть некие трудности, о которых вы знаете, что они вам по силам.
А вот длительное пребывание в стрессе может реально навредить вашему физическому и психическому здоровью. Проведённое учёными исследование показало корреляцию между стрессом и хроническими проблемами вроде высокого кровяного давления, ожирения, депрессии и прочего.
— What Does Stress Do to the Body? WebMD
▍ 2. Спринты предопределены
Если команда разработки может в ходе коллективного обсуждения решить поставлять код каждые две недели в соответствии с выстроенным ей же процессом — который она сочтёт разумным, и который будет подходить под обстоятельства — то это одно. Но спринты в Scrum работают иначе — каждый их аспект, и даже роли участников, предопределены. Вы можете подумать, что построение собственного процесса не создало бы большой разницы, но исследование говорит другое. Автономия — возможность организовывать собственную работу — существенно влияет на то, как эта работа воспринимается исполнителем.
Рассмотрим, к примеру, исследование, в котором мужских особей мышей разделили на две группы: одних заставляли бежать в течение определённого времени, а другим позволяли преодолевать те же дистанции в своём ритме. И несмотря на то, что обе группы пробежали одинаковые расстояния, мыши, которых бежать принуждали, демонстрировали более выраженные показатели стресса, страха и дискомфорта (бедняги!).
Мы зафиксировали обширную активацию 140 участков мозга у мышей, которые добровольно бежали в колесе и принудительно по бревну. При этом бег в колесе уникально активизирует работу 32 участков, а бег по бревну — 83. В отличие от добровольного бега в колесе, принудительный бег по бревну активизирует участки мозга, связанные со стрессом, страхом и болью.
www.ncbi.nlm.nih.gov/pmc/articles/PMC10943479
И это вполне разумно, не так ли? Никто не любит, когда ему говорят, что делать — это портит весь процесс. Это лишает нас внутренней мотивации и, что ещё хуже, вредит способности подстраиваться, экспериментировать и совершенствоваться. Даже самые трудные условия можно преодолеть, когда есть надежда на изменения к лучшему. Принудительное же подчинение лишает вас контроля и той самой надежды. Программистов, работающих по модели Scrum, можно сравнить с теми мышами, которых принудительно заставили бежать по брёвнам амбиций их начальников — круг за кругом.
Если вам интересно подробнее узнать о пользе автономности на рабочем месте, то у Дэниела Х. Пинка на эту тему есть хорошая книга «Drive».
▍ 3. В спринтах упускаются ключевые вспомогательные процессы
Ещё одним стрессовым аспектом спринтов является то, что ты зачастую чувствуешь недостаточную готовность к очередной задаче. Причина в том, что в этой модели не отводится время на должную подготовку. А ведь задача заключается далеко не в одном только печатном наборе решения. Как мудро отметили ДеМарко и Листер:
Если вам поставили задачу, то сколько времени вы выделите конкретно под её выполнение? Определённо не 100%. В решение также необходимо заложить тщательное обдумывание, изучение новых методов, поиск возможности избежать некоторых вторичных задач, чтения, обучения и банального отлынивания.
— Peopleware, Том ДеМарко и Тимоти Листер
Когда начинается спринт, предполагается, что время на подготовку уже прошло, и остаётся только реализация. В Scrum считается, что вы можете просто «выдать готовое решение» вроде сборки какой-нибудь мебели из IKEA — просто достать мануал из бэклога и сделать всё по инструкции. В реальности же получается так, будто вас выбросили в джунглях, без карты и провианта, дав две недели на поиск способа возвращения. Каждый раз вы начинаете с нуля, и часы тикают.
Вы можете рассчитывать на получение каких-то полезных советов по решению поставленной задачи на планёрках или в процессе груминга. Но дело в том, что даже в самой продуманной среде планирования эти совещания редко могут дать больше, чем поверхностное руководство. Реальное предметное понимание приходит, только когда начинается фактическая работа. Подготовку нельзя отделить от реализации — продумывание и выполнение неизбежно переплетаются. Пытаясь их разделить, мы создаём стресс.
▍ Scrumfall: реальная, более печальная картина
Как многие из вас знают, большинство реализаций Scrum представляют смесь моделей «Waterfall» и «Scrum». В результате где-то на фоне всегда маячит масштабный дедлайн в стиле «Waterfall». Бизнес просто не может иначе. (Нам нужно выводить товары на рынок!» «Нам нужно информировать клиентов о будущих продуктах!» «Нам нужно давать обещания на конференциях!» «Такова реальность!»)
И когда этот крупный дедлайн неизбежно наступает, работы, проделанной за предшествующие спринты, редко оказывается достаточно для реализации обещанного. Давление нарастает, процессы Scrum приостанавливаются, и вы остаётесь один на один со своим собственным Agile-маршем смерти, который выглядит, примерно так:
В этом сценарии вы получаете худшее из обоих миров, когда уровни стресса высоки изначально, и приближение старшего релиза их только повышает.
▍ Завершение
Спринты лишены перерывов, сильно ограничивают автономию и не дают достаточно времени на подготовку. Не удивительно, что современные разработчики выглядят более подавленными. Методика Scrum плохо сочетается с самой сутью их работы, и изменить они это не в силах. Единственным решением является восстановление в сфере разработки ПО автономии и профессионализма.
Позвольте разработчикам контролировать как своё мастерство, так и рабочий процесс. Относитесь к ним с уважением как к равным, а не как к заменяемым шестерёнкам в машине. Но достижение таких условий наверняка потребует от инженеров усилий на самом фундаментальном уровне, где им придётся либо создавать более этические организации, либо уходить во фриланс.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (54)
Zempik
20.09.2024 13:13Продолжительность спринтов команда определяет самостоятельно, исходя из своего стиля работы и удобства. При этом важно соблюсти баланс: за слишком короткий спринт команда не успеет создать значимую часть продукта, а за слишком долгий — команда потеряет концентрацию на целях.
Сейчас у меня в компании спринт длится 2 недели, а каждый пятый спринт - нерабочий, когда можно или доделать какую-то работу, или спланировать следующий инкремент.
Есть конечно свои недочёты в scrum, но почему-то в последнее время частенько стали появляться критикующие статьи, как-будто мой коллега пишет :)
FireFly111
20.09.2024 13:13+11Скрам имеет одну неразрешимую проблему: итеративность искуственна. Тоесть она не привязана к реальности проекта или продукта.
Все реализации скрама так или иначе пытаются сгладить эту проблему, но не избавиться от неё.
Zempik
20.09.2024 13:13+2Возможно это не проблема, а особенность. Со временем приучиваешься декомпозировать задачи на спринты. И в некоторых проектах это даже полезно. Мы с вами в разных проектах работаем, поэтому имеем различное мнение. Сколько слышал споров в команде по скрам методикам, а в итоге как работали, так и работаем.
Apoheliy
20.09.2024 13:13+6Рассказывали, что в армии взвод солдат на пробежке должен был до собственно команды "бегом" делать "бег на месте" - вот чтобы показать свою готовность. И это жутко выбешивало людей. Но в армии это делалось для улучшения дисциплины и следование принципу: не надо думать, делай что говорят.
В ИТ конторах ситуация несколько другая. Поэтому, подозреваю, и "принудительный бег" по бревну для мышек и, собственно, "принудительный бег" по спринту для разработчиков - всё будет выводить людей из себя. И чем более интеллектуальная основная работа, тем больше будет стресса от таких "активностей".
Причём (проведём аналогии с "бегом на месте") если пытаться делать такие "предложения":
давайте при беге на месте меньше поднимать ноги - будет легче, меньше устанете;
давайте при беге на месте немного вращаться вокруг оси - какое-то разнообразие;
Оно всё ситуацию не облегчает. Всё равно "активность" вызывает стресс.
Как можно уменьшить стресс? Убрать "бег на месте".
Так что со статьёй согласен - разработчики должны контролировать свой рабочий процесс и отличаться от мышек, принудительно бегающих по бревну.
Можно ли это сделать в рамках скрама? Сомнительно, там спринты и ритуалы.
gun_dose
20.09.2024 13:13+1Так много написано про стресс. А в чём проблема поставить такие сроки, чтобы работать в комфортном темпе без стресса?
metalidea
20.09.2024 13:13+3Проблема в том, что 80% усилий дают 20% результата, иногда при планировании это забывают. Ну и еще влеты задач в спринт - нельзя впихнуть невпихуемое, и тут либо убирать какие то задачи ради влетевшей, либо заранее планировать время для вот таких вот влетов, а они всегда будут.
gun_dose
20.09.2024 13:13+3Это всё называется отсутствие навыков планирования. Если разработчик оценил задачу в два часа, значит надо ставить 4, потому что ещё час на тестирование и ещё час на возможные доработки в случае, если QA вернёт задачу. Если задача сложная и большая, можно запросить развёрнутую оценку у нескольких разработчиков, посмотреть, за какие сроки делались похожие задачи ранее, и т.д. В идеале вообще всегда давать пессимистическую оценку, чтобы в конце спринта оставались неотработанные часы, и тратить эти часы, на те самые "влёты" или, например, на погашение технического долга.
MSoldatkin
20.09.2024 13:13+3А если ПМ поставил 4, а потом выяснилось, что еще чего-то не хватает, и надо уже 8 или 80?
Планирование без осечек - заведомо нерешаемая задача на дистанции.
Адепты scrum этот момент очень и очень хорошо понимают, и добрая половина скрам-гайда посвящена предложениям к решению этой проблемы.
Своеобразные решения конечно для многих, но они предлагаются (и у кого-то даже работают)gun_dose
20.09.2024 13:13Если эстимэйт оказался недостаточный, то ПМ должен уведомить об этом клиента и обосновать, что к чему. После этого как правило, задача либо будет на несколько спринтов, либо вообще откладывается на потом, если у клиента ограничения по бюджету.
MSoldatkin
20.09.2024 13:13Клиент с бюджетом и спринты? Если у вас такое практикуется, то менеджменту можно выписать грамоту в номинации "Прорыв года".
Скрам это про продуктовую разработку, и как правило in-house.
На внешнего заказчика это может работать только по схеме time & material, что в реалиях РФ и СНГ встречается крайне редко.
Всё остальное от незнания и попытки использовать хайповые подходы без понимания их сути, и для чего они изначально создавались.gun_dose
20.09.2024 13:13В СНГ действительно принято оговаривать сумму и сроки до начала работ, а если попробуешь попросить что-то сверх, то сразу окрестят мошенником, но я с рынком СНГ не работал уже несколько лет. А в Европе и США вся аутсорс-разработка ведётся исключительно по спринтам.
bubn0ff
20.09.2024 13:13Дельное замечание, кстати. Тоже думал об этом, но почему-то нет внятного ответа. Бизнес хочет быстрее, но не понимает специфики работы программистов.
Angry_Bel
20.09.2024 13:13+2Вопрос, пожалуй как вы оцениваете и куда вы двигаетесь.
Спринт - 2 недели. КПД в попугаях, попугай пол дня. Норма - 13попугаев. Куда делись ещё семь, на поговорить (как же мы без дейли), на подумать (прокрастинировать любят все), на почитать (приходится и заглядывать в документацию).
В целом, выходит вполне хорошо. Мне повезло с руководством, никто тебя не будет пинать, за спринт с условными 8попугаями, может что-то пошло не так.
Когда в расчетах закралась ошибка (считали на одного лишнего человека), и не выходило условные 100попугаев на команду, три спринта. То в первую очередь шли разговоры о том, что мы плохо оцениваем, а не вы все ....сы ленивые.
Но есть и дедлайна, выставки, релизы и прочее. А тех кто в творческом поиске перманентно (давайте девы самы будут решать когда и как им работать) - у нас просто выгоняют, иногда с проекта, иногда с компании.
Многое зависит от команды/проекта/руководства /заказчика. Может быть дело вовсе и не в сраме.
П.С не совсем дев, системный инженер, или как можно говорить девопс с не слишком большим стажем работы. Может не успел ещё выгореть, но становится интереснее и интереснее на работе
sovremeniypirat
20.09.2024 13:13+1дружище, просто девопс это совсем не дев и тут гораздо меньше стресса) Еще и если ты труъ девопс (не член отдела на компанию/кучу команд, а условно отдельный челобрек на продуктовую команду)
Хотя на самом деле может я не прав и мне всю мою карьеру в devops (около двух лет) просто везло с командами
markowww
20.09.2024 13:13+1У девопсов тоже много стресса. Если процессы поставлены не очень хорошо, то задачи на девопс/админов регулярно приходят с ДД на вчера.
Angry_Bel
20.09.2024 13:13Я в принципе в странно проекте. У нас 4 девопса, на одного тестера и 3х девелоперов.
Мой опыт не релевантен. Но есть и дедлайны, и прочие радости. И да, мы команда, под один продукт, в немного разных вариантах, но технически он один.
Однако я сторонник того, что нужно правильнее планировать. Если от вас хотят задачу на три дня за два рабочих, то это вопрос не спринтов, а хотелок и планирования.
arheops
20.09.2024 13:13что вам мешает переносить задачи в следующий спринт и делать спринты длинее?
Спринт это не данность "решить 1 задачу сейчас". Может быть больше одной задачи и больше одного спринта.
В целом стресс зависит от вашего планирования, а не выбранной системы планирования.
tolyanski
20.09.2024 13:13Можно перейти на канбан и через какое-то время внезапно обнаружить, что надо отчитываться перед руководством о том, что сделано за прошедший месяц. Еще через какое-то время ты начинаешь по такому случаю планировать задачи и фичи на ближайший месяц, а конец месяца становится уже привычным дедлайном, потому что потом встреча с руководством. А еще по такому случаю появляется желание устраивать ретро по итогам каждого месяца.
И вуаля, у тебя канбан, который выглядит как скрам, только с длиной спринта 1 месяц ))
FireFly111
20.09.2024 13:13+9Могу только подписаться под каждым тезисом этой статьи. Искуственность итераций, необходимость регулярных ритуальных приседаний, всё это вредит разработчику и разработке. Но, поскольку решения принимаются менеджерами, скрам стал практически стандартом индустрии. Скрам решает проблемы менеджмента, а не разработки.
tolyanski
20.09.2024 13:13Вообще да, насколько я помню/где-то читал, что основная идея скрама - поставлять бизнесу ощутимую ценность за предсказуемые промежутки времени.
markshevchenko
20.09.2024 13:13+4Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
ruimage
20.09.2024 13:13Ситуация когда не сделали 60-80 процентов задач это сигнал что что-то очень неправильно.
Либо оценка задач, декомпозиция проводились неправильно. Либо вам задачи в спринт засунул менеджмент несмотря на совокупную мощность команды. Либо предельно нарушен процесс разработки и кто-то грязными руками лазил и дёргал разработчиков.
Нужно остановится и подумать (о ретро об этом, не так ли?). Но, к сожалению, чаще просто переносят тачки дальше.
markshevchenko
20.09.2024 13:13+4Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
aiminkai
20.09.2024 13:13Слон в том, что команда сама планирует. У разработчика спрашивают, сколько займёт та или другая задача в спринте.
Никто не хочет завалить спринт. Никто не хочет сидеть без задачи. Так берите в спринт адекватно. Это же в ваших возможностях?
И будет вам 80% ежеспринтово и стремление к 100 как цель
markshevchenko
20.09.2024 13:13+3Но ведь это не в наших возможностях. Об этом и был мой комментарий.
Мир непредсказуем. Как ты ни крутись, но 100% всё равно не попадёшь. И статистика это подтверждает, можете сами посмотреть, как в индустрии обстоят дела с предсказуемостью.
Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
arheops
20.09.2024 13:13Ну так вносите непредсказуемость в вашие естимейты.
Это и есть основная идея теории хаоса.
У маленьких проектов в принципе больший процент неправильных естимейтов.
markshevchenko
20.09.2024 13:13+1Так я, вроде, именно это и делаю. Завершим, — говорю, — от 60 до 80% запланированных задач. Чем не непредсказуемость?
Mur466
20.09.2024 13:13У нас вообще прикольно сделали. У каждого проекта свои несихронизированные спринты. Команда разработки участвует в нескольких проектах, то есть у команды сразу несколько спринтов. Как в таких условиях живется команде, менеджеров не волнует. У них-то всё по феншую.
tolyanski
20.09.2024 13:13То есть 1 команда, 10 проектов, и в лучшем случае в каждый рабочий день заканчивается какой-то спринт?)) Можете назвать компанию, чтоб я туда не шел?)
reim
20.09.2024 13:13+2Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.
tolyanski
20.09.2024 13:13Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
Так ретроспектива не для это же предназначена. Я всю жизнь думал, что ретро - это мит где обсуждают проблему отсутствия очистителя воздуха в офисе
habryanin
20.09.2024 13:13Интересное мнение, но тут как посмотреть и смотря кому :)
Я, например, учился так работать (Scrum/Kanban) — так и работаю, ощущая себя очень комфортно в этой парадигме. И меня раздражает отсутствие краткосрочного планирования (дедлайнов на след. неделе), ректроспектив и постоянного обсуждения «а что же происходит, а что мы делаем/сделали/будем делать».
Да, другие методы разработки продуктов тоже содержат в себе эти процессы, однако они лишены такой динамичности — лично для меня это минус, потому что библейский вопрос «а не йухню ли мы делаем?» никто не отменял, но ответ на который лучше получать постоянно и непрерывно, пока не поздно.
При этом с некоторыми пунктами я не согласен. Например, про отсутствие автономии и априори недостаточность подготовки. Всё это сводится к конкретным случаям/продуктам/командам/задачам. Если процесс плохо выстроен, а исполнители не особо понимают что они делают, то неважно какая методика используется — будет хаос.
Современные продуктовые команды в рамках Scrum, на мой взгляд, наоборот, расширяют автономию каждого из участников, позволяя всей команде выбирать путь наименьшего сопротивления для достижения конкретной цели «здесь и сейчас», а не иллюзорного результата через месяц-год-полтора. Коммуницирование в Scrum стоит во главе угла, поэтому, если все налажено, не может возникнуть ситуации, когда тебя ну прям вот заставляют что-то делать. При этом никто не отменяет использование вспомогательных инструментов, как burndown chart — чем не помощник в планировании и уменьшении стресса связанного с «я не готов морально работать постоянно, потому что не вижу ни конца, ни края задач».
Но, с чего и начинал, опыт у всех разный, команды/продукты/процессы/задачи у всех разные, поэтому каждому своё.
ivcoder
20.09.2024 13:13Спринты все же являются частью квартального, годового планирования, например, и их бесконечность уже не так пугает.
whoisking
20.09.2024 13:13+3По личному опыту работы менеджеры(продакты/проджектов) за очень редким исключением могут подходить к команде/продукту/процессам индивидуально, адаптивно и в целом включать голову, в основном это дикий карго-культизм без понимания и зачем оно вообще нужно и нужно ли оно здесь вообще. Мало того, что эти люди как правило не понимают технической составляющей вещей, из-за чего любые созвоны затягиваются на жутко долгое время, так они и по своей части как правило просто следуют каким-то средним по больнице практикам, которые зачастую приносят больше вреда, чем пользы.
И порой думаешь, что хотелось бы видеть на этих позициях людей с техническим бэкграундом. Но, тут беда в том, что люди с техническим бэкграундом редко идут на эти роли и индустрия это никак не поддерживает (ведь даже если ты уже хороший сеньор, то ты просто обязан расти как специалист в своей сфере, ты и будешь уверен в своём будущем и к тому же станешь только скилловее и наверняка прибавишь к зп). Не говорят о том, что технические специалисты чаще являются интровертами, по мере работы им больше необходимо тратить времени на самообразование, на исследования и тд, что тоже их отдаляет от качеств, более необходимых для менеджера.
В итоге имеем то, что имеем. Задача не простая и тут, наверное, надо с умом подходить к системе образования специалистов. Да и методики надо сильно менять, либо заставлять менеджеров хотя бы прочитать их полностью, а не выжимки в пару абзацев.
Boethiah
20.09.2024 13:13Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
tolyanski
20.09.2024 13:13Я лично пока не встречал компаний с на 100% адекватной оценкой трудозатрат)
alpatovdanila
Из раза в раз в подобных статьях замечаю, что речь начинает идти о крайне странных вещах, типа обязаловки скопа спринта, каких-то "сроках", про которые в скраме нет ни слова, и каждый раз речь идет о каких-то имплементациях, которые забывают, что скрам идет снизу вверх, от ситуации к инструкциям, а не от инструкций к ситуациям.
thekingoftheworld
В этом как раз нет ничего странного. Вот пара моментов, раскрывающих эту точку зрения:
1. Все дело в том, что скрамо
ёб...любы говорят "вдвое больше работы за половину времени" (книга же так называется), но в реальности скрам - это скорее "неизвестное количество работы за неизвестное время", неопределенность и все такое. К тому же, как правильно замечено в статье, почти все проекты в реальности имеют и дедлайны и ограничения по бюджету, даже всякие НИОКРы и R&D и то обычно ограничены по бюджету.2. В скрам-гайде было написано: легок для понимания, но сложен для освоения (дословно: "Difficult to master"). В новых версиях эту фразу почему-то скрыли, но от того она не перестала быть правдой. С
крамо-менеджеры спотыкаются об эту сложность (и об игнорирование скрам-идеей реальности), и всё внедрение скрама заканчивается тем, что теперь они недели называют спринтами, добавляют 8 совещаний и устраивают понедельное планирование. Особенно смешно(нет) получается, когда только команда разработки играет в скрам, а вся остальная компания нет, потому что извините, у них поставки, отгрузки, декабрьский ажиотаж и прочее - в итоге - Scrumfall (спасибо за новое слово!).saboteur_kiev
Основная проблема была в том, что в waterfall была не низкая нагрузка на разработчиков, а из-за линейного планирования, могла быть полное отсутствие нагрузки на некоторые команды, пока они ждут свою очередь плана.
В agile (в том числе и скрам), есть возможность каждый спринт давать задачи всем.
Что же по поводу стресса - так ставьте нормальные дедлайны, которые включают в себя среднюю, а не высокую нагрузку на людей. Отдыхать можно вне работы, во время обеда, либо вообще если на задачу выделено адекватное количество времени, то в это время включено и обдумывание лучшей стратегии, а не срочно тяп-ляп любыми способами.
Таким образом я в корне не согласен с тем, что " Спринты лишены перерывов, сильно ограничивают автономию и не дают достаточно времени на подготовку. "
Ограничения и лишение перерывов не дает менеджмент, а не спринты.
ssmaslov
Вы рассказываете, извините, сказки. При долгосрочном планировании работ никакие *команды" не простаивают. А сам waterfall которым всех пугают не существовал НИКОГДА. Это термин из статьи описывающей ГИПОТЕТИЧЕСКИЙ линейный процесс, теоретическую вымышленную ситуацию, но к сожалению, из статьи выдернули только термин, исказили смысл и дальше в клювиках понесли миру страшилки. А так то - некоторые из нас умеют играть в шашки тьфу в шахматы тьфу в разработку, а некоторые не умеют. И никакие ритуальные церемонии это не изменят :-)
saboteur_kiev
Простите, я в таких работал лет 10. Я знаю ватерфалы не из статьи а из практики.
Когда идет разработка/поддержка какого-нить небольшого проекта в крупном ентерпрайзе на 10-20 человек. Релизы по полгода. Половина команды ничего не делает первые 1-2 месяца, половина вторые.
Ravager
Я пока не понимаю откуда простой берется. У нас после того как заканчивалась стадия разработки проекта 1, брался в работу проект 2. Тем временем тестировали проект 1,и если там находили баг то кто-то из команды переключался на фикс. Хотя конечно тестировщики работали более расслабленно, но они и при скраме тоже могут так работать.
ValeryGL
Из треугольника функциональность-деньги-время в водопадных проектах обычно ограничивается функциональность и деньги, поэтому сдвинуться (а сдвигается всегда в одну сторону) могут только сроки, но тут возникает желание их ограничить - вот и горячка в конце проекта.
В случае инкоементально-итеративного подхода сроки могут быть ограничены, верно, но функциональность может плавать. В любом случае к дедлайну (который определён планом, рынком, конференцией, договором с партнёрами..) основная функциональность будет поставлена и уже работать.
Siddthartha
факт "в скраме нет ни слова" прям очень кайфово резонирует с фактом "ни разу за 15 лет не видел чтобы было иначе".. )) в лучшем случае, мудрое руководство просто дает возможность команде периодически "расслабиться" в стиле "ну, давайте, ладно, этот спринт на рефакторинг".. (только роадмап рефакторинга не забудьте подготовить))))
Talewind
Да, действительно, какая-то странная форма, как будто человек зашит в какой-то шаблон.
"В спринте нет времени на подготовку", "спринт не кончатся" ээээ... Автор МП или как? Т.е. планировать часть работ в спринте как анализ и подготовку к следующему он не догадался? Запланировать "лёгкий спринт" не может? У него нет плана проекта чтобы понимать, когда пахать, когда сеять?
Пример с мышами ещё смешнее. Если людей заставлять, они работаю хуже... Да, верно, никто не спорит. А как же сроки?
Вот и получается какой-то скрам из учебника, к реальности не привязанный. Какой то "инвалидной", простите.
WebPeople
Увы, идеальный скрам существует лишь в фантазиях его апологетов. А в реальности, его применяют в большинстве случаев потому, что это модно. Вот несколько интересных моментов в скраме:
Серьезные фичи не вписываются даже в 2-3 спринта. Не будет никакого инкремента по бэклогу продукта в одном спринте. Как вариант, такую фичу можно сделать подпроектом. Со всем вытекающими церемониями и артефактами. Это усложнение ведения проекта. Вы так делаете? Я думаю, мало кто делает. На спринт ревью в итоге не результат показывают, а тупо перечисляют сделанные задачи (просто список задач с отметкой done).
Скрам-мастер. У вас он был? Или менеджер проекта это он и есть? Многовато тогда функций на PM падает, не думаете? Вести проект и ещё обучать всех скраму(команду, владельца продукта и прочих стейкхолдеров). Вот они и "горят" как спички. Похлеще разработчиков.
Сроки. Вы видели описание работы со сроками в скрам гайде? Предлагают работать эмпирически. Т.е. проведи не меньше 3 спринтов, высчитай велосити и рассчитай вероятный срок релиза. Зашибись! А то что этапы в разработке разные, люди могут болеть, ценность отдельных спецов может быть высока (заболеет - вся команда встанет) и т.д.? Как объяснить стейкхолдерам, что сроки релиза будут меняться после каждого спринта?))) А изменение срока - это обычно и изменение бюджета. Зарплату команде платить же надо.
Чисто по-человечески я понимаю. Это разумно. Типа работаем как можем, вот вам прогноз. Он может меняться, такова жизнь. Но в бизнесе это так не работает.
Ravager
Согласен. Считаю чтобы поставлять каждый спринт инкремент нужна разная длительность спринтов. Да и вообще скрам предполагает что у нас команда фуллстек разработчиков что в реальности не так. Короче это фреймворк не для корпораций а для стартапа. Где команда может действительно гибко управлять процессом. А иначе по факту получается буллщит.