На первый взгляд, гибкая разработка и сопутствующие методологии уже лет двадцать как стали новой нормой. Но если копнуть поглубже, немало инженеров и сегодня считают, что появление в компании консультантов по Scrum — повод срочно обновить резюме. Разбираемся, за что не любят спринты, кто виноват и можно ли с этим что-то сделать.

Вездесущая методика

«Гибкие методологии» традиционно связывают с Agile-манифестом разработки ПО. В 2001 году его сформулировала и подписала группа американских разработчиков, инженеров и ученых, после чего философия Agile начала покорять мир — сначала ИТ-компании, а потом и другие бизнесы стали следовать идеям Манифеста (они оказались применимы и для проектов, не связанных с технологиями). Поскольку Манифест содержал только основные ценности и принципы, вокруг него постепенно сформировались инструменты, позволяющие реализовать Agile на практике (справедливости ради, некоторые из них, например, тот же Scrum, возникли еще в 90-е).

Сейчас гибкие методологии в разработке программного обеспечения и иных продуктов применяют тысячи компаний по всему миру. Регулярно появляются новые материалы и специализированная литература по теме. Так, книга «Постигая Agile» Эндрю Стеллмана и Дженнифер Грин считается классикой в этой области. Более современные публикации — например, «Driving Value with Sprint Goals» — предлагают новые точки зрения и подходы к организации гибких процессов.

Один из принципов Манифеста гласит: «Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев». За реализацию этого принципа в рамках фреймворка Scrum отвечают спринты — короткие (от 1 до 4 недель, часто 2 недели) отрезки времени, за которые команда проекта должна реализовать инкремент продукта. Считается, что спринты формируют ощущение предсказуемости в работе и способствуют росту производительности: зная, чего ожидать, команда может сосредоточиться на выполнении задач (и планировать отдых) без лишнего стресса от постоянных изменений. В идеале спринты должны улучшать и общение внутри команды — во время регулярных встреч можно получить помощь или обратную связь от коллег.

Спринты стали популярны, потому что помогают фокусироваться на том, что действительно важно, быстро проверять гипотезы и исправлять недостатки в программном обеспечении. Еще в 2011 году в Adobe проанализировали исторические данные о количестве багов и других «дефектов» в коде. Специалисты хотели понять, какой эффект на эти показатели оказал переход на Scrum и работа спринтами внутри компании. Оказалось, что число ошибок существенно снизилось в семи из девяти команд, по которым Adobe смогла собрать статистику «до/после перехода на Scrum».

За прошедшие годы Scrum в целом и спринты в частности стали «общим местом» в разработке ПО: вряд ли кто-то о них еще не слышал, и большинство программистов в своей практике сталкивались (пусть и не всегда успешно) с подходами, которые предлагает фреймворк. Да и сами компании стали смотреть на Scrum более трезво. Автор статьи, опубликованной в прошлом году в научном журнале Computing & AI Connect, пишет, что комические причины внедрения Scrum, вроде стремления «казаться модными-молодежными» отошли на второй план — сейчас компании хотят ускорить процесс разработки и адаптироваться к быстро меняющимся требованиям.

Однако, несмотря на то, что бизнес-аналитики и консультанты буквально ставят знак равенства между «сферическим аждайлом» и «успешным успехом», немало разработчиков-практиков выступают с критикой Scrum. Посмотрим, какие минусы спринтов отмечают те, кто в них непосредственно участвует.

Четыре причины недовольства

1 — Гонка за показателями. Классический спринт дробит процесс разработки на двухнедельные промежутки, в течение которых команда постепенно движется к цели. В теории тикеты в пределах одного спринта должны закрываться равномерно, но на практике бывает иначе. Некоторые разработчики отмечают, что в конце спринта часто начинается кранч — гонка за выполнением задач. Чтобы уложиться в сроки, команда помечает тикеты как завершенные, даже если осталось доделать еще 5% работы, а все недоделки перетекают в новые задачи. Еще хуже, когда команда применяет хаки и костыли, чтобы уложиться в срок, жертвуя качеством.

Но если слишком увлечься погоней за показателями внутри спринта и каждый раз закрывать глаза на недоработки ради красивой статистики, можно прийти к анти-Scrum или, в простонародье, eXtreme Go Horse. Это — шуточная методология, которая высмеивает вредные практики в разработке: один из пунктов гласит, что разработчик «всегда все делает вовремя».

