Журнал "Information Security/ Информационная безопасность" #4, 2021

В некоторых случаях Agile-подход может заме- нить более формальную документацию информаци- ей, встроенной в программ- ные инструменты. Организациям, переходя- щим на Agile, могут потребо- ваться изменения как в своих методах управле- ния, так и в обеспечении контроля за связностью потребностей заказчика и задач, которые решают разработчики. Требования регулятора довольно часто меняются, причем это касается самых разных вопросов. Это зна- чит, что и программный про- дукт должен меняться, ино- гда коренным образом и в очень сжатые сроки. Изучение различных фреймворков масштабиро- вания Agile позволит извлечь максимум выгоды от гибкого подхода для своей организации. развиваются по мере поступ- ления дополнительной инфор- мации и дальнейшего опреде- ления потребностей заказчика. Поэтому в Agile-разработке необходимая документация составляется и обновляется в конце заранее определенных периодов времени в ритмиче- ской разработке Agile (напри- мер, итерация, релиз или дру- гая важная веха, определенная программой) в объеме, доста- точном для дальнейшего использования программы. Кроме того, в некоторых слу- чаях Agile-подход может заме- нить более формальную доку- ментацию информацией, встроенной в программные инструменты. Миф 5: Agile не требует контроля В рамках подхода Agile члены команды, работающие над про- дуктом, обладают автономией в принятии решений о том, как удовлетворить потребности заказчика. Однако в крупных организациях сложно предо- ставить командам полную авто- номию из-за требований к отчетности и подотчетности, да и команды не всегда имеют непосредственный контакт с заказчиком. В результате орга- низациям, переходящим на Agile, могут потребоваться изменения как в своих методах управления, так и в обеспече- нии контроля за связностью потребностей заказчика и задач, которые решают раз- работчики. Это включает в себя продумывание четко опреде- ленных границ ответственно- сти, в рамках которых команда может свободно принимать решения, и четко определен- ный, быстродействующий про- цесс управления принятием решений, которые находятся вне зоны контроля команды. Миф 6: Agile не применим к созданию безопасных продуктов, соответствующих требованиям регуляторов Требования регулятора довольно часто меняются, при- чем это касается самых разных вопросов. Это значит, что и программный продукт должен меняться, иногда коренным образом и в очень сжатые сроки. Например, требование по проверке на отсутствие уязвимостей и недокументиро- ванных возможностей было изменено на получение уровня доверия к процессу разработки. На первый взгляд, только Agile позволяет гибко реагировать и достраивать процесс под выполнение требований; поче- му же родился миф? Прежде всего, он обусловлен акцентом на Agile как на быструю разработку, зачастую в ущерб качеству, а значит и безопасности. К тому же соз- дание безопасных продуктов предъявляет значительно боль- шее количество требований и вносит дополнительную слож- ность в целевую систему. Рас- смотрим пример с разработкой приложения для мобильного банкинга. По требованию регу- лятора процесс запуска прило- жения должен быть разбит на несколько этапов, каждый этап отдельно задокументирован, отдельно защищен, должны быть защищены переходы между этапами и одновременно выполнены требования уло- житься в 200 мс для обеспече- ния достоверности авторизации клиента. Каждый этап не является отдельной функцией, а должен работать в едином потоке и не может быть разра- ботан сам по себе. Причем разные этапы могут быть в ведении различных команд на фронте, бэке и смежных системах. Можно ли при нали- чии таких требований приме- нять Agile? Можно, но это требует очень четкого документирования всех требований, процессов и про- цедур взаимодействия, чтобы обеспечить слаженность систе- мы и сплошное покрытие мера- ми безопасности. Разработка крупных систем с широким функционалом, к которым предъявляются серьезные тре- бования регулятора и характе- ризующихся четкой формали- зацией требований к каждому элементу, не может быть выполнена стихийной коман- дой. Для создания подобных систем в условиях регулярно изменяющихся требований необходимо применение гибкой методологии с высоким уров- нем организации процессов, одним из таких Agile-подходов является Scaled Agile Frame- work (SAFe), который исполь- зует 37% организаций, мас- штабирующих применение Agile 1 . Использование фрейм- ворков масштабирования поз- воляет объединить гибкость и разработку в сжатые сроки и выполнить требования регу- лятора. То же относится и к при- менению Agile в государствен- ных структурах. Заключение В ходе дискуссии мы пришли к выводу, что принятие Agile – это логичное развитие тради- ционных подходов к разработке ПО, при этом в основе Agile- методологии лежат теория менеджмента качества Демин- га, бережливое производство, теория управления изменения- ми, системное мышление и дру- гие проверенные долгой прак- тикой теории и методологии управления процессами разра- ботки ПО. Если для вас они не новость, то принятие Agile – не вопрос веры, а естественное развитие вашего опыта. Конеч- но же, использование Agile при создании сложных систем – это комплексный процесс мас- штабирования базовых прин- ципов, некоторые из которых перестают работать в новых условиях. Однако изучение раз- личных фреймворков масшта- бирования Agile позволит извлечь максимум выгоды от гибкого подхода для своей организации. А если всего этого будет недостаточно или захочется избежать типовых ошибок масштабирования, хорошей практикой будет при- влечение экспертов, которым уже доводилось пройти этот путь. Бесполезно, а иногда и опас- но внедрять Agile, если вы не понимаете, зачем он вам и как его применить в вашем окру- жении. Конечно же, это лишь корот- кий пересказ наших рассужде- ний, обзор лишь части мифов и только основной вывод, к которому мы пришли в ходе дискуссии. Но мы будем про- должать это обсуждение, будем продолжать искать оптималь- ный синтез скорости и каче- ства, функциональности и без- опасности, работать над тем, чтобы отечественное ПО было качественным, безопасным и не отставало от требований рынка. Предлагаем присоеди- ниться к нам в этом деле. l • 43 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru 1 15th State of Agile Report. URL: https://stateofagile.com/ Ваше мнение и вопросы присылайте по адресу is@groteck.ru