Agile, Scrum, Kanban: как разработчик чувствует разницу

В программировании мы привыкли обсуждать синтаксис, алгоритмы и оптимизацию кода. Но фундамент, на котором строится вся разработка, — это процесс. Термины Agile, Scrum и Kanban звучат на каждом собеседовании, в учебных курсах их называют обязательными для современного специалиста. Однако что они меняют лично для вас? Как меняется рабочая реальность, когда команда переходит от хаотичной «палочной» разработки к структурированному процессу?

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

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

Agile: философия, которая меняет отношение к разработке

Когда говорят «мы работаем в Agile», многие сразу представляют спринты, Jira и ежедневные планёрки. Но Agile (от английского agile — лёгкий, подвижный, гибкий) — это не конкретная методика, а набор принципов, описанных в Agile Manifesto (2001). Это философия, которая ставит в центр не процесс, а человека и результат.

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

Ключевые принципы Agile для разработчика

Вот как основные принципы Agile проявляются в ежедневной работе:

1. Люди и взаимодействие важнее процессов и инструментов.
   • Как это чувствует разработчик: Вместо того чтобы просто «закрыть задачу в тикете», вы начинаете больше общаться. Обсуждаете код с коллегами, спрашиваете, почему задача не делается, помогаете новичку. Инструменты (Jira, GitLab) становятся лишь средством коммуникации, а не целью.
   • Практический пример: В старой модели вы могли молча писать код, пока не наступит дедлайн. В Agile вы сразу идёте к тимлиду, если видите проблему, и вместе решаете, как её обойти. Я не раз наблюдал, как такой подход предотвращал катастрофы за день до релиза.
2. Работающий продукт важнее исчерпывающей документации.
   • Как это чувствует разработчик: Вам не нужно писать 50 страниц документации перед началом кода. Вы делаете минимально жизнеспособный продукт (MVP), который можно показать заказчику. Это даёт быструю обратную связь.
   • Практический пример: Вы не пишете весь модуль авторизации сразу. Делаете простую версию, которая проверяет пароль, и сразу показываете её. Заказчик говорит: «А давайте добавим вход через Google». Вы меняете код, а не перепечатываете документацию. В одном проекте мы так за две недели собрали работающую админку, хотя по первоначальному плану ушло бы два месяца только на спецификацию.
3. Вовлечение заказчика важнее согласования условий контракта.
   • Как это чувствует разработчик: Заказчик (или продукт-оунер) становится частью команды. Он не приходит раз в месяц, чтобы сказать «всё плохо», а участвует в обсуждениях, даёт идеи, корректирует приоритеты.
   • Практический пример: Вы не пишете код в темноте. Показываете заказчику прототип каждую неделю. Если он меняет требования, вы не бросаете работу, а адаптируетесь. В моей практике был случай, когда заказчик на еженедельном демо понял, что одна из фич не нужна, и мы сразу переключились на более важную задачу, не потратив ни дня впустую.
4. Реакция на изменения важнее следования плану.
   • Как это чувствует разработчик: План — это не догма. Если рынок изменился или заказчик понял, что функция не нужна, вы меняете план. Это снижает стресс, потому что вы не «должны» делать то, что уже не нужно.
   • Практический пример: Вы начали писать сложную функцию, но заказчик сказал: «Мы это не будем использовать, давайте сделаем проще». Вы не чувствуете себя неудачником, вы просто меняете направление. Это особенно важно для джуниоров: они перестают воспринимать изменения как провал и учатся гибкости.

Agile vs. Традиционная разработка (Waterfall)

Чтобы понять разницу, сравним Agile с традиционной моделью (Waterfall), с которой многие сталкиваются в учебных проектах или на старых предприятиях.

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

Почему Agile важен для карьеры разработчика?

В современной IT-индустрии Agile стал стандартом. Компании, работающие по Waterfall, теряют конкурентоспособность, потому что не успевают реагировать на изменения рынка.

