В дебрях водопада

[vit_r]

Сходил на Agile Q&A with Stories посмотреть на Alistair Cockburn. (Выше набросок из блокнота. На размер побольше места не хватило.)

Представляю какой контингент был бы в Берлине... В Цюрихе же народу немного и большинство старше стартапно-романтического возраста. Был, даже, вопрос про карго-культ. (Конечно, возражал.)

Из интересного стоит отметить только заявление о том, что по eXtreme Programming надо читать вторую книгу. "Она прекрасна." Первую читать не надо, потому что автор сам признался, что в ней был не прав. (Ну надо же! Даже до него дошло.)

Ещё пророк agile поделился тайной, "о которой не рассказано, даже, в блоге": agile is applicable only in environments where wrong decisions are easy (and cheap) to reverse.

Угу. Я знаю, где такие условия: в сказочной стране клубничного смузи и розовых пони. В реальных проектах agile будет работать до тех пор, пока до народа не допрёт, что что-то пошло не так. (В чём, естественно, виноваты глупые практики, не правильно применившие великие идеи.)

Ещё выступление позволило уточнить некоторые принципиальные проблемы подхода. Но об этом как-нибудь в другой раз. Цитирование выше, естественно, в сокращённой и обработанной форме, но по смыслу близко к оригиналу.

Comments

[cross_join]

Первую книгу не читал, но вторую не буду.

[vit_r]

Я подозреваю, надо подождать третью, в которой он объяснит ошибки во второй.

[sab123]

Чтобы от неправильных решений все не погибало, достаточно (и необходимо) хорошего тестирования.

[vit_r]

Во-первых, определение циклическое: "Хорошее тестирование - это такое тестирование, при котором проект не погибает от неправильных решений".
Во-вторых, архитектуру тестированием не исправишь.

[sab123]

Архитектура исправляется тем самым (правильно примененным) аджайлом - через ряд небольших изменений.

[vit_r]

Опять циклическое определение.

Хотел бы я посмотреть, как с помощью напильника из Запорожца получают Мерседес.

[sab123]

А так и получают - поменяли одну деталь, другую деталь, и так далее, потом глядишь - уже Мерседес.

[vit_r]

уже самокат.

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

[sab123]

За формальный agile я не в ответе :-) А по уму - намечается цель, пишется примерный список изменений, и эти изменения начинают по-одному прикладываться. Если по пути обнаруживаются новые проблемы, то список соответственно подправляется. За скажем полгода-год вполне можно наисправлять что угодно.

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

[vit_r]

Обычно клиенту не нужна наполовину летающая ракета. С бизнес приложениями тоже.

А не так что пять лет работали-работали, но в итоге ничего работоспособного не наработали.

Ну, если у людей такая квалификация, то тут уж только напильником.

[sab123]

> Обычно клиенту не нужна наполовину летающая ракета. С бизнес приложениями тоже.

Вовсе не, причем по многм пунктам.

Программа - это не ракета. Программа - это _чертеж_ ракеты. Ракета - это то, что программа делает.

Так чтобы нарисовали ракету, построили, и сразу полетели на Луну, бывает только в романах Жюль Верна. В реальности разработка проходит много промежуточных этапов. В которых есть и тестовые ракеты, и ракеты для решения каких-то промежуточных полезных задач. Когда кто-то решает уподобиться романам, ракета взрывается (между прочим, реальный случай с попыткой первого американского спутника, после каковых обосратушек все же позвали фон Брауна, и он поэтапно добрался до Луны). Аналогичная история была с первыми самолетами, где профессор Лэнгли Научно Рассчитал и построил самолет, который сразу сломался в куски и на этом все у него кончилось, а братья Райт шли маленькими шагами и у них все получилось.

В бизнес-приложениях тоже нет такого "всё или ничего". Даже частичная автоматизация всегда полезна. Ну, не говоря уже о том, что большая часть жизни бизнес-приложений состоит из того, что приложение уже есть, но в него надо постоянно вносить изменения в соответствии с меняющимися требованиями.

[vit_r]

Программа - это не ракета.

Так, для справки. Я работал в области под названием "space". К тому же, продукт - это не программа, а вся система целиком. Включая механику для инженерных систем и обучение с внедрением для систем в бизнесе.

