Применимость SAFe в крупной финансовой организации
•
4 gefällt mir•856 views
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Применимость SAFe в крупной финансовой организации
Ähnlich wie Применимость SAFe в крупной финансовой организации (20)
Применимость SAFe в крупной финансовой организации
- 1. Применимость SAFe в крупной финансовой организации Антон Немчинов Agile SDLC Manager Raiffeisenbank Russia
- 4. • Около 7000 сотрудников в Банке • Всего порядка 700 сотрудников в ИТ • Около 400 сотрудников в разработке (команды от 10 до 40 человек) • 100500 приложений • Центры разработки в Москве и Омске
- 7. • Развитие ролей в разработке (SA, Dev, QA) • Продукт менеджемент • Технологии (JAVA, .NET и т.п.) • Agile практики и формирование Mindset • Demand Management vs Portfolio Management • Гибкая модель бюджетирования • Быстрое принятие решений • Трансформация команд • Внедрение практик гибкой разработки • Визуализация • Метрики • Релизное управление • Синхронизация релизов • Работа с требованиями • Не путать с одновременными релизами
- 10. #1 - Take an economic view #2 - Apply systems thinking #3 - Assume variability; preserve options #4 - Build incrementally with fast, integrated learning cycles #5 - Base milestones on objective evaluation of working systems #6 - Visualize and limit WIP, reduce batch sizes, and manage queue lengths #7 - Apply cadence, synchronize with cross-domain planning #8 - Unlock the intrinsic motivation of knowledge workers #9 - Decentralize decision-making
- 11. Рассмотрим Case • Готовится к старту новый проект и проектный менеджер запрашивает команду дать ему оценку по срокам и стоимости работ • При этом, требуется дать комит на качество оценки в 80% на ранней стадии • Команда возвращает план на три месяца, утверждая, что они не умеют планировать на больший срок и трудоемкость в Story Points Вопрос: что вообще происходит?
- 12. Анализ после Retro • PMO не было изначально в скоупе трансформации • Недостаточный уровень коммуникаций между смежными подразделениями • Поздно были разработаны метрики • Существующие KPI противоречат внедряемой методологии • Внедрение только Bottom-Up позволяет трансформировать команду, но не организацию
- 13. Выбор команд для трансформации Порталы самообслуживания Internet банк Мобильный банк 1 день - 1 неделя Частые изменения Front-end приложения Интеграционная шина Конвейеры 1 месяц - 3 месяца Нечастые изменения АБС Card Processing Переводы Бухгалтерия Legacy-системы 6 месяцев - никогда Редкие изменения
- 14. Вход в команду Выстраивание коммуникаций Метрики Управление требованиями и планирование Качество • 360 View (Команда, заказчики, App Support, PM) • Статистика (JIRA, Remedy, HP ALM) • Визуализация работы (Kanban) • Ввод периодических встреч (Standup, Retro, Demo, Planning) • Эффективность • Качество • Удовлетворен- ность заказчика • Единый backlog • Декомпозиция требований • Итерации • Многоуровневые планирование • Тестирование неотъемлемая часть разработки • CI • Авто тестирование и Auto Deploy (DevOps). Трансформация команд
- 15. Scrum или Kanban • Визуализация при помощи Kanban досок • Бизнес заказчик «владеет» backlog’ом команды • Команда выпускает доработки согласно своей релизной политики и, по необходимости, по запросу • Двух-недельные итерации без комита на скоуп
- 16. Lean Agile
- 17. Время выполнения инициативы Проверка реализации Заказчиком, устранение функциональных дефектов UAT Тестирование реализации, интеграционное тестирование, Regress и Auto Tests Тестирование Реализация требований Разработка Декомпозиция требований, оценка требований, Тестовые сценарии Системный Анализ Сбор бизнес требований, анализ изменения бизнес процессов Бизнес Анализ Ожидание начала Инициатива проходит классификацию и попадает в Backlog к команде 50 дней 25 дней 40 дней 115 дней 50 дней 36 дней Lead-Time ~ 10,5 месяцев* Временный данные приведены для примера
- 18. Время выполнения инициативы Проверка реализации Заказчиком, устранение функциональных дефектов UAT Тестирование реализации, интеграционное тестирование, Regress и Auto Tests Тестирование Реализация требований Разработка Декомпозиция требований, оценка требований, Тестовые сценарии Системный Анализ Сбор бизнес требований, анализ изменения бизнес процессов Бизнес Анализ Ожидание начала Инициатива проходит классификацию и попадает в Backlog к команде Lead-Time ~ 10,5 месяцев* Временный данные приведены для примера
- 19. Время выполнения инициативы 50 дней 25 дней 115 дней 40 дней 50 дней 36 дней Lead-Time ~ 10,5 месяцев Проверка реализации Заказчиком, устранение функциональных дефектов UAT Тестирование реализации, интеграционное тестирование, Regress и Auto Tests Тестирование Реализация требований Разработка Декомпозиция требований, оценка требований, Тестовые сценарии Системный Анализ Сбор бизнес требований, анализ изменения бизнес процессов Бизнес Анализ Ожидание начала Инициатива проходит классификацию и попадает в Backlog к команде * Временный данные приведены для примера
- 20. Время выполнения инициативы 30 дней Проверка реализации Заказчиком, устранение функциональных дефектов UAT Тестирование реализации, интеграционное тестирование, Regress и Auto Tests Тестирование Проверка реализации Заказчиком, устранение функциональных дефектов UAT Тестирование реализации, интеграционное тестирование, Regress и Auto Tests Тестирование Реализация требований Разработка Декомпозиция требований, оценка требований, Тестовые сценарии Системный Анализ Сбор бизнес требований, анализ изменения бизнес процессов Бизнес Анализ Ожидание начала Инициатива проходит классификацию и попадает в Backlog к команде Декомпозиция требований, оценка требований, Тестовые сценарии Системный Анализ 42 дня Lead-Time ~ 6 месяцев ? * Временный данные приведены для примера
- 21. Поговорим про SLA… В нашем случае, у команд разработки есть SLA на небольшие инициативы 4 месяца Хорошо это или плохо?
- 23. • Выравнивание итераций (договоренность) • Наличие общей релизной политики • Визуализация (доски) и межкомандные коммуникации (встречи) • Техническая возможность выпускаться после каждой итерации • Никаких big boom релизов!
- 24. Инструменты
- 25. Remedy
- 27. Портфельное управление • Переход от разрозненных инициатив к Темам по направлениям бизнеса • Выделение бюджета на Темы (группы инициатив) и процесс change management отдельных частей темы. Обязательная верификация • Контроль за исполнением со стороны Портфельного Комитета • Функциональные и нефункциональные инициативы
- 29. Спасибо за внимание! Антон Нечминов E-mail: Anton.Nemchinov@raiffeisen.ru LinkedIn: https://ru.linkedin.com/in/anemchinov