а нужны ли мне эти ваши docker-контейнеры?

подход дающий результат

Цену акций, я надеюсь?

Но фишка в том что ни от Agile, ни от ООП ты никуда не денешься.

Угрожаете.

это работоспосбный подход

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

Именно тем, что и упомянул. Массово скупали в кредит асики и ставили фермы.

Горжусь соотечественниками. Русские, когда от них отстаёт государство со своими приколами, демонстрируют удивительную смётку и предприимчевость.

как собрать докер образ без запуска самого докера?

зачем?

А вот agile, это как если бы специальные болтуны рассказывали про гибкие методы программирования, чтобы программы были гибкими

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

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

И это не формальности, для реализации такого подхода нужно выбирать соответствующую архитектуру. То есть приходится подстраивать всю разработку.

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

И много других подобных «очевидных» вещей которые тем не менее приходится объяснять и обсуждать.

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

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

Я честно признаюсь, что никогда не выкатывал ничего «по расписанию» и опыт мой весьма ограничен достаточно узкоспециализированной областью. Мне не совсем понятно сарказм это или нет.
Поэтому далее ещё более непонятно, как верно - «по расписанию» или «подстраиваться на каждом шаге».
Поясните, пожалуйста.

Русские

Ну вот, теперь перед Нетфликсом придётся извиняться

когда от них отстаёт государство

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

Мне не совсем понятно сарказм это или нет.

Нет, это не сарказм.

Поэтому далее ещё более непонятно, как верно - «по расписанию» или «подстраиваться на каждом шаге».

Тут нет противоречия

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

https://en.wikipedia.org/wiki/Release_early,_release_often

Ознакомился с RERO. Однако я даже нафантазировать себе не могу ситуацию, когда можно по часам выкатывать релизы в строго заранее оговоренное время.
Это примерно как приходим мы с вами вдвоём к астрономам и ставим их в известность - так, в следующие три дня вы как хотите крутитесь со своими микроскопами, но ещё четыре чёрные дыры выньте да положьте к среде, у нас релиз выкатывать надо по Вселенным. И уходим поржать за дверь. А они чешут репу задумчиво.
А ещё было кино «Тот самый Мюнхгаузен» с текстом типа В 16-00 - Подвиг!

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

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

При хорошем управлении и сильной команде работает, что угодно. А если персоналии подкачали, то не работает никакая методология.

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

Битвы выигрывают полководцы, а не солдаты. Впрочем, проигрывают тоже.

в качестве разрабов нанимают макак за банан, а деньги тратят на девопса

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

Проблемы для кого? Для девопса? Девопс в шоколаде — я ни одной миллисекунды не спорю с этим.

Я являются тем самым экзотическим видом мамонта, который в свое время отработал кучу лет над продом за весьма посредственный оклад. Да, я конкретно упарываюсь по работающим решениям, а не «деньги получил — дальше мне пофигу». Причем, я подозреваю, что большая часть людей в том проекте таки следовали принципу «а дальше пофиг». Сбой такой подход начинает давать именно тогда, когда ты не занимаешься аутсорсом, а получаешь доход с того продукта, который разработал, то есть, тебя очень даже волнует, как он будет работать. Огромное число разрабов и манагеров «ловят звезду» в духе «заказчик заплатил за проект, значит всё хорошо — почему бы нам и для себя не сделать так же, и получать пассивный доход». Кучу кодеров остаются такими вот инфантилами, потому что «ну я же работаю в гугле — значит, я что-то понимаю в жизни». Или же повышены в роли наемного сотрудника и теперь принимают важные решения — не пересчитать уже, сколько рандомных челов сняли все сливки со успешной команды, присвоив успех этой команды себе, а потом «что-то пошло не так». Товарищ Паркинсон написал целую книгу по мотивам работы подобных бюрократов:

https://ru.wikipedia.org/wiki/Законы_Паркинсона#Жизненный_цикл_кабинетов

Работа стартапного девопса или подобного бюрократа — это продажа дохлого кота, то ли в мешке, то ли дергаемого за ниточки. Что потом с этим котом будет делать покупатель — проблема самого покупателя. Почему дохлого? Потому что разработка распределенной системы — это настолько сложная и ответственная задача, что «поручить ее макакам» значит гарантированный провал. Эдак десять лет назад готовых решений было достаточно мало, то есть, был даже не дохлый кот, а кишки, размазанные по стенке, и никакой лучший девопс не мог продать это как рабочий кот. В том числе мои любимые одноклассники не могли выдать рабочее решение, из-за чего аутсорснули разработку базовой системы британской компании.

