А я то думаю, что не так со мной)

Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/

Очень похоже на готовый Specification Pattern из коробки, причем, судя по исходникам, работает и с БД, и с объектами в оперативной памяти.
https://github.com/EvgSkv/logica

„Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль…“ —  Антуан де Сент-Экзюпери

Очень часто слышу "бизнес-логика" от слова "бизнес" - зарабатывать деньги.

Бизнес переводится с английского "дело".

"It's not your business!" - "Не твое дело!"

Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.

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

[UPDATE]:

Business - Software intersects with the Real World. Imagine that.

-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness

Stay ahead, lead the future of AI in project management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.

https://www.pmi.org/learning/ai-in-project-management

Leading AI Transformation: Organizational Strategies for Project Professionals
Project Management Institute

Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
https://www.pmi.org/standards/leading-ai-transformation-organizational-strategies-for-project-professionals

AI Essentials for Project Professionals

A companion guide to incorporating AI in day-to-day project management.
https://www.pmi.org/standards/ai-essentials-for-project-professionals

Из г...глины и палок? Чтобы работало? Легко! В руках мастера, как говорится...

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

Добавил в TaskJuggler поддержку подсчета Standard Deviation:
https://github.com/emacsway/TaskJuggler/tree/standard_deviation

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

Как это работает у меня сейчас. Мой коллега разработал для Jira плагин, который позволяет вводить трехточечную оценку по методу PERT. Это очень важный плагин, который решает целый ряд проблем, начиная от психологических (разработчики склонны оптимизировать оценки, а бизнес склонен воспринимать планирование как обязательство и понукать сроками) и заканчивая математическими (вероятностную распределенность невозможно выразить одним значением).

Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.

Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).

Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.

Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).

Список литературы по планированию см. здесь.

#Estimation #Scheduling #TaskJuggler #PERT

Зачем нужно стандартное отклонение?

Существует три качества оценки:

1. Honest (честность)

2. Accurate (достоверность, например, утверждение о том, что задача будет выполнена за период времени от текущего момента до конца существования Вселенной - это Accurate, но не Precise)

3. Precise (точность, т.е. сужение диапазона вероятности оценки, например, утверждение о том, что задача будет выполнена 11 октября 2025 года в 15:45:10.0639 - это Precise, но не Accurate)

Было хорошее видео на эту тему "YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)", но сейчас оно, к сожалению, недоступно. Может можно найти его копии где-нибудь.

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

Оценка - это диапазон. И диапазон с вероятностной распределенностью.

На этом построен принцип оценивания PERT, который снимает психологическое напряжение и позволяет выразить степень неопределенности оценки в виде среднеквадратичного отклонения. Коротко этот подход описан на 3-х страницах книги "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT". На русском она называется "Иделальный программист".

Для каждой стори снимаются 3 оценки - пессимистическая, номинальная и оптимистическая.

При коллективном оценивании для пессимистической берется самая пессимистическая из всех, для номинальной - средняя, для оптимистической - самая оптимистическая.

Вычисление можно легко осуществить в excel-файлике. Вероятностая оценка находится по формуле μ = (O + 4 N + P) / 6. А среднеквадратичное отклонение распределения времени выполнения стори находится по формуле σ = (P − O) / 6. Этот параметр выражает точность оценки.

Далее суммируются вероятностные оценки для всех сторей релизного цикла простым математическим сложением, это несложно сделать в excel. А вот среднеквадратичное отклонение распределения времени выполнения всех сторей высчитывается немного сложней, и равно квадратному корню суммы квадратов среднеквадратичных отклонений сторей, т.е. σ sequence = (∑ (σ story ^ 2)) ^1/2. Это тоже несложно автоматизировать в excel.

Ну а далее, как я уже говорил, для нахождения пессимистического срока релиза используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).

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

Важно понимать, что планирование - это не предсказание (Kent Beck). А прогноз - это не обязательство (Robert Martin).

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

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

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

Теперь могу уверенно ответить на вопрос о том, есть ли от него реальная польза, или это просто эффект новизы.

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

Я обсуждал этот вопрос с моим товарищем, к.т.н., который работает над докторской, и тоже пользуется бумажным ежедневником. Я не спец в физиологии и не могу в точности передать содержание разговора, но он мне объяснил о наличии некой связи между нейронами, отвечающими за мелкую моторику, и нейронами, отвечающими за память. Эта тема даже неплохо освещена в интернете, например:
https://hi-tech.mail.ru/news/119776-pismo-ot-ruki-luchshe-prokachivaet-nejronnye-svyazi-chem-pechat-novye-dannye/

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

Наверное, поэтому С.И. Поварнин в своей книге "Как читать книги" рекомендует конспектировать прочитанное.

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

Я пользуюсь форматами A6 и Personal. A6 удобней, но мне подвернулся по хорошей цене оригинальный новый Montblanc формата Personal.

Самым удобным форматом наполнения для меня оказался https://myfineplan.ru/product/blok-nedelya-v2-2 , т.к. он содержит страницу для заметок на каждую неделю. Но, если честно, места на странице недельного расписания (т.е. на левой) частенько не хватает.

Какие и где блокноты можно купить?

1. https://myfineplan.ru/
У этой мастерской есть телеграм-канал:
https://www.tgoop.com/myfineplan

2. На Авито часто бывают в продаже шикарные ежедневники из натуральной кожи Petek в непритронутом виде (просто лежал у кого-то дома в заводской упаковке). По непонятной для меня причине они лучше находятся по фразе "записная книжка Petek". Иногда попадаются Dupont и Montblanc.

3. На Aliexpress можно купить блокноты Moterm и Filofax. Мне очень нравится Filofax Holborn формата Personal, который есть в моей коллекции.

Цифровой блокнот из моей практики не исчез, продолжаю пользоваться
https://github.com/orgzly-revived/orgzly-android-revived
, который подкупил меня внутренним качеством своей кодовой базы по сравнению с другими Open Source решениями.

P.S.: Знаете чем обусловлен успех Юрия Никулина? Что для него было самым ценным, и прошло с ним через всю войну? Блокнот (в виде тетради), в который он записывал анекдоты.

Интерес к диалектике растет.

Знаю @YuryKupriyanov как очень грамотного спеца. Так что курс по микросервисам в его изложении обещает быть полезным.

Вдруг кто не знал, Logseq поддерживает org-mode, как и Markor.

Уже не надо подсчитывать. Добавил поддержку Left Standard Deviation, который подсчитывает значение только для незавершенных задач. Исходники там же.

Таким образом, в любой момент времени можно сделать сверку фактического срока с запланированным, и проверить, находится ли эта разница в пределах запланированных 3×sigma для завершенных задач, для которых σ находится как разница между σ и left σ. Получилось очень удобно, вся информация - на одной диаграмме.

Если разница попадает в запланированный резерв - все ок. Если нет, значит пора подготавливать бизнес-решения.