На AgileKitchen по теме Гибкие методы в государственных проектах собрались не только представители ИТ, чтобы обсудить свои трудности в работе по Agile в проектах для государственных и близких к ним заказчиков. Было много представителей заказчиков, то есть государственных и регулирующих структур. Как уже применяющих Agile при ведении своих проектов, так и желающих получить преимущества, которые дает Agile, прежде всего прозрачность продвижения проекта, для государственных проектов повсеместно. В том числе перенести практики на не-ИТ проекты, там, где это уместно. И основным вопросом при подготовке встречи как раз и было: какое нужно регулирование в виде стандартов, методических рекомендаций или других документов, чтобы достичь этих целей. А то, что встреча проходила в Аналитическом центре при Правительстве Российской Федерации подчеркивает заинтересованность.

Замечу, кстати, что мнение о том, что Agile-подход не предполагает нормативных документов - ложное. По Scrum есть нормативные документы, согласованные в Scrum Alliance и отделяющие от других методов. Есть сообщества и по другим методам, и Agile в целом тоже имеет свои нормативные документы, такие как Agile Manifest. Другое дело в характере нормирования и заложенной в нем гибкости и адаптивности методов, а также в ценностях и мышлении, которые и обеспечивают успех проектов.

Надо сказать, что в государственных проектах Agile как способ ведения достаточно широко применяется. Об этом были рассказы не только со стороны ИТ, но и со стороны Заказчиков. Включая неожиданные для меня - опыт принуждения заказчиком, Ростехнадзором, своего подрядчика к переходу на Agile для обеспечения предсказуемости и скорости выполнения доработок по проекту. Хотя традиционно федеральные ведомства считаются неповоротливыми и консервативными противниками новых гибких методов. И был интересный рассказ из Тюменской области о практике контрактования проектов с нефиксированным scope в рамках 44-ФЗ. Вообще входе обсуждения на openspace конкретных вопросов было интересно наблюдать диалог между заказчиками и подрядчиками в стиле "Мы делаем это, потому что наши ИТ-подрядчики это не делают - Нет, таких заказчиков не бывает, это делаем мы, потому что наши заказчики никогда этого не делают."

Подводя резюме встречи, можно зафиксировать следующее (это - авторское мнение, а не официальная резолюция).

  1. Нынешнее нормативное регулирование (ГОСТ, ФЗ) не препятствует проводить проекты по Agile при желании с обоих сторон. При этом желание может быть как начальным, добровольным, так и транслироваться с одной стороны разными просветительско-административными методами. Вместе с тем есть традиция применения нормативных документов, которая противоречит способу ведения Agile-проектов, и преодоление этой традиции требует существенных усилий в каждом случае.
  2. Признано, что точно будут полезны методические указания, рассчитанные на начинающих заказчиков и типовые категории проектов, которые помогут гос.заказчиком начать выполнять проекты в этом стиле. Особенно в регионах. Для тех ситуаций, когда есть взаимное желание заказчика и подрядчика, но не хватает подсказок, как сопрячь это с нормативными требованиями, включая защиту перед различными контролирующими органами.
  3. Есть интенция со стороны государства создать такое нормативное регулирование проектной работы, которое бы обеспечила прозрачность хода проекта, достижимость его результатов и другие, которые дает Agile-подход. Вообще говоря, не ограничиваясь ИТ-проектами. При этом сделать это через регламентацию метода, а не результата. Способ подтверждается опытом ряда стран, которые именно так и поступили.
  4. Придуман конкретный сценарий инициации проекта для неквалифицированного заказчика без четких требований. Сценарий довольно жесткий для подрядчиков.
    1. Запрос предложения рамочной темой. На него надо ответить набором user story (или другим описанием функционала) с ценой. В процессе формирования предложения - есть право контактировать с Заказчиком, который выделяет ресурсы.
    2. На основе полученных предложений, а также используя опыт коммуникации с потенциальными подрядчиками, Заказчик понимает и формирует scope проекта, который будет являться предметом заказа и именно его выставляет на конкурс.

Работа будет продолжена через рабочие группы и серию мероприятий. На встрече были и выступали люди из Аппарата Правительства и Минкомсвязи, хотя не все светили должности в программе. И они заинтересованы в результате.

А сейчас - резюме докладов. Видео будет выкладываться на канале ScrumTrek на youtube, первое уже есть. А презентации уже выложены, тоже на канале ScrumTrek на slideshare.

Водопад и Agile. Альтернативы или дополняющие подходы? Шестопалов Павел, референт Департамента экономики и финансов Аппарата Правительства Российской Федерации. Презентация, видео.

Внедрение проектного управления в Сочи-2014 и Agile. Андрей Бадин, Управляющий партнер компании «Проектные сервисы», Заместитель председателя Совета по внедрению проектного управления в органах власти при Минэкономразвития России. Презентация

Госзаказчик и исполнитель - коллеги или враги? Антон Душутин, ЗАО Сфера. Презентация

Практический опыт создания и развития Комплексной системы информатизации Ростехнадзора. ​Макарчук Марина Владимировна, советник, Управление специальной безопасности, Ростехнадзор Презентация видео.

А как у них? Agile в государственных проектах других стран. Асхат Уразбаев, ScrumTrek Презентация, видео - опыт США, Британии и Австралии.

Гибкая разработка ИС в рамках ГОСТ. Сергей Смирнов, начальник сектора разработки, СПб ГУП Санкт-Петербургский информационно-аналитический центр. Презентация видео

Практика заключения и реализации контрактов на создание и развитие ИС по T&M-модели в рамках 44-ФЗ. Иван Дубровин, внештатный эксперт Аналитического центра при Правительстве РФ. Презентация видео

После докладов был open space с открытой дискуссией по вопросам от самих участников. И входе обсуждения по ряду из них были получены вполне рабочие гипотезы, включая процедуру инициации контракта при нечетких требованиях, о которой я писал в начале. Участники заявились на участие в рабочей группе. Работа будет продолжена. А это - финальное фото.