Что делать с незапланированной работой?

Перевод оригинальной статьи.

«Как поступать с незапланированной работой?» - такой вопрос я довольно часто слышу в командах, с которыми работаю. И ответ на него совсем не так прост, как может показаться на первый взгляд. Прежде всего нужно понимать: незапланированная работа редко является проблемой сама по себе. Обычно она лишь симптом реальных проблем, которые скрыты от посторонних глаз. Крайне важно выяснить, откуда берется незапланированная работа. Только тогда возможно будет разобраться с первопричиной подходящим методом. Или же просто раз и навсегда смириться с появлением незапланированной работы и научиться с этим жить (как ни удивительно, но во многих случаях это самый разумный вариант).

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

Несмотря на то, что рекомендации из данной статьи применимы к любому итеративному процессу разработки, далее для простоты я буду использовать терминологию Scrum. В конце концов, согласно «State of Agile» именно Scrum является самым распространенным гибким методом. По той же причине будут использоваться термины «пользовательские истории – user story» и «производительность – velocity».

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

Решения «на ходу» и заплатки

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

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

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

2. Отделить и перенести.

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

Суть стратегии. Завершите пользовательскую историю, как было запланировано изначально. Отделите все дополнительные требования в виде новой пользовательской истории и запланируйте на предстоящие спринты.

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

Область применения. Текущий и несколько последующих спринтов.

Тип действия. Решение «на ходу».

Затраты и риски. Большой объем новых требований скорее всего говорит о том, что новый функционал действительно важен. И выпуск только ранее запланированной пользовательской истории более не имеет смысла для конечного пользователя. Стейкхолдеры будут недовольны тем, что выпуск полноценной фичи, которую они хотели на самом деле (включая и первоначальные, и новые требования), может быть отложен на спринт. В то же время нередки случаи, когда новая пользовательская история оказывается не такой уж критичной, как казалось на первый взгляд. В таком случае новая незапланированная работа может спокойно подождать еще несколько спринтов. Так или иначе, за установление правильных ожиданий у стейкхолдеров ответственным является Product Owner.

3. Заменить.

Пример 3.1. На второй неделе спринта стейкхолдеры сообщают о критическом дефекте. Становится ясно, что исправить его будет непросто. По оценкам разработчиков, это займет много времени. Но у команды нет выбора. Они начинают исправлять дефект.

Пример 3.2. В середине спринта Product Owner приходит к команде с запросом. Обнаружено, что новая фича должна быть завершена с самым высоким приоритетом, и Product Owner просит добавить ее в текущий спринт.

Суть стратегии. Добавьте новую пользовательскую историю или дефект в текущий спринт. Решите, каким другим элементом бэклога того же размера можно пожертвовать, и удалите его из текущего спринта. Удаленные элементы можно поместить в начало бэклога или сразу же запланировать на следующий спринт.

Когда применять. Использование этой стратегии достаточно прямолинейно. Всякий раз, когда решили добавить в текущий спринт достаточно большую часть незапланированной работы, удалите из спринта что-то такого же размера. Сразу напрашивается вопрос: как определить, незапланированная работа «достаточно большая»? Product Owner вам на этот вопрос не ответит. Ответственность за принятие такого решения лежит на команде разработки.

Область применения. Текущий и несколько последующих спринтов.

Тип действия. Действие «на ходу».

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

4. Запланировать буфер.

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

.

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

Суть стратегии. Во время планирования спринта резервируйте в бэклоге буфер (свободное место) для незапланированной работы. Есть два способа создать буфер. Во-первых, можно спланировать виртуальный элемент бэклога определенного размера, который будет учитываться в расчете скорости команды. Это будет буфером для незапланированной работы. Каждый раз, когда новая пользовательская история или работа над ошибкой будет попадать в текущий спринт, работа над ними будет вычитаться из свободного места в буфере, пока он не закончится. После этого вся новая незапланированная работа должна отклоняться командой и помещаться в бэклог. Во-вторых, можно запланировать в спринт меньше элементов бэклога, чем обычно рассчитывается к планированию исходя из скорости команды. В таком случае, в течение спринта есть возможность добавлять новую незапланированную работу. Эта разница между средней скоростью команды и прогнозируемой скоростью команды будет работать как косвенный буфер.

Когда применять. Используйте буфер в случае, когда: ситуация повторяется и незапланированная работа по сути неизбежна, а размер незапланированных пользовательских историй существенен. Например, команда обладает уникальными знаниями и опытом и должна консультировать другие команды; колебания рынка затрудняют составление надежных прогнозов даже на пару недель. Проверенное правило для применения этой стратегии - буфер для незапланированной работы не должен занимать более 20-30% производительности команды, и в то же время цели спринта должны оставаться достижимыми.

Область применения. В течение жизненного цикла продукта.

Действия. Быстрое и временное решение.

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

Процесс постоянных улучшений

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

5. Улучшить приоритезацию.

Пример 5.1. Команда завершает планирование спринта. Через три дня после начала спринта Product Owner дает команде кучу новых пользовательских историй, с сообщением о том, что приоритеты неожиданно изменились. В итоге, в конце спринта возникает ситуация, когда у команды ничего не готово.

