ScrumTrek

Чужой опыт как выход из тупика

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

Но собрать людей одной профессии мало. Хочется, чтобы после встречи у людей осталось что-то осязаемо полезное.

Поэтому 27 ноября на ArchDays 2026 продолжим разговор о решениях, с которыми нам предстоит жить долго. Иногда дольше, чем хотелось их авторам.

Что мы стараемся вам дать на ArchDays?
1. Возможность раскрыть важные для себя детали
Готовый ответ не показывает путь к нему. Почему выбрали то, а не иное? От чего отказались и почему? Спикеры дают историю, но каждому ведь интересны свои нюансы и конференция дает возможность эти нюансы прояснить, – через вопросы или более глубокую беседу после выступления.

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

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

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

🗓 27 ноября 2026, Москва, Центр событий РБК, + онлайн.

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

➡️Присоединиться к архи-крутому коммьюнити

Вспомните любую задачу, которую ваша команда закрыла на прошлой неделе. Сколько дней она была в работе? И сколько часов с ней действительно кто-то взаимодействовал? 🫪

Обычно бывает так, что задача в работе две недели, а реальных "человеко-часов" примерно шесть. Всё остальное время она просто ждала пока её прогонят по SDLC.

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

Проблема в том, что это ожидание нигде не видно. На доске есть колонки «Аналитика», «Разработка», «Тестирование» — то есть то, что люди делают. А карточка может простоять в «Разработке» четыре дня, из которых три она ждала, когда у разработчика дойдут руки.

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

17–18 ноября Александр Рыжков проводит двухдневный интенсив «Основы Канбан-систем» (KSD).

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

➡️Освоить Канбан в совершенстве

Уверены, вы не знали, что эти слова значат на самом деле! 🫣

Три слова, регулярно фигурирующие в современном деловом лексиконе, но про этимологию которых мало кто догадывается:

🪵 Бэклог. В 1680-х back log означало толстое полено, которое запихивали в глубину очага. Пламени оно не давало, тлело всю ночь и держало жар, чтобы утром было легче разжечь огонь заново. Изначальный контекст: запас тепла на завтра. Ярлык «гора невыполненных заказов» приклеился только в 1930-х, на индустриальном буме, и теперь мы используем его именно в этом значении.

🧩 Инкремент. Латинское incrementum от increscere, «прирастать». Тот же корень у растущей луны и у круассана, названного по её форме, и у крещендо, где звук набирает силу. Важная деталь — прирост всегда добавляется к чему-то целому. Луны по кусочкам не бывает. Поэтому «мы за спринт сделали кусок» инкрементом назвать нельзя. Инкремент — это весь продукт, который стал больше и при этом работает.

🎼 Каденция. От латинского cadere, «падать». В XIV веке словом называли понижение голоса в конце фразы, потом оно ушло в музыку и стало означать завершающий оборот. Родной брат слова «шанс», у них общий корень. Смысл один — фраза заканчивается предсказуемо. Каденция в команде тоже про предсказуемое регулярное завершение.

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

👉 Базовый Agile: основы Scrum, Kanban и командной работы

👉 Agile Project Management

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

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

Цифры Cockburn и Williams говорят другое: часов уходит на 15% больше, а не вдвое, дефектов на 15% меньше, кода на 20% меньше. А читаем мы код раз в десять дольше, чем пишем.

Сергей Баранов обновил статью про парное программирование, добавил раздел про AI.

Что внутри:
🧡пять стилей: штурман/водитель, строгий пейринг, пинг-понг под TDD, смешанный, mob;
🧡почему это навык, а не рассадка двух людей рядом, и три антипаттерна, которые убивают сессию;
🧡пара джун-сеньор: как не дать сеньору стать Keyboard Dominator;
🧡что делать, когда знаний не хватает одному партнёру, и что — когда обоим (иногда задача не решается вообще);
🧡AI в паре. Не «разработчик + AI», а «два разработчика + AI»: машина снимает механику и ровно поэтому поднимает цену ошибки штурмана.

