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

Video: https://youtu.be/XMJ3pAB5OYI

Transcript

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 Фарбен, Сбербанк. СПАСИБО ЗА ВНИМАНИЕ!