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

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

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

Василий окинул бэклог беглым взглядом. Больше никаких больших, вкусных задач в этом месяце не предвиделось. Осталась одна фигня, — подумал он, — если уж мы ТАКОЕ за день сделали, то мелочевка проскочит вообще незамеченной. Всё потому, что я крутой специалист, как никак ведущий разработчик. А вот зато эту большую вкусную задачу в таком виде мержить нельзя, просто стыдно! Мидлы засмеют. Надо вот тут выделить класс, здесь функции вынести в отдельный класс, и вообще, как-то плохо этот кусок написан, надо молодым бойскаут рул показать.
Василий садится за небольшой рефакторинг. Время есть, запас большой, может себе позволить. Через четыре часа он замечает, что можно очень круто обобщить вот этот кусок и тогда можно будет закрыть еще и тикет, который висит с позапрошлого года — всё руки не доходили. Но тут что-то тесты покраснели. Надо бы исправить. Ой, а тесты-то какие плохие! Ну кто так делает? Уф, всему надо учить, даже тесты за ними рефачить приходится.

Пока Василий рефачил, делал какие-то крутые, но никому не нужные фичи (в смысле никому не нужна конфигурация размера кеша http-заголовков??), чинил тесты и учил молодежь, как делать пулл-реквесты на 4к LOC, прошло довольно много времени. Возможно, Василий даже умудрился опоздать к дедлайну, потому что опять забыл заложить время на UA-тестирование.

Как же можно этого избежать? Нужно контролировать скоуп! Должна быть написана спека. Спека это просто, человеческим языком объяснение, что должна делать система. Вход, выход, сайд-эффекты. Круто, если будет еще и формальная спека (openapi, матан, jls ch. 17.4, you name it). Но хотя бы словами.
Спека должна быть минималистична в смысле MOVE (Minial Outcome-Value Effor). То есть фича в спеке должна иметь ценность сама по себе (без необходимости делать еще какие-то фичи, можно продавать, как есть), но при этом в ней абсолютный минимум функционала.

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

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

Что там про школы мысли-то?

Вот коллега пишет про дедлайны. Канал, кстати, совершенно замечательный, коллега тоже, подписывайтесь!
Если коротко, то его идея заключается в том, что нужно по каждой задаче ставить жесткий дедлайн и спрашивать за него.

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

1. Когда дедлайн _реально_ жесткий, есть последствия. Вам не заплатят денег, уволят с работы, четвертуют лида. Когда дедлайн "жесткий", вы максимум получите айяйяй и час в углу на горохе.
2. Когда делайн _обоснован_, люди _верят_, что это дедлайн и делают работу. Иначе это просто best effort.
3. Мы тут с вами выясняли, что никто не умеет оценивать. Некоторые, кстати, верят, что умеют или что могут научиться. Но пока что никто не умеет. А значит обязательно будут ошибки с дедлайнами. В обе стороны. Кого будут наказывать за хреновые оценки, впрочем, не уточняется.
4. В качестве способа достижения дедлайна указывается срезание углов и уменьшение скоупа. У меня вопрос: если что-то можно вырезать из скоупа, то почему бы не вырезать это с критического пути сразу? А всё nice-to-have'овое доложить в ганта где-нибудь с краешку, на случай внезапно освободившихся ресурсов.
5. Если _реально_ эскалировать всё подряд, то можно доэскалироваться. Как мы тут с вами знаем, подавляющее большинство работы в компании можно вообще не делать, будет только лучше. А если на каждую фигню отнимать время руководителей, то на действительно важные ресурса не останется.
Здесь хочется отметить, что требовать эскалации могут задачи на критическом пути. И то не все.

С другой стороны, настоящий хардовый дедлайн мотивирует бежать быстрее, фигачить, не шататься праздно между кофепойнтом и бильярдной. Но он еще и мотивирует работать сутками, ведь иначе секир башка — нет ножек, нет мультиков. Придется новую работу искать. Тут либо трусы, либо крестик.
Вот чего, как мне кажется, _на_самом_деле_ хочется добиться, так это "ощущения спешки". То есть выгорать и героически затаскивать всё за одну ночь не нужно, но и прохлаждаться некогда — конкуренты не спят (они роботы на основе LLM), опаздываем, ребята.