17 минут чтения, в конце шесть шагов для старта.

🔗 Изучить полезное чтиво

Семь раз отмерь. Один раз назови срок заказчику 📐

Разумеется, нет и не может быть таких специалистов, которые идеально предсказывают сроки в 100% случаев. Однако научиться базировать сроки на точных данных, управлять ими и называть наиболее точный дедлайн, не так сложно, как это малюют.

Спойлер: всё, чтобы в следующий раз назвать самый приближенный к реальности срок — у вас уже есть, и нет, это не просто экспертность и прошлый опыт (хотя и они тоже).

Завтра, 22 сентября, в 19:00 (МСК) Александр Рыжков на вебинаре «Как прогнозировать сроки без гаданий?» расскажет, как при формировании сроков оперировать этими понятиями:
🧡lead time
🧡throughput
🧡перцентили
🧡SLE

За такую оценку и ответственность нести не стыдно и аргументировать всегда будет чем.

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

🔗 Зарегистрироваться на бесплатный вебинар

Вебинар про подготовку встречи уже сегодня❗️

У фасилитации всегда есть невидимая сторона — работа с запросом. Сегодня в 18:30 на бесплатном эфире Дарья Охохонина разберёт и структурирует практические аспекты этой работы.

Что унесёте с эфира:
🧡вопросы, которые задают заказчику, чтобы понять точно понять его запрос;
🧡как честно взвесить свои силы и свою роль в предстоящей встрече;
🧡по каким признакам видно, что формат стоит поменять или сессию вообще не проводить.

Полезно тем, кто только осваивает фасилитацию, ведёт встречи как руководитель команды или проекта, собирает стейкхолдеров как продакт или фасилитирует внутренние сессии в роли HR.

Длительность: 45 минут
Платформа: Zoom

🔗Записаться на бесплатный вебинар

Лимит — это для вас какая-то шутка? 🧮

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

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

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

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

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

Либо ещё одна классика жанра: тимлид видит, что тестировщик (либо любой другой член команды) сидит без задач и даёт ему что-то вне очереди, допустим, из тех долга. А задач у тестировщика хватало: очередь копилась в разработке (либо в любом другом отделе), туда приходит больше, чем выходит. Новая задача доехала до этой очереди и сделала её длиннее.

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

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

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

6–7 октября Александр Рыжков проводит двухдневный онлайн-тренинг «Основы Канбан-систем (KSD)» — как раз про то, как читать эти сигналы и чинить процесс. Ставить WIP-лимиты и опираться на статистику Throughput, находить задержки в потоке, называть срок с вероятностью 80–90%.

👉 Записаться на тренинг

Ненужную встречу можно распознать на десятой минуте, а испортили её накануне

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

Упражнениями здесь не помочь. Здесь только исследовать и выяснять конкретный запрос за неделю до.

16 сентября в 18:30 проводим открытый эфир про подготовку к фасилитации сессий. Сорок минут плюс вопросы.

Тема: Подготовка встречи: какие вопросы перед встречей стоит задать себе и заказчику

Разберём как устроен этап подготовки:
❣️ какие вопросы задать заказчику;
❣️ какие вопросы задать себе, чтобы честно оценить свои силы, роль, и на что смотреть, чтобы распознать ситуации;
❣️ где фасилитатору лучше отказаться от выбранного формата или проведения сессии вообще.

Ведёт Дарья Охохонина: Agile-коуч, бизнес-тренер, фасилитатор в гештальт-подходе.

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

📣 Регистрация на эфир 16 сентября

Как прогнозировать сроки без гаданий?

Вы наверняка замечали, что прогноз погоды не утверждает, что будет дождь, а говорит, что вероятность осадков 70%. Американская метеослужба перешла на такие прогнозы в 1965-м, а до этого публиковала всего одно слово: дождь или ясно.

