Все статьи
Как жить с нежданчиками в SAFe®
Дата: 05.02.2024
Как эффективно управлять операционными и незапланированными задачами в Scaled Agile Framework® (SAFe®).
В мире Agile мы давно проповедуем переход от проектного к продуктовому мышлению. «Разве мир не был бы проще, если бы мы просто говорили о работе, а не о проектах и BAU?» – эту мантру можно услышать из уст многих Agile-практиков (прим. пер. – BAU, Business As Usual, операционная работа).
Сформировать команды и поезда (прим. пер. – ART, Agile Release Train), которые «просто делают самую важную работу, независимо от ее характера» – это важная цель, но у нее есть ряд проблем:
- Бюджетирование и учет затрат, как правило, существенно различаются для проектов и продуктов.
- Командам сложно планировать и брать обязательства, если часть (а иногда и большая часть) их задач влетает незапланированно.
Крупные компании как правило решают эту проблему путем изменения оргструктуры. Обычно первым шагом по внедрению Agile является переход от операционной модели «Plan, Build, Run» (прим. пер. – планирование, реализация, эксплуатация) к модели разделения «Plan & Build» от Run. Проекты реализуются в «Plan & Build», а затем через некоторый гарантийный период переходят в Run. Бюджетирование осуществляется раздельно, а Run больше зависит от SLA (прим. пер. – Service Level Agreement, соглашение об уровне сервиса), чем от планов.
По-настоящему ориентированное на продукт мышление требует создания команд и ART, которые сами могут «планировать, реализовать и поддерживать», и в этой статье мы подробно посмотрим на планирование и взятие обязательств, а также рассмотрим некоторые инструменты для решения вопроса бюджетирования.
Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.
Бюджетирование
Если существуют разные типы элементов бэклога, их же можно использовать для бюджетирования. Далее мы берем burn rate команды (прим. пер. – стоимость команды каждый месяц), процент ее ресурсов, выделенных на каждый тип, и соответствующим образом распределяем бюджеты.
Планирование
Кажется, что и PI в SAFe и итерации в Scrum не позволяют работать с BAU. Мы фиксируем наши приоритетные Фичи в SAFе на 8-12 недель и наши приоритетные пользовательские истории на 2 недели в Scrum, но что нам делать с незапланированными задачами?
На самом деле наперед известные BAU-задачи можно запланировать в виде задач бэклога, а вот чтобы управлять незапланированными задачами, нужно эффективно распределять ресурсы команды. Мы просто резервируем определенный процент ресурсов команды (или поезда) на незапланированные задачи, а оставшиеся ресурсы планируем как обычно.
Planning Interval (PI, Интервал Планирования) — это регулярный повторяющийся временной интервал, за который Agile Release Train (ART) непрерывно поставляет ценность клиентам в соответствии с Целями Интервала Планирования (PI-целями).
Итерации — это стандартный временной отрезок фиксированной длительности, в течение которого Agile-команды и ART по отдельности и совместно обеспечивают прирост потребительской ценности, работая над достижением PI-целей.
SAFe Scrum (Скрам-команды в SAFe) — это Agile-метод, применяемый командами ART для поставки ценности клиенту в короткие сроки. Скрам-команды в SAFe используют итерации, Канбан-систему и Скрам-события для планирования, выполнения, демонстрации и ретроспективы своей работы.
Фича представляет собой функциональность решения, которая несет ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, что она может быть реализована одним Agile Release Train в рамках одного Интервала Планирования (Planning Interval, PI).
Бэклог Команды — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.
Пример на уровне команды: дефекты на продуктиве
Одно из главных преимуществ постоянных продуктовых (прим. пер. – а не проектных) команд заключается в том, что мы можем вернуть дефекты на продуктивном окружении команде, которая их и породила. Так они получают ценную обратную связь, которая обычно значительно улучшает качество продукта.
Например, можно зарезервировать для таких дефектов 10% ресурсов команды. Тогда, если скорость команды равна 40 стори поинтов, они должны запланировать только 36, а 4 – зарезервировать на исправление дефектов.
Далее происходит следующее:
- Если дефектов меньше, чем на 4 стори поинта, команда вытягивает задачи из следующего спринта.
- Если дефектов больше, чем на 4 стори поинта, Владелец Продукта принимает решение: отложить работу над новой фичей или отложить низкоприоритетные дефекты.
Я предпочитаю использовать немного другую технику. Мы резервируем 10% на дефекты и инновации. Если команда выпустила чистый код без дефектов, они могут работать над своими инновационными идеями, а не вытягивать следующие задачи из бэклога!
Стори Поинт (Story Point) — это целое относительное число, используемое для оценки пользовательских историй с точки зрения объема, сложности, знаний и неопределенности.
Владелец Продукта (Product Owner, PO) — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Пример на уровне ART: BAU-задачи
При укомплектовании ART мы часто сталкиваемся с ситуацией, когда некоторые (или многие) из ключевых сотрудников доступны только «если они оставляют за собой свои BAU-задачи». В этих случаях мы, во-первых, планируем наперед известные BAU-задачи, а во-вторых, резервируем некоторый процент их ресурсов, который, по нашему мнению, необходим для «незапланированных BAU-задач», и учитываем это при планировании PI.
Управление незапланированными задачами на уровне ART/PI имеет более серьезные последствия. Здесь тоже применим описанный ранее подход к планированию дефектов как в итерациях, однако, важно отслеживать потенциальное влияние на PI-цели.
- Если в команду поступает меньше ожидаемого объема незапланированных задач, у нас есть возможность либо использовать свободные ресурсы, чтобы помочь другим командам в достижении их PI-целей, либо взять в работу Фичи, которые планировались на будущие PI.
- Если поступает больше ожидаемого объема, мы смотрим, как это влияет на PI-цели, по которым команда взяла обязательства. Мы можем пожертвовать ресурсами, выделенными для рискованных PI-целей (прим. пер. – Uncommitted PI Objectives, PI-цели, реализацию которых команда запланировала, но есть значительный внешний риск в достижении цели), но если под угрозой обязательные PI-цели, это является триггером для принятия решения на уровне менеджмента: откладываем/отменяем незапланированные задачи или ставим под угрозу обязательные PI-цели из-за важности незапланированных задач.
PI Objectives (Цели Интервала Планирования, PI-цели) — это высокоуровневое описание бизнес- и технологических целей, которые команды и поезда собираются достичь в предстоящем Интервале Планирования.
Дисциплина – наше все
Использование этих приемов быстро станет вызовом, ведь команды обычно небрежно относятся к BAU и незапланированным задачам. Они их просто делают, а усилия на создание, оценку и работу с элементами бэклога видят как ненужные накладные расходы. Поэтому они остаются без прозрачности, которая просто необходима для проактивного принятия решений, как в примере выше, а также когда в конце итерации или PI приходится извиняться за невыполненную PI-цель, «потому что BAU был больше, чем ожидалось» без каких-либо достоверных данных, подтверждающих это, и что еще более важно, не давая Владельцу Продукта/Менеджеру Продукта/Представителю Бизнеса возможность вовремя вмешиваться и отклонять незапланированную работу, чтобы команда могла работать над обязательными PI-целями.
Кроме того, я считаю, что большинство команд сильно недооценивают ресурсы, которые нужно закладывать на BAU-задачи. Мне регулярно встречались команды, которые закладывали только 30% ресурсов на BAU, а потом, когда они в конце концов не выполняли все PI-цели и начинали отслеживать свою фактическую работу с BAU, обнаруживали, что она составляет 50-60%.
Однако, настоящая польза дисциплины заключается в том, что генерируемые данные — это золотое дно.
Продуктовый Менеджмент (Product Management) отвечает за определение и поддержку разработки востребованных, осуществимых, жизнеспособных и устойчивых продуктов, удовлетворяющих потребностям клиентов на всем жизненном цикле продукта.
Представители Бизнеса (Business Owners) — ключевые заинтересованные лица ART, которые несут решающую ответственность за технологическую и бизнес-основу возврата инвестиций (Return on Investment, ROI), управления и нормативно-правового контроля (Сompliance).
Почувствуйте преимущества дисциплины
Первое преимущество дисциплины заключается в получении точного понимания объема своих ресурсов и, соответственно, способности более уверенно брать на себя обязательства и выполнять их. Но как только вы начнете анализировать получаемые данные, у вас появится намного большее преимущество. Ключевым первым шагом является понимание понятий failure demand (прим. пер. — необходимость исправлять ошибки) и value demand (прим. пер. — пользователи хотят новый функционал).
Исправьте дефекты или дайте фичу
Failure demand – это спрос, вызванный неспособностью что-то сделать или сделать что-то правильно для клиента.
Первый пример Failure demand я узнал много лет назад в контексте контактных центров. Помните второй и третий телефонные звонки, которые операторы контакт-центра должны сделать, потому что проблема клиента не была полностью решена при первом звонке? Если мы возьмем типичную Agile-команду или ART, то тоже можем найти множество примеров:
- Дефект, обнаруженный на поздней стадии разработки, вызван неспособностью «встроить качество» (прим. пер. – Built-In Quality, встроенное качество).
- Дефект, обнаруженный в продуктивном окружении, возник из-за невозможности развернуть качественный продукт.
- Запрос информации возник, когда мы не предоставили эту информацию заранее или не рассказали, где она опубликована.
- Проблема часто возникает из-за неспособности эффективно снизить риск.
- Время, потраченное на напоминания или обсуждения своего недовольства проблемами, тоже является примером failure demand, поскольку более эффективное установление понимания причины и четкое установление ожиданий позволили бы избежать этого.
Управление политикой невыполненных обязательств является результатом как не выполнения обязательства, так и неспособности эффективно управлять возможностью того, что это обязательство не будет выполнено.
Value demand – это требования клиентов, которых мы «хотим», и именно поэтому мы занимаемся бизнесом.
Value demand очевиден для команд и ART – это фичи и пользовательские истории, над которыми работают команды! Тем не менее, нюансы возникают очень быстро:
- Выполняется ли работа над улучшением Value demand? Наш клиент, вероятно, не просил об этом напрямую. На самом деле, многие инициативы по улучшению фактически являются failure demand, поскольку они основаны на устранении предыдущих ошибок.
- Большая часть BAU/незапланированной работы ошибочно воспринимается как value demand. «Я запускаю этот скрипт каждое утро», «Мы создаем и консолидируем этот отчет каждый месяц» – все это отличные примеры. Теоретически для кого-то существует ценность от скрипта или отчета, но потребность в выделении ресурсов для него возникает из-за неспособности его автоматизировать или неспособности исправить сломанный процесс.
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Встроенное Качество (Built-In Quality) — это практики, которые на протяжении всего процесса создания ценности для клиента обеспечивают соответствие результатов работы Agile-команд действующим стандартам качества в технической части и бизнес-домене.
Пользовательские Истории (User Stories) — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.
Инсайты из модели спроса
Допустим, мы достаточно дисциплинированны – мы добавляем все требования к команде в их бэклог и дальше соответствующим образом классифицируем эти требования как failure demand или value demand. Тогда мы можем начать добиваться значительных улучшений на следующей основе:
- Если я уменьшу failure demand, у меня будет больше ресурсов на value demand.
- Если я найду более эффективный способ прогнозировать value demand, у меня будет больше ресурсов на value demand.
- Тип 1: Устранение проблем – Реактивное решение проблем, основанное на быстрой реакции на немедленные симптомы.
- Тип 2: Отклонение от стандарта – Структурированное решение проблемы, сосредоточенное на определении проблемы, постановке целей, анализе основных причин, контрмерах, проверках, стандартах и последующих действиях.
- Тип 3: Целевое состояние – Непрерывное улучшение, выходящее за рамки текущей производительности стабильного процесса или потока создания ценности. Оно направлено на системное устранение потерь, перегрузок, неравномерностей и других проблем, а не на решение одной конкретной проблемы.
Когда вы формируете хорошую Agile-команду, их умение помогать друг другу, сплачиваться вокруг проблем и переходить от индивидуальной работы к командной, как правило, демонстрирует, как они умеют справляться с проблемами, особенно в случае незапланированной работы. Хорошие навыки устранения проблем имеют основополагающее значение для любой команды.
Чтобы решить каждую проблему с помощью более глубокого подхода через анализ первопричины, потребуется отслеживать и управлять списком проблем, длина которого буквально составляет сотни миль. Ни одна организация не может провести столько совещаний по решению проблем… эффективно.
Для большинства failure demand мы используем метод устранения проблем (прим. пер. – тип 1). Однако, это всего лишь поможет нам выжить в обычных условиях, но не поможет изменить что-то к лучшему. Изменения требуют стратегии решения проблем 2-го типа. Мы должны проанализировать наши данные, чтобы найти повторяющиеся проблемы и устранить их основную причину failure demand. Смолли уделяет большое внимание определению проблемы и начинает с двух важных советов, когда определяет границы проблемы.
- Первый шаг – прояснить первоначальный контекст проблемы, используя факты и данные, чтобы показать разрыв между тем, как все должно быть (текущий стандарт) и тем, как оно есть на самом деле (текущее состояние).
- Почему эта проблема требует времени и ресурсов? Как это связано с приоритетами организации? Стремитесь показать, почему проблема имеет значение, иначе люди могут не обратить внимания или подвергнуть сомнению усилия по решению проблемы.
Как только мы добились успеха в снижении failure demand с помощью стратегии 2-го типа, мы можем перейти к стратегии 3-го типа, чтобы внедрить активности для создания нового целевого состояния. Если мы точно понимаем, какие ресурсы выделяются для различных типов value demand, мы можем более точно оценить, оправдывает ли создаваемая ценность потраченные ресурсы, что приводит к непрерывному осознанному совершенствованию. PMO (прим. пер. – Project Management Office, проектный офис), с которым мы работали, недавно привел прекрасный пример.
Исторически сложилось, что к каждому проекту, который запускался в компании, они применяли процесс контроля качества. Этот процесс, конечно, рассматривался как BAU, и его нужно было делать каждый раз, когда проект проходил определенную фазу жизненного цикла. Когда они собрали данные о том, сколько ресурсов фактически тратится на этот процесс, они начали сомневаться в его ценности. Как часто проверка качества действительно выявляла проблемы? Каковы были последствия выявленных проблем? Какие другие ценные задачи не удалось выполнить из-за нехватки ресурсов? В итоге они смогли принять обоснованное решение и перейти к выборочной проверке качества, высвободив больше ресурсов для реализации других более важных инициатив.
Заключение
Аллокация ресурсов – это то, что позволяет справляться с незапланированной работой и BAU. Но, как показывает мой опыт, этого никогда не достаточно, если у вас нет дисциплины формально управлять этой работой через бэклог. Здесь от вас может потребоваться немного творчества, чтобы понятно отобразить эту работу (например, создать один элемент бэклога, обозначающий всю работу BAU, на всю итерацию). Сокращая failure demand в BAU и незапланированной работе, вы улучшите производительность и освободите ресурсы, которые затем можно будет направить на настоящие инициативы по непрерывному совершенствованию.
Тем не менее, итерация или PI, кажется, перестает быть полезным, если для незапланированной работы аллоцируется более 30-40% ресурсов команды. Хотя какая-то часть итерационного подхода все еще останется ценной, от вас потребуется адаптация стандартных церемоний, чтобы сделать их значимыми, и Kanban здесь, скорее всего, более вероятно обеспечит полезную модель жизненного цикла. ART, с которыми я работал в таких условиях, как правило, заканчивались укороченными мероприятиями по планированию, гораздо более сосредоточенными на «выравнивании приоритетов», чем на детальном планировании.
Но самую большую пользу вы получите, когда начнете собирать данные о том, «на что вы действительно тратите свое время», а не «каковы ваши приоритеты», и выработаете дисциплину действовать исходя из этих данных.
Канбан ART (ART Kanban) — это метод визуализации и управления потоком Фич в Конвейере Непрерывной Поставки от идеи до анализа, реализации и выпуска.
