Uploaded bySergey Rogachev
Масштабирование Agile в Единой фронтальной системе Сбербанка
Документ описывает принципы масштабирования Agile в банковской сфере, подчеркивая важность кросс-функциональных команд и быстрого решения проблем для достижения успеха. Основное внимание уделяется интеграции различных систем и необходимости синхронизации команд для оптимизации процессов разработки. Упоминается использование Scaled Agile Framework (SAFe) как инструмента для улучшения совместной работы и повышения прозрачности в крупных проектах.
More Related Content
Масштабирование Agile в Единой фронтальной системе Сбербанка
- 1. Сергей Рогачев, Agile Coach,ScrumTrek Масштабирование Agile в Единой фронтальной системе Сбербанка
- 2. Сергей Рогачев —ScrumTrek – AgileCoach – Масштабирование Agile —В прошлом – Заказная и продуктовая разработка, консалтинг – Разработчик, архитектор, менеджер проектов, технический директор, руководитель проектного офиса
- 3.
- 4. Трансформация банковского бизнеса Бесшовный кросс- канальный клиентский опыт Высокаядоля продаж в удаленных каналах обслуживания Низкий Time-to- Market продукта во все каналы обслуживания Низкие затраты на обучение новых сотрудников
- 5. Вызовы Колоссальный объем Различные устройства Огромное количество систем винтеграции Водопадная модель разработки Гигантская команда
- 6.
- 7. Все это будет построенона Agile… …потому что по- другому такой объем сделать нельзя – Герман Греф
- 8. Чем больше проект,тем меньше шансов на его успех * 2015 CHAOS Report – Standish Group (http://www.infoq.com/articles/standish-chaos-2015)
- 9. На любых размерахпроектов Agile успешнее, чем Waterfall * 2015 CHAOS Report – Standish Group (http://www.infoq.com/articles/standish-chaos-2015)
- 10.
- 11.
- 12.
- 13.
- 14. Вертикальная коммуникация Ценность не соответствует колодцам Задача:соединить колодцы Трения между колодцами Рассадка по функциям Политические барьеры
- 15.
- 16.
- 19. Проблемы Agile-команды —Размер командыот 5 до 9 человек —Команда такого размера не может самостоятельно поставлять ценность —Большой стек технологий —Интеграция с другими «водопадными» системами —Проблемы синхронизации (выравнивания) на уровне больших проектов и программ
- 20. Scaled Agile Framework SAFeсводобно доступная онлайн база знаний проверенных и успешных шаблонов реализации Lean-Agile разработки на корпоративных масштабах
- 21. Scaled Agile Framework(SAFe) Обеспечивает выравнивание, сотрудничество и поставку ценности большого количества команд 1. Встроенное качество 2. Исполнение программы 3. Выравнивание 4. Прозрачность Ценности
- 22. The 10th AnnualState of Agile Report – VersionOne https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf
- 23. Решение организационных проблем —Нужна командаруководителей для постоянного решения проблем команд —Движение проблем от команд наверх —Скорость преобразования организации – скорость решения проблем
- 24. Agile не работает!Что- то не так с вашим аджайлом! Agile не работает! Что- то не так с вашей организацией!
- 25. Поток проблем —Поток проблемснизу вверх —Постоянное решение проблем —Визуализация —Доска проблем
- 26. Доска блокеров –ROAM
- 27.
- 28.
- 29.
- 30. Web-site Accounting CRM RiskShop Marketing Loyalty ESB Как выглядитбанковский продукт?
- 31. Web-site Accounting CRM RiskShop Marketing Loyalty ESB Как выглядитбанковский продукт?
- 32. Кем это всеподдерживается? Web-site Accounting CRM RiskShop Marketing Loyalty ESB
- 33.
- 34.
- 35.
- 36.
- 37.
- 38. Работа над однойбизнес-задачей разными командами
- 39.
- 40. PO Sync –церемония продуктовой синхронизации команд Цели • Выявить зависимости между командами и рассинхронизации по продуктовым планам • Предотвратить создание «велосипедов» • Фасилитировать решения Результат • Прозрачная реализации взаимозависимых продуктов • Оперативное внесения изменений в планы • Системное решение проблем, а не реактивное • Командная работа владельцев продуктов
- 41.
- 42. Скрам- мастер Владельцы продуктов ОСНОВНЫЕ ПРАВИЛА • Еженедельноили чаще • Не более 30-60 минут • Выявить открытые вопросы, организовать встречи для их обсуждения • Проводит старший Скрам- мастер или владелец продукта • Владельцы продуктов – обязательные участники • При необходимости заинтересованные лица и внешние эксперты
- 43. Скрам- мастер Владельцы продуктов • Следит затем, чтобы PO Sync был • Следит за регламентом • Фасилитирует общение • Фиксирует проблемы
- 44. Скрам- мастер Владельцы продуктов По очереди рассказываюто том, что их команды сделали с момента прошлой встречи, планируют сделать, рассказывают проблемы
- 45.
- 46. Скрам- мастер Владельцы продуктов Все привет! Чтоу вас нового? Давайте расскажем по кругу.
- 47. Скрам- мастер Владельцы продуктов Привет! У насв проекте Сигма проблемы с реализацией справочников. Задержка со стороны вендора. Мы вынуждены перенести завершение на месяц
- 48. Скрам- мастер Владельцы продуктов Ребята, кто зависитот справочников Сигмы? Проект Альфа?
- 49. Скрам- мастер Владельцы продуктов Постойте! От ваших справочниковзависят сроки нашего релиза Альфы!
- 50. Скрам- мастер Владельцы продуктов Возможно, мысможем реализовать предварительную версию справочников только для вас в минимальном виде?
- 51. Скрам- мастер Владельцы продуктов Было бы неплохопонять, в каком виде?
- 52. Скрам- мастер Владельцы продуктов Ребята, давайте выэто обсудите после встречи вдвоем?
- 53.
- 54. Скрам- мастер Владельцы продуктов Хорошо, я запланируювстречу на вечер
- 55.
- 56.
- 57.
- 58. Скрам- мастер Владельцы продуктов Всем привет! Мыперешли на последнюю версию платформы. В этот раз критических ошибок не было.
- 59. Скрам- мастер Владельцы продуктов Кажется, у кого-тобыли сомнения в том, интегрировать новую версию платформы или подождать?
- 60. Скрам- мастер Владельцы продуктов Ага, это мы.Спасибо за информацию!
- 61. Скрам- мастер Владельцы продуктов А так, унас все по плану. У меня – все.
- 62.
- 63.
- 64. Скрам- мастер Владельцы продуктов У нас впроекте Гамма проблема… Мы почему-то думали, что базовый функционал заявки на продукты есть в платформе. Но его нет сейчас, придется делать самим.
- 65.
- 66. Скрам- мастер Владельцы продуктов Мы с этойпроблемой столкнулись раньше вас. И через месяц мы уже завершим свою реализацию, передадим в платформу на поддержку. Дождетесь?
- 67. Скрам- мастер Владельцы продуктов Супер! Конечно, дождемся. Самимы бы делали точно дольше.
- 68.
- 69.
- 70. Скрам- мастер Владельцы продуктов Да, я сведутебя с нашими разработчиками
- 71. Скрам- мастер Владельцы продуктов У меня– все. Отличный результат встречи: если бы не она, мы бы побежали делать велосипед!
- 72.
- 73.
- 77. Встречи не заработаютбез фасилитации
- 78.
- 79. Притча о планированиив Agile
- 80. Планы бесполезны, новот планирование обязательно Ошибка всего 15-20%, в ИТ намного хуже: • 43% проектов – На 74% отставание по срокам – На 59% превышение бюджета – На 69% незавершенный функционал • 18% проектов закрываются в корзину * Standish Group «Chaos Manifesto 2013» (http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf)
- 81. PI-планирование —Синхронизировать планы команд —Выявитьзависимости, белые пятна, пересечения и дублирования —Получить понимание результата по всем командам: что мы увидим на общей демонстрации в конце
- 98. Building planes inthe sky (https://youtu.be/Y7XW-mewUm8)
- 99.
- 100. Agile в ИТэто — ничего, если у тебя нет Agile всей организации. Все процессы должны быть перестроены. Те, кто не освоит Agile сегодня в куче бизнес-процессов – будет лузерами завтра – Герман Греф
- 106. С удовольствием ответим налюбые вопросы +7 (495) 374 88 12 info@scrumtrek.ru http://scrumtrek.ru