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

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

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 σ. Получилось очень удобно, вся информация - на одной диаграмме.

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

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

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

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

Мир сошел с ума.
Увидел что 3 компании архитектора ищут. У них норм продукты.
Кидаю им резюме, получаю автоотказ. Меня это удивило.

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

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

Финал.
У меня в резюме последний опыт содержит много деталей как я божил. Резюме большое, скучную операционку не пишу уже в нем.
Думаю а вдруг это их пугает. Добавляю что на последнем месте рабочем делал абсолютную тупость.
И от всех 3х компаний приглашение на интервью.

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

Умеет человек быть на гребне волны. Думаю, что эта репа будет пользоваться популярностью (сегодня там смотреть пока что нечего, но подписаться стоит):
https://github.com/ddd-crew/ai-ddd-prompts-and-rules

В последнее время начал смотреть старые кинофильмы. Сейчас хорошее кино снимают не так часто, как раньше.

Смотрю фильм "Идти тихо, идти глубоко" ("Run silent, run deep"), 1958г.

На 45 минуте разгорается конфликт по причинам, хорошо знакомым каждому архитектору.

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

В команде возник страх, который спровоцировал попытку смещения капитана.

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

Долгосрочные цели вступили в конфликт с краткосрочными целями.

Знакомая ситуация, не правда ли? Архитектор настаивает на существенных конструктивных преобразованиях системы, сдерживающих развитие системы, в то время как у представителей бизнеса возникает опасение рисков - а вдруг не справятся? А вдруг выйдет дороже? А вдруг это не принесет ожидаемых выгод? А стоит ли оно упущенной выгоды из-за задержки доставки бизнес-фич?

Рискнуть и получить много или жить спокойно и довольствоваться малым?

Это и есть та причина, по которой архитектор должен обладать храбростью.

Главное, чтоб не путать храбрость с глупостью. Обратите внимание, как действовал капитан:
1. Самоподготовка. Он смоделировал бой 200 раз сидя в кабинете.
2. Обучение команды, чтоб она обладала требуемыми навыками.
3. Прототипирование. Испытание нового тактического приема в бою с малозначимой целью.
4. Завоевание авторитета перед командой ("Вот это шкипер! Да, он знает своё дело!"). Т.е. установление и укрепление власти.
5. Коммуникативная психология. Преодоление сопротивления команды (здесь пригодился завоеванный ранее авторитет).

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

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

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

Управление сложностью (главный императив разработки ПО) на примере шахмат:

"Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам - разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.

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

Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.

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

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time. The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling—the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.

At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece. The goal of all software-design techniques is to break a complicated problem into simple pieces. The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation.

Keeping routines short helps reduce your mental workload. Writing programs in terms of the problem domain, rather than in terms of low-level implementation details, and working at the highest level of abstraction reduce the load on your brain.

The bottom line is that programmers who compensate for inherent human limitations write code that's easier for themselves and others to understand and that has fewer errors."

—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"