Автор: Асхат Уразбаев · Организованное программирование | Кирилл Мокевнин

Асхат Уразбаев — один из наиболее известных Agile-консультантов в России, основатель ScrumTrek, более двадцати лет внедрял Agile в крупнейших российских компаниях. В этом выпуске подкаста «Организованное программирование» (1:53:26) он говорит не о том, как «правильно внедрять Scrum», а о том, что произошло с Agile за двадцать лет — и куда это движение привело.

Центральный вопрос разговора: почему Scrum победил XP? Ответ неочевидный — не потому что лучше технически, а потому что церемонии, роли и сертификации проще продавать. XP требовал технической дисциплины: TDD, парного программирования, непрерывной интеграции. Scrum предлагал процесс, который мог вести не инженер, а специально нанятый Scrum Master. Это решило задачу менеджмента — и убило технические практики.

Кому смотреть: тимлидам и менеджерам, которые работают «по Agile», но чувствуют что что-то не так; разработчикам, которым интересна история методологий — не как мифология, а как реальные организационные и коммерческие решения.

Из этого можно взять в работу: спросить себя — Continuous Delivery в вашей команде есть, или только спринты? По словам Уразбаева, именно отсутствие CD при наличии Scrum-церемоний — самый частый симптом того, что «Agile» внедрён, а ценностей нет.

Автор: Екатерина Давыдова · AvitoTech

Екатерина Давыдова — программный менеджер в Авито, ведёт внутреннюю программу, которая объединяет все GenAI-команды компании. Авито — один из крупнейших классифайдов мира, и в этой связи их опыт выстраивания работу с GenAI отличается от опыта стартапов с «чистым листом».

Доклад начинается с конкретной ситуации: к продуктовой команде приходит CEO и говорит «давайте уже что-нибудь запустим на AI, иначе будет поздно» — и команда не понимает ни где брать идеи, ни какие ресурсы нужны, ни как вообще двигаться. Давыдова прошла через это с десятками команд и рассказывает, что работает на каждом из пяти этапов: от генерации идей до масштабирования.

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

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

Из этого можно взять в работу: WizardOfOz-эксперимент. До того как у вас есть рабочая модель, посадите человека имитировать AI в диалоге с пользователями. Вы начнёте собирать паттерны запросов, проверять первые гипотезы и снимать метрики — не написав ни строчки кода для самой модели.

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

Типичная архитектурная сессия выглядит так: техлид рисует диаграмму, остальные кивают или спорят о деталях реализации. Знание о домене остаётся в головах у бизнес-экспертов и не попадает в код. Event Storming переворачивает процесс: на стену клеятся оранжевые стикеры с доменными событиями («заказ размещён», «платёж подтверждён», «склад уведомлён»), и сразу становится видно, где у команды нет общего языка — кто-то называет одно и то же по-разному, кто-то предполагает событие, которого на самом деле не существует. Пробелы в знании домена вскрываются за часы, а не за месяцы.

Кому смотреть: техлидам и разработчикам, участвующим в проектировании новых фич или рефакторинге сложной предметной области — особенно там, где бизнес-логика плохо формализована.

Из этого можно взять в работу: следующий раз, когда команда пишет задачу на новую фичу, попробуйте перед техническим дизайном провести 30-минутный мини-Event Storming: попросите каждого участника написать 3–5 событий, которые должны произойти в системе. Несоответствия вскроются моментально.

Автор: Кирилл Мокевнин · TechLead Channel

Кирилл Мокевнин — основатель Hexlet, образовательной платформы для разработчиков. Он не просто учит программировать — он годами наблюдает, где люди застревают, и думает о том, чему именно нужно учить. Доклад на TechLead Conf.

Название доклада намеренно отсылает к «Гарри Поттеру и методам рационального мышления» — книге о применении научного мышления к реальным задачам. Мокевнин идёт тем же путём: берёт «Прагматичного программиста» Ханта и Томаса и разбирает, что за этим словом стоит на практике. Вывод неудобный: большинство обучающих материалов учат решать задачи с известным правильным ответом — алгоритмы, паттерны, синтаксис. Реальная работа — это задачи с неизвестным правильным ответом, где нужно выбрать направление при неполных данных, попробовать, получить обратную связь и скорректироваться. Этот навык почти нигде не преподают явно — и именно поэтому технически грамотные разработчики застревают на одном уровне годами.

Ценный угол: Мокевнин смотрит на обучение не теоретически, а через реальные данные — он видит, где именно тысячи студентов Hexlet теряются.

Кому смотреть: разработчикам, которые чувствуют, что технических знаний уже достаточно, но чего-то важного всё равно не хватает — и не могут точно назвать, чего.

Из этого можно взять в работу: найди задачу, которую откладываешь из-за «недостаточно знаю». Запиши письменно, что именно ты не знаешь. Скорее всего обнаружишь, что это не вопрос знаний, а вопрос принятия решения с неполной информацией — а это совсем другая проблема.

Автор: Егор Заплатин · Яндекс Вертикали

Егор Заплатин — фронтенд тимлид в Яндекс Вертикалях (Путешествия, Аренда, Авто.ру). Доклад на Vertis JS 2026: полгода работы с AI-агентами в реальных задачах, выводы о том, что нужно сделать, чтобы они работали предсказуемо.

