Приветствую вас, коллеги и соратники в мире управления проектами! При разработки программного обеспечения существует множество подходов, методологий к управлению 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? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!
Комментарии (4)
Pro_Project_Management Автор
19.01.2025 18:46Большое спасибо за ваш комментарий! Очень рад, что текст вызвал у вас положительные эмоции. Действительно, Scrum – отличный подход, и ваша идея комбинирования методов выглядит весьма перспективно. Здорово, что у вас был опыт, который помог команде не только организовать работу, но и получить ценный управленческий опыт. Такой анализ действительно позволяет лучше видеть общую картину и налаживать связи между задачами. И, конечно, ничто не сравнится с той позитивной энергией, которую приносит удовлетворение от выполненной работы и благодарность пользователей. Спасибо, что поделились своим опытом! P.S. Поправил 9 пункт в таблице!
AppCrafter
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
olku
Канбан, скрам и водопад в своей сути отличаются атомарностью отчётности - одна задача, пакет задач, все задачи. Отчётность подбирается под проект. Остальной инструментарий - бантики - подбирается по необходимости и степени следования карго культам. Пока не видел компании, которая следует им до точки.