Ещё есть такие периоды, когда вообще работать не можешь. Даже если много денег обещали. Даже если отобрать. В такие периоды важно делать хоть что-то: хоть коммитик, хоть документик, хоть кнопочку. Главное, начать. Не решить начать, а начать.
Тут никакие дедлайны не помогают, к сожалению.

Сегодня защитились мои ребята магистранты. Двое получили отлично, ещё двое капельку не дотянули до отла и получили хорошо (7) отл начинается с 8, один решил не защищаться в этом году по итогам предзащиты.
Поздравляю ребят! Два года занятий после работы, домашек по выходным и работе над полноценным проектом для диплома наконец-то окончены.
Получилось хорошо, сделали рабочий прототип, расписали реалистичный роадмап, можно даже пробовать это развивать в реальный бизнес.
Что мне особенно нравится в этом проекте: бизнес-план, маркетинговая компания, развитие ИТ-систем — всё связано между собой. То есть из работ ребят совершенно ясно, почему и в какой момент будет сделана та или иная фича, и как и когда изменится архитектура приложения, как будет меняться позиционирование на рынке. Я доволен.
Пока мне это достоверно не известно, но думаю, что получилась одна из самых сильных работ на потоке. Спасибо за работу, господа магистры 😊

Дельно, полезно, прикопал себе, покажу и вам

Когда собака из друга человека стала сыном человека? 🤔

Книжка топ, насколько раз ее рекомендовал на разных площадках. Отличная возможность изучить её. Касательно физики она сильно устарела, но лучше только чтение актуальных статей (за последние года два максимум), поэтому не важно. Можно поразбираться и на ЯМР.

Стори пойнты не работают
Планирование — это риск менеджмент
Решения принимаем насколько это целесообразно позже, чтобы быть более информированными
У разработчика нет 40 рабочих часов в неделю, оценивать сроки никто не умеет, а на пропускную способность команды влияет куча факторов
Математика нам говорит, что проекты чудесными образом сходятся к сроку, если этапам разрешить заканчиваться досрочно
Таймбоксинг < Скоупбоксинга

Пока ощущение, что ничего не работает, мы обречены, сроки не оцениваются, в дедлайны не попадается! Ужас!

Бизнесу вообще-то надо знать, когда примерно будет готово. Ну знаете, маркетинговые компании там, субсидирования проектов, планирование ликвидных средств — вот это вот всё. А мы такие: мы программисты, профессия творческая, вот посмотрите — quant valerian написал, что ничего не работает!

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

Наконец-то закончился период сдачи задач на SRE Week от Школы Анализа Данных. Это был интенсив, где за неделю показали всю суть ШАДа. Прочитали несколько лекций, а потом дали задачи. Ощущения в целом, как на картинке с совой. Но мне понравилось.
Скоро напишу пост, как я решал задачи (про то, как планировать проекты тоже напишу), как только найду полчаса с живым мозгом.
А пока предлагаю посмотреть задачки здесь https://gitlab.sreweek.ru/sre/sre-week

Задачи с SRE Week делились на три блока: bpftrace, binary-search и "sre". Я начал с бинпоиска, потому что "щас я вам покажу, кто здесь перфоманс инженер", вот почему.

Первая задача — моя любимая. Поиск в маленьком массиве (не более 100 интов). Я думал, что просто сделаю линейный проход, бранчей не будет, по памяти всё хорошо — зайдёт. Но не тут-то было! Впрочем, задача всё равно оказалась довольно простой: в условии упоминается, что для решения доступны AVX2. Просим chatGPT написать линейный поиск на AVX2 — есть решение. Не то, чтобы там был какой-то сложный синтаксис, но я его, конечно же, не помню. А тут получите, распишитесь.

Следующую задачу я решал часов пять. Нужно было искать в отсортированном массиве интов, размером от 256 до 2^16. Ха!, — подумал я, — это же просто galloping binary search! И снова оказался не прав. Я снова попробовал векторизовать, уже galloping binary search (тут chatGPT не справился совсем) — не хватает скорости. Переуложить массив в eytzinger точно дольше, чем поискать один раз. chatGPT снова бессилен.
Путём гугления в яндексе я обнаружил статью на хабре. Действительно, бранчлес версия бинпоиска залетела, как нож в масло. Вкратце: мы храним только начало и длину окна, тогда на каждой итерации либо двигаем начало, либо просто уменьшаем размер окна; единственная операция сравнения тогда будет в условии цикла.
Side note: я пробовал написать бранчлес версию сам (до того, как нашел статью). Реализация через тернарники не работает. Реализация через арифметику над булами тоже не работает. perf'а у меня на виртуалке толком не было, поэтому я не знаю, в чем причина.

