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

 Автор 

Руслан Алексеевич Долженко, д.э.н.

Ключевые слова:

Инновации, управление проектами, agile, гибкая методология разработки, банковские продукты.

Конкуренция как ключевой двигатель рыночной экономики не статична, она также развивается, проявляет себя в разных аспектах, заставляя бизнес постоянно пересматривать акценты в своих целях. Увеличение прибыли как ключевая детерминанта остается неизменной, но средства ее достижения постоянно меняются: максимизация производственных мощностей, налаживание отношений с клиентами, социальная ориентация бизнеса, успешный бренд и другие. В современных условиях, когда любая идея может быть скопирована, любой ресурс найден на рынке, успешными могут быть только такие организации в основе которых лежит уникальная управленческая концепция. Как отметил в одном из своих выступлений Г. Греф, руководитель крупнейшего банка РФ: «Нет никакой конкуренции товаров, продуктов или услуг. Есть конкуренция моделей управления и она развивается совершенно колоссальными темпами».

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

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

Цель статьи – рассмотреть особенности agile-методологии, описать возможности ее использования в банковской отрасли, конкретизировать содержание процедур, ролей, артефактов, предусмотренных в данном подходе. Данное направление крайне актуально для отечественного бизнеса, который понимает, что производство и реализация продуктов, осуществление услуг без опоры на ИТ имеет крайне мало перспектив, и значит нужно осваивать новые подходы к организации своей деятельности.

Понятие и сущность agile методологии

Что такое Agile? В переводе с английского это слово означает «шустрый, проворный, быстрый». Так называется семейство методологий создания продуктов, базирующихся на четырех ценностях, известных как Agile Manifesto, опубликованных в августе 2001 году. Вот эти ценности:

1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Помимо этих 4 ценностей в манифесте выделяются 12 правил Agile:

1. Наивысший приоритет — удовлетворение потребностей заказчика;
2. Изменение требований приветствуется;
3. Продукт следует выпускать как можно чаще;
4. Ежедневно работать вместе;
5. Мотивированные профессионалы;
6. Непосредственное общение;
7. Работающий продукт;
8. Поддерживать постоянный ритм;
9. Постоянное внимание к техническому совершенству;
10. Простота — искусство минимизации лишней работы;
11. Самоорганизующиеся команды;
12. Поиски улучшения эффективности.

И, наконец, можно выделить три базовых принципа гибкой разработки:

1. Прозрачность. Процесс должен одинаково пониматься всеми его участниками. Все участники процесса должны пользоваться общей терминологией. Те, кто выполняет работу, и принимает итоговый результат, должны иметь общее представление о критериях готовности продукта.
2. Инспекция. Участники процесса должны часто инспектировать ключевые моменты работы, отслеживать прогресс достижения цели проекта для своевременного выявления нежелательных отклонений. Однако, инспектирование не должно быть настолько частым, чтобы мешать работе и должно проводиться квалифицированными специалистами в области гибкой разработки.
3. Адаптация. Если в ходе инспекции было сделано заключение, что один или более аспектов процесса отклонились от допустимых норм, а производимый продукт может стать неприемлем, то необходимо внести изменения либо в процесс, либо в рабочие материалы. Изменения должны вноситься как можно раньше для уменьшения риска последующего отклонения от нормы.

На ценностях и принципах Agile основана деятельность таких лидеров как Google, Microsoft, Amazon. Некоторые отечественные компании, в первую очередь IT, все более активно используют данную методологию. Но лишь одна крупная компания решила внедрить agile‑методологию в свою практику, речь идет о Сбербанке, организации, которая создала собственный Agile-фреймворк в блоке «Технологии» совместно с Розничным блоком и начала использовать гибкие подходы в своей деятельности. По сути, пока еще частично, но Сбербанк можно обозначить как agile-организацию.

Agile организация – это объединение максимально самодостаточных самоорганизующихся кроссфункциональных команд, которые обладают всеми инструментами, навыками и полномочиями для удовлетворения определенной потребности клиента и используют гибкие методы разработки продукта (Scrum, Kanban, Design Thinking, Lean Startup и др.) при максимальной автоматизации внедрения (с помощью таких инструментов как DevOps, Continuous Delivery и др.) и максимальной гибкости поддерживающих процессов (HR, закупки, финансирование и др.).

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

Часто, когда говорят об agile-методологии, упоминают такое понятие как Scrum. Scrum – набор базовых элементов и правил, предназначенный для продуктивного и творческого создания продуктов с максимально возможной ценностью и для решения нетривиальных задач.

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

 

Рисунок 1. Сравнение эффективности Agile-команд и команд, работающих по всем другим методам разработки ПО

Таким образом, если судить о количественных показателях эффективности использования agile по совокупности ИТ-предприятий, то налицо явное повышение результативности команд. Как обстоят дела с качественными результатами, насколько люди, задействованные в agile-проектах, испытывают удовлетворенность от того, что им приходится работать в новых условиях? Результаты исследований показывают, что участники подобных проектов отмечают значительные улучшения от внедрения Agile (рисунок 2).

Рисунок 2. Улучшения, которые обеспечивает использование agile в бизнесе

Источник: 10-й отчет о состоянии адаптивных методик разработки (State of Agile Report), подготовленный в 2016 г. компанией VersionOne; 1 321 проектов отраслевой базе данных Numetrics о программном обеспечении; примеры клиентов

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

Agile-проекты не всегда оказываются успешными. Как показывает практика, некоторые подобны проекты не принесли должного эффекта. Основные причины неудачной реализации проектов agile приведены на рисунке 3.

Рисунок 3. Top-5 основных причины неудачной реализации проектов Agile (в %)

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

Каковы барьеры на пути внедрения методологии agile в практику бизнеса? Согласно 10-й отчета о состоянии адаптивных методик разработки, который был подготовлен в 2016 г. компанией VersionOne, ключевыми барьерами являются (Рисунок 4):

Рисунок 4. Top-5 барьеров для широкого внедрения Agile (в %)

Источник: 10-й отчет о состоянии адаптивных методик разработки (State of Agile Report), подготовленный в 2016 г. компанией VersionOne; интервью в ING

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

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

• вовлечение бизнес-заказчика – возможность выделения на стороне бизнес-подразделения сотрудника, который будет отвечать за продукт, выступать в роли его владельца, т.е. принимать итоговый результат;
• команда и её окружение – возможность создания кросс-функциональных (включающих все необходимые компетенции (аналитики, дизайнеры, архитектор автоматизированной системы, разработчики, тестировщики, администратор тестового стенда, администратор автоматизированной системы)) команд размером 5-9 человек и вовлечения всех участников процесса от производства до сопровождения;
• система и её окружение – архитектура системы должна обеспечивать возможность работы с атомарными задачами, гибкое управление требованиями и безопасные частые внедрения.

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

Текущие масштабы использования Agile-методологии в Сбербанке, промежуточные итоги по ряду территориальных банков

Во-первых, можно выделить следующие вызовы, которые обусловили необходимость внедрения Agile в Сбербанке:

1. Низкая скорость внедрения изменений, например, данные о Time-to-market (время от начального замысла нового продукта до его внедрения на рынок) по некоторым продуктам представлены в таблице 1.

Таблица 1 - Время от начального замысла до внедрения на рынок по некоторым продуктам Сбербанка

Банковский продукт	Время Time-to-market
Копилка – сервис Сбербанка для накопления денег на счете	27
Автоперевод P2P – перевод с карты на карту (временное решение)	29,3
СБНКД (Сбербанк на каждый день) – комплекс продуктов, которыми клиент может пользоваться каждый день (Мобильный банк, «Спасибо от Сбербанка», Автоплатеж и т.д.) (оформление базового пакета)	15,1
СБНКД (новые карточные продукты Momentum Classic)	21,9
Тарифный план «Золотой»	15,7

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

2. › Высокий уровень забюрократизованности;
3. › Низкая скорость принятия решений;
4. › Низкая коллаборативность;
5. › Сильная иерархичность – большинство решений принимаются на высоком уровне;
6. › Увеличивающаяся конкуренция со стороны более мелких и гибких игроков банковского сектора и финтех-стартапов;

Большинство крупных банков в мире сталкиваются со схожими вызовами, и пионеры в области изменений решают возникающие вызовы с помощью Agile-трансформации. Ориентируясь на успешный опыт руководство Сбербанка приняло решение внедрить agile в практику компании. Топ-менеджментом были поставлены следующие цели Agile- трансформации в Сбербанке:

• Суперкороткий Time-to-Market - способность выводить новую функциональность в продуктив каждые две недели;
• Максимальная удовлетворенность клиентов за счет предоставления продуктов, которые соответствует их потребностям и желаниям;
• Лучший на рынке клиентский опыт;
• №1 на рынке среди работодателей по удовлетворенности и вовлеченности сотрудников;
• Непрерывные и быстрые улучшения продуктов и процессов за счет внешних и внутренних инноваций;
• Повышение эффективности и продуктивности персонала.

В рамках адаптации методологии agile к специфике Сбербанк в организации родился специальный термин «Sbergile», под которым понималась методология для разработки и поддержки продуктов в Сбербанке, основанная на ценностях гибких подходов к разработке продукта.

