Приветствую вас, коллеги и соратники в мире управления проектами! При разработки программного обеспечения существует множество подходов, методологий к управлению IT проектами. Среди них топ места занимают Scrum и Kanban. Сегодня освежим наши знания об этих двух методах, и принципах их применении.
Скрам: Кратко о главном
Scrum — это фреймворк для управления проектами, который фокусируется на гибкости и адаптации к изменениям. Это одна из основных методологий по управления проектами из семейства Agile.
Основные элементы Скрам
Роли:
Product Owner: отвечает за создание и приоритизацию бэклога продукта.
Scrum master: помогает всей команде следовать процессам скрам и устраняет препятствия, которые могут мешать работе.
Developers: группа специалистов, которые выполняют работу по созданию продукта.
Артефакты:
Бэклог продукта: список всех задач и требований, которые должны быть выполнены.
Бэклог спринта: задачи, выбранные для выполнения в текущем спринте.
Инкремент: завершенная работа за спринт, которая добавляет ценность продукту.
События:
Спринт: имеет фиксированный период (обычно 2-4 недели), в течение которого команда работает над задачами.
Планирование спринта: встреча для определения задач, которые будут взяты в работу и выполнены входе спринта командой.
Ежедневный стендап(daily-ки): короткие ежедневные встречи для обсуждения прогресса и препятствий.
Обзор спринта: встреча для демонстрации завершенной работы(демо) заинтересованным сторонам.
Ретроспектива: встреча для анализа прошедшего спринта и выявления возможностей для их улучшения.
Канбан: Кратко о главном
Канбан — это метод управления процессами, который акцентирует внимание на визуализации работы, ограничении незавершенных задач и постоянном улучшении. Это одна из методологий по управления проектами из семейства Agile.
Основные элементы Канбана
Визуализация вашей работы:
Использование доски Kanban, на которой отображаются задачи в виде карточек, перемещающихся по колонкам доски, имеющие различные стадии/статусы (к примеру, «Todo», «In progress», «In QA», «In review», «Done»).
Ограничение незавершенной работы(WIP):
Установка лимитов на количество задач(WIP лимитов), которые могут находиться в каждой колонке одновременно, чтобы предотвратить перегрузку команды и улучшить поток работы.
Постоянное улучшение:
Регулярный мониторинг и оптимизация процессов, использование метрик для оценки производительности, результатов и выявления узких мест, горлышек.
Разница между Скрамом и Канбаном: Памятка для менеджеров проектов
Давайте сравним Scrum и Kanban по различным атрибутам, чтобы знать основные отличия, между этими методами управления (помним, скрам — это фреймворк, а канбан — метод организации и управления задачами). Таблица ниже показывает разницу между Scrum и Kanban.
No. |
Attribute |
Scrum |
Kanban |
1 |
Work cycle |
Итерации. Scrum включает спринты, в течение которых команда следует циклу plan-do-check-act (PDCA). |
Continuous flow. В Канбан, как только одна задача завершается, команда сразу берется за следующую. |
2 |
WIP - Work In Progress |
WIP лимиты устанавливаются командой Scrum для каждого спринта, и новая работа берется в работу только после завершения всех текущих задач. |
WIP лимиты в Канбан означает количество задач, которые могут одновременно находиться в одной колонке в течение заданного промежутка времени на конкретном этапе работы. |
3 |
Inspect-Adapt (Empiricism) |
Каждый спринт — это возможность для инспекции и адаптации. |
Нет конкретного механизма для инспекции и адаптации. Работа движется в одном направлении. |
4 |
Transparency (Empiricism) |
Артефакты в Scrum включают product backlog, sprint backlog и increment. Соответственно обеспечить прозрачность требований, реализации и результатов. |
Никаких специфических артефактов для прозрачности. Канбан-доска обеспечивает некоторую прозрачность. Многие команды используют бэклог продукта (из Scrum) в сочетании с досками канбана. |
5 |
Planning |
Конкретный митинг для планирования спринта и дня — sprint planning и daily scrum. |
Нет четких указаний по планированию работы. Команды самостоятельно выбирают свой ритм и подход к планированию. |
6 |
Responsibility/Structure |
Ответственность в Scrum: владелец продукта фокусируется на бизнесе, разработчики на реализации и Scrum мастер на устранении препятствий и имплементации Скрам. Вся работа выполняется кросс-функциональной командой. |
В канбане нет такого разбиения как в Скраме: владелец продукта, разработчики и т. д. Предполагается, что над задачами работает группа людей, они двигаются по флоу, пока не переходят в задачу со статусом done. И команда может быть не кросс-функциональной. |
7 |
Stakeholder/Customer |
Scrum предполагает активное участие заинтересованных сторон и клиента — по крайней мере, один раз за спринт во время мероприятия sprint review(демо). |
Канбан не дает возможности привлечь заинтересованные стороны или клиентов. Некоторые команды применяют подход “обзора проделанной работы” раз в месяц. |
8 |
Daily meetings |
Daily в скраме — это короткая ежедневная встреча команды, обычно длится 15 минут, на которой участники обсуждают, что они сделали, что планируют сделать и какие препятствия у них есть. Цель — координация работы и повышение прозрачности. |
Daily в канбане — стендап не является частью практик Канбана, но все равно можно проводить эту встречу. Стендап можно считать одним из способов реализации принципа improve continuously. Вопросы на них лучше задавать с фокусом на задачи. |
9 |
Поток работы |
Скрам использует фиксированные временные рамки, называемые спринтами, которые обычно длятся от одной до четырех недель. Это позволяет командам "пушить" заранее запланированные задачи в рамках каждого спринта. |
Канбан основан на принципе "пул", что означает, что работа вытаскивается из очереди по мере необходимости. Это позволяет командам адаптироваться к изменяющимся требованиям и приоритетам, так как новая задача берется только тогда, когда есть свободный ресурс. |
10 |
Метрики |
Основные метрики, которые применяются в скраме: Velocity (Скорость), Burndown Chart (График сгорания), Sprint Goal Achievement (Достижение цели спринта), Release Burndown. |
Основные метрики, которые применяются в канбане: Lead Time (Время производства), Cycle Time (Цикловое время), Throughput (Производительность), Work In Progress (WIP). |
11 |
Оценка и приоритизация |
В Scrum оценка задач по их приоритету и сложности является обязательной, поскольку без этого невозможно организовать спринт и приступить к его реализации. Все задачи, которые не укладываются в рамки спринта, должны быть декомпозированы на подзадачи и взяты в сприн исходя из капасити. |
В Kanban-е оценка тасков не является обязательной, но может применяться в определенных случаях, особенно когда отсутствует соглашение о уровне обслуживания SLA. |
12 |
Изменения в ходе работы |
Скрам изначально не приветствует изменения объема задач, включенных в спринт. Дело в том, что если мы определили цель для конкретного спринта и команда взяла на себя ответственность за ее достижение, то любые изменения в объеме работ могут подорвать все наши планы. В таких случаях целесообразно завершить текущий спринт раньше срока и начать новый. Однако на практике это приводит к дополнительным затратам времени. Поэтому часто выделяется часть ресурсов команды на внеплановые задачи, что противоречит принципу Agile о "ранней поставке ценного ПО". |
В методологии Kanban всё гораздо проще — изменения могут быть внесены в любое время. Если бизнес решает, что необходимо срочно приступить к выполнению задачи, это не требует долгих процессов перепланировки (работу можно начать буквально через несколько минут). Однако здесь также существуют свои сложности, например, возможные блокировки задач, которые уже находятся в работе, и снижение производительности разработчика из-за необходимости переключаться на новую задачу. О том, как с этим справляться, я постараюсь рассказать отдельно. |
13 |
Начала работ над тасками |
Скрам строится на основе спринтов, ограниченных во времени. Работа начинается только после того, как задачи будут расставлены по приоритету и оценены, проработаны ac, после чего они попадают в список спринта (Sprint Backlog). Обычно это происходит с регулярностью, соответствующей итерациям, что подразумевает ожидание включения конкретной задачи в ближайший спринт (хотя это не всегда происходит быстро). |
В Канбане нет таких ограничений, как в Скраме: задачи берутся сразу в работу по мере возможности или необходимости (например, когда кто-то завершает свою текущую задачу или возникает задача более высокого приоритета). Таким образом, разрыв между созданием задачи и началом работы над ней меньше, чем в Scrum. |
14 |
Проведение демо |
Demo проводится в конце спринта и является частью Sprint Review. На этом митинге команда демонстрирует завершенные элементы работы (например, функционал, который был разработан за спринт) заинтересованным сторонам, включая владельца продукта. А также в получении ОС по проделанной работе. |
Формальные демо-сессии не являются обязательными в канбане, их проведение может быть полезным для улучшения коммуникации и сотрудничества в вашей команде. Поэтому демо-сессии можно проводить, как на регулярной основе (например, раз в определенный период) или после завершения значительных задач. |
Напоследок пару слов о СкрамБане
Скрам-бан — это гибридная методология, объединяющая элементы, как Scrum так и Kanban, которая предназначена для управления проектами и улучшения процессов разработки.
Основные характеристики Скрам-бан:
Гибкость: Скрам-бан сохраняет гибкость, позволяя командам вносить изменения в процессе работы, что особенно важно в динамичных условиях.
Визуализация: Использование визуальных инструментов, таких как доски и карточки, помогает командам отслеживать задачи и их прогресс.
Поток работ: Скрам-бан фокусируется на оптимизации потока работ, уменьшая время выполнения задач и повышая эффективность команды.
Непрерывное улучшение: Команды регулярно анализируют свои процессы и ищут способы их улучшения, что способствует росту и развитию.
Скрам-бан подходит для команд, которые хотят сохранить структурированный подход (как в Скрам), но при этом желают иметь гибкость и визуализацию рабочего процесса (как в Канбан) и командам что хотят перейти из скрама в канбан как промежуточный степ.
Напишите в комментариях, что вы чаще используете в своих проектах — Scrum или Kanban? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!
Комментарии (21)
Pro_Project_Management Автор
19.01.2025 18:46Большое спасибо за ваш комментарий! Очень рад, что текст вызвал у вас положительные эмоции. Действительно, Scrum – отличный подход, и ваша идея комбинирования методов выглядит весьма перспективно. Здорово, что у вас был опыт, который помог команде не только организовать работу, но и получить ценный управленческий опыт. Такой анализ действительно позволяет лучше видеть общую картину и налаживать связи между задачами. И, конечно, ничто не сравнится с той позитивной энергией, которую приносит удовлетворение от выполненной работы и благодарность пользователей. Спасибо, что поделились своим опытом! P.S. Поправил 9 пункт в таблице!
vlad4kr7
19.01.2025 18:46Если еще короче - самая основная основа (это частично упомянуто в разделе Демо, статьи): результат работы команды. т.н. Артефакты или деплой:
в Скраме происходит в конце спринта, т.е. "деплоим, то что готово на момент времяни",
в Канбане - в момент завершения пула фичей - "Деплоим, когда готово заданный список задачь"
x012
19.01.2025 18:46Хотел бы у вас спросить, как практического знатока систем планирования/ведение проектов, какие есть системы (может менее известные или экзотические или настраиваемые) где объем проекта, подпроекта и даже задачи просчитать не получается?
Для исследовательских и изобретательских проектов.
Каждый раз ситуация одна и та же - объем работ порой равен полному рандому. Задача может занять несколько часов, а может пару лет, т.к. "внезапно" (а скорее предсказуемо) натыкается на неисследованный ключевой момент(ы).Но при этом все равно нужно как-то вести проекты. При чем не один, а сразу несколько.
Сейчас для ведения подобного типа проектов и планирования используются "палки-копалки" в виде гугл доков и таблиц. Пробовал разные системы - в одних упирается в том, что нужно точно фиксировать время/объем проекта, задач. В других - в том, что нужно точно знать структуру (разбитие всего проекта через древовидные структуры до микрозадач).
Но и то и другое - "облачно, туманно", то есть не определено.
gurewarudo
19.01.2025 18:46не аффтор но позволю себе написать свои мысли: вообще как раз скрам или ХП считаются подходящим для проектов с большой степенью неопределенности. В них это решается за счет итераций - если делаем не то - быстро замечаем и исправляем. Проблема, которую вы описали (задача может затянуться на пару лет) не решается никакой системой ведения проектов, все они направленны на ускорение типовых задач (понятно что сделать новую программу это новая но понятная задача). Единственное что я вижу - возможно проблема в недостаточном декомпозировании сложных задач (гуглите ADR, инициация требований)
x012
19.01.2025 18:46Единственное что я вижу - возможно проблема в недостаточном декомпозировании сложных задач (гуглите ADR, инициация требований)
Благодарю - гуглю на сию тему. Походу нужно назначат какие-то метрики чтобы останавливать процессу углубления в изучаемую под-задачу, т.к. всегда не ясно достаточно или недостаточно она изучена.
вообще как раз скрам или ХП
Подскажите, что означает ХП?
Merrynose
19.01.2025 18:46Если возникает некая неопределенная задача, связаннная с ресерчем чего бы то ни было, то я обычно сначала делаю задачу на ресерч и отвожу на нее некое определенное время, которое мы с командой посчитаем достаточным для иследования исхдной проблемы.
Результатом выполнения этой задачи будут шаги по решению проблемы (то есть список конкретных задач) и оценка трудоемкости.
af7
19.01.2025 18:46Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Debrainer
19.01.2025 18:46Я приверженец канбана для опытных и сработанных команд с понятным скоупом возможных задач по продукту.
Вижу регулярно коллег соседей, работающих по скраму. Так вот мы с командой даем результат для бизнеса существенно быстрее, так же быстрее переключаемся на более приоритетные задачи, но работать как на конвейере без пауз для людей не просто, выгорают. Ну и у менеджера команды работа с бэклогом считай постоянная при канбане, потому что нужно нагружать команду задачами, а даже бизнес не всегда поспевает, тогда приходиться набрасывать оптимизации, тюнинг, рефакторинг в промежутках между фичами и релизами для бизнеса.
Ещё, если у вас есть работа с внешним вендором в команде от которой зависит и ваша работа, то как по мне спринты при таком варианте вообще не подходят, ну или вы будете для бизнеса крайне медленными.
Merrynose
19.01.2025 18:46По моему опыту скрам лучше заходит, когда есть большой беклог и нужно откусыать от него понятными кусочками, чтобы итеративно идти к конечной реализации продукта. Канбан лучше, когда продукт уже живет, и нужно его развивать: выполнять как стратегические задачи по роад-мэпу, так и чинить проблемы, возникающие на проде.
AppCrafter
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
olku
Канбан, скрам и водопад в своей сути отличаются атомарностью отчётности - одна задача, пакет задач, все задачи. Отчётность подбирается под проект. Остальной инструментарий - бантики - подбирается по необходимости и степени следования карго культам. Пока не видел компании, которая следует им до точки.
Pro_Project_Management Автор
Согласен, каждая методология имеет свои уникальные аспекты и подходы к отчетности. Важно выбирать инструменты, которые действительно работают для вашей команды и проекта. Гибкость и адаптация — ключ к успеху!
tenzink
Как я слышал от "друга", скрам настолько совершенен, что его адаптация - табу. Адаптированный скрам - уже не скрам
Merrynose
Нет. Отчётность тут вообще ни при чём. Ее может даже не быть вовсе. Отличаются они подходом к планированию и организации работы. И это ни разу не "бантики".
dph
Вы описали скорее Канбан. К Скраму указанный подход не имеет никакого отношения (благодаря чему, скорее всего, и удалось получить пользу).
Pro_Project_Management Автор
Вы голосовали по карме мне? Если да, то не могли бы вы объяснить причину?
dph
Данная статья не содержит никакой полезной или новой информации, зато содержит множество ошибок, написана без особого понимания как Скрама, так и Канбана, противоречит даже скрам-гайду.
Более того, подобных сравнений и так очень много в интернете (и даже на хабре), причем гораздо более качественных. Т.е. проблема не в каких-то заблуждениях автора, а в полном безразличии к качеству предоставляемых материалов, потому и минус в карму.
Pro_Project_Management Автор
В отметке по карме вы указали не конструктивное общение - это полностью противоречит вашему нынешнему комментарию. Это означает, что причина была указана неверно. Спасибо.
Теперь, по поводу вашего текущего комментария с которым я Полностью Несогласен. Уточните, где именно вы видите противоречие со скрам гайдом? Поделитесь более детальной информацией, чтобы мы могли лучше понять вашу точку зрения.
dph
Так публикация статей без содержания - это и есть неконструктивное общение, так что причина указана верно. И как-то при такой реакции не возникает никакого желания указывать на ошибки, тем более каким-то странным "мы".
Сначала скажите, что в данной статье нового относительно примерно десятка прочих статей про скрам и канбан, которые опубликованы на хабре. Читали ли вы их вообще перед публикацией собственной? Если нет, то почему решили, что скажите что-то новое?
Pro_Project_Management Автор
Понятно. Противоречия со Скрам гайдом вы привести неможите. Общение, на мой взгляд, происходит либо в сообщениях, либо в комментариях. Я с вами лично не общался во время вашего голосования, и вы говорили про ошибки, соответственно, нужно было выбирать этот пункт. По остальным вопросам я не согласен. Если можете, раскройте тему подробнее и напишите пост/статью — Мы все почитаем!
AppCrafter
Да, вы правы, это скорее было похоже на Канбан, потому как не было спринтов с ограничением по времени. Но и визуализации тоже особой не было, просто список задач в Excel. Единственное, что вспомнилась ещё одна ассоциация, что если задача не решалась в течение 2-х недель, то приходилось с ней что-то делать. То ли дробить на более мелкие, то ли как-то перестраивать общую картину.