Agile *

И сразу отвечу на вопрос, зачем это вообще может понадобиться. 

Есть четыре типовых ситуации:

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

2. Участие в due diligence. Ваша компания планирует покупку стороннего бизнеса. Тут аудит нужен для того, чтобы не повестись сходу на красивые продающие слова и не купить кота в мешке. С большой вероятностью, техническая сторона при объединении бизнесов может оказаться в вашей зоне ответственности, и нужно понимать, чем это грозит.

3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.

4. Вы не собираетесь ни на новую работу, ни покупать чей-то бизнес — вам просто кажется, что у вас сейчас на работе что-то идёт не так, и вы хотите всё оценить и понять, что именно.

В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.

Всем привет! Меня зовут Марина Гончарова, и я IT-проджект-менеджер в Купере.

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

Именно во второй роли я сейчас работаю в Купере. Легко ли это? Нет, но безумно интересно и драйвово!

В пандемию моя команда из Москвы и Казани переходит на удаленку. Нет больше привычных смолл-токов у кулера, не слышно шума офисной жизни. Даже после снятия ограничений и возможности вернуться в офис, команда остается на удаленке, а география, наоборот, расширяется — теперь к нам присоединились ребята из Питера, Москвы, Калуги, Костромы, Рязани, Казани и Томска. Встречи традиционного ретро перешли в онлайн-формат.

В этой статье расскажу, как превратить ретроспективу в яркое событие, в котором каждый участник может снять стресс, проявить себя и получить положительные эмоции. Посмотрим, как работает каждый этап ретро с точки зрения сплочения команды на примере доски «Вокруг света за одну ретроспективу».

Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.

Привет! Сегодня расскажу про Discovery-процесс в команде. 

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

Что такое Disco? Discovery в первую очередь отвечает на вопросы  и «Что делать?»  и «Надо ли вообще делать?». Delivery -  «Как делать?».

Discovery-команда занимается обоснованием и проработкой инициатив, которые затем попадают в продуктовый бэклог для последующей реализации в Delivery. 

Для запуска с нуля такой команды и их процессов мы используем следующий чек-лист:

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

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

Существует несколько распространённых сценариев, но тот, о котором я хочу поговорить, касается ситуации, когда менеджеры формируются в организациях с жёстким централизованным планированием («роли, основанные на координации»), а затем оказываются на достаточно высокой позиции или в компании с организацией “снизу вверх”, где от них ожидают не координации, а именно лидерства («роли, основанные на лидерстве»).

Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.

Главная мысль статьи: Не подстраивайте Scrum под старую структуру компании. Меняйте структуру компании, используя Scrum как инструмент трансформации. Делайте это постепенно, маленькими шагами, постоянно учась и адаптируясь.

Статья является вольным переводом «Re.Imagine Your Scrum Firm up Your Agility» Гюнтера Верхейена.

Всем привет! Мы сотрудники отдела внедрения мультиязычных систем и сервисов из IT-компании SM Lab: отвечаем за обучение пользователей работе с информационными системами (ИС) группы компаний «Спортмастер». Проще говоря, мы те самые люди, которые находятся между разработчиками, выкатывающими новый функционал, и пользователями, которым с этим функционалом предстоит работать. Обучаем не только сотрудников офисов и магазинов, но и иностранных партнёров ГК «Спортмастер». 

Наша главная цель — помогать людям адаптироваться к новым системам и интерфейсам, будь то продавец Иван из Екатеринбурга или мистер Ли, упаковщик кроссовок на фабрике в Китае. Мы делаем всё, чтобы пользователи не терялись в новом интерфейсе, работали без проблем и ошибок, и всегда знали, на какую кнопку нужно нажать.

Всем привет! Меня зовут Амина Шарифьянова, и сегодня я хочу поделиться опытом трансформации, которая изменила не только подход к работе в нашей команде, но и в целом — наше мышление, отношения внутри команды и взаимодействие с бизнесом.

Сейчас agile-практиками никого не удивишь, все уже давно прочитали практическое руководство (или вы еще нет?:) ) и стремятся выполнять по методичке привычные функции: планировать, разрабатывать, тестировать и далее по циклу. «Но ведь все это мы делали всегда, зачем нам agile?» — с таким возражением пришлось работать больше всего, ведь сроки учитывались и раньше, ценность все понимают и так… При этом, меня не покидало тимлидское чувство что «что‑то не так», разобралась в этом для себя и делюсь с вами.

