В нашей LinkedIn-группе, Agile Requirements & Quality, появился вопрос о том, как эффективно управлять очередями требований в Scrum. В частности, как предотвращать эффект длинных, а значит, плохоуправляемых и плохопредсказуемых очередей (см. пост посвященный обсуждению эффекта длинной очереди), из-за которых очень сложно и часто просто невозможно вложиться в заданные самой же командой временные рамки.
Опишем интересующую нас ситуацию как можно более обобщенно, чтобы мы могли применить решение в разнообразных процессных моделях. Для этого, вместо рассмотрения только случая со Scrum, мы возьмем гораздо шире, и даже шире, чем семейство Agile-методов. А именно, будем рассматривать все процессы, в которых доставка может делаться часто - от нескольких дней, до 2-3 недель (мы говорим "может", поскольку часто речь идет о методах, где "внутреняя доставка" происходит более часто, чем "внешняя", конечному пользователю). Очевидно, сюда попадает Scrum, где доставка производится каждые две недели (или же "внутренняя" - каждые 2 недели, а внешняя, возможно, как результат нескольких спринтов). Сюда попадает XP и другие Agile-методы (Crystal, DSDM, ...). Сюда подпадает Kanban, где доставка делается либо сразу же по ходу завершения задачи, или же по заданному (1 или 2-х недельному) ритму. Сюда даже может попасть некий вариант Cowboy Coding, только бы доставка делалась часто. Некая широкая категория процессов с частой доставкой, причем доставляется конечная ценность (обычно это работающая функциональность системы). Эти процессы в некотором смысле противоположность пофазному процессу, где все требования проходят сквозь систему один раз, одним большим пакетом.
В каждом из таких "быстрых" процессов можно вести речь о бэклоге или его подобии - входной очереди ценных с точки зрения пользователя или стэйкхолдеров задач, возможно, с заданными предпочтениями одних задач перед другими. Что конкретно находится в бэклоге, нас тоже интересовать сейчас не будет, главное, что это "элементы ценности", а в каком виде они представлены - пользовательских историй или же сценариев или фич или MMF или запросов на изменение в любом формате или дефектов - не столь важно в данный момент.
На практике часто получается удивительная ситуация: методы как бы и "быстрые", но стейкхолдеры этого могут совершенно не ощущать и не испытывать отнюдь ни малейшей радости от процесса. Причина - плохая предсказуемость процесса. А получается так потому, что входная очередь (бэклог) совершенно неправильно управляется и понимается. Типичный сценарий в Scrum, например: владелец продукта, по просьбе одного из стейкхолдеров помещает в бэклог определенную задачу. Для стейкхолдера это звучит как обещание того, что о его задаче вскоре обязательно позаботятся, тогда как добавление задачи в и без того уже разросшийся бэклог не будет de facto подразумевать ровным счетом ничего. Задача может пролежать очень долго, пока до нее дойдет очередь с одной стороны потому, что длинная очередь, как мы раньше видели - это огромная вариация по времени, а с другой - постоянная переприоритезация может еще дальше отсрочивать задачу. Ну а если мы ставим ее сразу в главу очереди, то подобному эффекту поддается не она, а другие задачи, которые она вытеснит...
Первое, что важно понимать, чтобы работа с бэклогом приносила пользу, а не расстройство для вовлеченных сторон:
Эффективный бэклог - это не столько список задач, как надежное средство управления ожиданиями стейкхолдеров. При работе с бэклогом крайне важно умение достигать (иногда весьма сложных) соглашений с ключевыми заинтересованными лицами о том, что попадет к пользователю в ближайшее время, а что нет.
Для того, чтобы бэклог стал "работать", нужна весьма простая вещь, которая, тем не менее, может быть болезненной во многих случаях, обнажая целый ряд проблем с управлением ожиданий:
Входная очередь (бэклог) должна быть существенно ограничена. Эта очередь и ее жесткое ограничение по размеру должно быть известно всем стейкхолдерам и быть частью правил игры. В таких условиях управление бэклогом будет производиться прозрачно для всех и ожидания будут соответствовать действительным возможностям команды по доставке.
Всегда интересен вопрос, насколько ограниченной должна быть очередь. Ответ сильно зависит от контекста, но предоставим, тем не менее, некоторые идеи определения длины входной очереди. Рассмотрим примеры:
1) Команда производит поддержку системы (скажем, применяя Канбан), устраняет дефкты на проде, доставляет еженедельно или же сразу по мере критичности дефекта. В таком случае входная очередь, содержащая объем задач, приблизительно требующий 2 недели работы команды может быть близким к оптимальному. Хотя может быть и короче, если новые дефекты возникают часто, в противоположность случаю, когда новых дефектов не так много, а есть "запас" ранее обнаруженных.
2) Scrum-команда, работающая над новым продуктом. Очень удобно входную очередь отождествлять с бэклогом релиза - обычно это несколько спринтов, 2-6. Если команда релизит после каждого спринта, входная очередь может быть ограничена до приблизительного объема на 2 спринта вперед.
3) Cowboy coding. 5-10 задач, над которыми типично работает команда, чтобы было легко следить за происходящим.
Общая идея метода наверняка уже стала читателю очевидной: если ритмы внутренней и внешней доставки совпадают - тогда входная очередь может содержать объем на две ближайших поставки, если ритмы не совпадают и, соответственно, внутренний ритм чаще, то входная очередь может описывать как раз одну внешнюю доставку. Читатель наверняка уловил общую идею того, что такого рода бэклог (объем) достаточно легко проецируется на график доставки (время), эта возможность "вшита" в сам способ построения такого бэклога и его поддержки.
Однако это только общие примеры, "подгонку" команда все равно делает самостоятельно.
Важно также добавить, что бэклог - не единственный способ управления ожиданиями, вместе с ним могут использоваться и другие методы на иных уровнях абстракции. Например, очень полезно использовать бэклог на релиз, как основную текущую очередь (с обязательствами!), но при этом на более высоком уровне абстракции оперировать с дорожной картой.
На дорожной карте обычно грубо указан доставляемый объем на 2-3 релиза вперед и используется просто как вспомогательное средство, помогающее понять, куда мы движемся с нашим продуктом, но не предусматривающее, что очень важно, обязательств.
Опишем интересующую нас ситуацию как можно более обобщенно, чтобы мы могли применить решение в разнообразных процессных моделях. Для этого, вместо рассмотрения только случая со Scrum, мы возьмем гораздо шире, и даже шире, чем семейство Agile-методов. А именно, будем рассматривать все процессы, в которых доставка может делаться часто - от нескольких дней, до 2-3 недель (мы говорим "может", поскольку часто речь идет о методах, где "внутреняя доставка" происходит более часто, чем "внешняя", конечному пользователю). Очевидно, сюда попадает Scrum, где доставка производится каждые две недели (или же "внутренняя" - каждые 2 недели, а внешняя, возможно, как результат нескольких спринтов). Сюда попадает XP и другие Agile-методы (Crystal, DSDM, ...). Сюда подпадает Kanban, где доставка делается либо сразу же по ходу завершения задачи, или же по заданному (1 или 2-х недельному) ритму. Сюда даже может попасть некий вариант Cowboy Coding, только бы доставка делалась часто. Некая широкая категория процессов с частой доставкой, причем доставляется конечная ценность (обычно это работающая функциональность системы). Эти процессы в некотором смысле противоположность пофазному процессу, где все требования проходят сквозь систему один раз, одним большим пакетом.
В каждом из таких "быстрых" процессов можно вести речь о бэклоге или его подобии - входной очереди ценных с точки зрения пользователя или стэйкхолдеров задач, возможно, с заданными предпочтениями одних задач перед другими. Что конкретно находится в бэклоге, нас тоже интересовать сейчас не будет, главное, что это "элементы ценности", а в каком виде они представлены - пользовательских историй или же сценариев или фич или MMF или запросов на изменение в любом формате или дефектов - не столь важно в данный момент.
На практике часто получается удивительная ситуация: методы как бы и "быстрые", но стейкхолдеры этого могут совершенно не ощущать и не испытывать отнюдь ни малейшей радости от процесса. Причина - плохая предсказуемость процесса. А получается так потому, что входная очередь (бэклог) совершенно неправильно управляется и понимается. Типичный сценарий в Scrum, например: владелец продукта, по просьбе одного из стейкхолдеров помещает в бэклог определенную задачу. Для стейкхолдера это звучит как обещание того, что о его задаче вскоре обязательно позаботятся, тогда как добавление задачи в и без того уже разросшийся бэклог не будет de facto подразумевать ровным счетом ничего. Задача может пролежать очень долго, пока до нее дойдет очередь с одной стороны потому, что длинная очередь, как мы раньше видели - это огромная вариация по времени, а с другой - постоянная переприоритезация может еще дальше отсрочивать задачу. Ну а если мы ставим ее сразу в главу очереди, то подобному эффекту поддается не она, а другие задачи, которые она вытеснит...
Первое, что важно понимать, чтобы работа с бэклогом приносила пользу, а не расстройство для вовлеченных сторон:
Эффективный бэклог - это не столько список задач, как надежное средство управления ожиданиями стейкхолдеров. При работе с бэклогом крайне важно умение достигать (иногда весьма сложных) соглашений с ключевыми заинтересованными лицами о том, что попадет к пользователю в ближайшее время, а что нет.
Для того, чтобы бэклог стал "работать", нужна весьма простая вещь, которая, тем не менее, может быть болезненной во многих случаях, обнажая целый ряд проблем с управлением ожиданий:
Входная очередь (бэклог) должна быть существенно ограничена. Эта очередь и ее жесткое ограничение по размеру должно быть известно всем стейкхолдерам и быть частью правил игры. В таких условиях управление бэклогом будет производиться прозрачно для всех и ожидания будут соответствовать действительным возможностям команды по доставке.
Всегда интересен вопрос, насколько ограниченной должна быть очередь. Ответ сильно зависит от контекста, но предоставим, тем не менее, некоторые идеи определения длины входной очереди. Рассмотрим примеры:
1) Команда производит поддержку системы (скажем, применяя Канбан), устраняет дефкты на проде, доставляет еженедельно или же сразу по мере критичности дефекта. В таком случае входная очередь, содержащая объем задач, приблизительно требующий 2 недели работы команды может быть близким к оптимальному. Хотя может быть и короче, если новые дефекты возникают часто, в противоположность случаю, когда новых дефектов не так много, а есть "запас" ранее обнаруженных.
2) Scrum-команда, работающая над новым продуктом. Очень удобно входную очередь отождествлять с бэклогом релиза - обычно это несколько спринтов, 2-6. Если команда релизит после каждого спринта, входная очередь может быть ограничена до приблизительного объема на 2 спринта вперед.
3) Cowboy coding. 5-10 задач, над которыми типично работает команда, чтобы было легко следить за происходящим.
Общая идея метода наверняка уже стала читателю очевидной: если ритмы внутренней и внешней доставки совпадают - тогда входная очередь может содержать объем на две ближайших поставки, если ритмы не совпадают и, соответственно, внутренний ритм чаще, то входная очередь может описывать как раз одну внешнюю доставку. Читатель наверняка уловил общую идею того, что такого рода бэклог (объем) достаточно легко проецируется на график доставки (время), эта возможность "вшита" в сам способ построения такого бэклога и его поддержки.
Однако это только общие примеры, "подгонку" команда все равно делает самостоятельно.
Важно также добавить, что бэклог - не единственный способ управления ожиданиями, вместе с ним могут использоваться и другие методы на иных уровнях абстракции. Например, очень полезно использовать бэклог на релиз, как основную текущую очередь (с обязательствами!), но при этом на более высоком уровне абстракции оперировать с дорожной картой.
На дорожной карте обычно грубо указан доставляемый объем на 2-3 релиза вперед и используется просто как вспомогательное средство, помогающее понять, куда мы движемся с нашим продуктом, но не предусматривающее, что очень важно, обязательств.