Пример 5.2. Через пару дней после начала спринта Product Owner принимает решение включить в спринт новую пользовательскую историю, так как некоторые стейкхолдеры просят срочно ее исполнить. Еще через пару дней Product Owner принимает аналогичное решение, так как уже другой стейколдер просит незамедлительно взять новую пользовательскую историю в работу. Такая ситуация повторяется несколько раз за спринт, и результат не вызывает удивления: в конце спринта команда выложилась лишь в половину своей обычной производительности.

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

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

Область применения. Жизненный цикл продукта.

Действия. Устранение глубинной причины незапланированной работы.

Затраты и риски. Потребуется обучение Product Owner и взаимодействие со стейкхолдерами. Это может оказаться непростой задачей, поскольку связано с влиянием на поведенческую модель. Не стоит ожидать быстрых результатов.

6. Улучшить качество.

Пример 6.1. Команда получает множество сообщений об ошибках в течение спринта. Многие из них кажутся критическими и требуют немедленного исправления. На ретроспективе команда приходит к осознанию, что ситуация с ошибками повторяется из спринта в спринт. Ошибки становятся серьезной помехой. Они нарушают рабочий поток и влияют на поставку. Это можно явно проследить на диаграмме сгорания задач и на диаграмме производительности. Спринты кажутся хаотичными. Команда теряет чувство контроля над работой.

Суть стратегии. Проанализируйте причины низкого качества, например, с помощью диаграмм причинно-следственных связей (Causal Loop Diagrams). Может причиной тому сильное давление бизнеса на команду, и поэтому команда вынуждена экономить на качестве, чтобы уложиться в сроки? Или причина в низком покрытии автотестами? А может это связано с инфраструктурной проблемой, из-за которой время от времени приложение не доступно? Как только источники постоянных ошибок будут определены, уделите достаточно времени на их устранение. Попробуйте разные стратегии. Чаще всего случается так, что источников постоянных ошибок несколько, и требуются разные подходы для их устранения.

Когда применять. Довольно нетрудно понять, когда низкое качество является проблемой. Во время спринтов чаще возникают критические ошибки. Они нарушают рабочий поток и достижение целей спринта становится практически невозможным.

Область применения. В течение жизненного цикла продукта.

Действия. Устранение глубинных причин незапланированной работы.

Затраты и риски. Найти источник дефектов может быть непросто. Еще сложнее их исправить. Если число критических ошибок начинает нарушать рабочий поток, то скорее всего это следствие накопленного эффекта неправильных решений. И потребуются серьезные усилия для того, чтобы исправить ситуацию. Это приведет к замедлению поставки, в некоторых случаях – она почти остановится. На этом этапе команде придется решить дилемму. Хотят ли они устранить проблему (жертвуя производительностью) и вернуть продукт в легко поддерживаемое состояние? Или же пойдут на риск и будут надеяться, что смогут устранять дефекты до конца жизненного цикла продукта? Если команда выберет второй вариант, ей придется вернуться к стратегии планирования буфера. Тем не менее, стоит помнить - замедление команды, вызванное снижением качества может превысить замедление, вызванное исправлением дефектов быстрее, чем вы ожидаете.

7. Устранить зависимость.

Пример 7.1. Как и в примере 4.2, бэкенд системой владеет команда экспертов. Команда разработчиков недавно начала разрабатывать новый микросервис. Этот микросервис использует бэкенд часть в качестве источника данных. Через некоторое время разработчики понимают, что в бэкенд части не хватает большого количества необходимых данных. Запросы на внедрение (например, эндпоинта) становятся слишком частыми и начинают заметно отвлекать команду экспертов.

Пример 7.2. Команда владеет инфраструктурой системы. К ним постоянно поступают запросы от других команд. Типичным запросом является обновление настроек подсистемы и пересборка приложения. Такие запросы достаточно легко решаются, но их очень много и они отнимают время.

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

Во-вторых, подбирайте технологические способы сокращения зависимостей между командами. Без этого решения многие из упомянутых выше шагов невозможны. Разделение подсистем само по себе поможет командам стать более независимыми. Применительно к примеру 7.2, зависимая команда смогла бы перенести некоторые встроенные параметры в конфигурируемые. И в результате смогла бы самостоятельно настраивать параметры приложения без участия команды инфраструктуры.

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

Область применения. В течение жизненного цикла продукта.

Действия. Устранение глубинных причин незапланированной работы.

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

8. Адаптировать процесс.

Пример 8.1. У команды в течение спринта постоянно случаются заминки, и в их работу вмешиваются. Цели спринта устаревают, а бэклог спринта может полностью меняться несколько раз за спринт. Незапланированная работа, в основном, поступает от Product Owner. Тщательный анализ причин такой ситуации показывает, что команда ничего не может с этим поделать. И дело в том, что команда разрабатывает продукт в инновационной отрасли, где существует жесткая конкуренция. Задержка поставки критической функции даже на несколько дней может полностью вывести компанию из бизнеса.

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

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

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

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

Действия. Исправление основной причины.

Перспектива. Уклонение от основной причины.

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