Планируется, что внедрение Agile позволит перейти от иерархичной структуры к Agile-структуре, в которой не будет традиционных подразделений, которые специализируются на процессе/продукте, а будут трайбы, кросфункциональные команд с включением в них бизнес-экспертов и ИТ-специалистов.

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

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

Внедрение Agile в банке в первую очередь потребовало развития «soft-skills» сотрудников, ключевые из них представлены в таблице 2.

Таблица 2 - «Soft-skills» сотрудников, необходимые для эффективной реализации agile-подхода в банке

tadalafil generique.

Базовый «Soft-skill sovradosaggio di viagra. »	Характеристика компетенции
Самоорганизация	Берет на себя ответственность за результат и самостоятельно решает как выполнить задачу и какую роль на себя взять в ее выполнении, в условиях, когда известен лишь образ результата
Коллаборация	Быстро и эффективно находит решения, вовлекая других и делясь своим опытом и идеями с другими, ставит командный результат выше личных интересов
Эмпатия	Способен представить себя на месте другого человека и понять его чувства, желания, идеи и поступки для того, чтобы сделать взаимодействие с ним наиболее эффективным
Признание ошибок	Стремится обсуждать свои ошибки с коллегами, анализировать причины их возникновения и извлекать уроки для минимизации их повторения в дальнейшем
Психологическая безопасность	Поддерживает в команде особую атмосферу, позволяющую свободно высказывать свою точку зрения, давать предложения и действовать самым необычным, нестандартным методом без страха негативной реакции со стороны команды
Фокус на результат	Предпочитает проверить идеи на деле, вместо длительного согласования
Постоянное совершенствование	Ищет пути улучшить работу организации

В периметр первой волны внедрения Agile в Сбербанке попало около 1 800 сотрудников, представителей Розничного блока и блока Технологии.

3 ключевых сферы работы с использованием Agile в банке в настоящее время – это мобильные приложения, Единая фронтальная система (ЕФС), Платформа поддержки развития бизнеса (18+). В первой группе представлены такие продукты как: персональный финансовый менеджмент, документы, аватар / Мессенджер, сбербанк-Онлайн (мобильная версия) и др.

Сбербанк открыл новую стратегическую программу «Создание Платформы поддержки развития бизнеса (18+)», в рамках которой инновационные технологии будут повышать производительность, снижать совокупную стоимость владения ИТ-инфраструктурой группы, сокращать срок запуска новых продуктов.

Самой крупной пилотной площадкой стала программа «Единая фронтальная система», многие проекты которой уже успешно использует гибкую методологию. Для знакомства с основными практиками Agile блок «Технологии» совместно с Дирекцией программы был организован семинар «Погружение в Agile».

Цели первой волны внедрения Agile:

1. Улучшить Time 2 Market (или его аналог) при сохранении бизнес-результата;
2. Повысить вовлеченность персонала;
3. Опробовать разработанную методологию;
4. Повысить коллаборативность и научиться делегировать ответственность и решения.

Каждой цели сопоставлен свои КПЭ:

1. Улучшение в достижении вех программ (Производительность); исполнение КПЭ трайбов, включая КПЭ программ, NPS, P&L, доступность, надежность и т. п.
2. Вовлеченность сотрудников Банка, принимающих участие в первой волне Agile трансформации;
3. Степень применения практик Agile в первой волне.

В рамках трансформации банк планирует перейти от функционально-ориентированных подразделений к трайбам, объединяющим кросс-функциональные команды для удовлетворения макро-потребностей клиента.

Команда – кросс-функциональная совместно работающая группа специалистов, обладающая всеми навыками, инструментами и полномочиями для самостоятельной разработки работающего продукта. Размер команды, как правило, до 10-12 человек.

Трайб – группа взаимосвязанных команд, сформированная вокруг определенного продукта/бизнес- цели и отвечающая за бизнес-результат. Размер трайба - до 150 человек или до 1500 при наличии кластеров.

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

Кластер – виртуальная группа взаимосвязанных команд в рамках одного трайба, сформированная вокруг определенного продукта/бизнес-цели. Как правило, не имеет выделенных сотрудников, роль лидера трайба выполняется одним из владельцев продукта.

Кластер - до 150 человек опционально. Ограничение размера трайба/кластера построено на «Числе Данбара», которое говорит, что количество постоянных социальных связей, которые человек может поддерживать составляет 125-150 человек.

Куратор – член Правления банка, вовлеченный в Agile, отвечает за бизнес-результат нескольких трайбов. Чаптер – группа специалистов одной области компетенций, как правило, 10-12 человек.

Согласно типам решаемых задач, трайбы и команды в Сбербанке могут быть двух типов:

Клиентоориентированные:

• Реализуют элементы бизнес-задач и клиентского опыта, например, продукты или клиентские путешествия;
• Позволяют построить сквозной клиентский опыт;
• Состоят из кросс-функциональных специалистов, способных самостоятельно создать и выпустить продукт/сервис;
• Управляются руководителем Розничного блока.

Платформенные:

• Создают базовые модули платформ, предоставляющих стандартные сервисы множеству других команд;
• Используются в случаях, когда сложность модуля и/или взаимосвязей с другими модулями требует вовлечения нескольких технических специалистов c глубоким знаниями. Обеспечивают архитектурную целостность;
• Состоят преимущественно из технических специалистов, создающих автономный модуль платформы и устойчивые алгоритмы;
• Управляются руководителем Блока ИТ.

Ключевые базовые принципы формирования трайбов в Сбербанке приведены на рисунке 5. Основной принцип формирования трайбов – самодостаточность для удовлетворения конкретной потребности.

Рисунок 5. Базовые принципы формирования трайбов в Сбербанке

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

В «первую волну» трансформации были выделены 7 трайбов, сфокусированных на макропотребностях клиента, и один платформенный трайб:

1. Чувствовать себя уникальным / Mass Personalization;
2. Иметь Банк всегда с собой / Digital Business Platform;
3. Занять и сберегать / Core Banking Products;
4. Карточные продукты / Card Solutions;
5. Заплатить и перевести / Payments & Transfers Solutions;
6. Сбербанк всегда рядом/Банк рядом;
7. Чувствовать заботу и поддержку / Customer Care;
8. Базовые платформенные сервисы.

В Таблице 3 представлен шаблон плана внедрения agile-методологии, который был определен в качестве базового для 1 волны внедрения в Сбербанке.

Таблица 3 - План внедрения Agile-методологии в 1 волну внедрения

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

 

Чем отличается Agile-офис от обычного офиса Сбербанка? Agile означает не просто изменение подхода к деятельности команд и их участников, для этого необходимо также изменить контекст, условия в которых осуществляется работа. В банке было определено, что agile-офис будет удовлетворять 3 базовым требованиям: неформальная обстановка + оптимальные условия для командной и индивидуальной работы + бытовой комфорт. Сотрудник в этих условиях будет обеспечен зонами для комфортной работы, отдыха, переговоров, уединенной работы. Команда в свою очередь сможет осуществлять свою деятельность в отдельной рабочей зоне, у нее будет пространство для командной / индивидуальной работы, результаты своей деятельности она будет фиксировать на выделенной доске.

Как изменится проектный процесс в Сбербанке после внедрения Agile? Отличия традиционного проектного подхода от Agile в организации приведены на рисунке 6.

Рисунок 6. Отличия традиционного подхода к проектам в банка от agile-подхода

В новых условиях команда будет самостоятельно определять бэклог, нарезку фич и историй. Она будет отвечать за достижение релевантных исполняемой задаче бизнес-показателей и time-to-marker.

Трайб будет самостоятельно определять подход к достижению поставленных целей через определение бизнес-задач. Он будет отвечать за достижение бизнес-показателей (P&L, NPS, доля рынка и т.д.).

Взаимосвязанные стандартные Agile-церемонии трайба и команды определяют особенности работы в (супер)спринтах. Система agile-церемоний в Сбербанке приведена на рисунке 7. Рассмотрим их содержание подробнее.

Рисунок 7. Общая схема взаимодействия трайбов и команд в рамках спринтов и суперспринтов

Можно выделить следующие рекомендации по реализации церемоний:

1. В случае, если в трайбе несколько кластеров – все процессы и церемонии трайба проводятся в каждом кластере;
2. КОРТ = Квартальный Обзор Результатов Трайба;
3. Рекомендуется не начинать спринт в понедельник (чтобы освободить выходные от работ по финализации спринта).

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

MVP позволяет снизить риски и учиться на ошибках за счет итеративной и инкрементальной разработки. Минимально жизнеспособный продукт в agile должен создаваться итеративно, поэтому команды не должны стараться сделать продукт полностью и сразу. Кроме того, он создается инкрементально, поэтому процесс создания идеального и исчерпывающего продукта будет продолжаться длительное время в рамках большого количества итераций. Но уже на начальных этапах разработки продукт уже будет жизнеспособным. Как отметил Allister Cockburn: «Agile – это ранняя реализация пользы» [].

Как изменилась организационная структура подразделений Сбербанка, вовлеченных в процесс agile-трансформации? Новый вариант организационной структуры и количество штатных единиц в новых подразделениях приведен на рисунке 8.

Рисунок 8. Проект изменения организационной структуры с выделением подразделений для реализации Agile в Сбербанке

Для наполнения подразделения agile-коучей была организована специализированная процедура подбора сотрудников на эту роль. Данные о количестве поданных заявок, показатели воронки приведены на рисунке 9.