2 — Бюрократия. Также все чаще звучат мнения о том, что гибкие методологии приводят к микроменеджменту. Да, планирование, ретроспективы, стендапы — все это неотъемлемые составляющие каждого спринта, которые призваны помочь команде координировать усилия. К сожалению, как и в случае со многими другими разумными инициативами, их можно довести до абсурда — особенно, если команда обрастает менеджерами, с излишним рвением следующими букве фреймворка. В итоге программисты вместо реализации новых фич занимаются бюрократией: ресурсы уходят на отчёты и обсуждения. Эффект от такого «скрама» получается обратный: вместо того, чтобы сократить количество переписок и ускорить рабочие процессы, разработчиков топят в околоуправленческой рутине.

3 — Проблемы междисциплинарности и потеря фокуса. Scrum-гайд отмечает, что в спринтах участвует команда, состоящая из скрам-мастера (одна штука), владельца продукта (одна штука) и разработчиков. Иных ролей в «каноничном» Scrum нет. На практике компании пытаются дооснастить команду не только менеджерами, но и другими специалистами (аналитиками, тестировщиками, юзабилистами), которые, с одной стороны, тоже должны принимать участие в процессе разработки, а с другой — с трудом втискиваются в прокрустово ложе фреймворка. Команда исследователей из университетов Исландии и Швеции решила рассмотреть в этом контексте проблемы UX-специалистов. Респонденты отметили, что:

• Им сложно вписаться в проект — «юзабилист Шредингера» находится одновременно в команде (работает над инкрементом продукта) и вне ее (разрабатывает требования ко всему продукту, оценивает результаты работы программистов).

• Им приходится опережать спринты — стратегическое видение продукта, цели UX и, в некоторых случаях, прототипы приходится готовить до начала спринта, иначе разработчики будут простаивать без дела.

• При этом дробление не позволяет сформировать общую картину пользовательского опыта: отдельные элементы приложения или сервисы могут быть реализованы на высоком уровне, но это не гарантирует успешной интеграции этих частей в продукт. Отчасти это связано с тем, что «пользовательский опыт» — комплексное понятие, и его не всегда получается доставлять по частям.

О последнем, кстати, говорят не только юзабилисты: разбиение большой задачи на множество мелких зачастую приводит и «каноничные» Scrum-команды к потере фокуса на общей цели проекта. В идеале эту задачу решает владелец продукта, но и он не застрахован от ошибок и гиперфиксации на «текучке».

4 — Субъективная оценка производительности. Один из краеугольных камней, который появляется в каждом первом материале с критикой Scrum — сложности в оценке того, какой объем работы команда может реализовать за спринт. Вне зависимости от того, происходит оценка в человекочасах или стори пойнтах, точно спланировать объем работы, который не будет ни чрезмерным, ни недостаточным, крайне затруднительно.

И российские, и зарубежные специалисты при этом сходятся в одном: во-первых, оценить среднюю скорость/мощность/производительность команды (сколько стори поинтов команда может выполнить за спринт) можно только постфактум, по результатам двух или более спринтов, но никак не за «один пристрелочный подход». А во-вторых, даже эти оценки будут очень приблизительными, потому что команда не существует в вакууме: сотрудники уходят в отпуск и на больничный, у них рождаются дети, они увольняются, они, в конце концов, могут столкнуться с выгоранием или разочарованием в работе — все это влияет и на состав команды, и на ее скорость. А излишне оптимистичные оценки — это новый источник стресса, и привет, причина для недовольства номер 1 (кранч и гонка за показателями).

Scrum в этом не виноват (но это неточно)

В противовес критике стоит отметить и пару моментов в защиту фреймворка в целом и спринтов в частности.

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

Показательный пример — многострадальная оценка производительности и планирование спринта. Пусть стори поинты не являются идеальным мерилом, но (в отличие от человекочасов) они, как минимум, помогают сфокусироваться на коллективной работе и ее результатах. Кроме того, такая оценка, даже очень приблизительная, может быть интуитивно понятнее самим участникам спринта. В одном из старых постов на Quora Джефф Сазерленд, автор методологии Scrum, очень эмоционально советует переходить на стори поинты или на подход No Estimates: «Я придумал Scrum, чтобы команды работали эффективнее, а не чтобы истязать их подсчетом человекочасов».

