Контакты
Подписка 2024

Мифы об Agile в разработке корпоративного программного обеспечения

Андрей Акинин, 11/10/21

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

Авторы:
Василий Окулесский, эксперт по защите информации, к.т.н.
Андрей Акинин, СЕО Web Control и Agile-практик

Не позволяйте шуму чужих мнений перебить ваш собственный внутренний голос. Стив Джобс

В наши дни манифест Agile стал библией для многих команд разработчиков программного обеспечения. Но, как водится в истории, каждая команда трактует его по-своему, тем более что и авторы манифеста считают себя "спустившими на воду корабль" гибкой разработки. Написав манифест Agile и основав Agile Alliance, они были "рады отпустить корабль в плавание и позволить лидерству распространиться дальше". Отсюда и мнений, "что есть истина", примерно столько же, сколько в истории было проповедников. И споры по поводу того, кто прав, возникают, потому что мы говорим об одних и тех же вещах разными словами. Давайте попробуем определиться в дефинициях, а для начала – в смыслах.

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

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

Agile-манифест – "библия разработчика" – переведен уже больше чем на полсотни языков, и с каждым переводом "истины" множатся. Перевод без учета контекста (читай без изучения причин создания и опыта создателей) порождает иногда неоднозначные конструкции и даже трансформирует смысл. Не будем углубляться в рассмотрение тонких семантических различий англоязычной и русскоязычной версий этого документа, но в качестве примера отметим, что слово over в "Ценностях" манифеста переведено как "важнее", однако при более тщательном рассмотрении скорее подходят по значению выражения "на основе" или "посредством". Для человека, имеющего опыт разработки и думающего, это не проблема, но не все, кто читает манифест, таковы. Здесь же обратим внимание на тот факт, что без глубокого понимания устоявшихся подходов и практик организации процессов разработки ПО, без оценки опыта взаимодействия всех участников бизнес-процессов при создании новых продуктов не стоит ожидать чудес от "внедрения" "гибкой" разработки. Как минимум, для точного понимания предметной области нужен хороший список дефиниций и адекватный толковый словарь используемых терминов.

Agile ориентирован на потребителя, а точнее на создаваемую ценность, которая может быть гарантированно доставлена только при соблюдении требований к качеству процесса производства. Он способен принести большую пользу бизнесу, ускоряя создание новой ценности, но для его понимания и использования требуется изменение менталитета, корпоративной культуры, а не только названий должностей. А для этого прежде всего необходимо понять, на каких столпах базируется Agile.

Основы Agile

Дейв Томас, один из авторов манифеста, в своем знаменитом выступлении "Agile мертв" высказывает мысль, что непонимание идеи Agile приводит к тому, что эта методология становится не средством, а целью. Он определяет смысл понятия Agility следующим образом.

Что делать?

  1. Поймите, что сейчас происходит вокруг.
  2. Сделайте пусть маленький шаг, но обязательно в сторону достижения поставленной цели.
  3. Затем скорректируйте текущее понимание ситуации по результатам выполнения шага.
  4. Повторите вышеописанные действия.

Как делать?

Из всех возможных путей для создания похожей ценности выбирайте тот путь, который сделает будущие изменения проще.

Вам ничего это не напоминает? Этот подход к гибкой разработке, по нашему мнению, являются изложением основных положений стандарта менеджмента качества, известного как ISO 9001 (см. рис. 1).


Рис. 1. Структура стандарта менеджмента качества ISO 9001. Цифры в скобках указывают на раздел стандарта

Все принципы манифеста укладываются в этот рисунок. Слова Дейва Томаса являются просто пояснением к циклу Деминга PDCA, а двенадцать принципов – авторской интерпретацией основных положений стандарта менеджмента качества более понятными словами.

Принцип 1

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного

Основная цель любой деятельности – удовлетворение заказчика, принцип добавляет: благодаря регулярной и ранней поставке ценного продукта. Конечно же! Только имея возможность организовать короткую обратную связь, можно скорее извлекать уроки, опережать конкурентов и выдавать быстрее, чем они, продукт, лучше удовлетворяющий заказчика. Это же утверждает стандарт управления качеством: "В центре внимания находится повышение удовлетворенности потребителей".

Принцип 2

Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

Это прямое развитие первого принципа. Он означает, что у вас должен быть такой процесс управления требованиями, чтобы могло допускаться введение любых изменений в любой момент. И здесь мы видим отсылку у стандарту ISO 9001, который говорит, что система будет эффективна тогда, когда она сможет удовлетворять изменяющимся требованиям заказчика. Этот принцип гибкой разработки описывает, каким образом можно реализовать данное требование стандарта.