Рисунок 9. Количественные данные по подбору agile-коучей в Сбербанке в рамках 1 волны

Таков контекст ситуации, которая обусловила потребность agile-методологии в банке, а также описание тех действий, которые были совершены руководством Сбербанка для внедрения agile в практику бизнеса.

Далее рассмотрим роли участников agile-проектов, которые используются в рамках данной методологии в Сбербанке, но прежде дадим характеристику ряда специфических терминов agile, которые активно используется в данном подходе, но в силу того, что они пришли из ИТ-сферы не совсем ясны человеку, который не знаком с методологией. Термины, английские аналоги, а также их определения приведены в таблице 4.

Таблица 4 - Основные термины, используемые в agile-методологии

Термин	Английский вариант	Определение
	Agile	Agile – семейство методологий гибкой разработки (Scrum, Extreme programming, DSDM, FDD etc.).
Артефакт		Результат организованной деятельности, предусмотренный методологией
Бизнес – требования		Требования Заказчика по внесению изменений в процессы Банка.
Бэклог продукта	Product Backlog	Упорядоченный набор элементов, структурированный в соответствии с приоритетами. Элементом бэклога может быть (в порядке иерархии): эпик, пользовательская история, техническая история, дефект.
Бэклог Релиза	Release Backlog	Часть элементов бэклога продукта, которые необходимо реализовать в данном релизе.
Бэклог спринта	Sprint Backlog	Набор элементов бэклога продукта или бэклога Релиза, которые должны быть реализованы данной командой Разработки в рамках спринта а также Технические Истории и Дефекты.
Вики		Веб-сайт, структуру и содержимое которого пользователи могут самостоятельно изменять с помощью инструментов, предоставляемых самим сайтом
Дефект	Bug	Ошибка в функционировании продукта или несоответствие продукта установленным требованиям к продукту.
Демонстрация (Демо)	Sprint review	Мероприятие, которое проводится в конце спринта для получения к обратной связи и анализа степени достижения Цели спринта, в котором участвует вся команда продукта.
Доска Задач		Физическое или электронное пространство, предназначенное для визуализации процесса разработки и оценки статуса текущих задач.
Инкремент продукта		Законченный функционал как результат выполнения требований бэклога за текущий спринт, соответствующий критериям готовности и готовый к поставке.
Команда Разработки		Кросс-функциональная самоорганизующаяся группа специалистов, которая создает Инкремент продукта.
Команда продукта	Scrum Team	Команда продукта состоит из Владельца продукта/Менеджера продукта, Скрам-мастера и одной или нескольких команд Разработки.
Непрерывная интеграция	Continuous Integration	Практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения проблем интеграции результатов работы нескольких разработчиков
Оценка участников команд	POCLAC	Регулярная оценка участников команд, осуществляемая совместно владельцем продукта, лидером чаптера и Agile-коучем, с целью поиска возможностей для улучшения и трансляции этих возможностей командам
Пользовательская История	User Story	Элемент бэклога, представляющий собой подробное описание требуемой пользователю функциональности, построенное по шаблону Я как <категория пользователей> могу <описание функции> для того, чтобы <описание конечного результата> и содержащее критерии приемки. Размер пользовательской истории должен позволять закончить ее в рамках одного спринта.
Программное Обеспечение	Software	Совокупность программ системы обработки информации и документов, необходимых для эксплуатации этих программ.
Продукт		Функциональность АС или совокупности АС, обеспечивающая создание стоимости банковского продукта согласно бизнес-процессу
Правила организации работы		Документ, создаваемый командой продукта при переходе на Agile, в котором описаны правила организации работы в данной команде, включая распределение ролей, используемые автоматизированные системы, релизные политики, порядок и сроки проведения требуемых мероприятий и др.
Приёмо-сдаточные испытания		Вид тестирования, в рамках которого производится проверка реализации бизнес-требований, а также соответствие требованиям сопровождения и безопасности к объекту тестирования с участием представителей бизнес-заказчика, сопровождения и информационной безопасности.
Разработка ПО, Производство ПО	Software Development	Процесс создания Программного продукта путем последовательного выполнения анализа требований, дизайна ПО, кодирования и тестирования.
Релиз		Совокупность работ, направленных на модификацию одной АС в течение ограниченного периода времени на основе фиксированного набора бизнес-требований или ЗНИ; также результат этих работ (очередная версия АС). Состоит из нескольких спринтов. Для команды, которая внедряется в промышленную эксплуатацию в конце каждого спринта, понятие «релиз» тождественно понятию «спринт».
Самоорганизующаяся команда		Команда, которая совместно принимает решения и несет за них ответственность
Сборка		Совокупность исполняемых модулей в загрузочных кодах, полученная в результате сборки (в некоторых случаях компиляции) с исходных кодов АС.
Скорость команды	Velocity	Сумма оценок (story points) всех элементов бэклога, сделанных за спринт.
Скрам	Scrum	Фреймворк, предполагающий итеративно-инкрементальный подход для разработки и поддержки функционально сложных продуктов.
Скрам-митинг, стендап-митинг	Scrum-meeting, stand up	Ежедневное мероприятие для синхронизации работ и определения плана на день.
Спринт	Sprint	Период создания Инкремента продукта, длительностью от одной недели до одного месяца. Включает в себя активности по анализу, разработке и тестированию для каждого Элемента бэклога спринта.
Стори пойнт	story point	Условная единица, используемая командой Разработки для оценки трудоемкости по реализации Элемента бэклога.
Техническая История		Элемент бэклога, предназначенный для фиксации требований по оптимизации разработки, и требований по обеспечению сопровождения, безопасности и т.п. Не несет в себе функциональных требований.
Фасилитация, фасилитатор		Профессиональная организация процесса групповой работы, направленная на прояснение и достижение группой поставленных целей. Соответственно, фасилитатор – тот, кто обеспечивает успешную групповую коммуникацию
Фреймворк	framework	Каркас, структура, которая используется для определения возможных способов решения проблемы или организации работы, но не дает готовых рецептов, что делать в тех или иных случаях.
Цель спринта		Цель спринта – это задача, которая будет достигнута в результате спринта благодаря реализации бэклога спринта и которая объясняет команде продукта, почему она разрабатывает Инкремент продукта.
Ценность	Value	Способность продукта удовлетворять требования клиента.
Элемент бэклога		Элементом бэклога может быть (в порядке иерархии): Эпик, Пользовательская История, Техническая История, Дефект.
Эпик	Epic	Элемент бэклога продукта, явно описывающий конечную ценность для пользователя, который не может быть выполнен в рамках одного спринта и требует декомпозиции на несколько Пользовательских или Технических Историй.

Их знание необходимо для понимания дальнейшего изложения сути agile-методологии. Некоторые из этих понятий будут подробно изложены в ходе дальнейшего рассмотрения agile.

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

Основные роли участников Agile-проектов в Сбербанке

Система всех ролей в Sbergile приведена на рисунке 10.

Рисунок 10. Перечень ролей в рамках agile-методологии в Сбербанке

Agile-методология в Сбербанке на момент первичного внедрения предполагала взаимодействие участников, которые представляют 21 роль. Следует отметить, что методология допускает совмещение некоторых ролей одним и тем же сотрудником, поэтому в реальности реализация agile может осуществляться меньшим количеством работников, по сравнению с указанной схемой.

Как было отмечено ранее, основная деятельность участников agile осуществляется в рамках команд и трайбов. Рассмотрим содержание ролей их участников. Они представлены на рисунке 11.

Рисунок 11. Базовые роли в Agile в Сбербанке внутри трайба

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

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

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

Эта роль является выделенной, она должна выполняться 100% времени в рамках одной команды (в случае, когда несколько команд занимаются взаимосвязанными задачами, в качестве исключения, которое должно быть согласовано с куратором, роль может совмещаться для 2-3 команд). В зависимости от специфики проекта на роль владельца продукта может быть назначен:

• сотрудник бизнес-подразделения, отвечающий за развитие канала, продукта или услуги;
• руководитель проекта со стороны бизнеса.

Основные обязанности и полномочия сотрудника в данной роли:

По направлению управления продуктом:

• Разработка видения продукта и его синхронизация с лидером трайбакластера и владельцами продуктов в командах, отвечающих за связанные продукты;
• Определение требований к продукту; обеспечение их полноты, целостности и согласованности; единственный источник требований для команды;
• Формирование состава MVP c учетом имеющихся ограничений ресурсов и последовательного развития продукта;
• Приемка результатов спринта на демонстрации.

В части планирования и приоритизации работ:

• Формирование бэклога команды в терминах клиентских историй с учетом технических историй, технического долга и дефектов, приоритизация его элементов для достижения бизнес-целей, непрерывное поддержание бэклога в актуальном состоянии;
• Проведение встреч с командой по актуализации бэклога продукта команды;
• Обеспечение корректного понимания требований командой;
• Участие в планировании спринта команды, в планировании суперспринта трайба для подтверждения приоритетов и уточнения требований;
• Взаимодействие с другими командами своего и внешних трайбов в рамках церемоний синхронизации команд для реализации кросс-командных задач.

Он принимает активное участие в развитии команды:

• Совместно с архитектором трайба/кластера и лидерам чаптера определяет набор необходимых компетенций в команде;
• Участвует в POCLAC и в оценке работы команды.

