GOSAGILE? Итоги обсуждения применения Agile в госконтрактах
Published by Асхат Уразбаев, November 4th, 2015
Текущая ситуация
В группе AgileRussia в фейсбуке состоялась интересная дискуссия о применении Agile в проектах с государственным участием.
Разработка программного обеспечения по госконтрактам (ГК) — дело непростое. Она регламентируется, с одной стороны, 44-ФЗ федеральным законом, регулирующим госзакупки и стандартами ГОСТ (19 и 34).
ГОСТ–34 определяет разработку Автоматизированной Системы (АС). ГОСТ–19 (1979 год!) определяет создание Программного Обеспечения (ПО). Оказывается, внедренное ПО превращается в АС. Лично мне это было не очевидно.
Можно ли разрабатывать по Agile?
Эксперты сходятся во мнении, что это возможно:
Дмитрий Синяев. Госты регламентируют бумажки, что в них должно быть написано. А результаты работ и в том числе бумажки, которые вы должны написать, регламентируют контракт и календарный план. Делайте контракт и календарный план таким образом, чтобы он не мешал вам работать по Agile…
Ближе к классическому Scrum:
Дмитрий Шайдаев … Внутри команды работаем по эджайлу, выпускаем внутренние релизы каждые 2 недели, назначаем кого-то на роль продакт-оунера. А наружу отдаем ГОСТовские артефакты. Создание продуктового бэклога и первые несколько спринтов ведем параллельно с созданием ТЗ. В ТЗ оставляем пространство для маневра, не прорабатываем детально, т.к. по ходу спринтов у нас что-то скорректируется. Последние спринты делаем с фокусом на багфикс и стабилизацию. Или что там в этом ГОСТ что не позволяет внутри работать по Agile.
Или просто короткими (относительно) итерациями:
Сергей Нужненко. …по ГОСТ и без него комфортно строить системы (именно АС, а не ПО) итерациями по 3 месяца (и более) при условии, что концепция перед этим было нормально проработана и это тоже не менее 1–2 месяца. Таким образом мы можем получать за (минимум) 4–5 месяцев выход первой очереди в опытную эксплуатацию (которая для многих систем не может сводиться к демо-сессии и требует завершения производственного цикла для нормального измерения улучшаемых показателей, а это часто месяцы или кварталы) и по 3 месяца на следующие циклы.
Обоснование бюджетной заявки
Для работы по Agile требуется определенное пространство для маневра по уточнению рамок работ.
Иван Дубровин. Бюджетная заявка содержит высокоуровневый Scope работ и его оценку — от этого не уйти, но в ходе реализации контракта появляется поле для маневра, что есть бесспорное благо, т.к. очень часто и заказчик и исполнитель становятся заложниками детального ТЗ.
Дмитрий Шайдаев А для заявки нужны оценки всех работ на всех этапах и их декомпозиция — верно? Ну да придется написать воды. А во всех ли проектах по госконтрактам фактический план работ совпадает с бюджетной заявкой? ))
Это можно делать (при определенных знаниях и навыках):
Иван Дубровин Для справки: обоснование потребности в бюджете не требует детального ТЗ. И 44-ФЗ позволяет делать T&M контракты.
Такие преценденты были в опыте Ивана Дубровина. Он признает, что это непростой процесс:
Иван Дубровин …Проверки проходили тяжело, у аудиторов /счетной палаты/ сдвиг парадигмы конкретный, но НИ РАЗУ в такой схеме не было усмотрено нарушение закона.
С ним согласен Сергей Смирнов
Sergey Smirnov. На личном опыте могу сказать, что не все так безнадежно, и в комитете есть толковые специалисты, которым можно объяснить то, как в современном мире эффективно вести разработке. Для ряда ГК уже в этом году удалось переломить стереотип водопада и сформировать контракты с инкрементными, итеративными разработками.
При чем тут ГОСТ?
Иван Дубровин …убрать ссылки соблюдать ГОСТ /из ГК/ можно, но не всегда.
Риски плавающего scope
Sergey Smirnov… уровень абстракции прямо пропорционален риску появления недобросовестного исполнителя. Если ГК исполняется единственным источником или есть какие-то другие факторы, минимизирующие риск выигрыша стороннего недобросовестного участника, то такой подход вполне реализуем и очень удобен как потребителям услуг/заказчикам, так и исполнителям. В противном случае, заказчику приходится опускаться в детальную формализацию требований.
Sergey Smirnov … большая часть ТЗ составляется IT компаниями, которые либо уже заранее прорабатывают предмет или имеют значительные наработки и предварительные договоренности. В этом случае сами компании пытаются прописать в требованиях свои преимущества (причем очень часто встречаются и откровенные нарушения). Если у них это получается и они достаточно уверены в своем выигрыше, то высокоуровневые требования зачастую остаются. А вот, если явных факторов, указывающих на определенного исполнителя, прицепить к ТЗ не получается, или если ТЗ составляется не ИТ специалистами, то очевидным стремлением получить максимум и не быть обманутым является детализация требований.
Мешает ли ГОСТ
Sergey Smirnov. ГОСТ 34 сам по себе не мешает выстраивать итеративный процесс и не предписывает водопадную модель. Вот цитата из ГОСТ_34_601–90 “Стадии этапы, выполняемые организациями участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта. В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.”
Т.е. в ГК достаточно указать на необходимость создания ТЗ и ряда Дополнений к ТЗ, в которых уже в полном соответствии с ГОСТ можно уточнять календарные планы, этапы выполнения работ, виды документов и т.п. Можно успешно выполнять работы итерациями и даже вводить в эксплуатацию системы или ее части по нескольку раз в год.
Потребность в изменении и новом стандарте
Sergey Smirnov. Огромным недостатком ГОСТ 34 и 19 является то, что многие трактуют его как водопад и выстраивают календарные планы таким же образом. Также в ГОСТ довольно много устаревшей терминологии, наименований разделов документов и т.п.
Со всем этим вполне можно работать и работать эффективно и по agile, но определенно есть потребность в создании стандартов, рекомендаций, шаблонов документов, которые бы сразу указывали заказчикам, потребителям услуг, разработчикам на современные процессные и инженерные agile практики.
Проблема в том, что когда ребята из комитетов, министерств хотят что-то упорядочить и систематизировать, они берут ГОСТ 34, 19. А в них нет намека на итеративность/инкрементальность. Они начинают настаивать на всем наборе документов для всех АС, на всех стадиях и воспринимают это как жесткую водопадную модель, Я вначале года потратил месяц на то, чтобы убедить юристов, отделы контроля и т.п. в том, что ГОСТы не запрещают итеративность, что потребителю хочется получать результаты как можно быстрее, а не в конце года, что разработчикам удобнее работать итеративно и даже контролирующим органам/комитетам принимать работу намного проще поэтапно, а не разом всю систему в конце года. В этом и смысл, очень хорошо было бы создать стандарт или дополнение, которые бы сразу давали понятие о современных эффективных методах работы.
Максим Цепков. Я полагаю, что успешная разработка обеспечивается agile-процессом, который, при необходимости и по месту должен быть дополнен уместными более тяжелыми практиками, такими как тщательная спецификация ПМИ или трассировка решений до первичных требований или что-то еще подобное, а ты формулируешь, что ГОСТ (34), являясь основой, позволяет при необходимости использовать agile в необходимых пределах. Это — разница в исходных полаганиях. При том, что в конкретном проекте оба таких приближения могут привести к одному и тому же процессу, просто с разных сторон. Соответственно, я хочу, чтобы нормативка (ГОСТ) тоже позволяла стартовать от Agile.
Какие есть варианты
Есть вариант создать методические указания по организации Жизненного Цикла ПО
Иван Дубровин. … мы говорим не о госконтрактах, а о создании документа, который агрегирует все существующие лучшие практики (и не только Agile-подход, ИМХО надо затронуть темы QA/QE, DevOps) и станет реальным помощником для разработчиков, исполняющих государственный (и не только) заказ.
Сергей Нужненко. С этим многие (и я тоже) согласны: водопад по ГОСТ — это следствие применения бездумного copy-paste и отсутствия минимальных знаний о проектировании и планировании. И там выше обсуждали, что методические указания по организации ЖЦ АС тоже нужны. Возможно, они даже нужнее, чем асфальтирование в стандарте SCRUM процесса.
Достаточно ли этого, чтобы сменить парадигму в головах заказчиков? Максим Цепков считает, что нет.
Максим Цепков. Асфальтирование SCRUM — точно лишнее. Вообще Agile не равно SCRUM. Методические указания по организации ЖЦ систем — полезны. И всяк желающий может сделать инициативную группу для их разработке. Но вот для смены парадигмы мышления и подхода нужен именно ГОСТ, а методические указания это не сделают.
Какие следующие шаги
Однако это может стать отличным первым шагом.
Игорь Беспальчук Очень согласен с Максимом Цепковым по поводу практики применения. Мне тоже кажется, что наличие/отсутствие стандарта — совсем не самое главное препятствие. Но, с другой стороны, если подготовить рекомендательный (а не допускающий, как сейчас!) стандарт, то это может стать первым шагом и поводом для разговора и изменений.
Originally published at urazbaev.ru on November 4, 2015.