Принцип 3

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Частые релизы надлежащего качества – хорошая основа для того, чтобы разработчикам держаться на плаву, а заказчику успешно вести бизнес в высококонкурентной среде. Однако это требует очень высокого уровня организации и ответственности каждого участника команды и всей команды в целом. Причина частых релизов – не необходимость устранения ошибок, а добавление новых свойств продукта. Обратим внимание на то, что работающий продукт – это релиз надлежащего качества. Должна быть система, которая позволяет выпускать качественный продукт с такой периодичностью. И система управления требованиями, адекватное документирование и четкий контроль версионности помогают реализовать этот принцип. Всего этого требует стандарт управления качеством.

И конечно же, частый выпуск работающего продукта – это основа раннего обучения и, следовательно, улучшения продукта. А это опять же является одним из способов выполнить требование ISO 9001 к организации процесса улучшений: "Организация должна определять и выбирать возможности для улучшения и осуществлять необходимые действия для выполнения требований потребителей и повышения их удовлетворенности".

Принцип 4

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Это не принцип легализации хаоса: мол, раз мы работаем вместе, нам больше не нужно определять роли, мы не должны документировать требования, нам не нужно заботиться об обязанностях – как это часто истолковывается. "Работать вместе" означает, что коммуникации всех участников разработки должны быть более органичными, должны быть более короткие циклы реагирования, чтобы всегда и все участники процесса были "на одной странице". А это требует четкого распределения ролей и ответственности, иначе работа рискует превратиться в хаотические дискуссии. Ежедневное общение – это возможность найти общий язык, поместить людей в общую среду, а не ежедневные совещания.

При интеграции систем безопасности именно специалист по ИБ, выступающий в качестве заказчика, знает лучше всех, как устроены его системы, а разработчики – как реализованы их процессы. Общаясь в рамках одной кросс-функциональной команды, они создают коллективное знание, что и как нужно делать. Например, при разработке системы антифрода в одной из известных финансовых организаций только объединение специалистов из нескольких разрозненных подразделений в одну команду позволило значительно ускорить создание соответствующего продукта и отказаться при этом от внешних подрядчиков.

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

Мифы Agile в корпоративной среде

Хорошо, когда разработчики делают простые продукты для конечных пользователей – вебсайт, игрушку для смартфона или мобильное приложение, когда над программой трудится небольшая команда. Принципы Agile помогают ей работать слаженно и целеустремленно. Но корпоративная среда – это сложная система, включающая в себя множество взаимосвязанных компонентов и подсистем, соответственно создание программного обеспечения для нее одной небольшой командой невозможно. При разработке сложных систем возникает необходимость в синхронизации и организации работы многочисленных команд, комплаенсе, отчетности, и широко распространено мнение, что достигнуть всего этого с помощью Agile-практик нельзя. Мировая практика доказывает обратное. Большинство успешных корпораций заявляет о том, что применение Agile позволило им лидировать в своих отраслях. Давайте разберемся.

Стихийное применение Agile при создании сложных систем часто приводит к неудаче, что и формирует это мнение. Непонимание причин этой неудачи или нежелание разобраться в них порождает ряд мифов о нем.

Миф 1: Agile не требует планирования

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

Agile распределяет деятельность по планированию (например, когда и какие конкретные функциональные возможности будут доставлены) более равномерно на протяжении всего жизненного цикла создания программы. Такое непрерывное планирование позволяет начинать разработку гораздо быстрее и корректировать ее в соответствии с потребностями клиентов по мере поступления новой информации.

Миф 2: Agile не требует архитектуры

Agile не означает сборку ИТ-системы с отсутствующим проектированием или архитектурой. Agile подчеркивает упрощение предварительного проектирования, а не исключение его. В манифесте говорится, что "постоянное внимание к техническому совершенству и хорошему дизайну создает основу гибкости". Многие из лучших практик направлены именно на то, чтобы качество поставляемого продукта наиболее полно соответствовало поставленной цели. Agile делает акцент на простом, предварительном проектировании, чтобы сосредоточиться на фундаменте и общей структуре программного обеспечения, оставляя максимальную гибкость для последующих изменений. Например, разработчики Agile избегают создания функционала, который может понадобиться, а может и не понадобиться, а вместо этого запускают сборки с учетом текущих потребностей и получают обратную связь в процессе итерационной доставки ПО клиенту. Однако это не означает, что для успешной работы Agile-команд не нужна высокоуровневая архитектура. Скорее, Agile-системы стремятся сохранить свою архитектуру простой и добавляют сложность только тогда, когда это необходимо, чтобы упростить доработку в будущем.

Миф 3: Невозможность представить себе конечный результат