Работай девопсом, зарабатывай деньги — я не против, я одобряю, я жму руку и мы расходимся. Но не говори, что микросервисы на популярных нынче технологиях в реализации от макак за еду работают. Потому что если ты скажешь, что это работает, то я напомню в ответ, что пока этот подход не сработал НИГДЕ, а там, где cработал, в разработку вбухали астрономические деньги. То есть «вот мы строим прототип на микросервисной архитектуре с готовыми решениями и дешевой рабочей силой»... двадцать миллионов долларов спустя... «ну вот прототип и готов, не ошиблись мы с архитектурой, можно начинать масштабироваться». Естественно, если у стартапа этих денег нет, то он утонет — я не удивлюсь, если CEO этих стартапов даже не расчитывают на рабочий прототип, аля электрогрузовики Nikola.

Более того, я даже соглашусь, если ты скажешь, что весь смысл существования индустрии заключается только в том, чтобы переливать из пустого в порожнее. Потому что да, так и есть. Но я вхожу в число тех, кого фактор «все так делают» не особо волнует.

Это если менеджмент неквалифицированный. У них и agile не работает. Очень многие люди, которые из программистов стали менеджерами не хотят осваивать свою новую профессию... А вот если тебя назначили начальником, то почему-то нет понимания, что нужно учиться руководить

«Стой, братцы, стой! – кричит Мартышка. – Погодите! Как музыке идти? Ведь вы не так сидите. Ты с басом, Мишенька, садись против альта. Я, прима, сяду против вторы; тогда пойдет уж музыка не та: у нас запляшут лес и горы!»

Менеджмент может работать с заказчиком, менеджмент может ставить задачи. Если говорить про сложной интеллектуальный труд, то «чтоб музыкантом быть, так надобно уменье... А вы, друзья, как ни садитесь, всё в музыканты не годитесь».

А почему ты заливаешь employeers.sql, а считаешь какие-то другие файлы?

Я так понимаю, что ты Ъ лоровец и по ссылкам не ходишь. Получается непродуктивная беседа.

нафантазировать себе не могу ситуацию, когда можно по часам выкатывать релизы в строго заранее оговоренное время

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

Тысяча хостов приблизительно 50000 - 100000 евро в месяц, если компания зарабатывает хотя бы миллион в месяц, то это не так дорого. Не понимаю твоей зависти

Я тут сижу прикидываю масштабы. Ну вот ватсап образца 2013-2014 года получал $5-10 млн в месяц при 400-500 млн пользователей — в принципе, да, они бы не заметили расходов от тысячи хостов. А что, если ваша фирма — не ватсап? Там вот выше легионер не может выбить у начальства сервер с большим объемом оперативы, а ты нам рассказываешь про $50-100k в месяц — это же весь месячный бюджет средней айтишной конторы в СНГ.

тогда пойдет уж музыка не та: у нас запляшут лес и горы!

Что характерно, вместо руководителя у них мартышка.

Так внешнее (по отношению к сервису) хранилище же. Смысл в том, чтобы сервис не хранил никакого состояния у себя, мимо хранилища

Молодец. А теперь скажи, зачем мне нужен твой сервис, если по итогу вся архитектура и обслуживание упирается в БД?

При чем тут я-то, если у меня нет тыщи хостов, это не значит, что ни у кого нет

Я о том, что если у тебя система доросла до тыщи хостов, что проблемы «сервисы дохнут каждую минуту» тебя меньше всего будут волновать.

зачем мне нужен твой сервис, если по итогу вся архитектура и обслуживание упирается в БД?

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

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

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

Сервера должны знать хэши пароля и логины

Но зачем, если всегда можно спросить у сервиса авторизации, валиден ли полученный токен?

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

Мне кажется, что ты путаешь программистов с макаками. Booking брал кого попало на роль перловиков, потому что «профессиональные» перловики сами напишут такой трешак однострочный, что мама не горюй. Крестовики еще любят так делать, типа «мама, смотри, какие я конструкции я умею использовать — и глаза почти не вытекли».