При определении сроков многие до сих пор руководствуются методами из 1964-ого, отвечая только "дождь" или "ясно". Магне Йоргенсен свёл опросы практик оценки в разных компаниях и получил следующее: от 62 до 86% сроков называют экспертным суждением, то есть, холодный расчёт остаётся в меньшинстве, уступая наитию, прошлому опыту, либо конкретному дедлайну.

Есть ещё более-менее наукообразный способ —по среднему, но он очень коварный. Скажем, за квартал команда закрыла сто задач: 60 за 5 дней, 25 за 12, 10 за 25 и 5 за 45 дней, соответственно. Средний срок выполнения задачи — 11 дней, только в эти 11 дней не уложились сорок задач из ста, а половина закрылись за пять. Среднее сильно увеличили те пятнадцать штук, что шли дольше всех и быть валидным оно перестало.

Ещё добавим к этому буфер (запас, который накидывают к оценке), чтобы перестраховаться, умножим 11 на два и обозначим заказчику срок в 22 дня, ведь в 22 дня действительно укладываются 85 задач из ста.

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

На самом деле, для более точного определения сроков считать почти ничего не надо. Всего лишь отсортировать задачи от быстрых к медленным и посмотреть три из них. 50-я идёт 5 дней, так выглядит обычная задача, 85-я идёт 12 дней: в этот срок мы попадаем в 85 случаях из ста. 95-я — 25 дней, это почти гарантия.

При таком раскладе можно назвать заказчику два числа: срок и вероятность. За 12 дней закрываем в 85 случаях из ста, но если нужно надёжнее, тогда срок 25 дней. Он выбирает сам, так же как вы сами решаете, брать ли зонт при вероятности 50% дождя.

Выбранная пара чисел называется SLE (Service Level Expectation). Дальше команда замеряет сроки по ней: сколько задач за месяц уложилось в обещанные 12 дней. Если заметно меньше 85, то в процессе что-то изменилось и обещание пора пересматривать.

🗓 22 сентября в 19:00 Александр Рыжков, тренер Scrum и Kanban в ScrumTrek, покажет на бесплатном вебинаре, как собрать такой прогноз, оперируя данными: lead time, throughput, перцентили и SLE.

Зарегистрироваться на бесплатный вебинар «Как прогнозировать сроки без гаданий»

История одного маленького сообщества, которое смогло!
 
В середине 2010-х российский ИТ-рынок переживал бум гибких методологий. Компании массово внедряли Agile, команды бежали быстро, фичи поставлялись ежедневно. Однако возник побочный эффект: за скоростью процессов не всегда поспевала техническая база. Системы становились сложнее, монолиты начали рассыпаться на сотни микросервисов, а цена архитектурной ошибки выросла до миллионов.
 
На рынке существовало множество конференций для разработчиков (про конкретные языки) и для менеджеров (про процессы), но архитекторы — люди, которые стоят на стыке бизнеса и технологий — чувствовали себя «бездомными». Им не хватало площадки для обсуждения высокоуровневого проектирования.
 
Так появилась первая ArchDays - классический пример того, как профессиональное сообщество перерастает рамки «просто обсуждений» и создает свою собственную конференцию.
 
В последние годы ArchDays окончательно закрепила за собой статус главной архитектурной площадки страны (да, мы не самые скромные люди). Повестка стала еще глубже:
1. От микросервисов к здравому смыслу: Стали чаще обсуждать, когда микросервисы не нужны и как правильно нарезать границы контекстов.
2. DevSecOps и Platform Engineering: Архитектура стала рассматриваться не как «рисунок на бумаге», а как живая среда и инфраструктура.
3. Импортозамещение и суверенитет: После 2022 года конференция стала важнейшим местом обмена опытом по миграции с западных облачных решений и СУБД на альтернативные стеки.
 
27 ноября 2026 года мы встретимся вновь. Первые спикеры уже на сайте.
 
ПРОДОЛЖЕНИЕ СЛЕДУЕТ….