Третья задача в общем-то ничем не отличается от второй. Нужно искать в больших массивах (2^16 - 2^20 интов). Всё, что нужно сделать — добавить префетч к решению второй задачи. Реализация с префетчем есть в той же статье на хабре. chatGPT просить не пробовал :)

Дальше я взялся за задачи блока sre. Самое мне понятное — single producer single consumer queue. Я просто попросил chatGPT написать на C++ на слабых мемори семантиках spsc очередь. Он выдал достаточно лакончиный и рабочий код на кольцевом буфере. Там зачем-то был лишний массив, как член класса, но его было легко удалить. Локально эта реализация проходила тесты, но вот в контрольной системе — нет. Тогда я вкрутил самую попсовую оптимизацию: заменил остаток от деления на логическое И (предварительно захардкодив размер буфера в степень двойки: 2^15). И НЕ ЗАШЛО! АХАХАХАХА. Я поменял размер буфера на 2^16, и тогда зашло. Не ищите здесь логику. Дело в том, что тесты в контрольной системе ОЧЕНЬ шумные. Мог ничего и не менять, короче.

Разделавшись с очередью на раз-два-три, я взялся за задачу retry. Тут мы сталкиваемся с golang. Там есть клиент и сервер. Сервер падает на произвольное количество времени, потом поднимается. Клиент должен:
1. Не просыпать ни одного запроса
2. Поддержать RPS не более, чем x3 от нормы
3. Поддержать тайминги не более, чем х4 от времени недоступности сервера
Я сначала придумывал хитрые алгоритмы отображения отрезков одной длины в отрезки длины х4, но минут через 20 понял, что надо просто написать рейт-лимитер. Я попросил chatGPT написать мне тупейший рейт-лимитер на скользящем окне (никаких вам лики бакетов и подобного), прям с мьютексом, не выдумывая ничего. Настроил рейт-лимитер на параметры условия задачи. И зашло с первой попытки.

Далее я взялся за задачу traces. Я её так и не сдал. Условия там замудренное, но по-сути нужно научиться склеивать спаны в трейсы, находить самые нагруженные участки и репортить их. Извините за мой французский. Условие было довольно нечеткое, много белых пятен и неоднозначностей. Я сразу же, не думая, скормил его chatGPT. Тот выдал довольно понятный, но прям _очевидно_ неоптимальный код на golang. А, да, он еще и не работал. Даже на скормленных примерах. Я надолго откладывал эту задачу в пользу более интересных bpftraces, однако, вернулся к ней после всего. Мне удалось дожать версию нейронки до состояния, когда она падала по таймауту на последнем тесте. Правда, для этого пришлось реверс-инжинирить первый тест на сервере (печатал его данные в выхлоп, чтобы посмотреть в логах CI).
Когда я переделал алгоритм на сильно более оптимальный вариант, я его сломал 🤡 Теперь оно падает где-то на 35-м тесте. СОВРЕМЕННЫЕ ЧУДО-ТЕХНОЛОГИИ МЕНЯ НЕ СПАСЛИ! Ура! Нас не заменят! Хорошо, что я менеджер.

Дальше было самое мясо. Я вообще не знал, как пользоваться bpftrace. Поэтому уже на первой задаче (оттрейсить, какая программа и сколько пишет на диск) я пошел спрашивать chatGPT, чтобы научила меня писать скрипты для bpftrace. Оказалось, что тула очень сырая, некоторые синтаксические конструкции из доки не работают на многих версиях. Но с грехом пополам и one-liner'ами с сайта Брендона Грегга я разобрался. Первая задача залетела минут за 20.

