Изменения

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

* Практические кейсы использования agile-методов ведения проектов с военным блоком, МВД и другими тяжелыми заказчиками. И проблемные точки. которые возникают при осуществлении, в которых наличие соответствующих нормативных документов могло бы сильно облегчить коммуникацию. В докладе, правда, звучало. что при наличии документа заказчики сами проникнутся таким подходом, потому что должны будут исполнять. Я думаю, документа недостаточно, но он поможет. А набор проблемных точек, который звучал в докладе - полезен.

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

* Интересно тут, что инициатором перехода на Agile был Заказчик, и он заставил подрядчика перейти на 3-недельные поставки релизов и внедрить другие практики. В результате сейчас (уже три года) - все хорошо, система развивается удовлетворительным и предсказуемым образом. А что было раньше и ушло - тоже есть на слайдах презентации.

* Наиболее впечатляющий кейс - в США, где внедрение практик Agile как обязательной меры для государственных ИТ-проектов произошло после грандиозного фейла с сайтом национальной страховой программы здоровья HealthCare.gov. Создание сайта для регистрации страховок по первоначальным оценкам требовало 94 млн$, еще до старта работ сумма выросла до 292 млн$, а фактически сайт обошелся в 1.7 млрд.$ И при этом на момент старта сайт был практически не работоспособен: при планируемой нагрузке в 60000 посетителей тесты показывали максимум 1100, только 1% посетителей в первом месяце смогли завершить регистрацию из-за множественных ошибок и так далее. Проект велся по водопаду, подробности можно [https://en.wikipedia.org/wiki/HealthCare.gov прочитать в вики] и других источниках.

* В Англии есть отдельный сервис электронного правительства (Goverment Digital Services), являющийся частью кабинета министров. И есть нормативные документы, регламентируюшие ведение ИТ-проектов по созданию сервисов, доступных как часть электронного правительства. В которых тоже достаточно жестко прописан Scrum-метод. Методика родилась в 2011, после того как предыдущий вариант был признан неработоспособным и было решено, что его следует разработать заново, новыми способами, вместо эволюции. Из интересного - там диктуется 5 фаз проекта - discovery, alpha, beta, live and retiretment, каждая из которых должна кончаться поставкой, при чем альфа - уже работающее ПО. И при этом есть относительно жесткое ограничение по общему бюджету первых двух фаз - таким образом практически добиваются ранней поставки.

* Австралийский опыт интересен тем, что там премьер - из ИТ и он видит в управлении на основе Agile залог успешного развития страны - не только в ИТ, а и в других областях. Что касается конкретного регулирования, то оно взято у Британии

* В презентации - много ссылок, смотрите.

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

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

* В целом доклад - это хорошая основа для оглавления методологических рекомендаций, а по ряду разделов - и для их наполнения.

* В докладе был представлен конкретный кейс контрактования проектов с переменным scope в рамках 44-ФЗ.Заметим, что это не оплата по T&M, тут авторы неправы (и сами признавали это). Способ применяется в Тюменской области и успешно проходит аудиторские и другие проверки. Правда, как признал докладчик, у нас в каждом регионе - своя правоприменительная практика, и это не означает. что в вашем регионе контролирующие органы одобрят такую конструкцию.

* Контракт в этом случае выглядит из двух частей: не тарифицируемой и тарифицируемой. В не тарифицируемую входит сопровождение уже разработанного функционала, а в тарифицируемую - развитие системы. Тарифицируемая часть ограничена по бюджету и есть ставка за час. А дальше - самое интересное. Каждая доработка оценивается исполнителем в часах и идет торговля - нужна ли она Заказчику за столько часов, или нет. При этом Заказчик не обязан выбирать всю квоту тарифицируемых часов.

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