• Для джуниора: Agile даёт возможность быстро учиться. Вы не пишете код в вакууме, вы сразу видите, как он работает, и получаете критику. Я часто советую новичкам искать команды с настоящим Agile — там они растут в разы быстрее.
• Для миддла: Agile позволяет влиять на продукт. Вы не просто «закрыли задачу», вы участвовали в обсуждении, предлагали решения. Это развивает системное мышление.
• Для сеньора/тимлида: Agile — это инструмент управления рисками. Вы можете быстро перенаправить ресурсы, если что-то идёт не так. Я не раз спасал проекты, просто вовремя меняя приоритеты на основе обратной связи.

Типичные ошибки при переходе к Agile

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

1. «Мы делаем Agile, но без спринтов».
   • Ошибка: Команда говорит, что работает в Agile, но не вводит никаких границ времени. Это приводит к хаосу, задачи не закрываются, приоритеты меняются каждый час.
   • Как исправить: Agile требует структуры. Даже если вы не используете спринты, вы должны иметь чёткие периоды планирования и оценки. В одной команде мы ввели хотя бы недельные циклы, и это сразу снизило хаос.
2. «Документация не нужна, мы всё в голове».
   • Ошибка: Разработчики забывают, что Agile требует минимальной документации, а не полного отказа от неё. Без документации код становится нечитаемым, а новые сотрудники не могут понять систему.
   • Как исправить: Пишите документацию, но только ту, которая нужна для работы. Обновляйте её по ходу. Я обычно держу в README ключевые архитектурные решения и инструкции по развёртыванию — этого хватает.
3. «Заказчик не участвует, мы делаем всё сами».
   • Ошибка: Если заказчик не участвует в процессе, Agile превращается в «свободную» разработку, где вы не знаете, что нужно.
   • Как исправить: Найдите продукт-оунера, который будет отвечать за требования. Если его нет, создайте его роль внутри команды. Я был в проекте, где мы сами стали «голосом заказчика», собирая обратную связь через опросы пользователей.
4. «Мы не тестируем, потому что Agile».
   • Ошибка: Agile не означает, что можно не тестировать. Наоборот, в Agile тестирование должно быть автоматизированным и непрерывным.
   • Как исправить: Внедрите CI/CD, автоматические тесты. Тестирование — часть процесса, а не отдельный этап. Я всегда настраиваю пайплайн так, чтобы при каждом коммите прогонялись линтеры и юнит-тесты — это спасает от регрессий.

Scrum: спринты, роли и жесткая структура

Scrum — самая популярная реализация философии Agile. Если Agile — это философия, то Scrum — конкретный метод с чёткими правилами, ролями и процессами. Для разработчика переход к Scrum означает жизнь в «спринтах» — коротких, фиксированных периодах работы (обычно 2 недели).

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

Роли в Scrum: кто вы и кто ваши коллеги

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

1. Product Owner (Владелец продукта)
   • Что делает: Определяет, что нужно делать. Отвечает за ценность продукта, приоритеты задач и требования.
   • Как с ним взаимодействует разработчик: Вы получаете от него задачи (User Stories). Спрашиваете: «Что именно нужно сделать?», «Какой результат мы хотим?». Он не пишет код, но даёт направление.
   • Пример: Product Owner говорит: «Нам нужна кнопка входа через Google, чтобы пользователи могли быстрее регистрироваться». Вы не спрашиваете «как сделать», вы спрашиваете «какие данные нужны от Google».
2. Scrum Master (Мастер процесса)
   • Что делает: Отвечает за процесс. Помогает команде работать эффективно, убирает барьеры, организует встречи, следит, чтобы правила Scrum соблюдались.
   • Как с ним взаимодействует разработчик: Вы идёте к нему, если у вас проблемы с процессом. Например, если спринт не закрывается, или если вы не знаете, как организовать работу. Он не пишет код, но делает так, чтобы вы могли писать код без помех.
   • Пример: Вы не можете зайти в Git, потому что сервер сломан. Вы идёте к Scrum Master, и он решает проблему. В моей практике хороший Scrum Master однажды за час разрулил проблему с доступом к staging-серверу, которая тормозила всю команду.