Артефакты в зоне ответственности данной роли:

• Бэклог команды;
• Бэклог спринта (в части актуальности приоритетов и понятности требований);
• Дорожная карта продукта;
• Критерии готовности (Definitions of Done);
• Описание стрима;
• Видение продукта.

Не должен делать:

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

Пример спринта в 1 неделю для участника agile в данной роли приведен на рисунке 12. В реальной ситуации, как правило, спринт занимает 2-3 недели, с большей долей работы над продуктом.

Рисунок 12. Пример недельного спринта для Владельца продукта в agile

Следующая важная роль в agile – это скрам-мастер.

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

Основные обязанности и полномочия участника в данной роли:

Фасилитация процессов и церемоний:

• Фасилитация церемоний команды от планирования спринта до демонстрации;
• Отслеживание прогресса и достижения целей команды в рамках ежедневных стенд-апов с применением диаграмм сгорания/кумулятивных диаграмм потока;
• Координация взаимодействий с другими командами своего и внешних трайбов в церемониях планирования суперспринта и синхронизации команд трайбов;
• Управление процессами декомпозиции и оценки задач, выявления зависимостей с другими командами и актуализации бэклога для подготовки команды к планированию суперспринта трайба;
• Администрирование бэклога в производственной системе;
• Способствует другим командам и традиционной части организации в выстраивании эффективного процесса коммуникаций и взаимодействий с командой;

Развитие команды и поддержка Agile-процесса:

• Обеспечение соблюдения и непрерывного совершенствования церемоний и практик Agile, обучение команды новым методиками в зависимости от потребностей;
• Создание и поддержание атмосферы доверия за счет фасилитации ретроспектив и обмена обратной связи между участниками команды;
• Устранение препятствий, стоящих перед командой (например зависимостей от других команд), ведение списка препятствий;
• Участие в создании продукта команды в соответствии со своей компетенцией.

Артефакты в зоне ответственности:

• Критерии готовности (Definitions of Done);
• Результаты ретроспективы;
• Бэклог спринта (в части проведения эффективной церемонии планирования).

Не должен делать:

• Не должен назначать людей на задачи;
• Не должен быть начальником команды, директивно принимать решения по способам реализации;
• Не должен выстраивать иерархию внутри команды;
• Не должен единолично, директивно оценивать участников команды.

Пример рабочей недели из жизни «Скрам-мастера», совмещающего роль с разработкой приведен на рисунке 13.

Рисунок 13. Неделя в жизни «Скрам-мастера», совмещающего роль с разработкой

Следующая базовая роль в agile – это участник команды.

Участник команды - специалист, непосредственно участвующий в создании продукта команды в пределах своих компетенций, является членом чаптера по линии своей компетенции. Данная роль является выделенной, она выполняется 100% времени в рамках одной команды. Может совмещаться с ролью скрам-мастера или лидера чаптера.

Основные обязанности и полномочия:

Реализация продукта:

• Работает вместе с другими участниками своей команды над задачами команды спринтами по 2-3 недели;
• Берет на себя полную ответственность за достижение целей команды;
• Создает и итеративно совершенствует продукт.

Участие в команде:

• Участвует в церемониях команды;
• Участники команды поддерживают друг друга и в случае разногласий совместно ищут оптимальное решение.

Постоянное самосовершенствование

• Анализирует эффективность работы по итогам каждого спринта;
• Открыто делится достижениями и проблемами на ежедневных стэндапах, и при необходимости запрашивает поддержку команды и чаптера;
• Самосовершенствуется и обменивается опытом с коллегами по команде и чаптеру;
• Придерживается стандартов, установленных чаптером.

Артефакты в зоне ответственности:

• Критерии готовности (Definitions of Done);
• Бэклог спринта (в части реализации);
• Работающий продукт;
• Эксплуатационная документация;
• Детальная архитектура сервиса.

Не должен делать:

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

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

Основные обязанности и полномочия:

Обеспечение целостности архитектуры сервиса:

• Лидирование в разработке детальной архитектуры сервиса (область ответственности всей команды);
• Документирование детальных архитектурных спецификаций решения;
• Проектирование интеграции со смежными сервисами;
• Обеспечение соответствия архитектуры сервиса целевой архитектуре трайба;
• Управление техническим долгом сервиса совместно с владельцем продукта команды;
• Вовлечение архитектора трайба в решение открытых архитектурных вопросов;
• Мониторинг устранения технического долга автоматизированной системы/сервиса;
• Ведение списка отклонений и временных решений в архитектуре сервиса.

Артефакты в зоне ответственности:

• Детальная архитектура сервиса.

Не должен делать:

• Не должен отвергать предложенные решения, не предлагая альтернатив;
• Не должен ограничивать свою ответственность только личными задачами;
• Не должен уклоняться от принятия решений.

Зоны ответственности данных базовых ролей приведены в таблице 5.

Таблица 5 - Матрица ответственности владелец продукта, скрам-мастера, участник команды

Задача	Командная роль
	Владелец продукта	Скрам мастер	Участник команды
Формулировка видения продукта и целей спринта	Исполнитель/ Ответственный	Наблюдатель	Наблюдатель
Определение критериев готовности продукта	Исполнитель	Исполнитель / Ответственный	Исполнитель
Приоритизация и управление бэклогом команды	Исполнитель/ Ответственный	Советчик / Консультант / Наблюдатель	Советчик / Консультант / Наблюдатель
Написание и проведение тестов для приемки продукта	Советчик/Консультант	Советчик/Консультант	Исполнитель/ Ответственный
Обеспечение качества продукта	Исполнитель/ Ответственный	Исполнитель	Исполнитель
Обеспечение качества реализации продукта	Исполнитель	Исполнитель	Исполнитель/ Ответственный
Определение критериев приемки истории	Исполнитель/ Ответственный	Наблюдатель	Исполнитель
Устранение препятствий в работе команды	Исполнитель	Исполнитель/ Ответственный	Исполнитель
Обеспечение соблюдения и улучшение практик Agile в команде	Исполнитель	Исполнитель/ Ответственный	Исполнитель
Управление рисками	Исполнитель/ Ответственный	Исполнитель	Исполнитель/ Советчик/Консультант
Приемка историй на основании критериев приемки	Исполнитель/ Ответственный	Наблюдатель	Наблюдатель
Определение даты и цели релиза команды	Исполнитель/ Ответственный	Советчик/Консультант	Советчик/Консультант
Фасилитация церемоний	Исполнитель	Исполнитель/ Ответственный	Исполнитель
Развитие команды и оценка персонала в POCLAC	Исполнитель	Советчик/Консультант	Исполнитель/ Ответственный (Лидер чаптера)
Формирование и актуализация бэклога команды	Исполнитель/ Ответственный	Советчик/Консультант	Советчик/Консультант
Формирование бэклога спринта	Исполнитель/ Ответственный	Исполнитель	Исполнитель/Советчик/Консультант
Дорожная карта продукта	Исполнитель/ Ответственный	Советчик/Консультант/ Наблюдатель	Советчик/Консультант/ Наблюдатель
Результаты ретроспективы	Исполнитель	Исполнитель/ Ответственный	Исполнитель
Реализация бэклога спринта (работающий продукт)	Исполнитель	Исполнитель	Исполнитель/ Ответственный
Детальная архитектура сервиса	Наблюдатель	Исполнитель	Исполнитель/ Ответственный (Архитектор сервиса)
Эксплуатационная документация	Советчик/Консультант/ Исполнитель	Исполнитель	Исполнитель/ Ответственный

 

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

Команда должна быть кросс-функциональной (аналитики, дизайнеры, архитектор автоматизированной системы, разработчики, тестировщики, администратор тестового стенда, администратор автоматизированной системы). Участники команды разработки должны быть взаимозаменяемы, однако допускается распределение ролей и функций между ними. Размер команды разработки должен быть от 5 до 9 человек. В противном случае целесообразно разбиение на несколько команд разработки в рамках одной команды продукта.

Далее рассмотрим основные роли в трайбе в рамках ранее определенной логики (обязанности и полномочия, что должен делать и не делать участник в роли, какие артефакты использовать).

Лидер трайба - сотрудник, отвечающий за управление продуктом или группой продуктов и достижение бизнес-целей этого трайба. Отвечает за ключевые показатели эффективности трайба, в зависимости от его задач (напр. P&L, NPS, доля рынка, надежность систем (uptime, кол-во инцидентов) и т.д.). Является выделенной ролью, выполняемой 100% времени.

Основные обязанности и полномочия:

Управление продуктом:

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

Планирование и приоритизация работ:

• Формирование бэклога трайба: определение и приоритизация стримов и эпиков для трайба;
• Синхронизация видения продукта с владельцами продуктов в командах;
• Квартальное бизнес-планирование трайба, подготовка Квартального Обзора Результатов (КОРТ);
• Постановка целей при планировании релизов;
• Разработка и поддержание дорожной карты продуктов;
• Управление ожиданиями всех заинтересованных лиц.

Участие в управлении и развитии персонала:

• Лидирование при определении миссии и целей трайба и команд;
• Создание атмосферы доверия внутри трайба и мотивация на выполнение задач трайба;
• Формирование предложений по составу и численности трайба;
• Управление бюджетом трайба;

Артефакты в зоне ответственности:

