Часть 2. Почему невозможно
Какие системы мы считаем критическими? Это изделия авиационной и военной техники, подводные лодки, нефтяные платформы, крупные автоматизированные производства, атомные станции, сложная автоматизированная и автономная автомобильная техника, космические аппараты, железнодорожная техника, АСУ ТП химических и критических производств. Разработка таких систем являтся строго регулируемой деятельностью, и, в подавляющем числе случаев, выполняется по государственным контрактам и за государственные деньги. В этих контрактах указываются (и это не подлежит обсуждению) стандарты, регулирующие процессы и методологию создания таких систем. Жизненный цикл определяется контрактом, такие процессы, как инженерия требований, управление конфигурацией, управление верификацией и валидацией, управление качеством, набор целей и отчетных документов – все достаточно подробно описано в соответствующих предметной области стандартах.
Исполнители и производители этих контрактов по всей иерархии кооперации работают по тем же правилам, что и генеральный подрядчик. Жесткие правила, жестко заданная последовательность действий, стандарты, процессы, заданный перечень документов, необходимость собирать данные и доказывать, что все сделано правильно – все это содержится в требованиях контракта. Жесткий контроль со стороны заказчика, регуляторов, прокуратуры, финансовых органов. И ни-че-го про людей, про атмосферу доверия, про необходимость интенсивной, надежной и честной коммуникации. Таковы ценности waterfall. Давайте сравним ценности waterfall и agile.
Сравнили ценности, давайте сравним и принципы agile и waterfall. Принципы waterfall не описаны в манифесте, поэтому в левую колонку я поместил те неписаные принципы, которые я наблюдал неоднократно в реальных waterfall-проектах.
Таким образом, если говорить о принципах, то они для waterfall и agile, как и ценности, находятся в довольно серьезном противоречии друг с другом. Или, вернее будет сказать, что реальность waterfall находится в противоречии с принципами agile. И это противоречие настолько глубоко, что засыпать эту пропасть, на первый взгляд, невозможно. Применить agile для проекта, который выполняется по государственному, военному или крупно-корпоративному контракту, и для которого заданы стандарты ГОСТ P 15.xxx или ГОСТ РВ 0015.xxx (а также стандарты, выдвигающие требования функциональной безопасности, типа ГОСТ РВ 51904, Р 4754А, ГОСТ Р 26262 или ГОСТ Р ИСО 61508), представляется совершенно невозможным.
«В одну телегу впрячь не можно
Коня и трепетную лань»
– написал Александр Сергеевич Пушкин. Однако, как говорится, есть нюансы, и речь о них в следующей части.