Agile *

Как мы сегодня измеряем работу разработчиков: 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.

Меня зовут Дианова Анастасия, я — Lead Delivery Manager в Lenta Tech («Группа Лента»). Я отвечаю за скорость поставки новых фич в приложение для заказа продуктов онлайн. В статье расскажу, как мы переосмыслили роль Delivery Manager’а, когда столкнулись с жесткими ограничениями.

Меня зовут Вероника. Я технический проджект-менеджер в финтехе и мама троих детей: студентки, школьницы и детсадовца. Когда люди узнают оба этих факта, обычно задают два вопроса: “Как ты всё успеваешь?” и “Ты вообще спишь?”

На оба вопроса у меня один ответ — все дело в процессах, детка.

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

1. Битва с тенью: миф о «Водопаде»

Главный антагонист Agile — «Водопадная модель» (Waterfall) — в реальности никогда не существовал как общепринятая инженерная практика. Уинстон Ройс в своей статье 1970 года привел линейную схему как пример того, как делать не надо, сразу же предложив итерации и обратную связь.

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

Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.

Привет, Хабр! На связи Наталья Воронько из РТЛабс. Я RTE Аналитической Платформы и ЕЛК, а в прошлом — руководитель проектов и функциональный руководитель. Сегодня хочу поделиться своим взглядом на новую редакцию PMBOK® Guide от Project Management Institute (PMI).

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

Официального русского перевода PMBOK® Guide 8^th edition у меня нет. Я читала английскую версию, поэтому некоторые термины могут отличаться от будущего официального перевода. Для точности буду указывать в скобках оригинальные названия и термины.

Ссылки на информацию о Стандарте и на другие источники института PMI буду прикладывать, но открываются они только с помощью VPN.

Под моей прошлой статьей про КТЗ – коэффициент токсичности задачи (вот она) – был комментарий, на который я сначала не обратил особого внимания. Смысл такой: все, что вы описываете – это результат некачественной работы аналитика и руководителя. Их работу свалили на программиста и назвали методом.

Неприятнее всего, что человек прав. Фиксируй договоренности, проверяй готовность задачи, не отменяй проработку требований, возвращай сырое заказчику – это азбука ремесла. Этому учат на любом курсе по управлению. Любой аналитик с опытом прочитает и скажет: спасибо, кэп.

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

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

Все методологии управления проектами думают о процессе. Я попробовал поставить в центр человека — и получил первую версию продукта за 7 недель вместо пяти месяцев. Рассказываю, как.

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

Дело не в количестве регламентов. Небольшая команда может создавать продукт вовсе без них, а папка в Confluence ещё ни из одного джуна не сделала сеньора.

В ИТ намного важнее компетентность людей, чем наличие дцатого регламента. С работы над компетентностью и стоит начинать.

Об этом сегодня и поговорим 🙂

MS Project в 2026 году превратился в токсичный актив: блокировки, замороженные лицензии, серые схемы оплаты. Но прежде чем бежать, честно: если лицензия бессрочная и проекты не выходят за периметр, можно не дёргаться. А если риски перевесили привычку, разбираем 10 аналогов по классам задач (PPM, SDLC, трекеры), с реальной ценой миграции .mpp и честными минусами каждого, включая наш.

Рассмотрим методологию организации рабочих процессов, основанную на ответственности за результат, в противовес понятиям «рабочего времени», «ритуалов» и прочих весёлых забав