Примерно в этот момент объявили, что для получения сертификата необходимо набрать 1300 баллов. Это означало, что нужно обязательно сдать либо traces, либо bpftrace-3 (самые дорогие задачи). Поэтому, я тут же взялся за bpftrace-3. Это просто мозги в фарш, ребята. golang, функция-член структуры принимает аргументом указатель на структуру из инта и строки (строка в голанге это инт и массив байт, не 0-terminated, как в Си). Нужно собрать все вызовы, для каждой строки из аргументов сложить числа.
Не, ну так-то изян. НО ЭТО ГОЛАНГ! ChatGPT здесь выдает вообще не рабочие варианты. Брожение по документации bpftrace — тоже. Более того, там есть misleading обсуждения, что в голанге calling conventions разные в разных версиях (то на стеке, то в регистрах), но ни одна из этих версий у меня не сработала.
Я уже и таблицу символов всю до дыр просмотрел, уже и научился правильно трейсить такие методы (например, u:main:* не сработает, а вот u:./main:* — да 🤡), если хотите потресить метод, у которого в названии скобочки и звездочки (голанг же), то возьмите его название в двойные кавычки (u:./server:"main.(*Server).Serve"). И on-liner'ы ваше всё. Ничего не работает.
Пришлось расчехлять gdb. Там цепляемся к процессу, ставим брейкпойнт внутрь искомого метода, смотрим, че на стеке, че в регистрах, кастим всё к желаемому типу — находим аргумент в регистре rbx.
Далее в bpftrace скрипте читаем регистр, считаем смещения, собираем строку и вуа ля — нифига не работает, потому что регистра rbx нет. ebx, кстати, тоже. Вот вам знание, которого нет в интернете: надо читать регистр bx. Без префиксов. Тогда работает.

И на десерт я взял трейсинг мьютекса: какой трейс сколько держит лок (никогда так не радовался C++). Там всё просто, даже chatGPT не нужен. Если трейсите мьютекс. Но наивное решение не работает! Я битый час пробовал трейсить и lock (еще пойди научи bpftrace ловить деструктор!) и mutex. Несколько часов пытался понять, почему один из трейсов дублируется, хотя он ключ хеш-таблицы (это баг самой bpftrace). Оказалось, что я трейсил не то! Я считал время от момента входа в функция для лока (то есть вместе с ожиданием, когда лок станет доступен), а надо было трейсить выход! Это делается заменой u на ur.

В общем, сертификат я получил, но одну задачку не сделал. А упражнение весёлое. Мне понравилось.

Прям щас
Стрим Бушвакера
Средневековая Япония
Потом не говорите, что я вас не предупреждал
https://www.twitch.tv/bushhistory?sr=a

Так как планировать

На самом деле здесь есть несколько вопросов в одном. Будем разбирать по одному.
1. Как оценивать срок проекта?
2. Как спланировать проект (в смысле риск менеджмента)
3. Как исполнять сам проект? То есть как двигаться по проекту, вовремя определять риски и понимать с ними.

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

1. Сроки. Никто никогда не попадает в сроки. Это на самом деле очевидно, потому что срок это точка во времени (а время мощности континуум), иными словами вероятность попасть точно в срок равна нулю. Но это не возможное событие (вы почти наверное знаете о чем я, в этом то канале).

Но что тогда делать? Подумать! Что мы обычно имеем в виду, когда называем срок? Это какая-то точка, в которой скорее всего будет готово. Но с какой-то вероятностью будет готово раньше, а с какой-то позже. Более того, плотности вероятностей будут не линейны слева и справа от точки. Поэтому гораздо более честно будет называть несколько точек: будет готово через 7 дней с вероятностью 80%, через 8 дней с вероятностью 90%, через 14 дней с вероятностью 99% и т.д.

Да, это гораздо сложнее для других менеджеров (и вообще для людей, вероятности же), но на самом деле это гораздо честнее и позволяет более продуманно подходить к смежным активностям (маркетинг, лигал и т.п.). Кроме того, уже сам факт работы с вероятностями заставляет смежников заниматься управлением рисками. Петя из юр отдела послушает вас и подумает: "хм, если через неделю будет готово только с вероятностью 80%, то стоит поуправлять ожиданиями той стороны и заложиться в контракте на просрочку".

А как оценивать эти вероятности?
Начнём с того, что задачи делятся на две фазы: НИ и ОКР.
Вот НИ оценить очень сложно. Зато его можно задать! Мы можем управлять ползунком между качеством придуманного решения и временем, затраченным на его изобретение. Топорные решения обычно можно выдать за часы. Что-то поумнее требует больше времени. Вот ставьте дедлайн: думаешь не дольше, чем Х времени, потом приносишь, что надумал.

