Опыт использования AGILE на примере Сбербанка

1. Опыт использования методологии AGILE на
примере ПАО Сбербанк
Автор: Андрей Белобродский
АО «Сбертех»
Опыт работы: Siemens, Атос,
Accenture, ABC Фарбен
21.10.2017

2. 2
Производственный процесс
1. Подготовка ДБТ проекта консультантами заказчика
2. Анализ ДБТ генеральным подрядчикам, разделение ДБТ на ЗНИ
3. Выбор подрядчиков и консультантов для реализации ЗНИ
4. Написание консультантом СТАС по ЗНИ и утверждение его у
Заказчика
5. Написание консультантом спецификаций на разработку
6. Разработка ЗНИ программистом в системе разработки
7. МТ разработки консультантом в тестовой системе
8. ИФТ разработки тестировщиком на соответствие СТАС
9. ПСИ разработки и принятие решения о включении в состав
Релиза
10. Перенос разработки в продуктивную систему

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

4. 4
Об Agile и SCRUM
Гибкая методология разработки (англ. Agile) — серия подходов к разработке
программного обеспечения, ориентированных на использование итеративной
разработки, динамическое формирование требований и обеспечение их
реализации в результате постоянного взаимодействия внутри самоорганизующихся
рабочих групп, состоящих из специалистов различного профиля.
Существует несколько методик, относящихся к классу гибких методологий
разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.
SСRUM — это набор принципов, на которых строится процесс разработки,
позволяющий в жёстко фиксированные и небольшие по времени итерации,
называемые спринтами, предоставлять конечному пользователю работающее ПО с
новыми возможностями, для которых определён наибольший приоритет.
SCRUM как и ITIL представляют собой Книгу где описаны процессы при
разработке программного обеспечения.

5. 5
SCRUM

6. 6
История SCRUM
Подход впервые описан Хиротака Такэути и Икудзиро
Нонака в 1986 году в статье The New Product
Development Game. Авторы отметили, что проекты, над
которыми работают небольшие команды из
специалистов различного профиля, обычно
систематически производят лучшие результаты, и
объяснили это как «подход регби».
Впервые метод Scrum был представлен на общее
обозрение задокументированным, чётко
сформированным и описанным совместно Швабером и
Джефом Сазерлендом в книге «Agile Software
Development with SCRUM».

7. 7
Понятийный аппарат SCRUM
User story – требования клиента
Scrum master- координатор проекта
Sprint – двухнедельный период времени
Scrum meeting – ежедневное собрание
Sprint meeting – итоговое собрание по
итогом спринта
Jira – ПО учета рабочего времени и задач

8. 8
Производственный процесс при AGILE
1. Подготовка ДБТ (user story) проекта консультантами заказчика
2. Анализ ДБТ генеральным подрядчикам, разделение ДБТ на ЗНИ
3. Выбор подрядчиков и консультантов для реализации ЗНИ
4. Написание консультантом СТАС по ЗНИ
5. Написание консультантом спецификаций на разработку
6. Разработка ЗНИ программистом в системе разработки
7. МТ разработки консультантом в тестовой системе
8. Создание Scrum Master задач Jira по итогам Sprint Meeting
9. ИФТ разработки тестировщиком
10. ПСИ разработки и принятие решения о включении в состав
Релиза
11. Перенос разработки в продуктивную систему
Sprint

9. 9
Пример user story
Необходимо реализовать предупреждающее
сообщение «Риск двойной оплаты» при создании
документов «Счет на оплату» и «Заявка на платеж»
при совпадении в системе данных по полям:
ИНН/КПП, номер счета, дата счета, сумма и валюта.

10. 10
Дополнительная функциональность по итогам 3 спринтов
1. Настройка ключа проверки
2. Возможность исключения отдельных видов документа счета на оплату и ЗНП
3. Возможность просмотра дублирующих карточек счетов и ЗНП
4. Запрет «Б/Н», «.» в номере счета
5. Настройка запрещенных «номеров счетов»
6. Отсутствие проверки при сохранении если она уже пройдена
7. Дополнительная проверка при смене пользователя
8. Возможность исключения карточек в зависимости от статуса из проверки
9. Возможность настройки глубины проверки в днях
10. Возможность исключения определенных пользователей из проверки
11. Возможность исключения определенных контрагентов из проверки
12. Фиксация решения пользователя в системном журнале
13. Подавление других сообщений если есть «Риск двойной оплаты»
14. Вызов метода проверки в другие моменты времени.

11. 11
Сообщение «Риск двойной оплаты»

12. 12
Сообщение «Ввод «Б/Н» запрещен»

13. 13
Адаптированная AGILE методология по итогам пробного периода
1. Организационные изменения
2. Scrum meeting два раза в неделю
3. Sprint meeting перед передачей на ИФТ

14. 14
О Сбербанке
• Более 3000 различных АС (ПО)
• SAP ERP для УВХД (доходы и расходы от
небанковской деятельности) и АСУН
• 15 Балансовых Единиц
• Единая Бухгалтерия в Самаре и Новосибирске
• SAP BW для Аналитической отчетности
• Отдельные АС для Платежей, Регламентируемой
отчетности, Банковской деятельности.

15. 15
Об авторе
Белобродский Андрей Андреевич
E-mail: andrey.belobrodskiy@mail.ru
Телефон: + 7 951 562 2434
Опыт участия в проектах: Nokia Siemens Networks,
L'Oréal, Myllykoski, Siemens Healthcare,
ABC Фарбен, Сбербанк.
СПАСИБО ЗА ВНИМАНИЕ!