КРАТКИЙ ОБЗОР ЗАПАДНОГО ОПЫТА ГОСAGILE

Чем было вызвано внедрение Agile в правительстве Великобритании? Руководители департаментов и агентств видели, что работу над проектами нужно организовать более эффективно и с меньшими затратами, в целом обновить государственную стратегию в отношении ИКТ.

Изменение организационной культуры было сложным. Начинали с простого — со знакомства с Agile-подходами в небольших проектных командах. При использовании Agile применялись и адаптировались те методы, которые подходили проекту или организации: Scrum, Lean, Dynamic System Development Method (DSDM) и т.д.

При представлении и поддержке гибких подходов очень важна была роль специалистов по Agile: коучей, разработчиков. Организационная культура оказалась и помощью и помехой при реализации управления по Agile. Новички, те, кто сравнительно недавно начал работать в государственном секторе, откликались на новый подход очень хорошо. Однако процессы получения финансирования и традиционная модель контроля проектов сверху шли вразрез с разработкой по Agile. Проблемой была координация ведомств и команд: в разных ведомствах формировались отдельные, не связанные друг с другом команды цифровизации. Кроме того, команды, разрабатывающие фронт-энд (клиентская часть ПО), работали в соответствии с Agile-подходами, команды, разрабатывающие бэк-энд (данные, бизнес-логика), работали каскадным методом. В связи с этим возникала и до сих пор существует бюрократия, сложное взаимодействие между командами, что затрудняет необходимые изменения продукта, а иногда и отменяет их.

Для государственных цифровых услуг был создан свой стандарт (Digital Service Standard), действующий до сего дня. В него в том числе входит анализ понимания потребностей проекта со стороны пользователя: о чем вообще идет речь в этом проекте в целом, а не только в ИТ-части. В фокусе — использование общих платформ и открытых стандартов, таких как облако, правительственное облако, открытое облако. Одним из пунктов стандарта является тестирование систем на практике с целью обеспечить их простоту и доступность для пользователя.

Последним пунктом является тестирование сервиса министром, ответственным за сервис. Если сами министры могут использовать такого рода проекты, то и все остальные подчиненные смогут это использовать. Успех пилотных проектов по применению Agile был одним из самых лучших способов убедить остальную часть организации в эффективности Agile.

Для разработки качественных цифровых услуг был создан Service Manual («Руководство по цифровым услугам»). Этот документ касается всех аспектов разработки услуги — от проектирования, технологий, команды до исследования пользователей, поддержки пользователей при использовании сервисов, применения данных для анализа сервиса с целью его дальнейшего улучшения. Отдельным разделом руководства является работа по Agile: ключевые принципы Agile, основные способы организации работы по Agile, основные фазы проекта.

В Великобритании приняты следующие ключевые принципы ГосAgile:

• Фокус на потребностях потребителя.

• Итеративная разработка продукта. Раньше в соответствии с каскадной моделью британские госорганизации выпускали два релиза в год. Однако правительство производило по несколько изменений и в требованиях и в политике в течение одного дня. Традиционная модель не позволяла быстро реагировать на эти изменения. Сейчас разработанные с помощью Agile системы выпускаются изначально с минимальным набором функций, а затем новые функции добавляются уже в режиме онлайн по мере разработки, накопления опыта и получения отзывов от пользователей.

• Постоянное улучшение услуг и команд после введения в эксплуатацию. Имеет место более активная реакция на изменения в политике, на изменения потребностей пользователя и соответствующая коррекция сервисов и услуг. Постоянное улучшение команды также подразумевает, что команда должна быть более или менее постоянной и накапливать больше опыта в различных отраслях и в практической плоскости. Для сравнения: в каскадной модели этого часто не происходит, поскольку по завершении проекта команда или специалист переходит на другой проект.

• Быстрое выявление ошибок и обучение на них. Сбои, которые происходят на ранних этапах, проще устранить, и их последствия не такие тяжелые.

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

В госорганизациях Великобритании рекомендовано работать в соответствии с основными подходами и фреймворками: Scrum, Kanban, Lean. Сейчас Scrum используется в большинстве проектов. Можно применять другие фреймфорки Agile. Не обязательно выбирать только один подход при работе над проектом, можно сочетать инструменты и техники из разных подходов. Управление разработкой продукта или услуги по Agile включает в себя несколько основных правил:

1. Не замедлять разработку.

2. Принимать нужные решения на релевантном уровне. У команды и владельца сервиса должно быть право на принятие решений. Решения принимаются часто, поэтому необходимо, чтобы они были обоснованными и удовлетворяли требованиям пользователей.

3. Работать с правильными людьми, имеющими необходимый уровень знаний, опыта, иметь ясную организационную структуру.

4. Смотреть и разбираться в работе самому владельцу сервиса. Для этого необходимо принимать участие во встречах команды, особенно во встречах в конце спринта (Sprint Review Meeting). Рекомендуется использовать Agile-доску, поскольку это прекрасный способ следить за тем, как движется разработка.

5. Доверять и проверять. Для этого необходимо регулярно общаться с командой разработки, а в конце каждой итерации продукта проводить обсуждение итогов с командой.

Основные этапы разработки продукта в британском ГосAgile представлены в таблице 6.

На этапах Discovery и Alpha государство выделяет на каждый проект порядка 750 000 фунтов. За это время нужно определить пользователей, написать пользовательские истории, определить масштаб разработки, разработать прототип. В конце этапа Alpha уже оценивается бюджет на этап Beta, в конце этапа Beta — бюджет на поддержку, улучшение продукта (услуги), т.е. на этап Live.

На каждом этапе проекта организуется проверка соответствия разработки стандарту цифровых услуг. Проверку осуществляет Government Digital Service, которая может остановить разработку и сократить средства, выделяемые на эту работу, в случае несоответствия разрабатываемого продукта (услуги) стандарту, например, продукт недостаточно ориентирован на пользователей, проведено некачественное исследование пользователей и т.п.