• Дорожная карта трайба;
• Бэклог суперспринта;
• КОРТ (Квартальный Обзор Результатов Трайба);
• Стримы трайба;
• Описания стримов и видения продуктов.

Не должен делать:

• Не должен принимать решения по способам реализации;
• Не должен выстраивать иерархию внутри трайба;
• Не должен заниматься микроменеджементом и навязывать инструкций командам;
• Не должен наказывать членов трайба;
• Не должен единолично, директивно оценивать членов трайба;
• Не должен уклоняться от принятия решений.

Архитектор трайба - сотрудник (и), выделенный подразделением корпоративной архитектуры, который определяет целевую архитектуру продукта/ функциональной области/ продуктов трайба и обеспечивающий ее целостность и соответствие архитектурным стандартам банка. Является ролью, выполняемой 100% времени.

Основные обязанности и полномочия:

Создание решений:

• Участие в планировании, определении и высокоуровневом проектировании решения, исследование архитектурных альтернатив, помощь командам в определении технологий и принятии архитектурных решений;
• Синхронизация архитектурных решений между командами и разрешение архитектурных разногласий и зависимостей в рамках трайба;
• Определение критичных нефункциональных требований к решению;
• Разработка и актуализация концептуальной архитектуры продукта/ функциональной области;
• Защита концептуальной архитектуры продукта/ функциональной области на архитектурном совете (при необходимости);
• Принятие решения по пилотированию новых технологических решений в трайбе и вынесение предложений по тиражированию успешных решений на архитектурный совет;
• Управление взаимозависимостями с архитектурными решениями других трайбов.

Разработка и обеспечение соблюдения архитектурных стандартов:

• Обеспечение соответствия архитектуры трайба архитектурным стандартам и целевой архитектуре банка;
• Разработка архитектурных стандартов вместе с архитекторами других трайбов;
• Обучение архитектуре и коммуникации;
• Контроль соответствия архитектуры сервисов целевой архитектуре трайба / кластера;
• Управление временными решениями и техническим долгом на уровне трайба / кластера.

Планирование релизов:

• Определение необходимых технологических компетенций для команд совместно с лидером трайба;
• Участие в подготовке и планировании суперспринта в части определения необходимых архитектурных доработок согласно архитектурному roadmap и текущим приоритетам в бэклоге трайба.

Артефакты в зоне ответственности:

• Дорожная карта трайба (в части Architectural runway);
• Концептуальная архитектура продукта/ функциональной области.

Не должен делать:

• Не должен разрабатывать детальные архитектурные решения на старте планирования;
• Не должен уклоняться от принятия решений;
• Не должен отвергать предложенные решения без предложения альтернатив.

Скрам-мастер трайба - сотрудник, отвечающий за управление релизами трайба, синхронизацию работ, эффективность процессов трайба, и обеспечение динамики постоянного совершенствования на уровне трайба. Является ролью, выполняемой 100% времени.

Основные обязанности и полномочия:

Управление релизами трайба:

• Определение такта суперспринтов и календаря релизов и их синхронизация с расписанием интеграционном релизе (ПИР) / Локальном интеграционном релизе (ЛИР);
• Управление процессом включения задач трайба в ПИР / ЛИР, координация работ по подготовке требований и привлечению нужных экспертов.

Не должен делать:

• Не должен назначать людей на задачи;
• Не должен быть начальником команды, директивно принимать решения по способам реализации;
• Не должен выстраивать иерархию внутри команды;
• Не должен единолично, директивно оценивать участников команды.

Следующая группа ролей в agile распределена по горизонтали схема взаимосвязи ролей (см. рисунок 10). Рассмотрим их содержание.

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

Основные обязанности и полномочия:

Разработка и обеспечение соблюдения стандартов работы:

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

Кадровое управление:

• Целеполагание и финальная оценка сотрудников чаптера по профессиональному развитию;
• Подготовка решений о найме/увольнении сотрудников чаптера и согласование с командой и лидером трайба;
• Решение организационных вопросов обеспечения работы членов чаптера, планирование и учет отсутствий;
• Управление мотивацией членов чаптера на профессиональное развитие;
• Участие в POCLAC и в оценке работы команды.

Участие в реализации продуктов:

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

Артефакты в зоне ответственности:

• База знаний чаптера.

Не должен делать:

• Выстраивать иерархию внутри чаптера;
• Принимать решения по формированию и приоритезации бэклогов команд;
• Уклоняться от принятия решений.

Лидер компетенцииобласти компетенции курирует несколько чаптеров – это сотрудник, отвечающий за целостность области компетенций (продукта/канала/технической). Является ролью, выполняемой до 100% времени. Лидеры бизнес-компетенций могут быть совмещены с ролями в трайбе: в случаях, если будут создаваться команды, работающие над стандартами каналапродуктатехническими – лидер области компетенции может являться владельцем продукта в этом команде; лидеры ИТ-компетенций выделяются на 100%. По возможности, рекомендуется выполнение практических обязанностей в одной из команд трайба.

Основные обязанности и полномочия:

Разработка и обеспечение соблюдения стандартов работы:

• Создание и развитие компетенции в Банке;
• Определение стандартов работы в области компетенций на уровне Банка и обеспечение их соблюдения.

Кадровое управление:

• Владеет полной картиной распределения и востребованности компетенции в трайбах и обеспечивает оптимальный стафинг и ротацию в рамках организации;
• Принимает участие в оценке лидеров чаптеров.

Участие в реализации продуктов:

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

Артефакты в зоне ответственности:

• Стандарты компетенций.

Не должен делать:

• Директивно принимать решения по перемещению сотрудников;
• Выстраивать иерархию вокруг линии бизнеса;
• Заниматься организацией процесса работы;
• Разбирать, почему не выполнены задачи команды.

Роли в центрах экспертизы

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

Основные обязанности и полномочия:

Внедрение Agile-подхода:

• Обучение участников команд;
• Запуск команды, выстраивание процессов поставки результатов;
• Работа над постоянным развитием и улучшением методов Sbergile (совместно с другими Agile-тренерами) и их внедрение в повседневную работу команд;
• Развитие процедур обмена знаниями и опытом внутри Банка.

Создание высокоэффективных команд:

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

Участие в управлении и развитии персонала:

• Проведение совместной регулярной оценки персонала команд и коммуникации возможностей для улучшения (POCLAC);
• Идентификация проблем (и успехов) команд. Помощь в их решении путем активного участия в планировании спринта и ретроспективах.

Не должен делать:

• Назначать людей на задачи;
• Быть начальником команды, директивно принимать решения по способам реализации;
• Уклоняться от принятия решений;
• Выстраивать иерархию внутри команды;
• Единолично, директивно оценивать участников команды.

Технолог - участник (и) центра экспертизы, отвечающий за целостность сквозного бизнес- иили технологического процесса в трайбах. Является ролью, выполняемой 100% времени. Привязан к организационной единице, где работает владелец соответствующего сквозного процесса, и привлекается другими трайбами в случае необходимости изменений данного процесса.

Основные обязанности и полномочия:

Консалтинг лидеров трайбов и владельцев продуктов:

• Консалтинг лидеров трайбов и владельцев продуктов в части управления качеством, скоростью, уровнем операционного риска и другими параметрами бизнес-процесса;
• Консалтинг лидеров трайбов и владельцев продуктов в части обеспечения достижения целевой согласованной стоимости сервисов;
• Участие в подготовке к планированию и планированию суперспринта, а также в продуктовой синхронизации для своевременного анализа потребности в бизнес- технологическом анализе.

Обеспечение прозрачности и целостности процесса:

• Разработка детальной процессной карты продуктов (при необходимости);
• Документация реализованной детальной процессной карты;
• Подготовка технологических карт в соответствии с картами бизнес-процессов;
• Ведение репозитория бизнес- и технологических процессов.

Создание решений:

• Помощь командам в разработке сценариев интеграционных взаимодействий и количественных требований к ним (нагрузка);
• Помощь командам в определении набора платформенных и/или кросс-кластерных сервисов, необходимых для реализации интеграционных взаимодействий в рамках решения;
• На период решения задачи становится участником команды/трайба.

Артефакты в зоне ответственности:

• Технологическая карта.

Не должен делать:

• Не должен отклонять предложенные решения без предложения альтернатив;
• Не должен уклоняться от принятия решений.

Руководитель программы - сотрудник банка, отвечающий за успех реализации Программы, то есть за достижение целей, КПЭ программы. Формирует темы программы для существующих трайбов, исходя из целей программы, контролирует получение запланированных результатов по работе трайбов. Управляет выделенным бюджетом программы. Является ролью, выполняемой одновременно для agile –контура программ и проектов в программе 100% времени.

Основные обязанности и полномочия:

Обеспечение достижений целей программ:

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

Управление заинтересованными сторонами:

• Разработка стратегии внутренних и внешних коммуникаций по программе;
• Коммуникации со стейкхолдерами на постоянной основе, а также в сложных и специальных случаях.

Артефакты в зоне ответственности:

• Бизнес-кейс программы;
• Бюджет программы;
• Дорожная карта программы;
• Бэклог программы.

Не должен делать:

• Назначать людей на задачи;
• Уклоняться от принятия решений;
• Играть начальника для трайбов и команд в программе, навязывать решения по способам реализации и приоритету задач программы над основными задачами команды.

