Как я боролся с agile 3 года назад или как давить agile в организации

   Текущая увлеченность agile многих организаций во многом запоздала – шустрые коммерческие конторы уже давно внедряли у себя те или иные agile-практики. Где-то централизованно, где-то приходили привыкшие работать по agile менеджеры, где-то по другому было невозможно добавиться поставленных акционерами целей на волатильных рынках.

    Отдельно отмечу, что считаю agile не универсальной практикой (собственно, как и любую другую управленческую практику) – т.к. для разных типов бизнеса и этапов зрелости компаний нужны разные инструменты. Например, для бизнесов мало зависимых от ИТ и получающих основную выручку от продажи ограниченного количества в целом давно устоявшихся продуктов (нефтегаз, электроэнергетика, горно-металлургические компании, агропромышленный комплекс) agile может помочь набрать бизнесу скорость, на которой менеджмент уже не справится с управлением. А в отличие от банков и телекомов (канонических ИТ-зависимых бизнесов) в производстве и ТЭК ценой ошибки может стать человеческая жизнь, а то и не одна. Примерами тому служат Чернобыльская катастрофа, пожары на НПЗ в России и разлив нефти на платформе BP в Мексиканском заливе.

    Итак, допустим стратегического курса на agile в организации нет, но те или иные группы заинтересованных лиц де факто внедряют принципы и практики agile в организации. Как подавить ростки agile - добиться предсказуемости и глубокой архитектурной проработки изменений?

    Для начала нужно понять что пробиваются ростки agile. В некоторых организациях службы ИБ даже не в курсе реализуемых ИТ и бизнес-проектов. Интеграция ИБ в жизненный цикл ИТ-проектов уже не роскошь а необходимый элемент сколь нибудь результивной системы ИБ.

    Важным элементом будет реализация принципа владения активами на практике - определение владельца актива и согласование владельцем как самого изменения так и принятие риска, если безопасность идентифицировала риск и коммуницировала его в бизнес-терминах (неплохие шаблоны формы принятия рисков и примеров выражения рисков ИБ в бизнес-терминах есть в ISO 13569).

    Замыкающими контролями будут согласования  инфраструктурных изменений. Любая, даже самая agile проектная команда зависит от согласования предоставления доступов в другие системы, согласования сетевых портов, установки приложений на ПК. Все это возможно согласовывать, например, при наличии согласования руководителя сотрудника-инициатора, соответствии его должностных обязанностей характеру ПО\сервиса, правильного оформления соответствующих запросов.

    Безопасность в крупной корпорации консервативной сферы бизнеса должна быть неумолимой машиной, перемалывающей несогласованную активность в пыль. Это позволит недопускать "разбитых окон" (см. книгу Фрикономика), стимулирующих нарушения политики ИБ, кликанье на черте какие ссылки в письмах от черте кого и прочий бардак, точащий ржавчиной хаоса корпоративные меры безопасности.

    С другой стороны - необходимо создать и некий "клапан" выпуска "пара". Согласование возможно ускорить если инициатор смог эскалировать вопрос своему руководителю, и лучше поручить согласования рядовому сотруднику или руководителю направления, дабы руководитель ИБ мог выступить в виде арбитражной инстанции. 

P.S. Для справки - Ваш покорный слуга проектировал и реализовывал все 3 группы указанных контролей в 2012 и его тогдашний работодатель показал лучшую чистую прибыль среди лидеров своего сектора (миллиардов 9 долларов что-ли). А в 2013 перешел в другую компанию по рекомендации одного из инициаторов запросов. В том числе потому, что "неумолимая машина" (жесткий процесс) вполне симпатична, если быстро и постоянно работает по четким, понятным и прозрачным правилам.