Мне дали JS, я через пару месяцев уже мог утереть нос тимлиду, хотя до этого лишь ковырял hello world-ы на досуге. Я поковырял фронты пару лет — меня уже на сеньорские должности зовут. @вертехуа не даст соврать — у них в гугле та же история. Разве у вас это не актуально в свете низкой текучки? Если кадр меняется миинмум полгода — что такое 2 месяца?

докер — это удачная технология, которая взлетела и теперь все его знают и умеют с ним работать. Знают посредственно, но этого достаточно. Можно брать любого среднего админа или кодера и докер не будет для них сюрпризом

Ага, докер, не микросервисы. Мне вот интересно, у вас при приеме на работу админа спрашивают «вы умеете пользоваться apt? Покажите нам несколько команд... А можете найти, к какому пакету принадлежит файл? А собрать пакет из сорцов?». Я почему-то про такое не слышал.

С другой стороны, если говорить про докеры, то большинство девопсов на рынке могут лишь в минимальную конфигурацию готовых образов. У них в проде до сих пор крутится дырявый софт, не обновлявшийся с 2014 года — ну а чё, работает жи? Толку с них?

Ты мне рассказываешь что-то вроде «говночист не знаком с сортирами в этом здании — переносим датацентр в более подходящее помещение». Это ВТОРОСТЕПЕННЫЙ вопрос — если говорить про обычный деплой, не про микросервисы, конечно. Если говорить про микросервисы, то там прежде всего ничего не будет работать, а потом уже видимость работоспособности удобнее создавать традиционными докерами.

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

А вот если б я продавил использование guix environments, то мне пришлось бы объяснять каждому новому сотруднику что это такое и как с ним работать, основы scheme и как emacs+geiser настраивать, чтоб комфортно было. А оно мне надо со всеми няньчиться? А оно им надо вкладываться в технологию, которую нигде больше не используют?

Ну ты как бы сам ответил выше по треду — зато не убегут никуда. Волшебные практики подбора кадров на рыночке гарантируют, что любая минимально экзотическая технология приведет к «мы вам перезвоним» в 99% случаев.

Сервера должны знать хэши пароля и логины

Но зачем, если всегда можно спросить у сервиса авторизации, валиден ли полученный токен?

Сервера авторизации.

Тут вы сами виноваты, ибо именно вы смешали в кучу контейнеры, оркестрацию, микросервисную архитектуру и облачные технологии

Облака не мешал, не надо мне тут.

Про контейнеры я сразу сказал, что они мне довольно безразличны, поскольку ничего не решают. Но согласись, что не бывает такого, что «мы просто поставим образ нужного нам сервиса в докере, потому что он такой есть готовый» — и всё, больше ничего, никакой инфрастуктуры логирования, CI/CD, ничего этого — просто крутим один-два сервиса. Такого не бывает, даешь пальчик — норовит откусить руку. А крутить Firefox во Flatpak — это как бы вообще не считается за контейнер, хотя на самом деле очень даже контейнер с виртуальной ФС.

либо запрос сам по себе содержит все данные для его обработки, либо есть внешнее хранилище, либо вы в заднице

Передал запрос сервису — сервис упал. Чо делать? По итогу даже для передачи запросов между сервисами тебе нужна БД аля кролик/кафка — и мы просто преложили проблему с одной софтины на другу. Только по итогу при этом система стала сложнее.

Это личная БД этого сервиса, хранящая данные того же bounded context, в рамках которого работает сервис, а не общая помойка на всю распределенную систему, погибающая из-за этого под нагрузкой и взрывающая мозг каждому, кто пытается понять, что там происходит

О да, детка, даешь каждому сервису по БД! Потом ты еще осознаешь, что помимо личных БД все-таки нужны какие-то инструменты координации — здесь появятся БД между сервисами. Потом нужно будет координировать группы сервисов — появятся БД между БД. Просто и понятно.

в случае смерти и недоступности оного сервера без астропата не понять что же с ним случилось и как так вышло. Значит логи сервера нужно пересылать куда-то ещё. Вот это куда-то ещё и есть ELK или нечто подобное

