Вы вероятно помните знаменитый пример, который объясняет Agile на пальцах. Если нет, то давайте вспоминать. Итак, представьте, Заказчик хочет красный мерседес. В традиционных методиках управления проектами, Вы бы собрали полный перечень требований к этому мерседесу: начиная от количества лошадиных сил под капотом и заканчивая оттенком красного цвета, который бы его устроил. Но вот вопрос, а точно заказчику нужен именно красный мерседес? Допустим да, эта машина полностью удовлетворяет его потребностям. Тогда другой вопрос, представьте, что рынок (контекст) изменился, и стало запрещено ездить на красных автомобилях спустя 2 месяца после старта сборки.
Agile подход предполагает, что мы выявим самые базовые бизнес-потребности заказчика (по всей видимости, “передвигаться не пешком”) и сделаем для него, скажем самокат, он будет дешевый, быстро появится у заказчика и будет решать его самые насущные задачи. Потом этот самокат будет постепенно “обвешиваться” функциональностями и перерастет в велосипед, потом в мотоцикл и так далее. Это очень утрированный пример, так как один из принципов Agile, который мы, к сожалению, не учли в нашем примере — это повторное использование предыдущей версии продукта, чтобы создать новую (самокат, конечно, не используется при производстве велосипеда, ну совсем никак).
Теперь, когда мы вспомнили, что такое Agile подход, попытаемся проанализировать, в каких же проектах он применим. В этой статье мы начнем от обратного и попробуем порассуждать на тему того, где использование Agile подхода нецелесообразно. Представьте, что вы производите самолет-истребитель, мало шансов, что сработает пример самокат-мерседес, все таки здесь слишком много требований к безопасности, которые нельзя просто разбить на функциональности и постепенно добавлять к продукту. Это наталкивает на мысль о том, что системы так называемого “Safety critical” класса не совсем подходят для того, чтобы их разрабатывать с опорой на принципы Agile. Сложно представить, какие требования являются базовыми, а какие дополнительными фичами, если мы разрабатываем софт для кардиостимулятора, здесь напрашиваются применение традиционных методологий управления проектами в комбинации с формальными методами проектирования (formal methods, о них немного попозже).
Хотели бы мы поставить точку на обсуждении применимости Agile и сослаться просто на класс разрабатываемого софта, сказав, что требования к безопасности не могут реализовываться по принципу Agile. Но IT отрасль стремительно развивается, а исследователи и практики постоянно преподносят нам новую почву для рассуждений. Так, например, Baskerville, R. в рамках European Conference on Information Systems представил свою работу, в которой рассказал о том, что принципы Agile применимы и даже необходимы в том числе и для работы с “security requirements”. В исследовании говорится о том, что сегодня в компаниях начинают зарождаться особые принципы управления разработкой софта, которые включают требования к безопасности, спиральную (гибкую) разработку и объектное моделирование. Подкрепляется необходимость такого подхода тем, что динамика угроз с использованием современных технологий растет и только короткие циклы разработки (итерационная разработка методами Agile) способна разрабатывать меры безопасности быстро и динамично. Данная идея распространяется как на реализацию “security requirements”, так и на возможности для развития в системах класса “Safety-critical”.
Подводя итоги, ни один метод не может быть идеально применим к одной ситуации и являться абсолютно не подходящим в другой, накопленный опыт и знания рано или поздно приводят нас к открытию новых подходов (иногда весьма простых) к решению самых сложных задач.
Baskerville, R. (2004). Agile security for information warfare: A call for research. ECIS 2004 Proceedings,13