AI-агент не замещает инженера — он меняет то, на что инженер тратит время. Заплатин это понимает, хотя в докладе использует популярную аналогию «прокачать до мидла» — скорее как метафору для аудитории, а не буквальное сравнение. Содержательная часть, если убрать маркетинговую рамку, прикладная и по делу.

Центральная мысль: если ваш агент работает — это ещё ничего не значит. Надёжная работа в production требует инженерии. Заплатин разбирает четыре конкретные практики: правильно выстроенный контекст (что агент видит и в каком виде), feedback loop (как агент получает сигнал об ошибке и исправляет курс до конца задачи), MCP-интеграции (реальные инструменты вместо угадывания по обучающим данным), и скиллы — описания того, как решать конкретные задачи в конкретной кодовой базе. Примеры из продуктовых и технических задач на реальных проектах. Отдельно — задачи за пределами кода и масштабирование на команду.

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

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

Автор: Александр Макаров · Организованное программирование | Кирилл Мокевнин

Александр Макаров — Lead of Yii Framework, CTO нескольких компаний — пришёл с провокацией: «трофей» вместо «пирамиды тестирования». Идея в том, что классическая пирамида — карго-культ. Она хорошо работает на первом проекте, а потом перестаёт отражать реальную архитектуру системы и реальные риски.

Разговор — про то, где в живых системах проходит граница между юнит-тестом и интеграционным (она нечёткая, и зависит от того, что ты считаешь «единицей»), и почему формальные определения из книг не помогают принимать решения о тест-стратегии. Это дебаты, не лекция — Мокевнин оппонирует, Макаров защищает позицию.

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

Из этого можно взять в работу: вместо того чтобы спорить «юниты или интеграционные» — спроси: что ты называешь «единицей» в своей системе? Ответ важнее любой классификации.

Автор: Сергей Андржеевский · ScrumTrek

Сергей Андржеевский выступал на Ag;)eDays 2011 — одной из ранних российских Agile-конференций. Доклад старый, но вопрос, который он разбирает, не устарел: как работают XP-практики в условиях, когда команда разделена географически и работает на внешнего заказчика.

Офшорный проект — это специфический контекст. Разные часовые пояса, заказчик, который не сидит рядом, контрактная модель, которая создаёт стимулы скрывать проблемы, а не решать их. XP создавался для команды в одной комнате с заказчиком рядом. Андржеевский рассказывает, что из XP работает в офшорном контексте, что требует адаптации, а что — предположение, которое офшор разрушает принципиально. Центральный тезис: парное программирование и TDD в офшорном контексте — это не способ быстро работать, это способ поддерживать качество без прямого контроля. Заказчик не видит код — он видит результат. Дисциплина XP-практик создаёт доверие через предсказуемость результата.

Кому смотреть: тимлидам и менеджерам в распределённых командах, которые хотят понять, какие инженерные практики заменяют «управление через присутствие» в удалённом контексте.

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

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях, объясняет практики разработки коротко и без академической перегруженности. Этот выпуск — девятиминутный обзор Extreme Programming (XP).

Большинство разработчиков знают отдельные XP-практики: TDD, парное программирование, непрерывная интеграция. Многие применяют их в изоляции. Суть XP в том, что эти практики спроектированы как система: TDD даёт быструю обратную связь, парное программирование распределяет знание о коде, CI гарантирует, что интеграция не накапливает долг. Убери одно — другие становятся менее ценными. XP существовал до Agile Manifesto (Кент Бек опубликовал книгу в 1999-м), и многие принципы манифеста 2001 года прямо из него вышли. При этом XP как целостная система встречается в командах гораздо реже, чем Scrum, — хотя технические практики у него сильнее.

Кому смотреть: разработчикам, которые применяют TDD или CI по отдельности и хотят понять, зачем Кент Бек сложил всё это в одну методологию.

Из этого можно взять в работу: выбери две XP-практики, которые ты уже используешь (например, TDD и ревью кода), и попробуй применить их в связке — напиши тест вместе с коллегой до написания кода. Системный эффект виден только в паре.

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях и процессах, объясняет сложные концепции коротко и структурированно. Это видео — обзор Agile: не реклама и не критика, а попытка разобраться, чем Agile является на самом деле.

Большинство команд, которые «работают по Agile», работают по Scrum или Kanban — и это не одно и то же. Agile — это набор ценностей и принципов, сформулированных в Манифесте 2001 года. Он не описывает церемоний, ролей и спринтов. Scrum — это уже конкретный фреймворк, одна из возможных реализаций. Путаница между ними ведёт к тому, что команды «внедряют Agile» через ретроспективы и стендапы, не меняя при этом отношения к изменениям и клиенту — и потом удивляются, почему не работает.

Кому смотреть: разработчикам и тимлидам, которые участвуют в agile-церемониях, но не понимают, зачем они существуют. А также тем, кто слышит «мы agile-команда» и хочет проверить это утверждение на прочность.

Из этого можно взять в работу: спроси на следующей ретроспективе: «Какую ценность из Agile Manifesto мы фактически соблюдаем, а не просто декларируем?» Ответ покажет реальный зазор между заявленной методологией и тем, как команда работает.