3. Developers (Разработчики)
   • Что делает: Пишет код, тестирует, создаёт продукт. Это вы. В Scrum вы — самоорганизующаяся команда. Вы сами решаете, как выполнить задачи.
   • Как вы работаете: Вы не получаете задачи от менеджера. Вы сами выбираете задачи из списка (Sprint Backlog) и договариваетесь, кто их будет делать. Вы ответственны за результат спринта.

Процесс Scrum: как работает спринт

Scrum работает циклично. Каждый цикл — это спринт. Вот как выглядит процесс для разработчика:

1. Sprint Planning (Планирование спринта)
   • Что происходит: Команда (разработчики + Product Owner) собирается, чтобы выбрать задачи из общего списка (Product Backlog) для следующего спринта.
   • Как это чувствует разработчик: Вы смотрите на список задач, оцениваете их сложность (в часах или в «точках»), и договариваетесь, сколько вы сможете сделать. Вы не просто «записываетесь» на задачу, вы сами выбираете её.
   • Ключевой момент: Вы не планируете весь проект. Вы планируете только следующие 2 недели. Я всегда советую на planning poker использовать story points, а не часы — это снижает давление и учитывает неопределённость.
2. Sprint (Спринт)
   • Что происходит: Вы работаете 2 недели. В это время вы пишете код, тестируете, интегрируете.
   • Как это чувствует разработчик: Вы работаете в режиме «фокус». Приоритеты не меняются. Вы не можете добавить новые задачи, если они не были запланированы. Это даёт стабильность.
   • Ключевой момент: В спринте вы не меняете приоритеты. Если Product Owner хочет добавить новую задачу, он должен ждать следующего спринта. Это дисциплинирует и заказчика, и команду.
3. Daily Scrum (Ежедневная планерка)
   • Что происходит: 15 минут в день, вся команда собирается, чтобы обсудить, что сделано, что будет сделано и какие есть проблемы.
   • Как это чувствует разработчик: Вы говорите: «Сегодня я сделаю кнопку входа, вчера я сделал проверку пароля, у меня проблема с доступом к API». Это не отчёт для начальника, это синхронизация с коллегами.
   • Ключевой момент: Вы не должны рассказывать всё. Только то, что нужно для работы. Если кто-то начинает углубляться в детали, Scrum Master мягко возвращает фокус.
4. Sprint Review (Оценка спринта)
   • Что происходит: В конце спринта вы показываете Product Owner и другим заинтересованным лицам, что сделали. Вы демонстрируете работающий продукт.
   • Как это чувствует разработчик: Вы не просто «закрыли задачу», вы показали результат. Product Owner говорит: «Это хорошо, но давайте добавим ещё функцию». Вы получаете обратную связь.
   • Ключевой момент: Вы не просто «сделали», вы показали. Это даёт уверенность, что вы движетесь в нужном направлении. Я всегда готовлю демо так, чтобы оно было интерактивным — заказчик может «потыкать» прототип и сразу дать фидбек.
5. Sprint Retrospective (Ретроспектива спринта)
   • Что происходит: Команда обсуждает, как прошла работа. Что было хорошо, что было плохо, что нужно улучшить.
   • Как это чувствует разработчик: Вы говорите: «Мы не успели, потому что тесты были медленные», «Мы не договаривались, кто делает задачу». Вы вместе решаете, как улучшить процесс.
   • Ключевой момент: Вы не просто «работаете», вы учитесь. Вы меняете процесс, чтобы в следующий спринт работать лучше. Однажды на ретроспективе мы решили внедрить парные код-ревью, и качество кода выросло в разы.

Как разработчик чувствует Scrum: плюсы и минусы

Плюсы:

