Управление agile-портфелем

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

 

Dan Radigan Dan Radigan
Просмотр тем

Можно ли применить методики agile к крупному портфелю проектов, в работе над которыми задействовано большое количество команд и разработчиков? В этом нет никаких сомнений. В компании Netflix говорят о «строгой согласованности и слабой взаимозависимости», когда описывают отлаженный процесс разработки по методике 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 ко всему портфелю проектов? Узнайте, как с помощью корпоративной платформы для agile-планирования Jira Align можно обеспечить наглядность, согласовать стратегии и обеспечить адаптивность на уровне всей компании для ускорения цифрового преобразования.