Сегодня хочу поделиться с вами процессом разработки сайта по методике agile внутри огромного российского энтерпрайза, который работает по всем канонам каскадной разработки (waterfall). Примером послужит один из сайтов нашей компании, над которым работает наша молодая agile-команда. НРД —  крупная финансовая компания, часть Группы «Московская биржа», в которой разработка ведется по классической модели waterfall, она же каскадная или водопадная модель. Циклы релизов в компании заранее запланированы на годы вперед: в наличии красивые диаграммы и четкий план, выверенные до мелочей и продуманные элементы этапов разработки, тестирования и аналитики.  Всё это выглядит очень внушительно, каждый занят своим делом, есть конкретная схема внедрения разработок и доработок. Учитываются зависимости при проектировании: если, например, доработка влияет на другие системы, то проводят аналитику, все выверяют и делают оценки разработки —  все вносится в график, и этап за этапом ведется работа настоящими профессионалами. Основной функционал ИТ компании направлен на основную депозитарную деятельность —  финансовые услуги, связанные с хранением сертификатов ценных бумаг и/или учётом и переходом прав на ценные бумаги. Соответственно, все усилия направлены на оказание и поддержание должного качества услуг участникам финансового рынка. Отсюда в арсенале компании есть целый набор разного рода продуктов и проектов: это и legacy-системы, написанные на технологиях, которые уже мало кто использует, и ряд современных продуктов, написанных с использованием микросервисной архитектуры. Один из продуктов, где мы применяем гибкую методологию —  сайт nsddata.ru. Сайт представляет из себя «витрину» информационных продуктов компании, которые является логическим продолжением депозитарного бизнеса НРД. В них аккумулирована уникальная информация, накапливающая в результате депозитарной деятельности. Это, например, такие продукты, как Ценовой центр, где клиенты могут узнать справедливую стоимость ценных бумаг, или Диск НРД, где можно получить официальные данные НРД об организациях, ценных бумагах и связанных с ними событиях. Сайт получает огромный массив данных из core-системы и показывает эти данные клиентам по подписке в виде API и так же в интерфейсе самого сайта. Сайт, который является сложным и уникальным продуктом, поддерживает и развивает небольшая команда из 8 человек. Scrum-мастер 3 Разработчика Тестировщик Аналитик Владелец продукта Представитель бизнеса Мы стараемся придерживаться гибкой методологии agile при разработке продукта. У нас есть ежедневные дейли, ведем свои задачки мы на борде в гитлабе, собираемся раз в спринт на планирование и проводим обязательное демо. Конечно, мы не всегда делаем ретроспективу спринта, но на момент написания статьи работаем над тем, чтобы это стало обязательной рутиной. Но и есть некоторые модификации, про них я и хочу немного рассказать: Смотреть за заявками сторонних систем, при которых нужна доработка сайта. Реагировать на инциденты. Контролировать сроки поставки релизного цикла «больших систем» на этапе тестирования или опытной эксплуатации. Возникает обратная связь от клиента при которой мы видим, что нужно сделать новую фишку на сайте. Заводим в гитлабе карточку в колонке backlog.  На встрече по планированию спринта мы собираем backlog:  Сортируем задачки по простой системе скоринга ICE.  Если фишка не особо сложная на первый взгляд в реализации и и была инициирована клиентом, то, как правило, она будет выше всех карточек в backlog и попадает в ближайший спринт.  Передвигаем карточку в колонку DEV.  Перед разработкой создаем задачу в Redmine, так как в нашей компании это является неотъемлемой частью для связи коммита в git.  Создаем ветку /feature/334455, где номер — это ID задачи в Redmine. Разрабатываем Пишем unit-тест Если локально проходят тесты Push кода в gitlab и создаем MR Запускается сборка CI, при которой повторно проверятся unit-тесты. Следующий шаг —  запуск проверки когда на качество в SonarQube. Дальше проверка в CheckMarx на уязвимости. Код-ревью тимлидом. Если все успешно, автодеплой в тестовый контур с помощью AWX. Последний шаг —  запуск несколько smoke-тестов на проверку работоспособности контура и базовых интеграций. Дальше разработчик передвигает карточку в Очередь на тест. Вступает в дело тестирование. Карточка передвигается в колонку TEST. Если тест-кейсы пройдены и замечаний нет, карточка переходит дальше. За день до встречи проведения ДЕМО продукта, собирается предрелизная ветка из задач в колонке. На встрече происходит демонстрация продукта заказчику. Если замечаний не обнаружено, ветка финально проходит ручное тестирование. Все карточки переходят в колонку «Готово к установке». Происходит согласование задач, которые мы хотим установить в пром. Запуск процедуры деплоя на пром происходит по кнопке в TeamCity. Карточки переходят в колонку «Установлено на пром». Тест-кейсы переносятся в систему хранения HP ALM, где они описываются в формате для передачи в автотесты. Группа автотестеров добавляет новые тесты для постоянного регресс-тестирования проекта и берет их из ALM. Карточка переходит на аналитика, который документирует и формализует ее и вносит изменение в ФТ (Функциональные требования или ТЗ). PROFIT На каждом шаге могут возникнут трудности и форс-мажоры — это то, что мы решаем каждый день. Искренне скажу, что такой идеальный спринт у нас бывает нечасто. Как вы могли заметить, здесь нет шага ретроспективы.  Как говорят популярные в России agile-коучи «Ретроспектива - это сердце agile». Бывают спринты, где мы хотим сделать не только изменение кода, но и изменить процесс поставки или добавить какие-либо кусочки к нашей инфраструктуре. Мы обрабатываем такого рода задачи по такому же сценарию, только исключаем шаги, связанные с комитетом кода. Минимизируется количество дефектов при поставке в production Быстро создаем новые «фичи» Заказчик продукта видит результат гораздо раньше Только небольшая часть компании работает по гибким методологиям, отсюда приходиться сильно высокие требования к участникам команды в области знания методологии и высокий порог ввода новых участников или их замена. Можно «выжить» небольшой командой даже в условиях огромного entreprise, используя гибкие практики, но с некоторыми модификациями. Приходиться конечно следить сразу в нескольких системах за изменениями, адаптироваться. Но в целом эта история вполне реальна и на текущий момент мы продолжаем двигаться и разработать свой продукт.