• Стабильность: Вы знаете, что будете делать в следующие 2 недели. Приоритеты не меняются.
• Быстрая обратная связь: Вы видите результат каждые 2 недели. Это снижает риск сделать что-то не нужное.
• Самоорганизация: Вы сами выбираете задачи. Это даёт чувство контроля и ответственности.
• Командная работа: Вы не работаете в одиночку. Вы общаетесь с коллегами, решаете проблемы вместе.

Минусы:

• Жёсткость: Вы не можете добавить новые задачи в спринт. Если Product Owner хочет что-то новое, он должен ждать.
• Ритуалы: Ежедневные планерки, ретроспективы, оценки — это много времени. Если команда не умеет работать эффективно, это может стать бюрократией.
• Давление: В спринте вы должны сделать всё. Если не успели, вы чувствуете стресс.

Типичные ошибки в Scrum для разработчиков

1. «Я не могу выбрать задачу, мне её дают».
   • Ошибка: В Scrum разработчики сами выбирают задачи. Если вам дают задачу, это не Scrum.
   • Как исправить: На планировании вы сами выбираете задачи. Если вы не можете выбрать, спросите Scrum Master.
2. «Я не успеваю, я добавлю задачу в спринт».
   • Ошибка: В спринт нельзя добавлять новые задачи. Это нарушает правила.
   • Как исправить: Если вы не успели, вы не добавляете задачу. Вы обсуждаете это на ретроспективе и меняете процесс.
3. «Я не знаю, что делать, я жду, пока мне скажут».
   • Ошибка: В Scrum вы сами решаете, как выполнить задачу. Вы не должны ждать.
   • Как исправить: Если вы не знаете, спросите коллегу или Product Owner. Не ждите.
4. «Я не тестирую, я только пишу код».
   • Ошибка: В Scrum разработчики тестируют свой код. Тестирование — часть процесса.
   • Как исправить: Пишите тесты, автоматизируйте их. Тестирование — это не отдельный этап, это часть работы.

Kanban: непрерывный поток и визуализация

Kanban — вторая популярная реализация Agile, но работает она совершенно иначе. Если Scrum — это жизнь в спринтах, то Kanban — это жизнь в непрерывном потоке. Kanban (от японского kan — визуальный, ban — карточка) — метод, который фокусируется на визуализации работы, ограничении количества задач в процессе и непрерывном улучшении потока.

Для разработчика Kanban означает отсутствие жёстких границ времени. Вы не работаете в спринтах, вы работаете в потоке. Задачи приходят, вы их выполняете, и они уходят. Нет дедлайнов в виде «спринта», есть только дедлайны для отдельных задач. Я впервые применил Kanban в команде поддержки, где тикеты сыпались непрерывно, и спринты только мешали. Мы повесили доску, ввели WIP-лимиты, и хаос превратился в управляемый поток.

Ключевые принципы Kanban для разработчика

1. Визуализация работы.
   • Как это чувствует разработчик: Вы видите все задачи на одной доске (Kanban Board). Каждая задача — это карточка. Вы видите, где задача находится: в ожидании, в работе, в тестировании, в завершении.
   • Практический пример: На доске вы видите: «Задача 1: в работе», «Задача 2: в тестировании», «Задача 3: в ожидании». Вы сразу видите, где есть проблемы. У нас доска висела на большом мониторе, и каждый мог мгновенно оценить загрузку.
2. Ограничение количества задач в процессе (WIP Limits).
   • Как это чувствует разработчик: Вы не можете взять на себя больше задач, чем разрешено. Например, в столбике «В работе» может быть только 3 задачи. Если вы уже взяли 3, вы не можете взять 4.
   • Практический пример: Вы хотите взять новую задачу, но в столбике «В работе» уже 3. Вы не можете взять её. Вы должны сначала завершить одну из текущих.
   • Ключевой момент: Это предотвращает многозадачность и перегрузку. Вы фокусируетесь на одной задаче. Когда мы впервые ввели лимит в 2 задачи на разработчика, скорость выполнения выросла на 30%.
