Описание. Управление проектами по методике Agile — это гибкий подход к управлению портфелем проектов. Он подразумевает непрерывное проведение экспериментов, децентрализованный контроль и прозрачность.
Можно ли применить методики Agile к крупному портфелю проектов, в работе над которыми задействовано большое количество команд и разработчиков? Да, это можно сделать с помощью гибкого подхода к управлению портфелем. В компании Netflix говорят о «строгой согласованности и слабой взаимозависимости», когда описывают отлаженный процесс управления портфелем по методике Agile в рамках крупной организации. Давайте посмотрим, какую роль играют связность и независимость, а также что объединяет успешные портфели проектов, которыми управляют по принципам Agile.
Помещение в правильный контекст
Методика agile уделяет так много внимания команде, что руководители крупной agile-организации часто не понимают, в чем заключается их роль. Но они определяют стратегию, они прокладывают курс, а значит, они могут стать главными проводниками культуры agile в рамках целой организации. Когда мы применяем принципы agile-разработки к портфелю проектов, стратегия и курс выражаются в виде «тем» — больших объемов целенаправленной работы, продолжающейся в течение некого промежутка времени. Благодаря темам разные команды, работающие над одной бизнес-инициативой, взаимодействуют более эффективно и достигают целей организации.
В прозрачной культуре о проблемах говорят открыто, без страха возмездия; сглаживаются недостатки отстаивания интересов в компании. Как следствие, проще найти правильное решение, чтобы работа в командах не останавливалась.
Применение методик agile в масштабе всей организации
В наиболее успешных компаниях, применяющих методики Agile на всех уровнях деятельности, можно наблюдать три общих принципа. Во-первых, вся программа носит итеративный характер. В традиционной модели управления портфелем проектов во главе угла лежит нисходящее планирование, и под работу выделяются продолжительные отрезки времени. При внедрении Agile за основу берется концепция циклов «создать — оценить — узнать», которую используют отдельные agile-команды и которая затем распространяется в более широком масштабе. Долгосрочное agile-планирование осуществляется командами, которые работают сообща, опираясь на модульный подход, и регулярно обмениваются результатами работы. В ходе реализации проекта они вправе подбирать баланс между объемом работы, сроками ее выполнения и выделяемыми ресурсами, т. е. основными составляющими тройственной ограниченности планирования. Благодаря этому достигается невероятная гибкость, и команда, вместо того чтобы продолжать выполнять жесткий план, сосредотачивается на поставке ценности и достижении ощутимого прогресса в соответствии с бизнес-стратегией и целями.
Во-вторых, в успешных организациях налажен стабильный обмен информацией о портфеле проектов. Происходит обмен знаниями, преодолевается разрозненность внутри организации. В рамках организации должен постоянно происходить обмен контекстами, такой же, как на agile-собраниях на уровне команд, чтобы все были в курсе целей, хода работы и препятствий. Благодаря этому растет уважение между коллегами всех уровней, независимо от их роли в организации, и укрепляется взаимодействие, основанное на эмпатии и взаимопонимании.
В-третьих, для большинства agile-организаций характерны частые релизы в разных проектах портфеля, даже если релиз подразумевает работу сразу нескольких команд. Согласованность циклов спринта, работа над созданием надежных API и технической изоляцией, эффективная автоматизированная цепочка тестирования и развертывания в совокупности позволяют видеть, кто поставляет что и к какому сроку.
Единая точка зрения при поддержке разнообразия
Как в случае с традиционной agile-разработкой, работа по agile-разработке портфеля проектов поручается командам, а не отдельным сотрудникам. Каждая команда понимает главные цели организации, и в каждой команде складывается динамично развивающаяся культура, в которой оптимизируются подходы к работе и поставке.
Например, команды обычно оценивают сложность работы в очках за истории, используя шкалу, напоминающую последовательность Фибоначчи (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Одна команда, скорее всего, будет понимать оценку в 8 очков иначе, чем другая команда. По этой причине высшее руководство не должно оценивать скорость команд только в числовом выражении (скорость команды в числовом выражении — это количество очков за истории, которое команда может выполнить за спринт). Оно должно понимать, что скорость каждой команды уникальна, потому что каждая команда по-разному понимает реальный эквивалент очков за истории.
Кроме того, agile-команды по-разному подходят к релизам. Scrum-команды, как правило, выпускают программное обеспечение в конце каждого спринта, а kanban-команды делают это либо постоянно, либо когда владелец продукта запрашивает сборку, которую необходимо запустить в работу. Одна из самых больших проблем agile-разработок — релизы с большим количеством изменений, точнее — попытка их избежать. В конце концов, никому не нужны релизы, для выпуска которых необходимо задействовать весь технический персонал. Переход от монолитного дизайна к модульному, который обеспечивается путем разделения кода на отдельные потоки релизов, способствует повышению гибкости и независимости бизнес-подразделений. Модульный дизайн также снижает риски при релизах, т. к. каждый релиз содержит небольшое количество изменений, что значительно упрощает диагностику и устранение проблем.
Изоляцию можно распространить и на рабочие процессы в организациях, управляющих портфелями проектов. Команды, занимающиеся разными направлениями деятельности, могут использовать совершенно разные рабочие процессы. Разумеется, рабочий процесс команды разработчиков ПО будет отличаться от процесса маркетинговой команды, даже если оба отдела верны таким принципам agile, как итеративная модель разработки и регулярный анализ прошлой работы в ходе ретроспектив. Аналогичным образом две команды разработчиков могут делить свой рабочий процесс на разные этапы. И это абсолютно нормально! Такое разнообразие подходов формирует серьезное преимущество для крупных agile-проектов: оно способствует обмену знаниями. Чем больше подходов вы пробуете, тем больше вы узнаете, а этими знаниями можно делиться с другими командами в организации.
Расширяйте масштаб применения agile-принципов по мере развития
Чтобы применить методы гибкого управления к крупному портфелю проектов, нужно распространить принципы Agile, которым следуют отдельные команды, по всей организации. Культура Agile несет ощутимую пользу: ее охват естественным образом расширяется и углубляется по мере того, как все больше людей встраивает в работу основные принципы Agile. Но успешность портфеля проектов определяется успешностью самого слабого звена в организации. Чтобы создать работоспособную культуру Agile и достичь успеха, нужно наладить взаимодействие между руководством организации и всеми командами.
Готовы применить методы Agile ко всему портфелю проектов? Узнайте, как с помощью корпоративной платформы для agile-планирования Jira Align можно обеспечить наглядность, согласовать стратегии и обеспечить адаптивность на уровне всей компании для ускорения цифрового преобразования.