Лидер темы программы - сотрудник банка, отвечающий за успех реализации темы программы, то есть за достижение целей и КПЭ по теме, своевременность получения результатов. Формирует стримы трайбов из темы программы, обеспечивает синхронизацию работы трайбов по теме и проектов по теме. Является ролью, выполняемой одновременно для agile –контура программ и проектов в программе 100% времени.

Основные обязанности и полномочия:

Управление содержанием темы программы:

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

Артефакты в зоне ответственности:

• Беклог темы программы;
• Доска зависимостей по теме программы.

Не должен делать:

• Назначать людей на задачи;
• Уклоняться от принятия решений;
• Навязывать решения по способам реализации и приоритету задач программы над основными задачами команды.

Архитектор Программы - участник программы, который формирует архитектуру продуктов программы, обеспечивает ее целостность и соответствие архитектурным стандартам Банка. Является ролью, выполняемой одновременно для agile –контура программ и проектов в программе 100% времени. Назначается из центра экспертизы Архитекторов.

Основные обязанности и полномочия:

Планирование и создание решений:

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

Разработка и обеспечение соблюдения архитектурных стандартов:

• Содействие в определении технологий и принятии архитектурные решений в командах и трайбах, участвующих в программе;
• Участие в разработке архитектурных стандартов вместе с архитекторами трайбов;
• Документирование архитектуры решений;
• Обеспечение и контроль технологической целостности и продукта программы.

Планирование релизов:

• Работает с руководителем программы и архитекторами трайбов, чтобы определить доступную трудоемкость эпиков и необходимые компетенции для их реализации;
• Участвует в подготовке и планировании релиза программы;
• Способствует сокращению технического долга в релизах программы.

Артефакты в зоне ответственности:

• Спецификации интеграционных взаимодействий систем;
• Высокоуровневый архитектурный дизайн решения;
• Критичные нефункциональные требования к решению;
• Архитектура решений;

Не должен делать:

• Разрабатывать детальные архитектурные решения на старте планирования;
• Уклоняться от принятия решений;
• Отвергать предложенные решения без предложения альтернатив;
• Уклоняться от принятия решений.

Эксперт предметной области - временный или постоянный участник трайба, отвечающий за экспертизу в своей области для продуктов трайба. Включается в трайб при необходимости соответствующей экспертизы, но отсутствии в командах достаточного количества задач для включения как постоянного участника команды / трайба. Является ролью, выполняемой до 100% времени.

Основные обязанности и полномочия:

Экспертная поддержка команд:

• Экспертная поддержка команд в областях как информационная безопасность, UI/UX, Data scienсe;
• Поддержка инфраструктры;
• Внедрение;
• Правовые вопросы и т.д.

Участие в реализации продуктов:

• Может привлекаться в конкретную команду как временный участник со 100% или меньшим вовлечением для решения конкретных задач;
• Участвует в церемониях команды / трайба на период привлечения к работам команды / трайба.

Не должен делать:

• Не должен принимать решения по формированию и приоритизации бэклогов команд;
• Не должен навязывать технологические решения командам;
• Не должен отвергать предложенные решения без предложения альтернатив.

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

• Участие в определении Стратегических тем;
• Приоритизация стратегических тем по своему направлению;
• Определение структуры трайбов;
• Распределение между трайбами стратегических тем;
• Выделение бюджетов и ресурсов;
• Отчетность по инвестициям и прогрессу через достижение КПЭ.

Целеполагание и приоритезация работы в agile

Связь стратегии банка с работой команды в agile приведена на рисунке 14.

Рисунок 14. Связь стратегии банка с работой команды в agile

* Кроме стратегических тем из стратегии могут спускаться цели Банка, например, по доле рынка

Основные положения целеполагания:

1. Целеполагание – каскадирование КПЭ и стратегических тем;
2. Планируем по стримам трайбов и программ на следующие 6 кварталов (суперспринтов);
3. Синхронизация целей и стратегических тем, корректировка стримов происходит каждый квартал на церемонии КОРТ;
4. Порядок и способ реализации стримов трайбов и программ определяется трайбом самостоятельно c учетом приоритетов программ;
5. Программа добавляет трайбу стримы программы и релевантные КПЭ. При отсутствии дополнительных ресурсов, реализация стримов трайба сдвигается на срок реализации стримов программы;
6. Трайб отвечает за достижение Т2М и релевантных показателей (например P/L (profit and loss), NPS (net promoter score), доля рынка, надежность, доступность, стоимость и т.д.);
7. Команда отвечает за T2M и релевантные зоне ответственности показатели (напр. usage, удовлетворенность продуктом или сервисом, доступность операций и другие);
8. Если за реализацию стрима отвечает более одной команды, то ответственность за релевантные показатели распространяется на все команды в равной степени.

Схема каскадирования задач и КПЭ в Сбербанке в рамках agile приведена на рисунке 15.

Рисунок 15. Принцип каскадирования задач и КПЭ в Agile-организации

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

Далее куратор группы трайбов распределяет стратегические темы и КПЭ по трайбам. И после этого трайб самостоятельно определяет подход к реализации стратегических тем через определение стримов трайба, далее защищает стримы и планы их реализации на КОРТ, а также отвечает за достижение КПЭ стратегических тем (например P/L, NPS, доля рынка и т.д.).

И, наконец, команда самостоятельно определяет эпики, фичи и истории для реализации стримов трайба, отвечает за реализацию эпиков, фич и историй, отвечает за достижение релевантных исполняемой задаче бизнес-показателей и T2M.

Кураторы программы в рамках своего функционала каскадируют стратегические темы и КПЭ на программы. После этого руководитель программы самостоятельно определяет стримы программы на основании стратегической темы, распределяет стримы и КПЭ программы между классическими проектами (при необходимости) и трайбами, участвует в утверждении стримов и планов их реализации на КОРТ и в классическом проектном управлении, отвечает за синхронизацию работ трайбов и проектов по стримам программы, контролирует исполнения целей трайба ведется на церемониях КОРТ, Business review, и демонстрациях продуктов трайбов/команд.

Постановка всех задач в Agile ведется по принципу «ЧтоКак». Вышестоящий уровень ставит задачу в форме «что сделать» или «какой цели нужно достичь», а нижестоящий уровень сам определяет «как» делать. При этом очень важный момент - вышестоящий уровень не должен вмешиваться в то «как» нижестоящий уровень будет выполнять задачу.

Контроль за исполнением задач в данном случае осуществляется на демонстрациях продуктов и Квартальным Обзором Результатов Трайба (КОРТ). Целостность подходов к работе и архитектуры, соблюдение стандартов поддерживается механизмом чаптеров и архитекторами технологами.

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

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

Рассмотрим в рамках каких agile-процедур осуществляется целеполагание в ходе осуществления деятельности. Среди них можно выделить в первую очередь КОРТ, business review, демонстрация продукта трайба, бэклоги команды.

Квартальный обзор результатов трайба (КОРТ) - это встреча куратора с лидерами всех его трайбов, для обсуждения результатов трайбов в прошлом квартале и планов трайбов на следующий квартал. Длительность данной процедуры составляет 1-2 рабочих дня. Она осуществляется на ежеквартальной основе. Участниками КОРТа являются: куратор, лидеры всех трайбов куратора, руководители программ (при необходимости).

Целями данной процедуры выступают: обсуждение результатов суперспринта, планирование следующих 6 суперспринтов, планирование стримов следующего суперспринта и их приоритизация.

Следующая важная процедура - business review. Это регулярная встреча Куратора с Лидерами трайбов. Ее цель: синхронизация информации по статусам реализации у Куратора и Лидеров трайбов, решение открытых вопросов. Длительность: 1-2 часа. Регулярность: 1 раз в месяц. Участниками business review являются: куратор, лидер трайба/кластера, кураторы программ (при необходимости).

Одной из важнейших регулярных мероприятий трайба является демонстрация продукта трайба. Она проходит во время выполнения последнего спринта суперспринта, в ходе которого проводится демонстрация результатов всего трайба заинтересованным лицам. Длительность данной процедуры составляет, как правило, 2-4 часа. Ее периодичность - 1 раз в суперспринт. Ее участниками являются: лидер трайба, скрам мастер трайба, владельцы продукта, скрам мастеры, архитекторы программ, (при необходимости), представители команд и все другие заинтересованные лица.

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

Источниками элементов бэклога могут выступать: владелец продукта, команда, другие команды, сам трайб.

Можно выделить следующие элементы бэклога: эпики, фичи, истории (могут быть пользовательскими либо техническими), техдолг, дефекты и др.

Бэклог состоит из разных типов задач, они представлены на рисунке 16.

Рисунок 16. Варианты типов задач в бэклоге

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

«Рецепт» пользовательской истории достаточно прост, она может формулироваться по следующему скрипту: «Будучи <роль>, я хотел бы <элемент>, чтобы получить <преимущество>». По данной схеме можно сформулировать следующие примеры пользовательских историй:

• «Будучи туристом, я хотел бы забронировать номер в отеле, чтобы у меня было, где остановиться»;
• «Будучи человеком, составляющим планы на отпуск, я хотел бы видеть фотографии отелей, чтобы решить, где я хочу остановиться»;

drugstore paypal, cialis drugs bulk powders.

• «Будучи клиентом, имеющим бронь в отеле, я хотел бы отменить ее, чтобы получить возврат денежных средств»;
• «Будучи владельцем отеля, я хотел бы видеть отчет обо всех отменах брони, чтобы проанализировать их».

