Agile *

Меня зовут Сергей Ладыгин, я делаю Scruma - сервис онлайн-ретроспектив. До собственного инструмента я пару лет вёл ретро в таблицах и на досках общего назначения, и главный вывод из тех лет неудобный: ретро чаще всего умирает от рутины. Сбор карточек, ручная группировка, подсчёт плюсиков и протокол съедают именно то время, ради которого встреча собиралась. Ниже - зачем ретро вообще нужно (первая треть статьи обходится без моего сервиса), прикидка на пальцах, куда уходит час встречи, и карта «проблема команды и что с ней делает специализированный инструмент».

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

Я хочу поговорить про другое - про глубинные причины неудач во внедрении Agile и конкретные способы наконец-то получить от методологии тот результат, который она способна дать.

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

Эта статья — не про то, что Agile плох. Она про то, как сделать его работающим.

Привет, Хабр! Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.

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

Но все не так просто. В статье разберу, почему трекер экрана показывает только присутствие, какие метрики показывают реальный результат — и что с ними делает закон Гудхарта.

У меня был iPhone и ноутбук на Windows, а хранилище Obsidian лежало в iCloud. Работаешь себе, всё нормально, и в какой-то момент заметка, которую ты правил, превращается в 10 копий с номерами в именах. Что-то потыкал, вроде исправилось. Несколько дней тишина, потом то же самое. А когда я наконец заглянул в служебную папку, там лежали сотни копий одного файла workspace.json: он размножался активнее всего, просто на глаза не попадался.

Кончилось тем, что я перешёл на технику Apple целиком. Я и так к этому шёл, но история с копиями решение заметно ускорила.

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

В наши дни рынок корпоративного ПО переживает фундаментальную трансформацию. На мой взгляд, происходит то же самое, что мы уже наблюдали на рынке элитной недвижимости: если десять лет назад предприниматели сравнивали «квадратные метры», то сейчас большую роль играют комфорт и окружение. В этом посте поговорим о том, как меняется психология выбора B2B-решений и почему на первый план выходят «тихая роскошь» и когнитивная приватность, почему заказчиков все меньше интересуют интерфейсы, а истинной ценностью становится операционная тишина. Желающих подискутировать на эту тему приглашаю под кат. 

Под моей прошлой статьёй (про Scrum, который натягивают на всё подряд) читатель описал ситуацию, от которой у меня знакомо заныло под ложечкой. Пересказываю по памяти и анонимно: «У нас под предлогом адаптации отвалились оценки и демо. Команда называет это гибкостью. И теперь нечем показать бизнесу, что разработка вообще работает».

Если убрать эмоции, это самый частый вопрос, который я слышу после «какой фреймворк выбрать»: чем доказывать, что разработка работает, когда привычную витрину (оценки, графики сгорания, демо) разобрали? Я тогда пообещал в комментариях, что следующая статья будет об этом. Выполняю.

И сразу договоримся на берегу, чтобы не было ложных ожиданий. Это не манифест «долой story points». Скорее наоборот: я story points люблю, пользуюсь ими и на нескольких местах работы сам же их и внедрял. Но люблю я их как инструмент с понятной задачей, а не как подорожник, который прикладывают к любой ране в надежде, что само заживёт. Разговор впереди вообще не про оценки. Он про прозрачность: что видит бизнес, когда смотрит на вашу разработку. И почему «мы стали гибкими» так часто на деле означает «нас теперь не видно».

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

Почему Scrum не исчез, но многие привычные процессы уже никогда не будут прежними.

Искусственный интеллект не отменил Agile, но заметно изменил привычные процессы внутри продуктовых команд. Многие задачи, которые еще недавно занимали часы, сегодня выполняются за минуты: подготовка к Scrum-встречам, написание User Stories, планирование спринта, ведение протоколов, анализ результатов и работа с документацией. В этой статье я расскажу, как AI трансформировал мою повседневную работу Product Manager, какие Agile-практики изменились сильнее всего и почему роль человека в команде стала не менее, а даже более важной. Статья основана на личном опыте использования AI в разработке цифровых продуктов и будет полезна Product Manager, Project Manager, Scrum Master и всем, кто работает в Agile-командах.

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

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

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