Гильдия VS воскресный приход: сообщество экспертов, которое решает, а не только играет в Манчкина

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

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

Да и концепция давно получила подтверждение, есть очень интересные современные исследования (MIT 2018, Placci 2019, Banca d'Italia 2022).

Формулировка принципа звучит так:

«В иерархической системе каждый работник поднимается до уровня своей некомпетентности».

Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор». 

Попытки внедрить новые практики, такие как Scrum или Kanban, часто наталкиваются на сопротивление команды, которой комфортно работать в существующем workflow. Иногда проблема усиливается часто меняющимися менеджерами, каждый из которых приносит «волшебную таблетку», оставляя после себя след из никому не понятных артефактов. В результате процессы внедряются поверхностно, лишь создавая видимость изменений. Команда двигает тикеты на Kanban‑доске — значит, у нас «Kanban». Проводятся спринты — значит, у нас «Scrum». Но настоящей ценности такие формальные преобразования не приносят.

Как за год перезапустить онлайн-банк для бизнеса, влюбить в него клиентов и повысить продажи. Опыт продакт-лида 

Привет! Меня зовут Альберт Геворкян, я Product Lead в МТС Финтех. Здесь поделюсь опытом, как за время моей работы радикально обновился онлайн‑банк для бизнеса, доля продаж через платформу выросла на 25 п.п., а удовлетворённость клиентов — на 50%.

Агентные ИИ-системы обещают ускорить разработку, но ускоряют только там, где уже налажен быстрый поток поставки: автономные продуктовые команды, короткие циклы, непрерывная обратная связь. Реальность же прозаична: по DORA многие организации релизят реже раза в неделю, у четверти change failure rate доходит до 40%, а инциденты чинятся неделями.

В статье разбираемся, почему без «взрослого» Agile и DevOps ИИ-агенты всего лишь делают узкие места заметнее, и как организационная агентность (право и способность команд действовать) становится предпосылкой для реальной выгоды от ИИ.

Привет! Меня зовут Мария Белых, я занимаюсь управлением изменениями более 10 лет.

Последние 5 лет я работаю в SM Lab и в роли методолога продуктового подхода и помогаю ИТ-командам повышать пропускную способность, сокращать время выполнения задач и избавляться от ложной нагрузки. Применяю канбан-метод, фасилитацию и командный коучинг. 

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

Ты думаешь, что в IT достаточно быть сильным специалистом? Ошибаешься. Работодатели ждут от тебя гораздо большего, и часто об этом не говорят прямо.

Agile-методологии, основанные на манифесте 2001 года, стали краеугольным камнем современной разработки программного обеспечения (ПО) благодаря своей гибкости, ориентации на клиента и способности адаптироваться к изменениям. В России, где IT-сектор демонстрирует устойчивый рост Agile остается доминирующей парадигмой. Однако экономические вызовы, включая санкции, импортозамещение и нестабильность (инфляция 6,2% в апреле 2025), а также технологические сдвиги, такие как интеграция искусственного интеллекта (AI) и DevOps, порождают вопросы о будущем Agile. Действительно ли принципы Agile теряют популярность в российской разработке ПО? Если да, то что приходит на замену?

Российский IT-сектор уникален: он сочетает стремительный рост (CAGR 12% в разработке ПО) с ограничениями. Это стимулирует переход к локальным аналогам и гибридным методологиям. В то же время глобальные тренды, такие как автоматизация через AI и рост DevOps влияют на локальную практику. В этом контексте важно понять, сохраняет ли Agile свою актуальность или уступает место новым подходам, и как российские компании адаптируются к этим изменениям.

В этой статье я делюсь своим решением оптимизации подготовки к ежедневным командным встречам Daily Scrum. Я рассказываю о практических подходах к систематизации задач и автоматизации процессов с помощью собственного плагина для Obsidian.

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

Если вам важно сделать процесс Agile-встреч удобным и результативным, моя статья предложит простой и проверенный путь к этому.