3. Управление потоком.
   • Как это чувствует разработчик: Вы не просто «делаете задачи», вы управляете потоком. Вы видите, где задача «застряла», и вы помогаете ей двигаться.
   • Практический пример: Вы видите, что задача в столбике «Тестирование» застряла. Вы идёте к тестировщику и спрашиваете: «Что нужно, чтобы задача прошла?». Вы не просто «делаете», вы «управляетесь».
4. Открытость к изменениям.
   • Как это чувствует разработчик: Вы можете добавить новую задачу в любой момент. Нет спринта, нет дедлайна. Вы просто добавляете задачу в список «В ожидании».
   • Практический пример: Product Owner говорит: «Нам нужна новая функция». Вы добавляете её в список «В ожидании». Вы не должны ждать спринта.
5. Постоянное улучшение.
   • Как это чувствует разработчик: Вы постоянно анализируете поток. Вы видите, где есть проблемы, и вы меняете процесс.
   • Практический пример: Вы видите, что задачи долго застряли в «Тестировании». Вы меняете процесс: добавляете больше тестировщиков, или вы меняете правила тестирования. Мы, например, внедрили автоматические smoke-тесты, и время в столбце «Тестирование» сократилось вдвое.

Процесс Kanban: как работает поток

В Kanban нет спринтов. Процесс работает непрерывно. Вот как выглядит процесс для разработчика:

1. Задача появляется.
   • Что происходит: Product Owner или другой человек добавляет задачу в список «В ожидании».
   • Как это чувствует разработчик: Вы видите новую задачу на доске. Вы не должны ждать спринта. Вы просто видите, что задача появилась.
2. Вы выбираете задачу.
   • Что происходит: Вы берёте задачу из списка «В ожидании» и перемещаете её в «В работе».
   • Как это чувствует разработчик: Вы не должны ждать, пока вам дадут задачу. Вы сами выбираете задачу. Но вы должны убедиться, что в «В работе» не больше задач, чем разрешено.
3. Вы выполняете задачу.
   • Что происходит: Вы пишете код, тестируете, интегрируете.
   • Как это чувствует разработчик: Вы фокусируетесь на одной задаче. Вы не переключаетесь между задачами. Вы завершаете задачу, и только потом берёте новую.
4. Вы перемещаете задачу.
   • Что происходит: Вы перемещаете задачу в «Тестирование», затем в «Завершение».
   • Как это чувствует разработчик: Вы видите, как задача движется. Вы не просто «делаете», вы «управляетесь».
5. Вы анализируете поток.
   • Что происходит: Вы смотрите на доску, видите, где задачи застряли, и вы меняете процесс.
   • Как это чувствует разработчик: Вы не просто «делаете», вы «учитесь». Вы меняете процесс, чтобы в следующий раз работать лучше.

Как разработчик чувствует Kanban: плюсы и минусы

Плюсы:

• Гибкость: Вы можете добавить новую задачу в любой момент. Нет спринта, нет дедлайна.
• Фокус: Вы фокусируетесь на одной задаче. Вы не переключаетесь между задачами.
• Визуализация: Вы видите все задачи на одной доске. Вы сразу видите, где есть проблемы.
• Отсутствие давления: Вы не должны сделать всё в спринт. Вы просто делаете задачи, пока они есть.

Минусы:

• Нет дедлайнов: Вы не знаете, когда задача будет завершена. Это может привести к стрессу, если задача долго не завершается.
• Нет самоорганизации: Вы не выбираете задачи, как в Scrum. Вы просто берёте задачу, которая есть. Хотя это зависит от реализации: в зрелом Kanban команда сама решает, что брать из бэклога.
• Многозадачность: Если вы не ограничите количество задач в процессе, вы можете начать работать на нескольких задачах одновременно. Это снижает качество.

Типичные ошибки в Kanban для разработчиков

