Сегодня хочу поделиться с вами процессом разработки сайта по методике agile внутри огромного российского энтерпрайза, который работает по всем канонам каскадной разработки (waterfall). Примером послужит один из сайтов нашей компании, над которым работает наша молодая agile-команда.

Условия разработки в Национальном расчетном депозитарии (НРД)

НРД — крупная финансовая компания, часть Группы «Московская биржа», в которой разработка ведется по классической модели waterfall, она же каскадная или водопадная модель.
Циклы релизов в компании заранее запланированы на годы вперед: в наличии красивые диаграммы и четкий план, выверенные до мелочей и продуманные элементы этапов разработки, тестирования и аналитики. Всё это выглядит очень внушительно, каждый занят своим делом, есть конкретная схема внедрения разработок и доработок. Учитываются зависимости при проектировании: если, например, доработка влияет на другие системы, то проводят аналитику, все выверяют и делают оценки разработки — все вносится в график, и этап за этапом ведется работа настоящими профессионалами.

Продукты компании

Основной функционал ИТ компании направлен на основную депозитарную деятельность — финансовые услуги, связанные с хранением сертификатов ценных бумаг и/или учётом и переходом прав на ценные бумаги. Соответственно, все усилия направлены на оказание и поддержание должного качества услуг участникам финансового рынка. Отсюда в арсенале компании есть целый набор разного рода продуктов и проектов: это и legacy-системы, написанные на технологиях, которые уже мало кто использует, и ряд современных продуктов, написанных с использованием микросервисной архитектуры.

Описание кейса: разработка сайта agile-командой

Один из продуктов, где мы применяем гибкую методологию — сайт nsddata.ru. Сайт представляет из себя «витрину» информационных продуктов компании, которые является логическим продолжением депозитарного бизнеса НРД. В них аккумулирована уникальная информация, накапливающая в результате депозитарной деятельности. Это, например, такие продукты, как Ценовой центр, где клиенты могут узнать справедливую стоимость ценных бумаг, или Диск НРД, где можно получить официальные данные НРД об организациях, ценных бумагах и связанных с ними событиях.

Сайт получает огромный массив данных из core-системы и показывает эти данные клиентам по подписке в виде API и так же в интерфейсе самого сайта.

Команда

Сайт, который является сложным и уникальным продуктом, поддерживает и развивает небольшая команда из 8 человек.

• Scrum-мастер

• 3 Разработчика

• Тестировщик

• Аналитик

• Владелец продукта

• Представитель бизнеса

Мы стараемся придерживаться гибкой методологии agile при разработке продукта. У нас есть ежедневные дейли, ведем свои задачки мы на борде в гитлабе, собираемся раз в спринт на планирование и проводим обязательное демо. Конечно, мы не всегда делаем ретроспективу спринта, но на момент написания статьи работаем над тем, чтобы это стало обязательной рутиной. Но и есть некоторые модификации, про них я и хочу немного рассказать:

• Смотреть за заявками сторонних систем, при которых нужна доработка сайта.

• Реагировать на инциденты.

• Контролировать сроки поставки релизного цикла «больших систем» на этапе тестирования или опытной эксплуатации.

Идеальная поставка релиза

1. Возникает обратная связь от клиента при которой мы видим, что нужно сделать новую фишку на сайте.

2. Заводим в гитлабе карточку в колонке backlog.
   

3. На встрече по планированию спринта мы собираем backlog:
   

   1. Сортируем задачки по простой системе скоринга ICE.
      

   2. Если фишка не особо сложная на первый взгляд в реализации и и была инициирована клиентом, то, как правило, она будет выше всех карточек в backlog и попадает в ближайший спринт.
      

4. Передвигаем карточку в колонку DEV.
   

5. Перед разработкой создаем задачу в Redmine, так как в нашей компании это является неотъемлемой частью для связи коммита в git.
   

6. Создаем ветку /feature/334455, где номер — это ID задачи в Redmine.

7. Разрабатываем

8. Пишем unit-тест

   

9. Если локально проходят тесты

10. Push кода в gitlab и создаем MR

    

11. Запускается сборка CI, при которой повторно проверятся unit-тесты.

12. Следующий шаг — запуск проверки когда на качество в SonarQube.

13. Дальше проверка в CheckMarx на уязвимости.

14. Код-ревью тимлидом.

15. Если все успешно, автодеплой в тестовый контур с помощью AWX.

15. Последний шаг — запуск несколько smoke-тестов на проверку работоспособности контура и базовых интеграций.

16. Дальше разработчик передвигает карточку в Очередь на тест.

17. Вступает в дело тестирование.

18. Карточка передвигается в колонку TEST.

19. Если тест-кейсы пройдены и замечаний нет, карточка переходит дальше.

Демо

20. За день до встречи проведения ДЕМО продукта, собирается предрелизная ветка из задач в колонке.

21. На встрече происходит демонстрация продукта заказчику.

22. Если замечаний не обнаружено, ветка финально проходит ручное тестирование.

23. Все карточки переходят в колонку «Готово к установке».

24. Происходит согласование задач, которые мы хотим установить в пром.

25. Запуск процедуры деплоя на пром происходит по кнопке в TeamCity.

26. Карточки переходят в колонку «Установлено на пром».

27. Тест-кейсы переносятся в систему хранения HP ALM, где они описываются в формате для передачи в автотесты.

28. Группа автотестеров добавляет новые тесты для постоянного регресс-тестирования проекта и берет их из ALM.

29. Карточка переходит на аналитика, который документирует и формализует ее и вносит изменение в ФТ (Функциональные требования или ТЗ).

30. PROFIT

Ретроспектива

На каждом шаге могут возникнут трудности и форс-мажоры — это то, что мы решаем каждый день. Искренне скажу, что такой идеальный спринт у нас бывает нечасто. Как вы могли заметить, здесь нет шага ретроспективы.

Как говорят популярные в России agile-коучи «Ретроспектива - это сердце agile».

Бывают спринты, где мы хотим сделать не только изменение кода, но и изменить процесс поставки или добавить какие-либо кусочки к нашей инфраструктуре. Мы обрабатываем такого рода задачи по такому же сценарию, только исключаем шаги, связанные с комитетом кода.

Плюсы такого подхода

• Минимизируется количество дефектов при поставке в production

• Быстро создаем новые «фичи»

• Заказчик продукта видит результат гораздо раньше

Минусы

• Только небольшая часть компании работает по гибким методологиям, отсюда приходиться сильно высокие требования к участникам команды в области знания методологии и высокий порог ввода новых участников или их замена.

Итого

Можно «выжить» небольшой командой даже в условиях огромного entreprise, используя гибкие практики, но с некоторыми модификациями. Приходиться конечно следить сразу в нескольких системах за изменениями, адаптироваться. Но в целом эта история вполне реальна и на текущий момент мы продолжаем двигаться и разработать свой продукт.