Если сервер мертв до такой степени, что его нельзя никак запустить и прочитать post-mortem логи — зачем он нужен? Сдаешь на металлолом, покупаешь новый сервер — живешь дальше. Гугл прямо так и делает.

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

Монолит — это и есть «простой случай». Самый простой, какой только может быть, все проблемы распределенных систем к нему не относятся.

Есть проблема, есть решение, все довольны. Гораздо хуже, когда проблема есть, а решения нету

Предпочитаю решать проблемы, которые есть, а не которые «может быть могут быть». YAGNI

Вот, например, в основном продукте моей конторы есть компонент, который может присутствовать только в одном экземпляере. Его уже пытались переписать (возможно дважды), но воз и ныне там. Эта хреновина адово тормозит. Хотелось бы создать десять её экземпляров, чтобы она тормозила в десять раз меньше

Если она statefull, то никакие контейнеры не помогут. Также они не помогут, если она работает под какой-то виндой или нелинуксовыми никсами, или даже достаточно старым линем (если уж мы говорим про 10 лет).

У вас инфраструктура заточена под контейнеры? У нас инфраструктура заточена под башекостыли

Сектор Газа - Опарыш.мп3

Сами скрипты сборки контейнеров — такое же башеговно. Ну думай, что я адвокатирую баш — докеры просто не решают сути проблем никсов, а проблемы есть, очень даже серьезные, даже без микросервисов.

Грамотность, конечно, важна, спору нет. Причем как в разработке, так и в эксплуатации. Но при чем тут стандартизация и облегчение эксплуатации, которые делает возможным виртуализация (особенно контейнеры)?

А потом тебе приносят виндовый блоб, а ты им «не видите, у нас тут стандартизация и облегчение эксплуатации, не можем запустить, даже не просите». Забавно, что облачные хостеры предпочитают облегчаться, засовывая контейнеры в виртуальные машины. А alpha в этом треде облегчалась, засовывая VM в контейнера. Если засунуть VM с контейнером в контейнер, то получится двойное облегчение.

А вообще agile идет от Тойоты, которая стала мировым брендом из-за него

Да что там мелочиться, электричество только благодаря agile изобрели. Производство железяк — это прежде всего waterfall, потому что трансмиссию перекинуть с передних на задние колеса не получится за пару часов. Toyota прославилась никаким не agile, а прежде всего грамотной организацией конвеера, который организовывался самими рабочими. Но чтобы такую обратную связь получить, прежде всего нужно иметь мотивированных и квалифицированных рабочих, а не набранную по объявлениям шваль из силиконовой долины, которая сыпет базворды через слово и через два месяца свялит в другую контору. В япошке работники работают на одном и том же заводе всю жизнь, так что в их же интересах позаботиться о своем рабочем месте. Вот о чем их «agile», а никак не о том, чтобы не знать конечной цели разработки и постоянно бегать к шоферу с вопросами «мы поставили колёcа на крышу, а сидеть вы будете на ручке коробки передач — вас так устроит или поставить дополнительный обогрев?».

Сейчас все, что наработали за эти годы, Маск использует в ракетостроении

Ты наивно предполагаешь, что Маск вообще понимает, как летают ракеты. Его коллега по цеху, Ричард Брэнсон, не умеет читать. НЕ УМЕЕТ ЧИТАТЬ. Зато держит аэрокосмическую компанию и уже слетал в космос.

Kanban тойота придумала, от этого и пошел весь agile

LOL, при чем тут канбан к аджайлу? Так-то можно договориться до того, что покупатели в супермаркете тоже «работают» по agile: пришел, посмотрел на доступную нуменклатуру, перекинул в корзину «в работе», потом на кассе сменил статус на «оплачено».

Agile - это такой unix-way для управленцев.
То есть это некий принцип, имеющий под собой вполне разумные основания. Но при применении на местах либо не виден, либо не работает, либо работает не так, либо вызывает совершенно безумные холивары на тему что это всё же такое

Спасибо за развернутое определение понятия «абстрактная хрень».

Монолит — это и есть «простой случай». Самый простой, какой только может быть, все проблемы распределенных систем к нему не относятся.

К нему относятся все проблемы монолитов.

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

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

Спасибо за развернутое определение понятия «абстрактная хрень».

Я думала программисты отучаются от позиции «если это нельзя увидеть и пощупать - этого не существует» где-то на первом месяце обучения, а поди ж ты.

