Недавно мы наткнулись на пост в одном популярном телеграмм-канале с интригующей подписью:

Scrum для личных дел? Смотрите сами:

Его ошибка, вероятно, связана с одним из тех тараканов, которые заставляют нас объяснять непонятное привычными терминами. Но сегодня мы не будем учить вас тайм-менеджменту на примере этого треда. Мы поговорим о гибких методологиях управления проектами, то есть об Agile.

Как это связано с Agile?

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

Настоящий Scrum — это подход, который помогает навести порядок в задачах и сосредоточиться на создании ценности. Заметьте, это метод управления проектами, который помогает выпускать продукты. То есть результат применения Scrum — это всегда поставка ценности для клиента. Уже сейчас становится понятно, что в примере нашего героя никто никакой ценности никакому клиенту не производит. 

Начало истории

Перед написанием этой статьи, мы попытались связаться с героем истории, чтобы спросить, как ему помогла его разработка, и узнать, как у него сейчас обстоят дела с личным планированием. Но, увы, его аккаунт оказался удалён. 

Как вы уже поняли, несмотря на User Story и декомпозицию задач, Scrum у него всё же не получился. А что получилось?

В итоге получилось что-то похожее на методологию таск-менеджмента Getting Things Done (GTD) из книги Дэвида Аллена «Как привести дела в порядок», но всё равно не совсем то. На первый взгляд может показаться, что автор сделал всё правильно, если сработал принцип «Не трогай, если работает». Но поскольку он заложил туда основы планирования, перекликающиеся не то со скрамом, не то с ГТД, мы попытаемся указать на некоторые различия.

Сам Дэвид Аллен, создатель GTD, определяет «проект» не как одно большое дело, а как желаемый результат, для достижения которого требуется выполнить несколько действий. Что в теории похоже на «поставку ценности» в скраме.

Первое видимое отличие: область применения

Дадим полное определение Scrum, согласно «Scrum Guide» Кена Швабера и Джефф Сазерленд — это легковесная методика, которая помогает создавать ценность, находя новые эффективные подходы для решения сложных задач.

Тем временем GTD (Getting Things Done) — это методология личной продуктивности, которая позволяет «разгрузить мозг» и избавить вас от необходимости держать все задачи в голове. 

Наверняка вы сами замечали, как голова начинает кипеть, если задач наваливается слишком много. Или, как у автора треда, появляется ощущение эмоционального и, возможно, физического истощения, близкого к депрессии. Но стоит начать записывать дела в список или To-Do-лист — и жизнь сразу же налаживается. В методике GTD ты сам становишься себе менеджером: вносишь задачи, расставляешь приоритеты и освобождаешь запас когнитивного ресурса для выполнения этих дел. Максим Дорофеев в своей книге «Джедайские техники» называет этот ресурс «мыслетопливом».

«Это то, что мы расходуем, когда думаем, переключаемся между задачами и обращаемся к памяти. А любые списки — это способ разгрузки рабочей памяти».

В Scrum за управление «мыслетопливом» команды отвечает продакт-оунер (Product Owner). Именно он определяет вектор работы — что и зачем нам нужно сделать. Он помогает команде сфокусироваться на цели текущего спринта.

Разные системы планирования неизбежно пересекаются. В нашем случае общее — это подход к организации списков задач

В GTD используется идея «инбокс» — своеобразной корзины, куда попадают все входящие задачи, идеи и дела. GTD как бы говорит: 

«Освободи голову. Собери все, что требует внимания в своего рода входящий поток». 

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

На уровне бэклога продукта вполне нормально записать что-то вроде «сделать такой-то отчёт» — и это ок. Можно ещё добавить детали: что отчёт должен показывать, откуда брать данные, как их обрабатывать, и так далее. Такой уровень описания достаточен, потому что в бэклоге много задач, и пока они приоритизируются, не всегда понятно, когда конкретно эта задача попадёт в работу. Что-то вообще откладывается на потом (как в GTD с его списком «когда-нибудь», поговорим об этом далее), а что-то можно быстро закрыть вот прямо здесь.

Вернёмся к отличиям. Следующее: как приоритизировать задачи

В GTD задачи выполняются в зависимости от текущих условий. То есть если нам кажется, что именно эту задачу стоит сделать первой, то её и делаем. Это больше похоже на интуитивный подход, однако задачи всё же распределяются по категориям в зависимости от того, что это такое, и что с этим нужно сделать:

• следующие действия — конкретные шаги, которые можно выполнить прямо сейчас,

• проекты — цели, для которых требуется несколько шагов,

• ожидания — задачи, которые зависят от других людей,

• когда-нибудь — идеи, которые можно рассмотреть позже.

Ближайшие таски из категории «следующие действия» должны быть чётко сформулированы и разбиты на ближайшие шаги. Вместо расплывчатого «подготовить отчёт» лучше написать что-то вроде «собрать данные для отчёта». Ведь сам по себе «шаг» — это же действие. 

