Если вы хотя бы пару раз листали вакансии на позицию PM или SM, то наверняка сталкивались с этим: “Обязательное знание методологий: Agile, Scrum, Kanban…”

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

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

И вот теперь: – Agile — если совсем душить, то это манифест, из которого выросла методология; – Scrum — фреймворк, основанный на Agile-принципах; – Канбан — метод управления потоком задач, который может применяться вообще где угодно (даже в бухгалтерии, даже без айтишников).

Это важно потому, что если вы принимаете метод за методологию, вы начинаете от него ожидать лишнего. Вы требуете от Канбана стратегических решений. Ждёте, что Scrum сам решит проблему с неопределённостью требований. И начинаете строить процессы не под команду, а “как по бумажке”, где в конце обязательно демонстрация ради галочки — просто потому, что «так положено».

В результате: – внедряем Scrum, – пропускаем daily, – бэклог — в голове у тимлида, – Канбан-доска — в Notion, но никто на неё не смотрит, – зато в вакансиях гордо пишем: «работа по методологиям Agile, Scrum, Kanban».

🙃 Ну что, agile delivery, как он есть.

За канбан особенно обидно. Он не про роли. Не про user stories. Не про velocity. Он про то, чтобы видеть, где задача застряла. Чтобы не пинать её слепо по колонкам, а понять — где bottleneck и зачем он вообще возник. Он не требует спринтов и ритуалов. Он просто помогает оптимизировать поток. И если вы им пользуетесь правильно — он тихо делает своё дело. Без фанфар. Но стабильно. Это и есть признак хорошего метода: он не мешает, когда работает.

Где ещё всё путают? Design Thinking — не методология, а набор методов. Lean — ближе к методологии. А 5 Whys и Value Stream Mapping — это методы внутри неё. Waterfall — это метод. Но любят называть его «традиционной методологией», чтобы казаться серьёзнее.

Я снова пишу о путнице потому, что путаница понятий = путаница ожиданий. HR и руководитель ждут стратегического виденья от Scrum Master’а. Команда ждёт конкретных действий от Product Owner’а, но наняли его как PdM. Методы не работают, методологии не внедряются, а виноваты — “неподходящие сотрудники”. Ну конечно.

А вы сталкивались с этой терминологической кашей? Может быть в вашей проф области есть свои подобные примеры? Буду рад прочитать ваши комментарии и примеры.

Благодарю за внимание! 🤝 Всем хороших выходных 🙂