Спорный вопрос. Никлаус Вирт, например, утверждал, что группирование данных и поведения существовало с 1970 года, и никто не называл это новомодным словом ООП. А месседжинг, по его словам, притянули за уши, чтобы замаскировать процедурное происхождение ООП. Месседжинг и в самом деле очень скоро стал редкостью в ООП, и сегодняшний общепринятый ООП мало чем отличается от тех приемов, которые использовались с 1970 года в процедурном программировании. В целом, появление термина ООП он связывал с маркетинговыми причинами. Это примерно как микросервисы в наши дни - вроде бы Bounded Context с Open Host Service / Publish Language, но такое название мало кому говорит что-то на современном рынке. Индустрии регулярно нужен хайп.

Золотые слова. Регулярно приходится объяснять людям эквивалентность машины Тьюринга и лямбда исчисления

Ну, да, реальный ООП сейчас сдвинулся в сторону модульного программирования, которое было практически всегда )
И очень жалко, что Модула или Оберон не стали популярными (и я до сих пор люблю паскаль).

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

Коллеги! Какие бывают ещё методы приоретизации кроме "Срочно/Важно" и "Must have/Should have/Could have/Won't have" и правила Парето? Кто что знает?

еще по сложности (если это не правило Парето)

А как по сложности? Самые быстрые и лёгкие или самые важные  и трудные?

за сколько решишь
быстро
обычно
долго

🙏

если кратко про приоретизацию задач то фундаментально первая часть - это про время
(когда надо быть в фиксированном месте или не быть в нем) тут все понятно должно быть
дальше идет категория задач - что надо сделать к определенному времени
формируется таблица 2 на 3
где первая метрика это важно/не важно
вторая метрика легко/норм/сложно
задачи кладутся в корзины и распределяются по этой таблице
сначала делают легко и важно
дальше стредне и важно или быстро и не важно ну и дальше по аналогии
основные моменты вроде такие
если что я про приоритеты распределения времени говорил

но уже ответили

Очень интересно!

только вместо легко норм сложно
быстро средне долго должно быть

вот

Отличная ссылка. Добавлю еще от себя про фреймы. Часто рассказываю  на своих занятиях. Задача - заполнить набор слотов (чаще временных, но не обязательно) новыми продуктами или фичами. Ну, например, решить что мы предлагаем рынку под Новый год, потом на гендерные праздники 14, 23 февраля и 8 марта, а еще к майским и т.д. Выбираем из воронки идей сначала то, что хочется и заполняем слоты. Потом смотрим деньги, риски, сроки реализации и добавляем для каждого фрейма "План Б" (или меняем выбранный раньше на более реалистичный или дешевый). Потом увязываем их между собой, т.к. часто они конфликтуют по ресурсам. И так несколько итераций

А где-то на ютубе есть видео с этой практикой?

Приоритет один, всегда. Во времени естественно, так что таймлайн, и фитчи на нем. Последовательно, если команда одна, нет двух приоритетов в тот же промежуток. Если команд больше то уже можно два трека на pipe. Таков будет результат какие бы матрицы и воронки не использовались как инструменты выбора.

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

Скорее всего этот справочники есть еще в mdm (ЕС УНСИ) и приказах, выложенных на сайт