Но фишка в том что ни от Agile, ни от ООП ты никуда не денешься. И не потому что все дураки и не лечатся, а потому что несмотря на все проблемы это работоспосбный подход дающий результат

А дом 2 все смотрят потому, что сия передача помогает обучаться семейным отношениям. Тебе не приходило в голову, что ООП и Agile люди упарываются просто потому, что ОНИ ДЕБИЛЫ? Как и зрители дома 2, как и успешные клиенты прикрокредитных организаций, как и вкладчики МММ, и прочие, прочие, прочие примеры массовых помешательств.

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

Я предлагаю оставить в стороне методологию agile и включить методологию «мозг». Зачем мне релизиться по расписанию? Просто потмоу что because? Я прежде всего задействую свой agile для того, чтобы прикинуть «зачем мне ваши релизы по расписанию и ваше ООП?», и дальше буду итерировать принятие решений. Вот такой у меня аджайл.

Кто те сотрудники, которые могут автоматически релизить по расписанию хоть что-то?

По моему опыту, аджайл в большинстве случаев сводится к «спланировать, за какие задачи отчитаться». Или, иными словами, «да отстаньте вы от меня уже».

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

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

В каких областях можно делать релизы по расписанию?

В любых. Как бы то что этот принцип встречается как у Эрика Рэймонда, так и в «суровом энтерпрайзе» с Lean Agile Scrum и этим вот всем намекает.

Кто те сотрудники, которые могут автоматически релизить по расписанию хоть что-то?

Кто угодно.

Надо только сесть и хорошенько подумать, что такое вообще «релиз».

Собственно вот идеальная иллюстрация к вопросу зачем нужны все эти «agile-болтуны». Они нужны затем чтобы не тратить время инженеров коллег по команде на вот таких вот «мозговитых» кадров, которым надо с нуля объяснять суть регулярных релизов, почему это не значит «умереть но доделать фичу в завтрашнему дню» и как это вообще работает.

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

Собственно вот идеальная иллюстрация к вопросу зачем нужны все эти «agile-болтуны»

Они нужны для того, чтобы объяснить, зачем нужно то, что не нужно. Примерно как продавцы косметики или свидетели Иеговы.

Спасибо за развернутое определение понятия «абстрактная хрень».

Я думала программисты отучаются от позиции «если это нельзя увидеть и пощупать - этого не существует» где-то на первом месяце обучения, а поди ж ты.

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

Кто те сотрудники, которые могут автоматически релизить по расписанию хоть что-то?

По моему опыту, аджайл в большинстве случаев сводится к «спланировать, за какие задачи отчитаться». Или, иными словами, «да отстаньте вы от меня уже».

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

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

В каких областях можно делать релизы по расписанию?

В любых.

Кто те сотрудники, которые могут автоматически релизить по расписанию хоть что-то?

Кто угодно.
Надо только сесть и хорошенько подумать, что такое вообще «релиз».

М-м-м-м-м... Как я это люблю. Если мы крепко зажмуримся, и будем три раза в сутки выкатывать рассинхрованные бэк с фронтом, мы можем говорить, что это не мы обосрались, а что это у нас такие «релизы», и не важно, что конченный пользователь сможет воспользоваться фичей только через пару месяцев. Ведь мы же аджайл и релизимся три раза на дню!

аджайлом кормят исключительно конечных исполнителей, и практически всегда это выглядит как «Ну, вот мы наконец-то перешли на аджайл и вот наш календарный план на следующие три года»

https://cs10.pikabu.ru/post_img/2018/12/09/10/1544377848152047338.png

Когда закончишь выяснять про закредитованность домохозяек ради покупки безумных асиков,

Как связано? Если это отбивается, то можно взять кредит, если нет, то это не зависит от того на что именно кредит.

Если бы крипта стала хоть немного средством платежа, то да, я бы в первых рядах побежал размахивать флагом биткоина

А в чем проблема то использовать его как платежное средство? Вон у иркутских спроси накрайняк. Они не просто так майнят.

По каким именно ссылкам? У тебя их там не было.

это же весь месячный бюджет средней айтишной конторы в СНГ.

Это проблемы СНГ, хотя если верить App Annie миллион долларов в месяц выручки имеют огромное количество компаний и в СНГ.