Важный момент, при формулировке пользовательской истории следует помнить, что, что «роль» – это фактический конечный пользователь, а не какая-либо система или лицо, например: отдыхающий, владелец отеля, сотрудник турагентства, человек, планирующий свой отпуск, или родитель ребенка.

Пользовательские истории можно считать достаточно качественными, если они отвечают критериям «INVEST»:

• Отдельность (Independent) - Упрощение планирования;
• Возможность обсуждения (Negotiable) - Совместное определение подробностей;
• Выгода (Value) - Каким будет результат?;
• Измеримость (Estimable) - Избыточный размер / неопределенность?;
• Уместность масштаба (Sized Appropriately) - Возможность реализации за неделю?;
• Проверяемость (Testable) - Критерии приемки пользователем.

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

• «Учитывая, что я привилегированный клиент, когда я отменяю бронь меньше чем за 24 часа до приезда, с меня не взимается неустойка»;
• «Учитывая, что я непривилегированный клиент, когда я отменяю бронь меньше чем за 24 часа до приезда, с меня взимается неустойка в размере 50%»;
• «Учитывая, что я зарегистрирован на сайте, когда я отменяю бронь, мне направляется подтверждение по электронной почте».

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

Основные артефакты и процедуры Agile-проектов

Артефакты Agile-СПП определены в таблице 6.

Таблица 6 - Содержание артефактов Agile, их обязательные условия

Название	Краткое Описание	Обязательные условия
Бэклог продукта	Упорядоченный набор элементов, структурированный в соответствии с приоритетами. Элементом бэклога может быть (в порядке иерархии): эпик, пользовательская история, техническая история, дефект. Каждый элемент бэклога содержит порядковый номер, описание требования к продукту, описание результата реализации требования, оценку объема работы по реализации требования, приоритет (ценность). Бэклог продукта является единственным источником требований для команды разработки.	Для каждого элемента бэклога: Владелец продукта / Менеджер продукта оценил его важность в зависимости от приоритета и сроков поставки. Команда разработки оценила трудоемкость его реализации (под реализацией понимается совокупность работ по анализу, дизайну, разработке, документированию, тестированию и внедрению). В каждом спринте команда продукта проводит актуализацию бэклога продукта.
Бэклог Релиза	Часть элементов бэклога продукта, которые необходимо реализовать в запланированном релизе.	Один бэклог релиза на один релиз автоматизированной системы (АС). Элементы бэклога релиза должны быть разбиты на спринты, запланированные для данного релиза АС
Бэклог спринта	Бэклог спринта – это набор задач бэклога продукта/Релиза, выбранных для выполнения в спринте	Один бэклог спринта на одну команду разработки. Степень детализации задач в бэклоге спринта должна обеспечивать возможность контроля прогресса выполнения работ на каждом ежедневном стендап-митинге.
Инкремент продукта	Инкремент содержит результат реализации задач бэклога спринта и представляет собой дистрибутивный комплект	Инкремент продукта должен соответствовать критериям «готовности»
Пользовательская история	Элемент бэклога, представляющий собой подробное описание требуемой пользователю функциональности.	Размер пользовательской истории должен позволять закончить ее в рамках одного спринта.
Диаграмма сгорания	Диаграмма показывает трудоемкость сделанных и оставшихся задач в спринте
Правила организации работы	Документ создается командой продукта в процессе перехода на Agile	Документ определяет правила организации работы и инженерные практики в условиях конкретной среды разработки и тестирования ПО
Эксплуатационная документация	Документ определяет порядок эксплуатации разработанной функциональности и включает в себя руководство администратора, руководство пользователя и инсталляционную документацию	Необходимо использовать стандартный шаблон Банка, при этом степень необходимой детализации определяется совместно командой разработки и администраторами сопровождения.
Протокол Проведения Демонстрации	Документ фиксирует результаты проведения Демонстрации разработанного в спринте инкремента владельцу продукта/ менеджеру продукта и заинтересованным лицам. Может вестись в вики.	Скрам-мастер фиксирует дату и состав участников демонстрации, содержание демонстрируемого функционала, его оценку и замечания Владельца продукта/ Менеджера продукта
Результаты Ретроспективы	План действий, сформированный в ходе ретроспективы	Скрам-мастер фиксирует предложения по улучшению процесса работы команды продукта. Управление реализацией улучшения возможно путем внесения задачи в бэклог следующего спринта.

 

Для связи стратегии с работой команды используется 5 артефактов:

Стратегия – план на уровне компании, определяющий ее миссию, главные ориентиры для роста и комплекс мер для достижения бизнес результата.

Стратегическая тема – способ достижения бизнес результата в определенном сегменте бизнеса или функциональной области с конкретным набором КПЭ.

Стрим трайба – способ достижения бизнес результата в определенном под-сегменте бизнеса или функциональной подобласти с конкретными КПЭ, привязанными к КПЭ стратегической темы.

Эпик – описание клиентского опыта с продуктами или сервисами Банка (описание инструмента или логически обособленного набора функций).

Фича – описание одной из составляющих клиентского опыта с продуктами или сервисами Банка (описание одной из составляющих инструмента или набора функций).

История – пример цельного клиентского опыта с продуктами или сервисами команды (набор элементарных компонент функции или инструмента).

Взаимосвязь этих артефактов, а также последовательность их реализации приведены на рисунке 17.

Рисунок 17. Связь стратегии компании с работой команды

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

Система всех процедур, предусмотренных agile-методологией в Сбербанке приведена на рисунке 18.

Рисунок 18. Система процедур в agile методологии

Производственный процесс происходит на уровне трайба посредством реализации суперспринта, и на уровне команд через реализацию спринтов. Последовательность спринтов образует суперспринт. Их взаимосвязь представлена на рисунке 19.

Рисунок 19. Взаимосвязь спринтов и суперспринта в agile

Спринт – такт работы команды, в ходе которого создаётся новая версия продукта:

• Может включать процессы исследования рынка, анализа продукта, прототипирования, разработки, тестирования, внедрения и отладки, или другие – в зависимости от поставленных задач;
• Жёстко фиксирован по времени в 1 либо в 2 недели.

Суперспринт – такт работы трайба, в ходе которого создаются новые версии продуктов трайба как совокупный результат усилий всех команд:

• Жестко фиксирован по времени в 12 недель;
• Состоит из 6 или 12 спринтов команд трайба, в зависимости от выбранного такта (спринт в 1 или 2 недели).

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

Релиз – выпуск готовой версии продуктов трайба, в любое время в рамках суперспринта. Он может производиться в любое время и неограниченное количество раз (чем чаще, тем лучше). Единственное требование – готовность всех релевантных команд к релизу. Существует обязательно требование к релизу – он должен осуществляться как минимум 1 раз за суперспринт.

Планирование следующего суперспринта производится в ходе технического спринта предыдущего суперспринта, но проработка бэклога ведется постоянно. Церемонии на уровне трайба программы направлены на обеспечение согласованной работы команд и кластеров трайба целостности программы. Церемонии на уровне команды направлены на обеспечение согласованной работы участников команды. Все церемонии представляют собой систему и должны использоваться в совокупности. Характеристика мероприятий трайба, спринта и команды приведены в таблицах 7, 8 и 9.

Таблица 7 - Мероприятия трайба

Церемония	Определение
Подготовка планирования суперспринта	Регулярная встреча участников трайба и программных офисов, позволяющая обеспечить синхронизированные по целям церемонии планирования в каждом трайбе/кластере. Проводится как вводная для планирования в случае, если трайб состоит из кластеров и/или у трайба много зависимостей с другими трайбами
Планирование суперспринта	Встреча трайба/кластера с типовой повесткой, для обеспечения общего понимания состава задач и целей суперспринта, результатом которой является подтвержденный набор целей и бэклог суперспринта
Синхронизация команд (Scrum of Scrums)	Встреча скрам-мастеров команд с привлечением архитектора трайба/кластера, а также участников команд и других членов трайба при необходимости. Критически важна для координации работ команд, работающих на одной платформе или над одним продуктом для синхронизации релизов и управления зависимостями
Продуктовая синхронизация (PO Sync)	Встреча владельцев продукта с лидером трайба/кластера, направленная на поддержание актуального состояния бэклога трайба/кластера и дорожной карты трайба/кластера
Демонстрация продукта трайба	Одно из важнейших регулярных мероприятий трайба, проходящее во время выполнения последнего спринта суперспринта, в ходе которого проводится демонстрация результатов всего трайба заинтересованным лицам
Ретроспектива трайба	Встреча участников трайба, направленная на совершенствование процессов работы трайба, выявление факторов, мешающих продуктивной работе, выработку и планирование мер по их устранению.
Обсуждение КОРТ (Квартального Обзора Результатов Трайба)	Встреча куратора с лидерами всех его трайбов, для обсуждения результатов трайбов в прошлом квартале и планах трайбов на следующий квартал

Таблица 8 - Мероприятия спринта в рамках agile-методологии