большая часть жизни бизнес-приложений состоит из того, что приложение уже есть, но в него надо постоянно вносить изменения в соответствии с меняющимися требованиями.

И при чём тут agile?

[sab123]

В механике тоже делают кучу прототипов, часто с настраиваемыми параметрами. Не надо смешивать этап разработки и этап массового производства. Гм, а какая механика в бизнес-приложениях?

> И при чём тут agile?

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

[vit_r]

Нельзя покрасить фасад дома, а потом перестроить канализацию и изменить несущие конструкции.

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

[sab123]

Так программа - не дом, а _чертеж_ дома. Так что можно.

[vit_r]

Чертёж дома не приводит к ошибкам на много миллионов или потерям человеческих жизней. Так что, сравнивать надо именно с построенным домом. Кстати, дома тоже перестраивают и перепланируют.

[sab123]

Еще как приводит, когда дом падает.

[vit_r]

На бумаге падает?
По-моему, подозреваемый начинает путаться в показаниях.

[sab123]

Дом по проекту строят, и он падает. Программа может привести к убыткам тоже только своей работой. Пока она тихо лежит на диске - никаких убытков.

[vit_r]

Программа может привести к убыткам тоже только своей работой.

Нет, конечно. Тогда бы все программы просто не работали.

Есть в контрактах такое понятие как упущенная выгода. Иногда штрафы астрономические.

[sab123]

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

[vit_r]

Предлагаю не путать классические адаптивные методики с тем, что в наше время продают под новомодным словечком "agile". А то получается какое-то дикое смещение смыслов.

[sab123]

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

[nnimble]

Только при этом промежуточные варианты должны вполне работать, иначе не аджайл.

[cross_join]

О тестировании какого уровня идет речь? Рефакторинг функциональных требований у вас тоже регулярно проводится или ограничиваетесь кодом?

[sab123]

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

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

[cross_join]

Рефакторинг = реструктуризация + факторизация, раньше использовались эти термины.
Функциональные требования также имеют иерархию уровней: от общесистемных до пользовательских. Функциональная архитектура, формирующаяся "эволюционным путем" - это нонсенс, означающий у подрядчика отсутствие знаний предметных областей.

[sab123]

Наоборот, нонсенс - это функциональная архитектура, формирующаяся через intelligent design. Сформулировать-то так можно, только работать оно не будет.

[vit_r]

Почему-то прекрасно работало. Причём, видел в разных областях.

Мне жалко тех людей, которые ни разу не видели, как люди работают головой.

[sab123]

Это возможно только когда новый проект - почти что повторение предшествующего. Или когда предметная область примитивна.

[vit_r]

Ой, вот только не надо мне рассказывать, что из того, с чем я работал, возможно, а что - нет.

[cross_join]

Ничего, подучите матчасть по предметным областям или наймете функциональных специалистов-аналитиков (ранее известных, как постановщиков задач) - заработает.

[sab123]

Ха-ха. Видели мы этих постановщиков.

[cross_join]

Тоже верно. Какие программисты, такие у них и постановщики. Квалифицированный аналитик вряд ли пойдет оформлять разрозненные требования пользователей без возможности анализа и проектирования системы в целом. В итоге, все остаются при своих. Обратная связь, точнее, отрицательный отбор, работает :)

[rasta]

Реклама соцсетей на ТВ - в кадре радостные лица, затем показывают небольшой квадрат с толстыми тюремными решётками.

Интересно, что заставляет мозго@бов в ТВ и интернете постить картинки людей за решётками, да ещё и в постах, абсолютно несвязанных с этой темой.

Ответ в том, что мозго@бы.

В общем очередной мурзилка под ником vit-r улетел в нирвану.

[vit_r]

Реклама соцсетей на ТВ - в кадре радостные лица, затем показывают небольшой квадрат с толстыми тюремными решётками.

Какой загадочный бот...

Бан, конечно.

[sab123]

Нет, из других бесед - не бот. Но безусловно человек со странностями. Ну или исходя из особенностей понимания человеческого языка, возможно человекоподобный робот :-)

[nnimble]

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

Всегда привожу Инстаграм в качестве примера, где можно и нужно применять канбан.

[vit_r]

Человек, рекомендующий kanban должен на практике быть мастером hensei, hourensou, jidoka, jishuken, чтобы уж потом иметь веское слово по поводу буквы "k".