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

При разработке сложных систем возникает необходи- мость в синхронизации и организации работы много- численных команд, компла- енсе, отчетности, и широко распространено мнение, что достигнуть всего этого с помощью Agile-практик нельзя. Мировая практика доказывает обратное. Agile распределяет дея- тельность по планированию (например, когда и какие конкретные функциональ- ные возможности будут доставлены) более равно- мерно на протяжении всего жизненного цикла создания программы. Разработчики Agile избе- гают создания функционала, который может и не понадо- биться в будущем, а вместо этого запускают сборки с учетом текущих потребно- стей и получают обратную связь в процессе итерацион- ной доставки ПО клиенту. Адаптивный и итератив- ный характер Agile делает меньший акцент на необхо- димости исчерпывающей документации по сравнению с каскадным методом раз- работки, но это не означает, что документация не требу- ется. более короткие циклы реаги- рования, чтобы всегда и все участники процесса были "на одной странице". А это требует четкого распределения ролей и ответственности, иначе рабо- та рискует превратиться в хао- тические дискуссии. Ежеднев- ное общение – это возмож- ность найти общий язык, поме- стить людей в общую среду, а не ежедневные совещания. При интеграции систем без- опасности именно специалист по ИБ, выступающий в каче- стве заказчика, знает лучше всех, как устроены его систе- мы, а разработчики – как реа- лизованы их процессы. Обща- ясь в рамках одной кросс-функ- циональной команды, они соз- дают коллективное знание, что и как нужно делать. Например, при разработке системы анти- фрода в одной из известных финансовых организаций толь- ко объединение специалистов из нескольких разрозненных подразделений в одну команду позволило значительно уско- рить создание соответствую- щего продукта и отказаться при этом от внешних подряд- чиков. Можно и дальше разбирать принцип за принципом, чтобы убедиться, что гибкая разра- ботка – это не революция, а естественный эволюционный шаг в развитии методов про- граммирования, отвечающий вчерашнему и сегодняшнему моменту, базирующийся при этом на принципах системы менеджмента качества. Завтра обязательно появится что-то еще, новые требования окру- жения будут рождать новые технологии и инструменты, будут предлагать нам новые подходы, новые "сверхгибкие" или "супергибкие" методики, но все равно будут основы- ваться на базовых принципах, описанных в существующих на текущий момент стандартах и подходах. Мифы Agile в корпоративной среде Хорошо, когда разработчики делают простые продукты для конечных пользователей – веб- сайт, игрушку для смартфона или мобильное приложение, когда над программой трудится небольшая команда. Принципы Agile помогают ей работать слаженно и целеустремленно. Но корпоративная среда – это сложная система, включающая в себя множество взаимосвя- занных компонентов и подси- стем, соответственно создание программного обеспечения для нее одной небольшой коман- дой невозможно. При разра- ботке сложных систем возни- кает необходимость в синхро- низации и организации работы многочисленных команд, ком- плаенсе, отчетности, и широко распространено мнение, что достигнуть всего этого с помо- щью Agile-практик нельзя. Мировая практика доказывает обратное. Большинство успеш- ных корпораций заявляет о том, что применение Agile позволило им лидировать в своих отраслях. Давайте раз- беремся. Стихийное применение Agile при создании сложных систем часто приводит к неудаче, что и формирует это мнение. Непо- нимание причин этой неудачи или нежелание разобраться в них порождает ряд мифов о нем. Миф 1: Agile не требует планирования На самом деле, как и в любом другом подходе, плани- рование является жизненно важным аспектом, игнориро- вание которого значительно снизит эффективность успеш- ного внедрения. При каскадной разработке тщательное плани- рование ей предшествует, в случае гибкой разработки на старте происходит только высо- коуровневое планирование, которое постоянно уточняется и дорабатывается в ходе реа- лизации по мере поступления новой информации. Agile распределяет деятель- ность по планированию (напри- мер, когда и какие конкретные функциональные возможности будут доставлены) более рав- номерно на протяжении всего жизненного цикла создания программы. Такое непрерыв- ное планирование позволяет начинать разработку гораздо быстрее и корректировать ее в соответствии с потребностя- ми клиентов по мере поступле- ния новой информации. Миф 2: Agile не требует архитектуры Agile не означает сборку ИТ- системы с отсутствующим про- ектированием или архитекту- рой. Agile подчеркивает упро- щение предварительного про- ектирования, а не исключение его. В манифесте говорится, что "постоянное внимание к техническому совершенству и хорошему дизайну создает основу гибкости". Многие из лучших практик направлены именно на то, чтобы качество поставляемого продукта наи- более полно соответствовало поставленной цели. Agile дела- ет акцент на простом, предва- рительном проектировании, чтобы сосредоточиться на фун- даменте и общей структуре программного обеспечения, оставляя максимальную гиб- кость для последующих изме- нений. Например, разработчики Agile избегают создания функ- ционала, который может пона- добиться, а может и не пона- добиться, а вместо этого запус- кают сборки с учетом текущих потребностей и получают обратную связь в процессе ите- рационной доставки ПО кли- енту. Однако это не означает, что для успешной работы Agile- команд не нужна высокоуров- невая архитектура. Скорее, Agile-системы стремятся сохра- нить свою архитектуру простой и добавляют сложность только тогда, когда это необходимо, чтобы упростить доработку в будущем. Миф 3: Невозможность представить себе конечный результат Смотря что считать резуль- татом – соответствие первона- чальным техническим требо- ваниям или продукт, удовле- творяющий потребности кли- ента. Да, мы не можем себе представить, как он будет выглядеть, но если есть плани- рование и архитектура, то результат предсказуем: про- дукт будет делать то, что нужно клиенту, и будет рабочим. Миф 4: Agile не требует документации Адаптивный и итеративный характер Agile делает меньший акцент на необходимости исчерпывающей документации по сравнению с каскадным методом разработки, но это не означает, что документация не требуется. При каскадной раз- работке в конце каждой фазы составляется подробная доку- ментация, так как ожидается, что требования программы не будут сильно меняться с тече- нием времени и ее не нужно будет изменять. Однако эле- менты программы постоянно 42 • ТЕХНОЛОГИИ