В GTD есть крутой принцип: если задачу можно не делать — просто удали её. А если на её выполнение уходит меньше 2-х минут, то сделай сразу. Многим свойственно откладывать мелкие задачи на конец дня. Но когда настанет пора уходить домой, у вас ещё останется список из 10 мелких дел, которые всё равно придётся доделывать. 

А 10 маленьких задач по 2 минуты — это уже 20 минут, плюс время на переключение, плюс непредвиденные моменты, плюс что-то еще. Всё это тратит «мыслетоплево», которого уже итак нет в конце дня. В итоге набегает целый час, но даже не это является основной проблемой.

Лирическое отступление

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

«В особо тяжелых случаях у человека формируется список дел такого размера, что все, на что он остается способен, — это паниковать, сокрушаться о нехватке времени и расставлять приоритеты (что с точки зрения пользы для дела, по сути, одно и то же)». Максим Дорофеев

Какой тут может быть совет?

Если есть что-то мелкое, что нужно срочно сделать, и ты точно не можешь это делегировать или отменить — просто сделай это. Помните про дела менее двух минут? Нужно быстро ответить на письмо клиенту — сядь и ответь. Есть небольшой баг в коде, который можно пофиксить за пару минут? Поправь его, особенно если у тебя всё покрыто тестами, и ты уверен, что ничего не сломаешь.

А как дела в скраме?

В Scrum для этой цели используется Sprint Planning (планирование спринта), который проводится в любом проекте, продукте и у любой команды.

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

Дальше начинается планирования спринта. Тем же составом мы собираемся и смотрим на эту проработанную верхушку бэклога еще раз, чтобы понять, все ли нам там понятно. Действительно же прошло два дня, могло что-то и поменяться. И если нам все понятно, то выбираем задачи, которые нам нужно выполнить в течение недели и дойти до соответствующей цели спринта.

Но мы занимается планированием спринта не только для того, чтобы декомпозировать задачи. Пока мы копаемся в деталях, мы задаём друг другу вопросы и обсуждаем, где могут возникать проблемы. Например, мы можем выяснить, что у нас нет доступа к нужному источнику данных — а раньше об этом никто не знал.

«Повторюсь, зачем мы вообще декомпозируем и разбиваем задачи на мелкие шаги — чтобы внутри спринта больше фокусироваться на том, КАК это реализовать и меньше думать о том, ЧТО нужно сделать. Для того, чтобы разобраться, ЧТО нам нужно, у нас есть груминг бэклога».

Ещё одна причина проводить совместное планирование спринта — это возможность подключить сразу нескольких человек к одной большой задаче. Это как раз та командная работа, на которой построен Scrum. Мы стараемся все вместе «накинуться» на одну задачку, чтобы быстро получить что-то, что можно потрогать, протестировать и показать на ревью. В обычном проекте каждый бы взял свою часть и ушёл с ней работать в своём направлении. Когда бы появился общий результат — вообще непонятно.

Кроме того, такой подход помогает избежать ситуаций, если одна из задач станет «узким местом» проекта. Например, если какая-то мелочь, которую мы упустили, внезапно всплывет и затормозит нам всё движение.

Ну и, конечно, стоит поговорить о том, как Scrum и GTD ведут себя в далекой перспективе. Это отличие мы назовём: горизонт планирования.

В методологии GTD масштабы планирования представлены в виде метафоры высоты высоты взлёта. Представьте, что вы в самолёте. Теперь по мере набора высоты в каждой фиксированной точке вы должны записывать пункты плана так, чтобы они соотносились с другими уровнями. И чем выше расстояние от земли, тем сложнее будет формулировать задачи. Следите за мыслью, это и правда очень не просто:

• 15 километров: самый высокий уровень. Здесь вы решаете, к чему стремитесь в целом.

• 12 километров: цели на 3-5 лет, чтобы понять, какого уровня жизни вы хотите достичь.

• 9 километров: это планы на ближайшие 1-2 года. Конкретные шаги, чтобы двигаться к целям из более высоких уровней.

• 6 километров: зоны, где требуется ваше постоянное внимание. Сюда относятся семья, работа, здоровье и всё, что вы хотите контролировать.

• 3 километров: здесь живут проекты, которые вы планируете закрыть в течение года.

• Взлётная полоса (0 км): это уровень ваших текущих задач.

В Scrum, когда мы работаем с бэклогом проекта, мы можем делать приоритизацию на месяц, квартал или даже на год. Чтобы это организовать, сначала мы выбираем из большого списка идей, что хотим сделать, например, в 2025 году. Затем уточняем, что из этого списка мы планируем сделать в первом квартале. Потом фокусируемся на задачах на ближайший месяц, скажем, в январе, а дальше уже на задачи ближайшего спринта — например, с 10 по 15 января.

В Scrum важен фокус: команда работает над одним продуктом непрерывно, избегая переключений. Это одна из ценностей Scrum, которая помогает команде быстрее добиваться результатов и деливерить продукт с высоким качеством.

