Обсуждение

Да никто американскую лунную программу от народа не скрывал: я в начале восьмидесятых легко набрал сотни страниц публикаций о ней. И луноходы отличные машины по любым меркам. Во-первых, это автомат, а не тележка для гольфа :), а во-вторых там ходовая часть такая, что и через 20 лет ничего лучше для экстремальных условий не придумали. Я не удивлюсь, если они и до сих пор где-нибудь по вулканам катаются.

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

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

Модель - это модель. Agile модели не существует, это просто декларация.

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

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

Я вижу, как безумные аспиранты вводят процессы в работающих системах. Причём, не в отчётах, а на местах. Любая формализация - это препоны. Формализация, вводимая безумно - конец нормальной работы. Водопад - это модель выделения бюджетов. Это, если не в теории, а как оно на самом деле работает. Что там одно, под бумагами, это свосем другое дело. (И, как правило, циклично и агильно)

Не любая формализация это препоны. Любая как формализация, так и деформализация, вводимая бездумно -- это препоны и конец нормальной работы. Есть совсем разные варианты формализации, и разные объекты формализации. Так, процедурность (вытягивание практик в предзаданные последовательности операций -- скорее всего именно это делают ваши безумные аспиранты в работающих проектах, этого ведь требует "процессный подход") обычно в инженерных проектах пагубна, использование одного и того же набора практик для любых проектов также пагубно. Отсутствие хоть какого-то формализма в управлении конфигурацией и управлении изменениями -- не менее пагубно. Цикличность (итеративность) и параллельность -- это разные концепты. В инженерии сейчас модная тема обсуждать разницу в итеративных практиках и практиках cuncurrent engineering. Я думаю, у нас ещё и терминологичское непонимание. Я стараюсь пользоваться терминологией из OMG Essence и работ по adaptive case management, плюс работ Boehm по "генератору жизненных циклов". Ибо на бытовой терминологии тут не проедешь, все слова уже захватаны и затёрты. То есть "практика" это ни разу не "процесс" у меня.

Слово "должны" хорошо употреблять в теоретических построениях. Практически же все фирмы вводящие бюрократизацию, имеют за отчётностью определённые модели. Из всего, что я видел, ничего разумного мне не попадалось. (Если, конечно, рассматривать нацеленность на результат, а не прикрытия задницы менеджменту)

Реальность - это реальность. Модель - жизненного цикла, системы или ещё чего-то, это просто модель. Это я о том, что рассматривать модели имеет смысл только в контексте их практического применения. С этим всё хреново. По крайней мере, с того момента, когда начинаешь снимать метрики без ошибок. Нужны стабильные модели, устойчивые к ошибкам. Их нет.

Я почитал сначала книжку checklist manifesto, потом (практически книжку по объму) OMG Essence, а ещё книжку и ряд статей по adaptive case management. И мне это в сочетании показалось очень разумным. Boehm тут нужен, чтобы как-то привязываться ко всяким Ганттам и учитывать интересы менеджеров (которые ведь тоже стейкхолдеры и их интересы нужно учитывать). Но Boehm очень околовоенный и консервативный, поэтому я к его работам отношусь с бОльшей настороженностью.

"Модель жизненного цикла" обычно -- это жесткое указание стадий с их возможным перекрытием, а также используемых практик работы. Типа "а тут мы будем использовать RUP". Так что это не "просто модель". Нужно иметь такой способ размышления, который позволяет сравнивать все эти "модели" и конструировать на лету то, что нужно для твоего проекта. Ибо "стабильные модели" означает "игнорирующие особенности твоего проекта", так что нужны некоторые теории (метамодели), а не модели (застывшие порождения этих теорий). Боюсь, что я сваливаюсь в изложение примерно 150 страниц текста, из которых полсотни страниц уйдёт на введение терминологии и отстройку от разной бытующей в различных отраслях (айтишной, железячной, встроенных систем, строительной и т.д.) терминологии. Не буду этого делать сейчас, ибо всё одно у меня в планах на зимние каникулы писать на эту тему материалы для студентов.

Любая статистика работает на больших числах. Тем более, что реальность адаптируется под метрики.

Проблема с метомоделями в том, что практики их совершенно не понимают и применять не могут. Тем более, адаптировать их под конкретные нужды. Так что всё вводится методом дыры в потолке, а потом люди адаптируют процессы под требования отчётности. Если, конечно, это получается.

все же круче, когда "прополз" непилотируемый агрегат в автономном режиме, а не под управлением двух жующих дуболомов.

Если говорить про научную нефантастику, о которой не писали фантасты: http://elementy.ru/news/432085 Только представить себе - интерференция материи...

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

С интересом (и с запозданием) прочитал, очень интересный обзор. > в 2014 году собираются напечатать человечью печень, которую ещё пересаживать нельзя, но для фармакологических экспериментов использовать уже можно, Как я понял, они собирают эту печень из готовых клеток, отдельные клетки печатать из химических веществ не умеют ?

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

He круче - луноходом с земли по радио управляли такие же "жующие дуболомы", никакой "автономности" в нем не было.