Вторая — про сам кейс. Он тяжёлый. Спринт вдвое больше собственного лимита, треть незавершёнки без движения месяцами, задачи с семнадцатью сменами исполнителя. Нормальным этот проект не был, и типичным я его не выдаю. Полезен он ровно этим: в здоровой команде все описанные ниже эффекты тоже есть, но дают процентов пять и потому не видны. Здесь они дают триста и становятся различимы. Это стенд, а не образец, и интересен тут метод, а не кейс.

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

Несколько лет назад мой рабочий день выглядел вполне типично для Product Manager: исследования рынка, анализ конкурентов, интервью с пользователями, подготовка требований к продукту, приоритизация бэклога, подготовка релизов, аналитика после запуска, анализ обратной связи пользователей и прочее. При этом большую часть моего рабочего времени занимало не принятие решений, а подготовка информации для них.

С появлением современных AI-инструментов изменилось не то, что делает Product Manager, а как он это делает.

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

Вот мои семь задач, для реализации которых я прибегаю к помощи AI.

Показываю как Projex работает на реальном проекте: разработка ПО, закупка железа, сборка и пусконаладка. Планирование, КТ, блокеры с примерами.

Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта.

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка.

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

Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов.

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

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

Я Наташа, менеджер проектов в Selectel. Уже дважды я выносила спринты из команд ногами вперед, и хочу поделиться этим опытом с теми, кто ищет предсказуемости и результативности в сложных технических продуктах.

AI уже вошёл в работу IT- команд. Доступы выдали, обучение провели, демо показали, и как будто активность в инструментах растёт. А Lead Time (время от взятия обязательств до прода), Throughput (сколько работы команда делает) меняются гораздо медленнее. Иногда не меняются вообще.

Сопротивление AI в такой ситуации полезно читать как диагностику системы. Оно показывает место, где команда ещё не договорилась: про цель, инструмент, ответственность, безопасность или поток работы.

Привет! Я Владимир Крылов, продуктовый дизайнер и тимлид. В этой статье я поделюсь опытом проведения ретроспектив по методологии Squad Health Check, придуманной в Spotify. Расскажу, почему нам не подошел стандартный формат ретроспектив, в чём суть метода, какие темы для анализа проблем мы выбрали и к каким результатам в итоге пришли.

Привет, Хабр! Меня зовут Аркадий Озеров, менеджер в ИТ-команде Россельхозбанка, и я продолжаю делится историей роста своей команды. Мы выросли с 7 до 25 человек, а я продолжал управлять так же, как раньше. И это превратилось в проблему.  Как не утонуть в хаосе при росте команды в 4 раза? 

За последние десятилетия у компаний появился внушительный набор управленческих инструментов. Waterfall, Scrum, Kanban, SAFe — каждый описан, стандартизирован, проверен на тысячах внедрений.

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

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

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

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

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

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

Этот материал – не стандартный кейс формата «мы запилили продукт, хвала нам». Это двухтомный производственный триллер о том, как построить цифровой космолет внутри панциря Левиафана. Как обеспечить безопасность команды, выстроить железобетонную стену по периметру и не поехать при этом «кукухой». Когда ты помещаешь живую инновацию в жернова госкорпорации, ты либо становишься жертвой системы, либо учишься управлять гравитацией.

Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов, которые спасали наши задницы от бесконечных правок.

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

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье расскажу, какие гипотезы мы проверяли при внедрении ИИ, почему рост использования чатов и кодинг-агентов не равен росту скорости, какие метрики помогали отделять привычку от результата и как мы пришли к идее Agentic Engineering.