Однако исследование Rally за 2022 год, основанное на данных 160 тысяч проектов, показало — 79% команд, использующих Rally Software, придерживаются так называемого подхода Full Scrum. Они оценивают объем работы в стори поинтах, потом дробят каждый «поинт» на задачи и проводят предварительную оценку задач в человекочасах. И это при том, что Сазерленд, по его словам, рекомендовал отказаться от такой практики еще в нулевых. Среди всех участников исследования его рекомендации следуют только 10% команд. А 8% для оценки не используют ничего, кроме человекочасов — авторы исследования делают вывод, что эти команды «вышли прямиком из дикого леса доаджайлового периода» и, в отсутствие консультантов по методологии, продолжают и в 2020-х работать по накатанной.

Scrum — не серебряная пуля. Но и его альтернативы — тоже не серебряная пуля. Например (продолжая тему с оценкой) тот факт, что на команду и ее производительность влияют внешние и внутренние факторы, никак не зависит от выбранной методологии. Вряд ли другая методология, фреймворк или подход к управлению проектом сможет гарантировать, что сотрудник не уволится и не заболеет. Соответственно, и доля неточности в оценках будет присутствовать в любой выбранной модели. Или, например, «избыточное» планирование и ретро в ходе спринта могут показаться не такими уж времязатратными — если сравнивать их с этапами аналитики и проектирования в водопадной модели.

Человеческий фактор никто не отменял. Как отметил один из резидентов HackerNews в соответствующем треде, «только готовясь к экзамену на [сертификат] руководителя проектов, я понял, насколько далеки обещания Agile-манифеста от того, что делают люди для его реализации». Любая рекомендация, вполне адекватная на бумаге, может стать совершенно невыполнимой, если руководитель проекта негибок к возможным изменениям, компания подписалась на кабальные условия по договору, в команде много новичков и нет системы их адаптации — причин для неэффективности может быть очень много. Или, как замечает автор «Черных страниц Scrum» Иван Селиховкин, Scrum и спринты не сделают команду дружной и эффективной — первичен не фреймворк, а люди и отношения между ними.

Спринты, да не те: кто выбирает альтернативы

Некоторые компании, внедрившие Scrum, со временем поняли, что строгое следование правилам не всегда эффективно. Они адаптировали работу по спринтам под свои нужды, оставив лишь те элементы методологии, которые действительно помогают достигать результатов. В этом направлении движутся даже такие ярые поклонники философии Agile как учредители компании Basecamp. Давид Хейнемейер Ханссон, известный как DHH, пишет, что его кумирами были Уорд Каннингем, Мартин Фаулер и Дэйв Томас — соавторы того самого Манифеста. Он даже опубликовал собственную книгу по теме: «Гибкая разработка веб-приложений в среде Rails».

В целом неудивительно, что в Basecamp используют основы фреймворка Scrum для разработки своих продуктов. Однако, несмотря на увлечение гибкими методологиями, команда не следует Scrum буквально. В частности, компания заменила классические двухнедельные спринты шестинедельными рабочими циклами. Подход, получивший название Shape Up, по мнению руководства, лучше соответствует организационной культуре и позволяет снизить влияние негативных аспектов спринтов — излишнее давление и жесткость сроков. Так, в каждом шестинедельном цикле реализуются два типа проектов. Первые называются Big Batch — это крупные задачи, разработка которых занимает много времени. Обычно в рамках цикла команда берется за один или два таких проекта. Второй тип — Small Batch — мелкие задачи: фиксы, улучшения или дополнения. За один цикл команда успевает завершить от четырёх до восьми подобных проектов. По окончании шестинедельного периода берется пауза на пару недель. Это время отведено под pet-проекты, рефлексию и отдых.

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

Противоположный подход применили в Skype, когда отказались от традиционных спринтов. В компании посчитали, что они не ускоряют, а, наоборот, тормозят разработку и перешли к ежедневным релизам. Руководство компании внедрило методику, вдохновленную Kanban, с отказом от большинства ритуалов вроде показа демо владельцу продукта, а сами разработчики получили больше автономии (а также меньше совещаний, бюрократии и контроля со стороны менеджеров). При этом команда сама решила оптимизировать процессы: все разработчики стали тестировать написанный ими код, а SDET-специалисты плотнее подключились к разработке.

Иначе говоря, даже в командах с традиционно сильной культурой разработки далеко не всегда эффективны «каноничные» спринты. С другой стороны, даже если «это не настоящий Scrum», такой подход вполне соответствует духу Манифеста гибкой разработки: «Люди и взаимодействие важнее процессов и инструментов».

beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.