При проведении множества наших учебных курсов по системной инженерии мы, так или иначе, касаемся вопросов выбора модели жизненного цикла, организации процессов проектирования, отчетности, метрик и контроля. С завидным постоянством при этом слушатели задают вопрос: «А как же agile?». Почему невозможно в проектах критических систем применять agile-подходы? Или все-таки можно?
Часть 1. V-model, waterfall и agile
Перед тем, как обсуждать, возможно ли применение agile-подходов при создании критических систем, необходимо определиться в ценностях, которые ставятся во главу угла agile и waterfall, и, заодно, понять, почему waterfall и V-модель это, в общем, то же самое, только вид сбоку.
Что такое waterfall? Это постадийное и поэтапное, строго регламентированное выполнение проекта, в котором одна стадия следует за другой, один этап строго следует за другим, и последующий этап не начинается до тех пор, пока предыдущий не завершен полностью. Такой подход имеет весьма практичное основание, поскольку между этапами расположены так называемые «ворота качества» или «точки принятия решения», или «целевые шлюзы» в которых инвестор (обычно это государство) может оценить:
- в том ли направлении развивается проект,
- учтены ли все требования к безопасности и надежности,
- и есть ли шансы в конце процесса получить требуемый результат.
Системная инженерия добавляет к этому подходу необходимость строго соблюдать процессы разработки, основные и интегральные, в основном для того, чтобы доказать регулятору, что коллектив разработчиков сделал все возможное для обеспечения надежности и всех видов безопасности. Поскольку в области безопасности действует презумпция виновности, – «ты виноват, если не можешь доказать обратное» – то сбор доказательного материала становится проблемой исполнителя.
Системная инженерия, помимо этапов и процессов жизненного цикла предлагает особые усилия сосредотачивать на первых стадиях и этапах жизненного цикла, на том времени развития проекта, когда система проходит состояние осмысления и декомпозиции, существует только «на бумаге» (пусть даже это и 3d-модели), а ее изготовление и интеграция еще не начались. Для иллюстрации этого подхода стадии и этапы жизненного цикла графически изобразили в виде латинской буквы V, и такое изображение назвали V-модель.
Поэтапное осуществление крупных проектов (в том числе и программных проектов), основанное на выполнении процессов, существовало длительное время как единственный признанный способ выполнения сложных технических проектов вообще. Так обстояли дела и у нас, и на Западе. Для России становление разработки информационных систем происходило в контексте применения семейств стандартов ГОСТ 34 и ГОСТ 19. Но однажды, именно со стороны программистов, прозвучало волшебное слово « agile».
Набирал силу опыт разработки свободного программного обеспечения, в котором рассредоточенные по всему миру и не находящиеся под воздействием контрактных обязательств и стандартов программисты неожиданно стали создавать операционные системы, программные системы и приложения промышленного уровня. Этот опыт показал альтернативные пути организации совместной работы, пути гибкие, основанные на открытости и адаптивности, на взаимном уважении и интенсивном обмене информацией как внутри команды исполнителей, так и с потенциальным потребителем этих программных продуктов. Весь этот опыт был сконцентрирован в манифесте agile, и многие российские программисты, давно уже занимающиеся в одиночку или вдвоем разработкой разного рода внутриорганизационных бухгалтерий, программ учета складских запасов, ведения графиков, и прочего прикладного ПО, обнаружили (или решили, что обнаружили), что вот именно так они и работают.
Особое внимание стоит обратить на несколько моментов, связанных с применением agile-подходов:
- agile появился как методология разработки именно программного обеспечения;
- agile был ориентирован на программные проекты, свободные от множества контролирующих органов: регуляторы, прокуратура, военная приемка, финансовый контроль были далеки от agile-проектов;
- agile изначально находился в оппозиции к «управленческим иерархиям» и «менеджерскому планированию», когда в больших организациях у каждого программиста находится множество начальников, планирующих и контролирующих его работу, и требующих в точности соответствовать тому, что они напланировали;
- agile – подход подразумевал, что с заказчиком (и всеми его заинтересованными сторонами) возможно установление тесного и продуктивного взаимодействия;
- agile принимает за основу тот факт, что систему можно создавать, реализуя отдельные функции или слои, или модули, или пользовательские интерфейсы, которые при предъявлении их заказчику в этом промежуточном состоянии будут иметь для заказчика какой-то смысл.
Надо ли говорить, что при всех преимуществах в производительности и в надежности планирования, в качестве и соответствия поставляемого продукта потребностям заказчика, у agile – подходов были не только сторонники, но и очевидные противники. Эффективный менеджмент быстро понял, что agile направлен на эффективность работы команды и получения качественного результата, но совсем не способствует их личному процветанию. При agile становятся ненужными многостраничные графики мероприятий, выполнение которых повышает KPI. Нет, эти противники не отвергают agile вообще. В целом, говорят они, это штука хорошая. Просто она не для нас, не для наших проектов, не для нашей ситуации. Не жили мы agile, и не стоит начинать. И они правы. Для больших критических проектов agile – «это не наш метод». Основание для столь категоричного высказывания будет в следующей части.