Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которых мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.
Зачем мы используем скрам?
Сферический разработчик в вакууме (а именно к этой фигуре стремится инженер, которого не таскают на митинги) не требует сложных методик. Обычно этот человек просто выполняет рабочие задачи, зачастую даже выполняет их хорошо, а иногда проявляет инициативу и думает на несколько уровней выше и ниже своих задач.
Однако когда инженеров накапливается много, встает задача ими управлять, распределять работу, и как-то следить, что она выполняется в срок. Чем больше и сложнее задачи, тем больше сил уходит на организацию, и тем сложнее выстроить коммуникации в команде.
На помощь приходит скрам - серебрянная пуля всех методик, волшебная таблетка всех процессов. От мала до велика - все работают по скраму - и стартап, и мегакорпорация. И это не удивительно - за пару десятилетий подход превратился в золотой стандарт индустрии, отход от коротого обсуждают презрительным шепотом.
Но почему же я раз за разом, в одном проекте за другим, вижу одинаковые проблемы? Эти проблемы были десять лет назад, есть и сейчас. И кажется, мы их вот-вот решим, стоит только сильно захотеть...
Разделяй сейчас, властвовать переносим в другой спринт
Сколько раз вы слышали подобное:
Эта задача не умещается в спринт, поэтому нужно разделить ее на две.
Не знаю как вы, но я встречал эту практику в 10/10 компаний где я работал, где был внедрен скрам. Казалось бы, что в этом плохого?
Концепция разбиения задач на атомарные части проста, но умна в то же время: разбивайте задачу на части до тех пор, пока части не будут так малы, что их нельзя больше разбить. А раз задача настолько мала, значит должно быть очевидно, как ее делать, и сколько времени это займет, так?
Так, но с одной оговоркой: это работает для задач, где мы точно знаем, что нужно сделать, или хотя бы в какую сторону идти. Чтобы разбить задачу на части, нужно для начала понимать, из каких же частей она состоит. А это само по себе требует некоторых знаний о задаче, и часто не самых поверхностных.
Нюанс в том, что под это определение не попадают RnD задачи, то есть задачи, в которых присутствует большая доля неизвестного. Причем часто это не такое неизвестное, которое известно как найти, а неизвестное неизвестное - то есть мы не знаем, что это, и где его искать, но знаем только, что нам оно пока не известно.
RnD задачи не вписываются в спринты
Например, исследование новых технологий, дизайн архитектуры, разработка нового функционала (особенно вкупе с интеграцией) - это задачи, где всплывает множество неизвестных неизвестных. Так много, что их просто невозможно оценить заранее - задачу можно выполнить за день, "случайно наткнувшись" на решение проблемы, а можно две недели изучать документацию, проводить эксперименты и сидеть в дебаггере, но по-прежнему не найти выход.
Может быть, точная оценка решит проблему неизвестности?
Оценивай, или оценят тебя!
Оценка - ключевая концепция скрама. Каждый спринт строится вокруг оценки задач и наполнения ими спринта. А уж сколько инструментов для оценки у нас есть! И Planning Poker, и Bucket System, и T-Shirt Sizes, и множество других.
Они все разные, но у них есть одно сходство - ни один не предоставляет работающей методики оценки объема задач. Это либо гадание, либо соревнование, либо аукцион "кто назовет меньше". Ни один метод не даст гарантированного хотя бы с 25% погрешностью результата оценки.
А в чем же причина? Неужели разработчики саботируют свою работу? Или метрики не подходят, и нужно изменять не в числах Фибоначи, а в прыжках лягушки? Или размеры футболок нужно корректировать в разных странах?
Нет, дело не в этом. Все дело в том, что мы не умеем оценивать задачи. Нет, не так.
Мы не умеем оценивать задачи!
В индустрии до сих пор нет механизма, позволяющего оценивать RnD задачи с хоть сколько бы то ни было приемлемой погрешностью. И попытки построить на этой недостоверной информации целую систему приводит к одинаковому результату - задача переезжает из спринта в спринт, а скрам мастер все больше и больше теряет терпение.
Может мы просто недостаточно стараемся?
Церемония
Спросите у любого скрам мастера: "Из-за чего возникают подобные проблемы?". Ответ ожидаемо похож - "недостаточное соблюдение церемоний" или "недостаточное внедрение скрам практик".
Что это значит в переводе на разговорный язык? То, что в неправильной оценке задач виновата команда, которая проводит недостаточно refinements, и недостаточно усердно делится переживаниями на ретроспективе. А может, кто-то неправильно стоит на daily standup? Или нужно больше времени тратить на планирование спринта, чтобы уж никто не смог отмазаться от данных оценок!
Ведь по мнению многих скрам мастеров и прочих менеджеров, инженеры - это просто лентяи, которые не способны самостоятельно решать проблемы, поэтому тянут резину и переносят задачи из спринта в спринт. Проблемы может быть две - недостаточная мотивация, или недостаточное разбиение задач. Таким образом любую инженерную задачу можно решить, побив ее на мелкие части, и повысив мотивацию работника.
Что мы имеем в реальности? По 10 часов скрам церемоний в неделю, которые не дают сосредоточиться на выполнении задач, на которых постоянно спрашивают про статус этих задач (хотя статус можно узнать, просто заглянув в Jira). Вместо фокуса на работе, мы занимаемся "дрессировкой джиры", коллективно тренируемся разделять задачи, которые не влезают в спринт, и тыкать пальцем в небо с умным видом, когда нас спрашивают об оценке.
Мотивации и церемоний недостаточно, чтобы решать задачи.
Иногда может потребоваться работать.
Весь процесс скрама в RnD команде превращается в попытки натянуть рабочий процесс на методологию, которая ничего общего с ним не имеет. При этом сотрудники находятся под постоянным давлением из-за того, что задачи не ложатся идеально на спринты, и приходится либо отрезать кончики, либо докладывать. С другой стороны, они чуствуют себя перманентно виноватыми в том, что их оценки не сбываются, а значит они подводят команду и руководителя.
Но это еще не все.
Скрам - новый Ватерфол
Доводилось ли вам работать в крупной международной компании? Слышали ли вы про SAFe? Держали ли в руках книгу на 100 страниц про процессы жизненного цикла software в компании?
Если да, я вас поздравляю - ваша компания купилась на аферу под названием "аджайл для взрослых"! А именно, жесткие и сложные методологии под эгидой "гибкости" и "легкости".
Что такое аджайл? Откройте Agile Manifesto. Вы удивитесь, насколько мало общего такие вещи, как SAFe, имеют с этим документом. Мне не сложно включить его прямо в статью:
-
Люди и взаимодействие важнее процессов и инструментов
-
Работающий продукт важнее исчерпывающей документации
-
Сотрудничество с заказчиком важнее согласования условий контракта
-
Готовность к изменениям важнее следования первоначальному плану
Однако ловкие продавцы церемоний усвоили только часть:
-
процесс важнее всего
-
документация не нужна
-
плохой план можно исправить итеративностью
-
бумажка превыше всего
В итоге мы получили все, против чего боролись авторы agile manifesto - жесткие фиксированные сроки, запланированный объем работ для каждой фазы, давящие кросс-командные планирования, загоняющие команды в жесткие рамки и лишая гибкости коллаборации, а также большое количество бюрократии и бумагомарания.
Но ведь это аджайл, верно? Мы же продаем компании гибкость! А как этого добиться?
Легко! Возьмите классический waterwall, теперь разбейте фазу реализации на двухнедельные отрезки, добавьте церемоний (не важно, подходят ли они процессу или нет), и заставьте разбивать задачи на атомы! Скажите клиенту, что это делается во благо обратной связи, и не забудьте выписать счет!
SAFe это совсем не ватерфол, ну вот ни разу!
Продавец скрама, аджайл-коуч, бизнес-тренер
В итоге мы получили поголовное помешательство на скраме под соусом "гибких методологий". Однако скрам давно перестал хоть отдаленно напоминать исходную идею, и оброс огромным слоем корпоративного мусора, сертификаций и мастер-классов.
В итоге применение скрама к таким задачам превращается в бюрократический цирк, в котором никому не до смеха.
Все кончено?
На самом деле нет. Есть надежда.
К счастью, аджайл не ограничивается скрамом. Даже наоборот, скрам несмотря на все старания не смог убить хорошую идею в основе гибкого подхода.
Для RnD существуют более подходящие методологии - например, Kanban. Практика не требует четких оценок, которые сложно дать в условиях высокой неизвестности или новизны. К тому же, Kanban не привязывает задачи к синтетическим временным контейнерам, позволяя выполнять задачи в той мере, в которой они этого требуют - иногда один день, а иногда и целый месяц.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
Есть другие практики, который подходят к разным ситуациям и разным командам. Однако спустя годы я пришел к иному выводу.
Аджайл предоставляет большое количество методик, но всего лишь несколько ключевых идей. Подбирайте практики, которые позволят вам реализовать эти идеи в вашем конкретном процессе. Нравится парное программирование - никто не мешает вам внедрить его на постоянной основе. Хочется оценивать задачи по факту выполнения - вы вольны сделать это.
Начните с Agile Manifesto. Экспериментируйте. Стройте свой уникальный процесс.
Гибкость также и в том, чтобы быть гибким в выборе методик и их применении. Многие команды экспериментируют с технологиями и инструментами. Не бойтесь подвергать экспериментам и аджайл - тем более, что это не требует расходов на лицензию.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Такая работа идеально ложится на скрам - задачи легко оценить, они обычно невелики, а работа заключается в поиске и исправлении ошибок, либо мелких доработках. Идеально для скрам! Только не забывайте приносить часть рабочих часов в жертву своему мастеру, иначе это не будет работать.
Утешительные Итоги
Если прочитав статью, вы узнали себя - не стоит вешать нос! Хоть скрам и является карго-культом, он все-таки худо-бедно работает, а значит помогает решать задачи. По крайней мере это позволяет бизнесам двигаться вперед, а значит у вас и завтра будет работа.
Но если вы стоите перед задачей построения гибкого процесса разработки - не слушайте тех, кто громче всех кричит. Вернитесь к истокам agile, и выберите то, что будет работать лучше всего для вас. И если это будет скрам - примите это решение осознанно!
P.S.: спасибо за комментарии, мне приятно их читать и отвечать. Хочу добавить:
Скрам сам по себе хорошая, целостная и продуманная методология, и наверняка есть те, кто освоил ее в совершенстве. Однако я не встречал таких проектов, работая и в малых, и в огромных компаниях, и в продукте, и в оутсорсе, и в консалтинге. И множество моих знакомых имеет сходный опыт.
Скрам - как коммунизм - в теории элегантен и эффективен, на практике сколько ни пробовали - работает только в Китае, и то с оговорками.
Если концепция хрупкая и неустойчивая, а для ее "правильного" применения нужно очень очень постараться (с чем большинство не справляется) - стоит заключить, что эксплуатационные характеристики не соответсвуют ожиданиям.
Индустрия же пошла своим путем - компании пытаются "накормить" скрамом своих сотрудников, насаждая практики не разобравшись. В итоге имеем то, что в заголовке.
Картинки
-
Braden Collum
-
Clark Douglas
-
Julia Arte
-
Parabol
-
Ozan Safak - продавец скрама
-
Stormseeker - обложка
Автор: Ilya Kaznacheev
