Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCRUM в госбанках
•Transferir como PPTX, PDF•
1 gostou•540 visualizações
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (10)
Semelhante a Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCRUM в госбанках
Semelhante a Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCRUM в госбанках (20)
Mais de ScrumTrek
Mais de ScrumTrek (20)
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCRUM в госбанках
- 1. «AGILE СРЕДИ ВОДОПАДОВ» ОПЫТ ВНЕДРЕНИЯ AGILE В ГОСУДАРСТВЕННОМ БАНКЕ 15 марта 2016
- 2. 2 О чем мы расскажем 1. 2. Как мы его строили 3. Через что прошли 4. Чему научились Наш путь к SCRUM
- 3. 3 С чего все началось
- 4. 4 Что надо было сделать Риски на финансовых рынках Рыночный риск Кредитный риск Независимый контроль
- 5. 5 Почему обычно waterfall • Проект – это не только IT • «Колодцы» • Риски • Согласованность • Контроль • Зрелость
- 6. 6 Зачем нужен был SCRUM Высокая изменчивость финансовых рынков Time to market Регулярные изменения методологии оценки рисков
- 7. 7 Что помогло Green field Низкая формализация процесса разработки Вовлеченность Высокая экспертиза
- 8. 8 1. Наш путь к SCRUM 2. 3. Через что прошли 4. Чему научились Как мы его строили
- 9. 9 Рождение SCRUM Пилот Формирование процессов • Прототип • Buy vs build • Инструменты • Встречи • Спринты • Continuous integrationВ результате: • Доверие • Собственная разработка В результате: • SCRUM-процесс
- 10. 10 Эволюция SCRUM Адаптация процессов под стандарты Банка Улучшение процессов • Аutodeployment • Удлинение спринтов • Коуч • Тиражирование В результате: • SLA • Надежнось В результате: • Рестарт • Новые команды
- 11. 11 Руководство рисков CIB • Спонсор • Установка приоритетов Как выстроена команда Заказчика? Руководство программы Управление программой Выстраивание процессов Расчет риска Стейкхолдеры продуктов Методология расчета рисков Владельцы продуктов
- 12. 12 Функция Program management ”Scrum of scrum” – построение процессов Участие в построении IT архитектуры PO по инфраструктурным продуктам Контроль value спринтов по Продуктам
- 13. 13 1. Наш путь к SCRUM 2. Как мы его строили 3. 4. Чему научились Через что прошли
- 14. 14 Через тернии - 1 Открытие проектов предполагает описание бизнес-требований для оценки ресурсов IT. Детализация требований определяется IT и Заказчиком Задача Решение Описание на высоком уровне, доверие между IT и Заказчиком Открытие проектов
- 15. 15 Через тернии - 2 СберТех Отдел разработки Отдел тестирования Отдел сопровождения Сбербанк Формирование SCRUM команды
- 16. 16 Через тернии - 2 СберТех Отдел разработки Отдел тестирования Отдел сопровождения Сбербанк Формирование SCRUM команды
- 17. 17 Через тернии - 2 SCRUM команда product owner Stakeholders (end-users) Заказчик (Сбербанк) Формирование SCRUM команды
- 18. 18 Через тернии - 3 Безопасность Сбербанк должен обеспечивать высокие требования к безопасности данных в системах. Это усложняет процесс согласования доступов и доработок систем Задача Решение Подключение представителей безопасности к Sprint Review
- 19. 19 Через тернии - 4 Вывод релиза В связи с высоким приоритетом надежности IT систем в Сбербанке, процесс внедрения релизов достаточно трудоемкий Задача Решение Автоматизация deployment Включение команды внедрения в Команду разработки
- 20. 20 Через тернии - 5 SCRUM рестарт После 4 лет работы команды разработки перестали оптимизировать собственные процессы Задача Решение Найм коуча Возврат практик SCRUM в обязательном порядке
- 21. 21 Архитектура и инженерные практики Autodeployment Microservices Autoconfig
- 22. 22 1. Наш путь к SCRUM 2. Как мы его строили 3. Через что прошли 4. Чему научились
- 23. 23 Заключение • SCRUM должен решать бизнес-задачи • Доверие между IT и Бизнесом – необходимо! • Экспертиза важна • Вовлечение стейкхолдеров – не только Заказчика • Архитектура, практики и инструменты
- 24. 24 Ваши вопросы КОНТАКТЫ Лукьянов Михаил Департамент рисков CIB, ПАО Сбербанк +7-916-831-08-05 MSLukyanov@sberbank.ru Дмитрий Шайхатаров АО «Сбербанк-Технологии» +7-916-904-04-52 DKSHaikhatarov.sbt@sberbank.ru
Notas do Editor
- МИША: Представиться и обяснить за что кто отвечает. И мы одна команда Основная идея – мы расскажем об реализации СКРАМ в одной из стратегических Программ Проектов Банка План – Бизнес задача, истории появления СКРАМ и об основные вызовы которые перед нами стояли
- МИША: Завершили сделку по покупке Тройки диалог Валовый рост бизнеса на глобальных рынках Глобальные рынки отличаются от стандартного банковского бизнеса Глобальные рынки – это сделки с акциями и облигациями, производными финансовыми инструментами, к примеру азиатские опционы или опционы на погоду Сделки совершаются в интересах клиента или за собственные средства Банка Алготрейдинг или сделки с крупнейшими клиентами банка
- МИША: Одной из стратегических целей Банка было формирование функции рисков на Финансовых рынков под новые объемы бизнеса. Для обеспечения функции рисков на Финансовых рынках было принято решение о создании единой ИТ платформы для автоматизации бизнес процессов риск менеджмента ФР – АСУР ФР. Рыночный – Metallgesellschaft делали форворда на продажу нефти в 92 году, на большие объемы и рассчитывая на прибыль. Из за изменения стоимости нефти в итоге они потеряли 1.5 миллиарда долларов Кредитный – Lehman or AEG, теряются выданные кредиты Valuation – National Australia Bank сделали опционы на покупку валюты, при этом сделали ряд несуществующих сделок в системах, для попадания в лимиты. В результате потери от сделок составили 360 миллионов долларов Надо оценивать и управлять в соответствии с аппетитом Формула1 и велик, машина без тормозов
- ДИМА Заменить картинку, показать всю сложность - фильм фильм фильм Почему waterfall – проекты это не создание ИТ системы Совместная работа нескольких фкнуциональных подразделей – дать цифры, 300 тыс чел, сколько ВСП и функц подразделений Универсальная методология, гарантирующая предсказуемость, согласованность и контроль независимо от масштаба и сложности проекта Сказать про награды 2 РП – бизнес и ИТ
- МИША Высокая изменчивость финансовых рынков приводит к частому изменению требований из-за внешних факторов Требования к Time to market со стороны бизнеса – необходимость быстро выводить на рынок новые продукты Нефункциональные требования к системе потребовали использования наиболее современных технологий и компетенций команды. Пример – санкции, за 2 дня сделали доработку о видимости контрагента и его ограничений по сделкам, иначе штрафы со стороны регулятора
- ДИМА ПОДУМАТЬ ПРО ПЕРВЫЙ ПУНКТ Оставить по одному слову на раздел 2 пункт - рассказать про ПИР Фокус был на проектной составляющей, а не на процессе разработки Отсутствие интеграций с системами Банка, отсутствие необходимости синхронизации с водопадными командами Обособленность команды. Квалификация команды, большой опыт работы в SCRUM Разработка системы с нуля, green field development, возможность заложить правильную архитектуру решения. Низкая формализация процессов ИТ разработки в Банке на момент старта разработки системы – возможность модифицировать процесс под задачу.
- МИША: Представиться и обяснить за что кто отвечает. И мы одна команда Основная идея – мы расскажем об реализации СКРАМ в одной из стратегических Программ Проектов Банка План – Бизнес задача, истории появления СКРАМ и об основные вызовы которые перед нами стояли
- МИША В 2012-м году Первый Delivery – работающий прототип Демонстрация работы команды Принятие решения buy vs build 2013 – фомирование спринтов, появление континиус интегратион. В результате бизнес начал получать наиболее приоритетные бизнес фичи раз в 2 недели ОСТАВИТЬ ОРАНЖЕВОЕ
- МИША Началось тиражирование на ДБ Сбербанк Европа, где оказалось, что системы рисков устарели, усилились требования СЛА, повысились требования к надежности, как следствие потребовалось подстроить процесс под стандарты банка, включив вывод релиза после каждого спринта с регрессионным тестированием, обновлением документации и пр. Наши системы подошли больше ЧЕМ ЕВРОПЕЙСКИЕ АНАЛОГИ! Пример про Mercury
- МИША
- МИША VALUE – контроль Value по разным продуктам, сравнение SOS – развитие процессов на уровне Программы, вовлечение бизнеса Enterprise architecture – помогаем поскольку видим стратегию развития PO – продукты, которые нужны всей программе, ведем их
- МИША: Представиться и обяснить за что кто отвечает. И мы одна команда Основная идея – мы расскажем об реализации СКРАМ в одной из стратегических Программ Проектов Банка План – Бизнес задача, истории появления СКРАМ и об основные вызовы которые перед нами стояли
- МИША ТЗ – детализация Бизнес хочет переложить риски ИТ хочет правильно оценить После пилота доверие – помогло ВЫВОД – делайте пилоты и доверяйте друг другу
- ДИМА Кратко про оргструктуру организации Про разные ППР/КПЭ Разработка – цель: передать на приемку Заказчиком весь запланированный функционал -> чем больше дефектов отклонили, тем лучше, т.к. быстрее передаем на приемку Заказчиком QA – цель: как можно больше багов найти до этапа приемки заказчиком -> чем дольше тестируем, тем больше багов находим -> задержки с переводом на приемку заказчиком Support – цель: минимизация кол-ва инцидентов в ПРОМ-е -> лучше вообще не выводить новые версии в ПРОМ Итого – цели разные, все плохо )))
- ДИМА Объединяем сотрудников разных отделов в кроссфункциональные команды. Люди сидят рядом, за одним «островком» из столов.
- ДИМА
- МИША Очень важна сохранность данных ИБ согласует все – от документов до доступов Решение - обновление документации на каждом спринте Вовлекли их в демо Учли их требования в DoD
- МИША Надежность систем очень важна. Ряд систем с несколькими девятками Релиз – 1.5 месяца проверок что бы все было хорошо У нас – сделали deployment с одного сервера, автоматизировали все процессы релиза. Автотесты Вовлекли команду Support В итоге у нас – неделя!
- ДИМА В 2012-м году Первый Delivery – работающий прототип Демонстрация работы команды Принятие решения buy vs build Обучили Product Owners и сертифицировали
- ДИМА ВМЕСТО ТЕХНОЛОГИЙ – БУЛЕТ ПОЙНТЫ ПРО ВАЖНЫЕ ПРАКТИКИ – МОДУЛЬНАЯ АРХИТЕКТУРА, АВТОТЕСТЫ (% покрытия), АВТОСБОРКА, АВТОdeploy, autoconfig, что-то еще? Важность инженерных практик Максимальная автоматизация всех процессов на пути от кода до развертывания на промышленных стендах. Высокое покрытие unit test-ами: от 50 до 80% кода. Автоматизация развертывания Autodeployment - вся риск платформа развертывается в «один клик», используется разработанный in-house фреймворк – с его помощью развертывается все необходимое окружение (нужная версия jvm и т.п.), само приложение, а также обновляется схема базы данных. Все это делается за несколько минут. Принцип «инфраструктура как код» – все конфигурационные параметры приложений, а также адреса всех внешних endpoint-ов хранятся в системе контроля версий (git), что дает полную повторяемость процесса при развертывании в dev/qa/uat/prod средах и максимально исключает человеческий фактор и необходимость писать длинные инструкции по установке.
- МИША: Представиться и обяснить за что кто отвечает. И мы одна команда Основная идея – мы расскажем об реализации СКРАМ в одной из стратегических Программ Проектов Банка План – Бизнес задача, истории появления СКРАМ и об основные вызовы которые перед нами стояли
- МИША: SCRUM должен быть нужен для решения каких то Бизнес задач, а не просто потому что ИТ так захотело Делайте пилот, он даст доверие, тогда можно будет решить большинство проблем Важно вовлечь в процесс всех стейкхолдеров, не только пользователей, что бы не было проблем с согласованием вывода новой версии Продукта.