Журнал "Information Security/ Информационная безопасность" #4, 2021
Agile очень активно осваивает рынок разработки программного обеспечения, и чем шире он распростра- няется, тем больше появляется о нем полярных мнений. Agile ориентирован на потребителя, а точнее на создаваемую ценность, которая может быть гаран- тированно доставлена толь- ко при соблюдении требова- ний к качеству процесса производства. В наши дни манифест Agile стал библией для многих команд разработ- чиков программного обеспечения. Но, как водится в истории, каж- дая команда трактует его по-своему, тем более что и авторы манифеста счи- тают себя "спустившими на воду корабль" гибкой разработки. Написав манифест Agile и основав Agile Alliance, они были "рады отпустить корабль в плавание и позволить лидерству распространиться дальше". Отсюда и мнений, "что есть истина", примерно столько же, сколько в истории было про- поведников. И споры по поводу того, кто прав, возникают, потому что мы говорим об одних и тех же вещах разными словами. Давайте попробуем определить- ся в дефинициях, а для начала – в смыслах. Agile очень активно осваивает рынок разработки программного обеспечения, и чем шире он рас- пространяется, тем больше появляется о нем полярных мне- ний. С одной стороны хор аполо- гетов поет осанну, с другой – толпы разочарованных "потре- бителей" Agile придумывают все новые и новые уничижительные прозвища для этого явления. В действительности причина разочарования в "новой" мето- дологии в большинстве случаев заключается либо в недопони- мании ее основ, либо в попытке использовать в крупных компа- ниях при разработке сложных систем не масштабированный, а простой командный Agile. Вот отсюда и возникают мифы о невозможности сквозного пла- нирования, непредсказуемости конечного результата, ненужно- сти документирования разработ- ки, неуправляемой версионности, неспособности оценить стабиль- ность и перспективы развития программы и, наконец, о невоз- можности создания безопасных и качественных продуктов. Agile-манифест – "библия раз- работчика" – переведен уже больше чем на полсотни языков, и с каждым переводом "истины" множатся. Перевод без учета контекста (читай без изучения причин создания и опыта созда- телей) порождает иногда неоднозначные конструкции и даже трансформирует смысл. Не будем углубляться в рас- смотрение тонких семантических различий англоязычной и рус- скоязычной версий этого доку- мента, но в качестве примера отметим, что слово over в "Цен- ностях" манифеста переведено как "важнее", однако при более тщательном рассмотрении ско- рее подходят по значению выра- жения "на основе" или "посред- ством". Для человека, имеющего опыт разработки и думающего, это не проблема, но не все, кто читает манифест, таковы. Здесь же обратим внимание на тот факт, что без глубокого пони- мания устоявшихся подходов и практик организации процессов разработки ПО, без оценки опыта взаимодействия всех участников бизнес-процессов при создании новых продуктов не стоит ожидать чудес от "внед- рения" "гибкой" разработки. Как минимум, для точного понима- ния предметной области нужен хороший список дефиниций и адекватный толковый словарь используемых терминов. Agile ориентирован на потре- бителя, а точнее на создаваемую ценность, которая может быть гарантированно доставлена толь- ко при соблюдении требований к качеству процесса производ- ства. Он способен принести боль- шую пользу бизнесу, ускоряя создание новой ценности, но для его понимания и использования требуется изменение ментали- тета, корпоративной культуры, а не только названий должностей. А для этого прежде всего необхо- димо понять, на каких столпах базируется Agile. Основы Agile Дейв Томас, один из авторов манифеста, в своем знамени- том выступлении "Agile мертв" высказывает мысль, что непо- нимание идеи Agile приводит к тому, что эта методология ста- новится не средством, а целью. Он определяет смысл понятия Agility следующим образом. Что делать? 1. Поймите, что сейчас про- исходит вокруг. 2. Сделайте пусть маленький шаг, но обязательно в сторону достижения поставленной цели. 3. Затем скорректируйте теку- щее понимание ситуации по результатам выполнения шага. 40 • ТЕХНОЛОГИИ Мифы об Agile в разработке корпоративного программного обеспечения последнее время сотрудники службы ИБ часто сталкиваются с тем, что корпоративное программное обеспечение, разрабатываемое для нужд компании, не всегда отвечает корпоративным требованиям ИБ и регуляторов. Иногда даже предлагается выбор: делаем безопасный код или укладываемся в дедлайн. Во время одной из наших встреч возникла дискуссия, почему это происходит, и как-то само собой всплыло типовое объяснение: во всем виноват Agile. Мы решили разобраться, так ли это, и пришли к интересным выводам. Не позволяйте шуму чужих мнений перебить ваш собственный внутренний голос. Стив Джобс В Василий Окулесский, эксперт по защите информации, к.т.н. Андрей Акинин, СЕО Web Control и Agile-практик
Made with FlippingBook
RkJQdWJsaXNoZXIy Mzk4NzYw