Инженерные тренды 2014 (2)

Нет, давно не катаются. Это легко находится на русском, даже через википедию.

Я предпочитаю не говорить слов "модель жизненного цикла" (чтобы не путать с действительно моделями -- несмотря на обилие языков описания практик жизненного цикла и связанных с этими практиками видов жизненного цикла).

Конечно, agile "модели" не существует, как и классической "водопадной" модели. Agile я использую как указание на стиль определения вида жизненного цикла (который должен быть по норме уникальным для каждого проекта, плюс должен меняться по ходу этого проекта по мере понимания профиля рисков этого проекта).

Скрам -- это отнюдь не весь agile, там ведь много разных школ, в том числе и более приспособленных к реалиям больших проектов. Кроме того, "процессы" это тоже только одна из парадигм, в обсуждении agile более пригодна парадигма практик+управления кейсами (хотя и проектная парадигма тоже хороша, оценки времени-то выполнения в крупных проектах тоже нужно делать). Конечно, в современном инженерном agile есть инструментально поддержанные практики верификации и управления конфигурацией -- так что всегда хорошо понятно, на чём стоит верификационная подпись, и какая при этом проводилась верификация тем, кто ставит эту подпись. Ничего необычного, хотя современный инструментарий позволяет существенно облегчить и верификацию и управление конфигурацией, а также выполнение координационных практик (типа "подписывание"). Ну, и современная инженерия различает валидацию (по отношению к user needs) и верификацию (где проверяется, насколько хорошо выполнена спецификация, составленная самими инженерами). Так что потихоньку дело идёт.

Водопад это не просто модель финансирования. Пошаговое выделение финансирования не эквивалентно водопаду. И даже в современной трактовке гейты (все эти майлстоуны "графиков верхнего уровня" -- их когда три всего, а когда и штук восемь проектах типа строительства АЭС) необязательно должны быть водопадными, просто это моменты сбора полной конфигурации и дополнительной верификации и оценки рисков (я тут поминал Boehm, он как раз этим озабочен больше всего: стыковкой инженерных практик и менеджерских практик, модели финансирования и модели разработки).

А что любым топором можно либо по полешку, либо по пальцу -- это и так понятно. Но топор должен быть острым. Понятно, что agile можно извратить как угодно, равно как и водопад и все их возможные гибриды. Но это не повод прекращать обсуждать способ организации разработки, вид жизненного цикла и поддерживающий их инструментарий.

Не любая формализация это препоны. Любая как формализация, так и деформализация, вводимая бездумно -- это препоны и конец нормальной работы. Есть совсем разные варианты формализации, и разные объекты формализации. Так, процедурность (вытягивание практик в предзаданные последовательности операций -- скорее всего именно это делают ваши безумные аспиранты в работающих проектах, этого ведь требует "процессный подход") обычно в инженерных проектах пагубна, использование одного и того же набора практик для любых проектов также пагубно. Отсутствие хоть какого-то формализма в управлении конфигурацией и управлении изменениями -- не менее пагубно.

Цикличность (итеративность) и параллельность -- это разные концепты. В инженерии сейчас модная тема обсуждать разницу в итеративных практиках и практиках cuncurrent engineering.

Я думаю, у нас ещё и терминологичское непонимание. Я стараюсь пользоваться терминологией из OMG Essence и работ по adaptive case management, плюс работ Boehm по "генератору жизненных циклов". Ибо на бытовой терминологии тут не проедешь, все слова уже захватаны и затёрты. То есть "практика" это ни разу не "процесс" у меня.

Мне из этой серии нравятся ещё "пространственно-временные кристаллы" -- http://physicsworld.com/cws/article/news/2012/jul/03/space-time-crystals-on-the-horizon

Я думаю, что отдельные клетки довольно долго ещё проще не печатать будет, а производить в биореакторах разного типа.