ОКР на самом деле очень неплохо оценивается экспертами. Это, кстати, контринтуитивно. Кажется, что чем меньше размер задачи, тем менее волатильна оценка. Практика показывает, что это не так. Задачи, которые оценивали в пару дней, делаются месяцами, а какие-то космолеты на три недели зачастую схлопываются в "вот там поправить конфиг, работы на день".
Но проекты как раз усредняют эти ошибки от каждой задачи. И получается довольно точно.
А вы думали, что дело просто в том, что программисты тупые и неопытные, а вы крутой менеджер, все предусмотрели? Жаль, но нет.

Для нас с вами, любителей дата дривен всего (хотя я тут совсем не фанатик), у меня есть бонус-трек. Если вы работаете MOVE'ами, если у вас уже есть какая-то история такой работы, то у вас есть статистика. У меня, например, есть прям графики, где можно посмотреть, за сколько какой персентиль каких эпиков/сторей/move делается.
Вот мы недавно спланировали проект на квартал. Экспертная оценка (целились в 80% вероятности) совпала с оценкой по 85%% из статистики.

2. Про риски. Тут я никакой Америки не открою. Составляете табличку рисков (можете привлечь команду, например, через футореспективу "кораблик", добавить стандартные таблички из интернета, взять с прошлых проектов, попросить у коллег). Bowtie diagram вам в помощь (риск, вероятность, импакт, как предотвратить, что делать при реализации).

Отмечу только, что есть ещё один полезный взгляд на риски (и вообще на многие вещи, Брукс так на проблемы разработки ПО смотрит в no silver bullet).
Бывают случайные риски (кто-то заболел), а бывают системные/процессные (не знаю как назвать нормально) риски. Вот вторые бывает сложно заметить, но они самые злые, они жрут ваш фрупут постоянно, очень тихо чавкая. Это могут быть какие-то неэффективные коммуникации, ненужные бутылочные горлышки, размытые договорённости и т.п. Например, нужно всегда получать апрув на фичу от тимлида, который вечно занят на встречах — это вот оно. Или надо ждать викли, чтобы сообщить о проблеме — тоже оно.

Про третий пункт будет позже.

SCRUM это хороший инструмент для слабых менеджеров

Буквально все ритуалы скрама призваны угнетать пролетариат и снимать ответственность с руководителя. Давайте разбираться.

1. Планирование. Это встреча, где менеджер напихивает разрабам в спринт побольше работы, причём, если они не успели, то сами виноваты (неправильно оценили!), а если успели, то менеджер молодец — хорошо планирует.
Причём инфляцию стори пойнтов менеджеры стараются пресекать (как мы знаем из макроэкономики, зря), а меньше, чем в прошлом спринте взять нельзя. Поэтому ошибки в сторону недооценки задачи уплотняют спринт (в прошлый раз же успели 100 sp, давайте в этот тоже успеем), а ошибки в сторону переоценки караются (потому что менеджер выглядит плохо планирующим, ему неприятно).

2. Демо. Этот ритуал нужен для того, чтобы вызывать чувство вины и комплекс неполноценности у разработчиков, которые приболели, у которых проблемы в личной жизни или просто накопилась усталость. К демо нужно успеть показать, что ты молодец и хорошо поработал. Иначе будет неудобно "перед пацанами".

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

4. Груминг. Акт снятия ответственности с лида, переноса её на коллектив. Неверно выбрали приоритеты — МЫ виноваты. Ошиблись в оценке задач — ВЫ виноваты (разработчики). А вот если всё у команды идёт хорошо, то молодец менеджер, это же он всё настроил так хорошо.

5. Ретроспектива. Это либо поиск виноватых в предыдущих проблемах, либо способ заставить работников придумать, как их получше эксплуатировать. Зачем думать менеджеру, если может подумать команда!

А помните, был такой — семавер?
Ну вот он остался в Фетхие. Оказалось, что в Белграде такую штуку не найти! Но мои любимые коллеги в этом году подарили мне новый на день рождения ❤️
Привёз из Москвы в Белград турецкую вундервафлю и счастлив. Такие дела.

Держу в курсе.