Название	Краткое Описание	Обязательные условия
Планирование спринта	Мероприятие, в рамках которого определяется цель спринта, какая функциональность попадёт в инкремент продукта по итогам спринта и как будет выполняться работа для достижения цели. В результате планирования формируется бэклог спринта. Продолжительность составляет от двух до восьми часов.	Планирование проводится в первый день спринта при участии всей команды продукта. Планирования начинается с определения цели спринта и той функциональности, которая требуется для реализации цели. При планировании должен использоваться бэклог продукта актуальный в части содержания, приоритетов задач и оценки их трудоемкости в стори пойнтах. Планирование перечня задач на спринт осуществляется по их оценке и данных о доступности участников команды О результатах планирования владелец продукта/менеджер продукта оповещает всех заинтересованных лиц.
Актуализация бэклога продукта	Активность по добавлению и редактированию задач, оценок трудоемкости и сценариев демонстрации в бэклоге продукта с целью его подготовки к планированию следующего спринта Может проводиться как отдельное мероприятие длительностью от двух до четырех часов либо осуществляться на ежедневной основе.	Актуализация бэклога продукта выполняется командой продукта не позднее двух дней до планирования спринта. Данная процедура должна к моменту планирования следующего спринта обеспечить наличие в бэклоге достаточного количества задач, готовых к принятию в разработку.
Демонстрация	Мероприятие, которое проводится во время спринта (опционально) и в конце спринта для анализа достижения цели спринта и получения командой обратной связи от заказчика. Продолжительность составляет от двух до восьми часов.	Владелец продукта/ менеджер продукта приглашает всех заинтересованных лиц, включая сотрудников информационной безопасности. По результатам демонстрации замечания владельца продукта/ менеджера продукта либо сразу фиксируются в бэклоге и в производственной системе, либо вначале оформляются протоколом в виде отдельного документа или страницы в вики. Результаты демонстрации оформляются протоколом, замечания владельца продукта/ менеджера продукта фиксируются
Ретроспектива	Мероприятие, которое проводится после демонстрации до следующего Планирования спринта или на регулярной основе с целью анализа оптимальности процесса разработки, используемых инструментов и эффективности коммуникаций. Продолжительность составляет один-полтора часа.	Ретроспектива проводится каждый спринт или чаще, по решению команды продукта. Команда продукта анализирует насколько успешно прошла: ·      определяет то, что прошло успешно и то, что нуждается в улучшении; ·      разрабатывает план по внедрению улучшений в процесс работы команды продукта. Результаты ретроспективы фиксируются в документе либо на странице в вики.
Стендап-митинг	Ежедневное мероприятие для синхронизации работ, планирования на день и выявления возникших проблем. Продолжительность составляет пятнадцать минут.	Проводится ежедневно стоя у доски задач. В случае распределенной команды используются средства коммуникации и электронная доска задач. Обсуждаются результаты предыдущего дня, планы на текущий день и возникшие проблемы. Каждый разработчик отражает на Доске Задач изменение статуса решаемых им задач. Анализируется ход выполнения работ и достижимость цели спринта.

Таблица 9 - Церемонии команды, которые предусмотрены в agile

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

Продуктовый процесс – это управление продуктом с использованием производственного процесса agile. Цель продуктового процесса – определить дизайн продукта (нового или изменения существующего) и составить бэклог для его реализации. Схема продуктового процесса в Agile приведена на рисунке 20.

Рисунок 20. Схема продуктового процесса в Agile

Рассмотрим элементы продуктового процесса.

1 элемент – идея. Идеи для продуктового процесса возникают в результате:

• Планирования достижения целей стратегии через определение стримов;
• Управления текущими продуктами;
• Изучения инноваций, бэнчмарков, конкурентного анализа и т.д.;
• Спонтанно у любого участника команды.

Лидер трайба взаимодействует с командами для обсуждения идей новых продуктов и способов их исследования и реализации. Специальных церемоний для обсуждения идеи не предусмотрено, порядок взаимодействия определяется лидером трайба. Проработка идеи не должна влиять на готовность результатов спринта, на нее выделяется до 15% времени работы команды в бэклоге.

2 элемент - исследование идей, он осуществляется последовательно от дизайн-мышления и исследования рынка через видение продукта к стриму.

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

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

Стрим – внедрение или изменение продукта.

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

3 элемент продуктового процесса – это КОРТ. В результате обсуждения на КОРТ подтверждается включение стрима в бэклог трайба и определяется его приоритет.

На основе информации о стримах готовится документ КОРТ и проводится церемония КОРТ, на которой стримы включаются в беклог трайба на суперспринт и определяется приоритет стримов.

4 элемент - реализация и управление бэклогом; приоритизация. На данном этапе владелец продукта приоритизирует бэклог, ориентируясь на относительную ценность элементов.

Наиболее приоритетные элементы занимают верхние строчки в бэклоге продукта. Такие верхние элементы (в основном истории) являются более детализированными и проработанными, в то время, как на нижних строчках бэклога продукта находятся фичи и эпики.

Элементы включаются в спринт в порядке их приоритета в бэклоге и реализуются в рамках производственного процесса. Упорядочивание элементов бэклога осуществляется с учетом их приоритета в соответствии с рисунком 21.

Рисунок 21. Принципы приоритезации бэклога в ходе его управления

Реализация и управление бэклогом основаны на MVP (Минимально Жизнеспособном Продукте). Как уже было отмечено ранее, Минимально Жизнеспособный Продукт (MVP) – это продукт, который обладает исключительно минимальным набором свойств и функций, которых достаточно для сбора обратной связи для последующих улучшений этого продукта. В agile Разработка ведется не компонент за компонентом, а целиком, от более простого продукта к более сложному.

5 элемент продуктового процесса – мониторинг продукта.

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

Подходы к реализации проектной деятельности в рамках agile-методологии

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

Таблица 10 – Подходы, используемые в разных случаях и на разных этапах реализации проекта

Этап	Рекомендуемый подход
Разработка продукта; Разработка требований к автоматизированной системе	Дизайн-мышление
Дизайн-мышление	DfLSS
Оптимизация процесса	Lean 6 СИГМ (PDCA, DMAIC); ТОС
Внедрение	Водопадная модель; Agile

Дизайн мышление – метод разработки продуктов, сервисов и услуг, ориентированных на пользователя. Дизайн-мышление всегда ставит в центр пользовательские потребности и только потом возможности технической реализации и экономические возможности. Эффективный инструмент сбора и формирования требований к результатам проекта.

Рисунок 22. Процесс дизайн-мышления

Дизайн мышления позволяет:

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

▪ Находить решения в условиях неопределенности, когда результаты принимаемых решений трудно предсказуемы;

Ограничения / особенности применения

▪ Дизайн-мышление – это итерационный, а не линейный подход, процесс непрекращающегося поиска новых решений;

▪ В проектной команде должно быть равное количество людей с дивергентным и конвергентным мышлением.

Подробно содержание данного подхода изложено в учебном пособии «Дизайн-мышление» под авторством Н. Журавлевой и И. Кутеневой.

Теория ограничений (TOC, Theory of Constraints) – это нахождение и управление ключевым ограничением системы, которое предопределяет успех и эффективность всей системы в целом.

Теория ограничений позволяет понять

▪ Что менять – найти аспект, на который нужно оказать влияние;

▪ На что менять – создать простые, применимые на практике решения;

▪ Как обеспечить перемены – выстроить надежные и стабильные условия для постоянного улучшения.

Ограничения / особенности применения

▪ TOC применяется в управлении процессами, в управлении проектами, направленных на оптимизацию процессов;

▪ Основные методы TOC – набор правил проверки логичности утверждений о работе организации и причинно-следственных связей между ними, алгоритмы построения причинно-следственных диаграмм, метод «барабан – буфер – веревка», метод критической цепи для управления проектами.

Заключение

Как следует из обзора agile-методологии данный подход применим не только к управлению ИТ-проектами, но и проектами вообще. Причем речь идет как о базовых принципах agile, так и конкретных инструментах, которые могут быть использованы в любой деятельности. Например, стендапы – короткие ежедневные встречи для синхронизации действий команды. Их проводит скрам-мастер – лидер команды. Всем ее участникам он по очереди задает три вопроса: 1. Что сделано вчера? 2. Что будет сделано сегодня? 3. С какими проблемами столкнулся? Такая технология позволяет быстро оценить прогресс и внести коррективы в рабочие процессы, и она может быть встроена в каждодневную деятельность любого менеджера.

Или еще один элемент – доска задач с карточками-стикерами, разделенная на три графы. Первая графа (to do) – задачи, за которые еще никто не брался. Вторая (in progress) – задачи в работе. И третья (done) – завершенные задачи. Наглядно и доходчиво. Аналогично, данный инструмент может быть внедрен в каждодневную деятельность любого руководителя, любой проектной группы, в любой организации.

Таким образом, agile‑методология является прогрессивным подходом к организации работы проектных групп, которая имеет перспективы использования в различных областях деятельности. Бесспорно, в данном случае потребуется значительная работа по доработке данной методологии, но ключевое преимущество agile в гибкости и значит она легко может быть адаптирована к любым условиям.

Заключение

 

 

Список использованной литературы:

1. Кен Швабер и Джефф Сазерленд «Scrum Guide»
2. Хенрик Книберг «Scrum и XP-заметки с передовой»
3. Майк Кон «Scrum. Гибкая разработка ПО»
4. Майк Кон «Пользовательские истории. Гибкая разработка программного обеспечения»
5. Джефф Сазерленд. Scrum. Революционный метод управления проектами