Смотря что считать результатом – соответствие первоначальным техническим требованиям или продукт, удовлетворяющий потребности клиента. Да, мы не можем себе представить, как он будет выглядеть, но если есть планирование и архитектура, то результат предсказуем: продукт будет делать то, что нужно клиенту, и будет рабочим.

Миф 4: Agile не требует документации

Адаптивный и итеративный характер Agile делает меньший акцент на необходимости исчерпывающей документации по сравнению с каскадным методом разработки, но это не означает, что документация не требуется. При каскадной разработке в конце каждой фазы составляется подробная документация, так как ожидается, что требования программы не будут сильно меняться с течением времени и ее не нужно будет изменять. Однако элементы программы постоянно развиваются по мере поступления дополнительной информации и дальнейшего определения потребностей заказчика. Поэтому в Agile-разработке необходимая документация составляется и обновляется в конце заранее определенных периодов времени в ритмической разработке Agile (например, итерация, релиз или другая важная веха, определенная программой) в объеме, достаточном для дальнейшего использования программы. Кроме того, в некоторых случаях Agile-подход может заменить более формальную документацию информацией, встроенной в программные инструменты.

Миф 5: Agile не требует контроля

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

Миф 6: Agile не применим к созданию безопасных продуктов, соответствующих требованиям регуляторов

Требования регулятора довольно часто меняются, причем это касается самых разных вопросов. Это значит, что и программный продукт должен меняться, иногда коренным образом и в очень сжатые сроки. Например, требование по проверке на отсутствие уязвимостей и недокументированных возможностей было изменено на получение уровня доверия к процессу разработки. На первый взгляд, только Agile позволяет гибко реагировать и достраивать процесс под выполнение требований; почему же родился миф?

Прежде всего, он обусловлен акцентом на Agile как на быструю разработку, зачастую в ущерб качеству, а значит и безопасности. К тому же создание безопасных продуктов предъявляет значительно большее количество требований и вносит дополнительную сложность в целевую систему. Рассмотрим пример с разработкой приложения для мобильного банкинга. По требованию регулятора процесс запуска приложения должен быть разбит на несколько этапов, каждый этап отдельно задокументирован, отдельно защищен, должны быть защищены переходы между этапами и одновременно выполнены требования уложиться в 200 мс для обеспечения достоверности авторизации клиента. Каждый этап не является отдельной функцией, а должен работать в едином потоке и не может быть разработан сам по себе. Причем разные этапы могут быть в ведении различных команд на фронте, бэке и смежных системах. Можно ли при наличии таких требований применять Agile?

Можно, но это требует очень четкого документирования всех требований, процессов и процедур взаимодействия, чтобы обеспечить слаженность системы и сплошное покрытие мерами безопасности. Разработка крупных систем с широким функционалом, к которым предъявляются серьезные требования регулятора и характеризующихся четкой формализацией требований к каждому элементу, не может быть выполнена стихийной командой. Для создания подобных систем в условиях регулярно изменяющихся требований необходимо применение гибкой методологии с высоким уровнем организации процессов, одним из таких Agile-подходов является Scaled Agile Framework (SAFe), который использует 37% организаций, масштабирующих применение Agile [1]. Использование фреймворков масштабирования позволяет объединить гибкость и разработку в сжатые сроки и выполнить требования регулятора. То же относится и к применению Agile в государственных структурах.

Заключение

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

Бесполезно, а иногда и опасно внедрять Agile, если вы не понимаете, зачем он вам и как его применить в вашем окружении.

Конечно же, это лишь короткий пересказ наших рассуждений, обзор лишь части мифов и только основной вывод, к которому мы пришли в ходе дискуссии. Но мы будем продолжать это обсуждение, будем продолжать искать оптимальный синтез скорости и качества, функциональности и безопасности, работать над тем, чтобы отечественное ПО было качественным, безопасным и не отставало от требований рынка. Предлагаем присоединиться к нам в этом деле.


  1. 15th State of Agile Report. URL: https://stateofagile.com/ 

 

Темы:Безопасная разработкаЖурнал "Информационная безопасность" №4, 2021

Инструменты и решения для защиты информации и предотвращения кибератак
Конференция | 2 апреля 2024

Жми для участия
Обзоры. Спец.проекты. Исследования
Участвуйте в обзорах / исследованиях проекта "Информационная безопасность"!
Станьте автором журнала!
Статьи по той же темеСтатьи по той же теме

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2024
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Персональные данные
4 апреля. Персональные данные в 2024 году: регулирование, практика, тенденции
Участвуйте!

More...
Обзоры. Исследования. Спец.проекты
Обзоры и исследования проекта "Информационная безопасность"
Жми, чтобы участвовать