1. «Я беру на себя много задач, я не могу ограничить».
   • Ошибка: В Kanban вы должны ограничить количество задач в процессе. Если вы берёте на себя много задач, вы не можете завершить их.
   • Как исправить: Ограничите количество задач в «В работе». Если вы уже взяли 3, не берите 4. Я обычно ставлю лимит 2, и это дисциплинирует.
2. «Я не вижу, где задача застряла».
   • Ошибка: Вы не видите, где задача застряла. Вы не можете управлять потоком.
   • Как исправить: Используйте доску Kanban. Вы должны видеть, где задача застряла. Цифровая доска в Jira или Trello с настроенными колонками решает эту проблему.
3. «Я не анализирую поток».
   • Ошибка: Вы не анализируете поток. Вы не меняете процесс.
   • Как исправить: Анализируйте поток. Вы должны видеть, где задачи застряли, и вы должны менять процесс. Раз в неделю смотрите на кумулятивную диаграмму потока (CFD) — она покажет узкие места.
4. «Я не тестирую, я только пишу код».
   • Ошибка: В Kanban вы должны тестировать свой код. Тестирование — часть процесса.
   • Как исправить: Пишите тесты, автоматизируйте их. Тестирование — это не отдельный этап, это часть работы.

Сравнение Scrum и Kanban: что выбрать разработчику?

Scrum и Kanban — два разных подхода к реализации Agile. У них разные цели, процессы и роли. Для разработчика выбор между ними зависит от типа проекта, команды и личных предпочтений.

Ключевые различия

Когда выбрать Scrum?

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

Когда выбрать Kanban?

• Проект с постоянным потоком задач. Если проект имеет постоянный поток задач (например, поддержка, исправление ошибок), Kanban подойдёт.
• Команда, которая не хочет жёстких границ. Если команда не хочет работать в спринтах, Kanban подойдёт.
• Проект, где нужно быстро реагировать на изменения. Если нужно быстро реагировать на изменения, Kanban поможет.

Как разработчик чувствует разницу: личный опыт

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

В Kanban я чувствовал гибкость и свободу. Я мог добавить новую задачу в любой момент. Я не должен ждать спринта. Я фокусировался на одной задаче, и только потом брал новую. Но в Kanban я также чувствовал стресс, если задача долго не завершалась. Я не знал, когда задача будет завершена. Это больше похоже на марафон: нужно уметь распределять силы и не терять темп.

В итоге я понял, что выбор зависит от контекста. Для стартапа с неясными требованиями я бы выбрал Scrum, чтобы быстро проверять гипотезы. Для зрелого продукта с непрерывным потоком улучшений — Kanban. Часто мы комбинировали: Scrum для основной разработки, Kanban для багфиксов и срочных задач.

Что выбрать вам?

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

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

Как разработчик чувствует разницу: практические сценарии

Чтобы понять, как именно меняется ваша рабочая реальность, давайте рассмотрим несколько практических сценариев.

Сценарий 1: Новая задача появляется

В Scrum:

• Вы не можете добавить новую задачу в спринт.
• Product Owner говорит: «Нам нужна новая функция».
• Вы добавляете задачу в список «В ожидании» для следующего спринта.
• Вы не можете начать работу, пока не наступит следующий спринт.

В Kanban:

• Вы можете добавить новую задачу в любой момент.
• Product Owner говорит: «Нам нужна новая функция».
• Вы добавляете задачу в список «В ожидании».
• Вы можете начать работу сразу, если в «В работе» нет ограничений.

Сценарий 2: Задача не завершена

В Scrum:

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

В Kanban:

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

Сценарий 3: Изменение требований

В Scrum:

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

В Kanban:

• Product Owner хочет изменить требования.
• Вы можете изменить требования в любой момент.
• Вы меняете задачу, если она в «В ожидании».
• Вы не должны ждать спринта.

Сценарий 4: Многозадачность

В Scrum:

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

В Kanban:

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

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