6911
правок
Изменения
м
Нет описания правки
На AgileKitchen по теме [https://agilerussia.timepad.ru/event/260880/ Гибкие методы в государственных проектах] собрались не только представители ИТ, чтобы обсудить свои трудности в работе по Agile в проектах для государственных и близких к ним заказчиков. Было много представителей заказчиков, то есть государственных и регулирующих структур. Как уже применяющих Agile при ведении своих проектов, так и желающих получить преимущества, которые дает Agile, прежде всего прозрачность продвижения проекта, для государственных проектов повсеместно. В том числе перенести практики на не-ИТ проекты, там, где это уместно. И '''основным вопросом при подготовке встречи как раз и было: какое нужно регулирование в виде стандартов, методических рекомендаций ''' или других документов, чтобы достичь этих целей. А то, что встреча проходила в Аналитическом центре при Правительстве Российской Федерации подчеркивает заинтересованность. Замечу, кстати, что мнение о том, что Agile-подход не предполагает нормативных документов - ложное. По Scrum есть нормативные документы, согласованные в [https://www.scrumalliance.org/ Scrum Alliance] и отделяющие от других методов. Есть сообщества и по другим методам, и Agile в целом тоже имеет свои нормативные документы, такие как Agile Manifest. Другое дело в характере нормирования и заложенной в нем гибкости и адаптивности методов, а также в ценностях и мышлении, которые и обеспечивают успех проектов.
Надо сказать, что в государственных проектах Agile как способ ведения достаточно широко применяется. Об этом были рассказы не только со стороны ИТ, но и со стороны Заказчиков. Включая неожиданные для меня - опыт принуждения заказчиком, Ростехнадзором, своего подрядчика к переходу на Agile для обеспечения предсказуемости и скорости выполнения доработок по проекту. Хотя традиционно федеральные ведомства считаются неповоротливыми и консервативными противниками новых гибких методов. И был интересный рассказ из Тюменской области о практике контрактования проектов с нефиксированным scope в рамках 44-ФЗ. Вообще входе обсуждения на openspace конкретных вопросов было интересно наблюдать диалог между заказчиками и подрядчиками в стиле "Мы делаем это, потому что наши ИТ-подрядчики это не делают - Нет, таких заказчиков не бывает, это делаем мы, потому что наши заказчики никогда этого не делают."
# Есть интенция со стороны государства создать такое нормативное регулирование проектной работы, которое бы обеспечила прозрачность хода проекта, достижимость его результатов и другие, которые дает Agile-подход. Вообще говоря, не ограничиваясь ИТ-проектами. При этом сделать это через регламентацию метода, а не результата. Способ подтверждается опытом ряда стран, которые именно так и поступили.
#* С моей точки зрения, нормативного документа будет не достаточно, необходимо формирование определенной культуры. Но регламентирующий документ может этому способствовать, быть способом убеждения, особенно в государственной среде. Замечу, кстати, что такой подход отчасти противоречит философии Agile "Люди и взаимодействие важнее процессов и инструментов" - нормированием процесса пытаются подменить убеждение людей.
#* А еще обсуждение показывает, что есть набор конкретных практик, давно известных и принятых в отрасли, таких как тестовая интеграционная среда, например, которые не обеспечивают успех проекта, но устраняют давно (с 70-х) известные грабли на его завершении, и которые, тем не менее, не применяются в конкретных проектах. Или вера в идеальные конструкции, такие как идеальное проектирование и затем реализация с неизменными требованиями. И вот их - можно разрушать нормативно, например, ограничивая сроки или стоимость первых этапов, оканчивающихся внедрением продукта или наличия на проекте соответствующей инфораструктуры инфраструктуры и методик, тоже в привязке к этапности. Но к нормативам должна прилагаться практика, в виде соответствующей службы, готовой помочь на конкретном проекте, иначе они будут восприниматься как "опять эти теоретики требуют невозможного".
# Придуман конкретный сценарий инициации проекта для неквалифицированного заказчика без четких требований. Сценарий довольно жесткий для подрядчиков.
## Запрос предложения рамочной темой. На него надо ответить набором user story (или другим описанием функционала) с ценой. В процессе формирования предложения - есть право контактировать с Заказчиком, который выделяет ресурсы.
* В докладе были конкретные примеры контрактных условий со ссылкой на тендерный сайт - поскольку это было открыто опубликовано как условия конкретных тендеров.
После докладов был open space с открытой дискуссией по вопросам от самих участников. И входе обсуждения по ряду из них были получены вполне рабочие гипотезы, включая процедуру инициации контракта при нечетких требованиях, о которой я писал в начале. Участники заявились на участие в рабочей группе. '''Работа будет продолжена'''.А это - финальное фото. <img src="https://scontent-ams2-1.xx.fbcdn.net/hphotos-xlp1/v/t1.0-9/12239555_10153209758835924_310694419160189612_n.jpg?oh=8ca7487dc7dc8307c021ec5c3cba89d7&oe=56F4BD04">