Наши мозговые ресурсы должны быть все время сосредоточены на одной задаче, так как скорость переключения между ними в интеллектуальной работе очень дорогая. Нужно много «мыслетоплива», чтобы вспомнить, что уже сделано, понять контекст и глубоко продумать, как улучшить результат.

В Scrum мы стараемся отсекать задачи, которые не несут ценности. Обычно как бывает — в компании есть продукт или несколько продуктов, есть заказчики и есть владелец продукта. И все эти люди постоянно генерируют идеи. Что-то предлагают клиенты, что-то владелец продукта, и от этого бэклог постоянно раздувается.

«Фишка в том, что во всех компаниях идей всегда намного больше, чем возможностей их реализовать».

Поэтому ещё до приоритизации важно задуматься: а точно ли стоит это делать? Может, задача вообще не связана с нашим продуктом? Или она не принесет той пользы и денег, на которые мы рассчитываем? Иногда лучше просто её вычеркнуть. Мы не можем сделать всё, поэтому приходится выбирать.

В корпоративной среде заказчики часто говорят «Нет, не удаляйте эту задачу, когда-нибудь вернёмся и сделаем». Хотя всем понятно, что к ней никто никогда не вернётся, и никто её не сделает. Такое корпоративное отсутствие воли приводит к тому, что задача постоянно спускается в бэклоге, продолжая занимать место и отвлекать внимание.

Помимо банального отказа от некоторых задач, в аджайл-сообществе есть методы приоритизации, которые можно применять во время актуализации бэклога. И первая — это MOSCOW:

• Must have (обязательные)  — это самые важные элементы, без которых сам проект теряет смысл.

• Should have (важные, но не критичные) — это задачи, которые от нас ожидают получить пользователи, и они же повышают ценность продукта на рынке. 

• Could have (желательные) — это дополнительные фичи, которые могут быть полезны, но не критичны для проекта. Если их не сделать, на итоговый результат это сильно не повлияет.

• Won’t have (не будем делать) — это задачи или функции, которые мы не сделаем. Обычно это то, что не соответствует целям, слишком дорого или сложно для реализации. Да-да, снова вычеркиваем.

Вторая методика — WSJF (Weighted Shortest Job First): 

W — взвешенная,
S — кратчайшая,
Jobs First — задача в первую очередь. 

WSJF = стоимость задержки / размер работы

Стоимость задержки (Cost of Delay) состоит из трех элементов:

1. Бизнес-ценность

2. Критичность по времени

3. Факторы риска или открытия возможностей

Таким образом, формула WSJF в развернутом виде выглядит так:

WSJF = (Бизнес-ценность + Критичность по времени + Факторы риска или открытия возможностей) / Размер работы

Методика работает по принципу: чем выше соотношение «ценность задачи/затраченные усилия», тем раньше задача берётся в работу. То есть, грубо говоря, мы оцениваем, сколько нам это принесёт или сэкономит, и делим на то, сколько усилий потребуется. Подробнее можете почитать о модели приоритезации WSJF в нашем блоге.

Ещё одно заметное различие: подведение итогов и оценка результата

В GTD мы «собираем обратную связь» через личную рефлексию и еженедельные обзоры, которые, по словам Дэвида Аллена, играют ключевую роль в успешной работе его системы. На это даётся 30-60 минут, чтобы проанализировать прошедшую неделю, запланировать следующую и проверить, все списки задач и проекты актуальны. То есть рефлексия + анализ + актуализация.

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

Второе событие — ретроспектива. Это как раз рефлексия, как прошёл спринт, что сработало, и что можно улучшить в нашем процессе работы. Думаю, про неё мы напишем отдельную статью.

Последнее отличие, на которое хотелось бы обратить внимание: ритм работы

Вернёмся к исходному треду. Герой упомянул, что сначала у него были двухнедельные спринты, потом недельные, а потом он стал делать их плюс-минус на несколько дней. В контексте GTD это, возможно, и нормально, но в проектной работе так не делают, потому что нарушается ритм, а он для команды очень важен.

Люди привыкли жить ритмично: у нас есть года, смена сезонов, день и ночь, которые всегда начинаются в одно и то же время. Поэтому и работу лучше организовывать так, чтобы она шла в стабильном и понятном ритме. Длина спринта туда-сюда не ездит.

Двухнедельные спринты всегда двухнедельные, пока команда не решит, что это слишком долго. Например, если нам хочется чаще получать промежуточные результаты и обратную связь, мы можем перейти на недельные спринты. Но важно, что после такого перехода мы продолжаем работать в этом ритме. Плюс-минус один день не делаем.

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

Что же получается, это и не Scrum, и не GTD, а что тогда?

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

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

Даже учебники иногда переписывают, поэтому не отказывайте себе в удовольствии искать своё, пробовать новое и находить то, что сработает именно для вас. ^{[Реклама удалена мод.]}