CC BY
197ПРОГРАММНОЕ И ОРГАНИЗАЦИОННОЕ ОБЕСПЕЧЕНИЕ РЕАЛИЗАЦИИ AGILE PROJECT MANAGEMENT НА ПРИМЕРЕ ПАО
«СБЕРБАНК»
SOFTWARE AND ORGANIZATIONAL SUPPORT FOR AGILE PROJECT MANAGEMENT ON THE EXAMPLE OF PJSC "SBERBANK"
УДК 005
DOI: 10.24411/2658-4964-2020-1087 Кагерманов Ш.Ш., студент, 2 курс магистратуры, факультет «Информационные технологии», Российский Технологический Университет МИРЭА, Россия, г. Москва Kagermanov S.S. lo.sogeking@mail.ru
Аннотация
В статье рассматриваются методы управления проектами по разработке программного обеспечения на проектах ПАО «Сбербанк». Дан обзор основных концепций, приведено определение ключевых понятий гибкой методологии. Описаны инструменты реализации Agile Project Management. Описана адаптация Agile под технологический процесс ПАО «Сбербанк» — Sbergile. Описан переход на новую методологию разработки. Даны конкретные примеры в сфере банковской деятельности ПАО «Сбербанк». Описаны церемонии гибкой методологии на примере Sbergile. Произведено описание бизнес-процессов. Построена бизнес-модель процесса управления ИТ проектом.
Summary
The article uses agile project management methods on the example of PJSC Sberbank. An overview of the main methods is given, a definition of flexible development methods is given. The technologies and frameworks for using these methods are described. The adaptation of Agile to the technological process of Sberbank PJSC "Sbergile" is described. The transition to a new development methodology is described. Concrete examples are given in the field of banking and enterprise management in PJSC "Sberbank". A description of the accounting business processes of the enterprise is made. A business model of the IT project management process is built.
Ключевые слова: жизненный цикл, agile, sbergile, проектирование программ, управление проектами, хранилище данных, артефакт, нотации, бизнес-процессы
Keywords: life cycle, cascade method, agile, sbergile, е program design, project management, data storage, artefact, notation, business processes
Введение
На сегодняшний день Сбербанк — крупнейший банк в России, Центральной и Восточной Европе, один из ведущих международных финансовых институтов. В региональную сеть Сбербанка входят 11 территориальных банков с 14 200 подразделениями в 83 субъектах РФ. В составе зарубежной сети Группы Сбербанк — дочерние организации, филиалы и представительства в 18 странах мира.
В ПАО «Сбербанк» проводятся радикальные изменения рабочего процесса. Ключевым аспектом является реформа подхода к развитию продуктов компании. Основываясь на опыте европейский финансовых институтов и передовых корпораций Кремниевой долины, банк сконструировал уникальную модель работы, включающую в себя основные принципы Agile — гибкой методологии разработки. Компания изобрела новый фреймворк реализации Agile Project Management и назвала его Sbergile.
Особенности использования Agile на проектах Сбербанка
Компания в своих публикациях отмечает, что Agile — не панацея, а всего лишь один из способов достижения целей. Он позволяет сохранять конкурентоспособность в период резкого увеличения числа финтех-стартапов. Об актуальности и популярности использования финтех-сервисов в России свидетельствует диаграмма со статистическими показателями, которую составила аудиторская компания Ernst & Young. Россия занимает 3-е место миру.
FIGURE 1 | Consumer FinTech adoption across 27 markets
Рис 1. Диаграмма уровня распространения финтех-сервисов во всем
мире
Согласно стратегии Сбербанка на 2020 год, которую утвердил Наблюдательный совет, ключевыми приоритетами развития являются:
• Лучший клиентский опыт и экосистема;
• Технологическое лидерство;
• Люди нового качества в эффективных командах.
Рассмотрим детальнее специфику работы компании по Sbergile.
Свыше 12 000 сотрудников разделены на трайбы (от английского tribe
— племя). Трайб — это общая структура команд, объединенных вокруг определенной общей бизнес-цели. Возьмем для примера развитие карточной продукции. «Карточная» в данном контексте — условное обозначение, так как в рамках этого направления рассматриваются любые способы оплаты, включая смартфоны, эквайринг, NFC-кольца и так далее. Основой все еще являются стратегии развития банка, из которых как раз и вытекают цели трайба. Они формируются лидерами трайбов при непосредственном участии топ-менеджмента банка.
С периодичностью в квартал кураторами и трайбов обсуждаются цели на ближайшие три месяца. В рамках встречи встрече лидеры трайбов синхронизируются между собой, проговаривают результаты прошедшего квартала и планы на предстоящий. После этого команды разбивают цели на
конкретные задачи в бэклоге и делят на спринты (итерация работы команды, в ходе которой создаётся новая версия продукта).
В трайбе может состоять от сотни до нескольких сотен человек . На данный момент в банке функционируют более 20 трайбов. Вот примеры некоторых из них: «Платежи и переводы», «Эквайринг и банковские карты», «Занять и сберегать», Digital business Platform — «Сбербанк Онлайн», мобильное и веб-приложение для разных устройств. Они сочетают в себе как самостоятельные продукты, так и каналы для других продуктов компании.
Структурной единицей племени является команда, а единицей команды
— специалист. Внутри трайба может быть от 5 до 25 команд. Каждая команда состоит из 9-12 человек, которые в разных соотношениях образуют категории
— бизнес и ИТ. Один из принципов Agile говорит о необходимости прямой и регулярной коммуникации между бизнесом и исполнителем. Такая разбивка по командам идеально удовлетворяет данному требованию, что несомненно ускоряет работу.
Формирование бэклога проекта.
Перед тем, как организовать рабочую деятельность по созданию продукта, необходимо провести сбор и анализ потребностей клиента. Бэклогом проекта называется список конкретных задач, выполнение которых приведет к созданию версии продукта.
Sbergile не запрещает постановку долгосрочных целей, но при составлении бэклога наиболее детально следует проработать элементы, которые войдут в первые 1 -2 спринта. Элементы для следующих спринтов можно описывать с меньшей степенью детализации — скорее всего, они потребуют доработки с учетом обратной связи [20].
Выходным артефактом формирования бэклога служат структурированные по блокам задачи. Теперь предстоит выставить им приоритет.
Приоритезация элементов бэклога — актуальная и сложная задача при планировании работы Agile-команды. Кажется, что всегда есть аспекты, упрощающие этот процесс — сроки, зависимости между задачами в бэклоге, объем задачи. Однако все предположения о ценности или трудозатратности элемента очень приблизительны. Существуют инструменты, позволяющие конкретизировать процесс приоритизации и придать иерархии элементов числовые значения. Рассмотрим в применении один из популярных инструментов — система оценки Weighted Shortest Job First. Чем выше коэффициент WSJF, тем выше приоритет у задачи.
Рис 2. Система оценки Weighted Shortest Job First.
Элементы системы:
• Ценность для клиента/бизнеса (User-Business Value) — фактор,
отвечающий за полезность выполнения конкретной задачи для клиента и бизнеса.
• Фактор времени (Time Criticality) — критичность выполнения задачи в первую очередь. В условиях повышенной конкуренции, чтобы успеть к установленному дедлайну (что в проектах Agile является трудновыполнимой задачей) или дать возможность для работы над зависимыми задачами.
• Уменьшение рисков или реализация возможностей (Risk Reduction or Opportunity Enablement) — отражает, как исполнение конкретной задачи уменьшит риски или какие возможности откроет.
• Размер, продолжительность работы (Job Duration, Job Size) — оценивают в часах на одного человека, требуемого для выполнения задачи, либо в относительных пунктах (Story points).
Оценивая приоритет задачи (ее размер в частности) команды в основном оперируют именно относительной единицей измерения Story points (далее SP).
Главная особенность SP — единица измерения не привязывается к конкретному промежутку времени (дни, часы). Вместо этого применяют относительную единицу, которая не позволяют обозначить конкретное время на разработку, но помогает очень быстро и эффективно выставить приоритет задачи [16].
Метрика SP противопоставляется оценке в «идеальных инженерных днях». Идеальный инженерный день — это вес задачи в объеме дней, требуемых на ее выполнение «средним разработчиком». В данном методе «день» называется «идеальным» в связи с рисками и вероятностью допустить ошибку при разработке.
Проблема данного метода в сильной привязке к навыкам конкретных разработчиков. Необходимо держать в уме, какой конкретно специалист будет выполнять задачу. Придется учитывать экспертность специалиста — в какой сфере он специализируется, каким набором технологий владеет, уровень экспертизы и т.д. Это возможный, но долгий и сложный путь. Особенно, если бэклог уже имеет в себе большой объем задач — ведь это значит, что каждая задача требует более детального разбора, анализа её особенностей и общения с каждым экспертом, который участвует в оценке задачи.
Для современных бизнес процессов в сфере банка характерна высокая неопределенность, редко все идет по плану. Это связано с появлением новой информации, добавлением требований и т.д. Попытка предугадать каждый аспект приводит к тому, что либо нарушаются установленные сроки, либо увеличивается количество переработок, чтобы втиснуться в них. Обе проблемы решаются в альтернативном подходе к оценке — относительной оценке в Story Points [15].
Для создания, ведения и модификации конкретного выходного артефакта «задача» и «бэклог» на рынке присутствуют следующие инструменты:
• Atlassian JIRA. Решение Jira Software разработано таким образом, чтобы каждый член вашей команды разработчиков мог планировать и отслеживать статус запланированных задач [21]. Широко применяется в корпоративной разработке, имеет большой набор диаграмм, панелей быстрого доступа и механизмов визуализации рабочего процесса, структурной единицей которого является «задача».
Рис. 3. Доска задач в Atlassian JIRA • Trello. Одна из самых популярных систем управления проектами в режиме онлайн. Имеет меньшее разнообразие инструментов визуализации, но простотой и доступностью функционала идеально подходит для работ небольших команд и продуктов.
Рис. 4. Доска задач в TreПa Планирование спринта
Имея приоритезированный бэклог, команда под руководством владельца продукта выбирает задачи, которые они будут выполнять в течении следующих 2 или 3 недель (в зависимости от установленной длины спринта.
Чтобы оценить, какой объем работы действительно можно выполнить за установленное время, используют показатель скорости команды. Это среднее количество SP, выполняемых командой в спринт. Стоит отметить, что применение данного метода в начале проекта невозможно, так как вес SP рознится от проекта к проекту и опыт команды по разработке предыдущего продукта не может быть переиспользован.
Стоит уделить особое внимание формированию целей спринта на планировании. Цель спринта должна обозначать конкретное действие, по выполнению которого у пользователь получит пользу для бизнеса. Например, «дать возможность пользователю указывать лимит по продукту» или «провести рефакторинг главной экранной формы продукта».
Цели должны формироваться по методу SMART [16]. Критерии цели по SMART:
1. S - Specific. Цель должна быть ясной, учитывать специфику, актуальной и имеющей отношение к делу, бизнесу.
2. M - Measurable. Цель должна быть измеримой. Зачастую на проектах измеряют прогресс цели в процентах абсолютно абстрактно, не привязываясь к конкретным артефактам.
3. А - Achievable. Цель должны быть достижимой. Это говорит больше о том, что амбициозные, крупные цели стоит декомпозировать до тех пор, чтобы их достижение действительно укладывалось в один спринт.
4. R - Relevant. Цель должна быть согласована с основными целями компании и планами по разрабатываемому продукту.
5. T - Time bound. Цель должна иметь срок для подведения промежуточных и для конечных итогов
Ежедневный утренник.
Церемония имеет множество названий — дэйли, стендап, пятиминутка, утренник. Мы будем придерживаться терминологии, принятой в банке. Данная встреча проходит утром каждый день в течении спринта. Перед первым утренником формируется доска с целями и задачами, которые на планировании выбрали для выполнения в текущем спринте. Данный инструмент популярен в фреймворке Kanban, отчего получил название kanban-доска.
Гибкая методология разработки уделяет особое внимание наличию осязаемой и наглядной доски. Этот подход позволяет команде иметь четкое визуальное представление о прогрессе каждой задачи в спринте.
Встреча длится около 15 минут и проходит обязательно стоя. Она индивидуальна для каждой команды. Каждый участник рассказывает о прогрессе его работы, отвечая на три вопроса:
1. Что я делал для достижения цели спринта вчера?
2. Что буду делать сегодня?
3. С какими проблемами и препятствиями я столкнулся?
По итогам встречи бумажки с целями перемещаются по жизненному циклу спринта, сигнализируя о соответствующем прогрессе.
Демонстрация.
Презентация заказчику результатов спринта. Происходит показ разработанного функционала на примере MVP (Minimum Viable Product — минимальный жизнеспособный продукт). В данной встрече сосредоточена вся суть гибкой методологии — заказчик видит продукт в каком-то его формате и может дать обратную связь. Коммуникация впервые совершается не в момент сдачи функционала через месяцы кропотливого труда, а уже через спринт (иногда 2-3). Это дает возможность с минимальными потерям внести коррективы в активную стадию разработки, а также гарантирует, что разрабатываемое программное обеспечение не потеряет актуальность.
Квартальный обзор результатов трайбов.
Встреча, на которой происходит синхронизация между трайбами и переоцениваются поставленные глобальные приоритеты проекта. Участниками являются лидеры трайбов, руководители ИТ- и бизнес-подразделений.
Для эффективной работы любого фреймворка предпочтительно иметь весь штат сотрудников в одном офисе. В современных реалиях на крупных проектах это условие почти невозможно соблюсти, отчего возрастает необходимость создать среду, в которой все участники могут легко и непринужденно проводить коммуникации вне зависимости от количества участников встречи. Внутри каждого трайба для общения выбирается та среда, которую предпочтет коллектив.
Заключение
В связи с тем, что конкуренция не перестает возрастать, и время выхода программного обеспечения на рынок сокращается, гибкие методологии предлагают огромные преимущества и минимальные недостатки. Показатели гибкого внедрения будут продолжать расти во всех отраслях по всему миру. ПАО «Сбербанк» успешно «оседлал волну» Agile Project Management и выстроил рабочей процесс по канонам методологии, добавив свои усовершенствования и новаторские элементы.
Литература
1. Стеллман, Эндрю. Постигая Agile. Ценности, принципы, методологии / Эндрю Стеллман, Дженнифер Грин; пер. с англ. С. Пасерба — М. : Манн, Иванов и Фебер, 2017. — 448 с.
2. Бринкер С. Agile-маркетинг / С. Бринкер — «Манн, Иванов и Фербер (МИФ)», 2016.
3. Деннинг С. Эпоха Agile / С. Деннинг — «Манн, Иванов и Фербер (МИФ)», 2018
4. Д. Визуализируйте работу / Д. Деграндис — «Манн, Иванов и Фербер (МИФ)», 2017 — (МИФ Бизнес)
5. Криспин Л. Agile-тестирование. Обучающий курс для всей команды / Л. Криспин — «Манн, Иванов и Фербер (МИФ)», 2015
6. Лоффлер М. Ретроспектива в Agile / М. Лоффлер — «Манн, Иванов и Фербер», 2018 — (МИФ Бизнес)
7. Фунтов В. Н. Agile. Процессы, проекты, компании / В. Н. Фунтов — «Питер», 2019 — (IT для бизнеса)
8. Шохова З. Путь скрам-мастера. #ScrumMasterWay / З. Шохова —
9. «Манн, Иванов и Фербер (МИФ)», 2017
10. Пихлер Р. Управление продуктом в Scrum. Agile-методы для вашего бизнеса / Р. Пихлер — «Манн, Иванов и Фербер», 2017
11. Андерсон Д. Канбан. Альтернативный путь в Agile / Д. Андерсон — «Манн, Иванов и Фербер (МИФ)», 2016
12. Воропаев В.И., Гельруд Я.Д., Клименко О.А. Управление проектами для стейкхолдеров. Математические модели и методы управления проектами с позиций разных заинтересованных сторон. — Саарбрюккен: Lambert Academic Publishing, 2015. — 230 с.
13. Статья «Agile, scrum, kanban: в чем разница и для чего использовать?» [Электронный ресурс] // Официальный сайт электронного издательства «Rusbase» URL: https://rb.ru/story/agile-scrum-kanban
Literature
1. Stellman, Andrew. Comprehending Agile. Values, Principles, Methodologies / Andrew Stellman, Jennifer Green; trans. from English S. Pasherba - M.: Mann, Ivanov and Feber, 2017 .-- 448 p.
2. Brinker S. Agile marketing / S. Brinker - "Mann, Ivanov and Ferber (MIF)", 2016.
3. Denning S. Age of Agile / S. Denning - "Mann, Ivanov and Ferber (MYTH)", 2018
4. D. Visualize the work / D. Degrandis - "Mann, Ivanov and Ferber (MIF)", 2017 - (MIF Business)
5. Crispin L. Agile testing. Training course for the whole team / L. Crispin -"Mann, Ivanov and Ferber (MIF)", 2015
6. Loffler M. Retrospective at Agile / M. Loffler - "Mann, Ivanov and Ferber",
2018 - (MIF Business)
7. Pounds V.N. Agile. Processes, projects, companies / V.N. Funtov - "Peter",
2019 - (IT for business)
8. Shokhov Z. The path of the scrum master. #ScrumMasterWay / Z. Shokhov -
9. "Mann, Ivanov and Ferber (MIF)", 2017
10. Pichler R. Product Management in Scrum. Agile methods for your business / R. Pichler - "Mann, Ivanov and Ferber", 2017
11. Anderson D. Kanban. An alternative way to Agile / D. Anderson - "Mann, Ivanov and Ferber (MIF)", 2016
12. Voropaev V.I., Gelrud Y.D., Klimenko O.A. Project management for stakeholders. Mathematical models and methods of project management from the perspective of different stakeholders. - Saarbrücken: Lambert Academic Publishing, 2015 .-- 230 p.
13. Article "Agile, scrum, kanban: what is the difference and what to use for?" [Electronic resource] // Official website of the Rusbase electronic publishing house URL: https://rb.ru/story/agile-scrum-kanban
