Отличие канбан доски от скрам доски

Обновлено: 02.05.2024

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

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

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

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

Но давайте вернемся ближе к нашему времени, в начало двадцатого века. В Европе и США идет бурное развитие промышленности, предприятия ищут возможности для повышения эффективности. В США Фредерик Тейлор начал свои подробные исследования в области научной организации труда и менеджмента, а его ученик Генри Гант изучал менеджмент на примере постройки кораблей во время Первой мировой войны и предложил свою диаграмму, состоящую из отрезков (задач) и точек (завершающих задач или вех), как средство для представления длительности и последовательности задач в проекте.

Нам они известны как “Диаграммы Ганта” или Каскадная модель. Они совершили настоящую революцию в управлении проектами в 20-х годах XX века. Диаграммами пользовались во многих грандиозных инженерных проектах, например при строительстве дамбы Гувера и при строительстве сети скоростных магистралей США.

Необходимость перехода к современным методам управления проектами

С момента массового появления в 1980-е годы персональных компьютеров, стало проще создавать самые разнообразные и сложные диаграммы - делать их по настоящему комплексными.Они превращались в подлинные художественные произведения. Абсолютно каждый шаг проекта детально размечен. Любая стадия. Всякая дата. Диаграммы Ганта производят глубокое впечатление. Но есть одна единственная проблема: они всегда неправильны.

Как только план сталкивается с реальностью, он сразу рассыпается в прах. Каждый день на пути выполнения проекта появляется множество новых факторов которые в диаграмме не учитываются, что постепенно уводит этот план от реальности. И конечно же все это ведет к удорожанию проекта и к бесконечному увеличению сроков выполнения. Многие годы люди не замечали эту проблему и делали вид, что это вынужденные, необходимые или даже форс мажорные обстоятельства.

Такая проблема начала остро вставать и перед разработчиками программного обеспечения в 1980-х. Дело дошло до того, что отсутствие новых стандартов и правил при разработке программного обеспечения привело к полноценному мировому кризису разработки.

Практически у всех разработчиков того времени встречались одни и те же проблемы:

Проекты всегда превышали бюджеты;

Реализация проекта всегда превышала первоначальные сроки и зачастую вообще не доходила до завершения;

Готовое ПО неэффективно выполняло заявленную функцию;

Финальный результат был низкого качества;

Scrum

В 1995 году Кеном Швабером и Джеффом Сазерлендом на OOPSLA 95 в Остине была представлена новая сформулированная и задокументированная методология ведения проектов при разработке ПО. Назвали ее Scrum (Схватка - термин взятый из регби).

Ее разработкой и внедрением Д. Сазерленд занимался во время своей работы в компании Easel в 1993 году. Перед ним стояла задача в очень сжатые сроки создать абсолютно новую линейку ПО. Он решил отказаться от каскадной модели ведения проекта и занялся поиском оптимального решения.

В ходе поисков он наткнулся на статью японских ученых, изучавших успешный опыт на предприятиях Японии. Суть ее заключалась во внедрении командного подхода к разработке. В японских компаниях собирали кросс-функциональные команды специалистов, обозначали им амбициозную бизнес-цель, ставили сроки запуска, а дальше – предоставляли командам большую степень свободы в планировании, выборе способов достижения цели, управления бюджетом и тд. По итогам, оценивался результат команды в целом, а не вклад отдельного специалиста.

Те принципы и методы которые он почерпнул для себя из этой статьи, позволили ему успешно завершить проект небольшой командой и в максимально короткие сроки. А затем он сформулировал основные принципы Scrum.

Итак давайте рассмотрим основные принципы Scrum:

Работа короткими циклами (Спринт). Проект разделяют на части, которые называют Спринтами. Продолжительность Спринта от 1 до 4 недель. За это время команда берет на себя некоторое количество задач. Которые она стремится выполнить в этот временной отрезок.

Гибкость. После окончания каждого спринта, команда собирается для обсуждения и выявления слабых и сильных моментов, учитывает их и при необходимости корректирует Бэклог (список задач).

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

Командная работа. В команду обычно входите не более 6-10 человек с необходимыми для выполнения проекта компетенциями и навыками.

Гибкость Agile методик

Scrum относится к гибким моделям разработки Agile. Это целая философия, которую сформулировали благодаря «Манифесту Agile» в 2001 году. В манифесте особое внимание уделяется взаимодействию участников разработки и возможности изменений в проекте, которых не хватает в жесткой методологии управления проектами.

Ценности и принципы Agile:

Наивысший приоритет - удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

Изменение требований приветствуется, даже на поздних стадиях разработки.

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

На протяжении всего проекта разработчики и представители бизнеса должны работать вместе.

Над проектом должны работать мотивированные профессионалы.

Работающий продукт — основной показатель прогресса.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

К основные методологиям Agile относятся Scrum, Kanban и Lean. Scrum мы уже рассмотрели, а что из себя представляют Kanban и Lean. Они тоже пришли к нам из Японии, и родственны философии бизнеса Кайдзен и Тойоту.

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

Что касается Lean, то это больше философия и набор методик для создания бизнеса и подхода к разработке. Она подробно описана в книге Lean startup Эрика Риса.

Характерно для Lean:

Устранять в продукте все, что не приносит ценности клиенту.

Постоянное обучение команды - самый эффективный инструмент решения задач.

Принятие решения как можно позже.

Быстрая доставка изменений.

Основа успеха в сильной команде.

Экономия ресурсов достигается через изначально качественный продукт.

Важна целостная картина.

Основные преимущества Scrum в сравнении с каскадным методом

В чем же отличие Scrum от Каскадной системы управления проектом?

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

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

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

Поскольку в Scrum в каждом спринте команды выдают готовое решение (которое является частью всего продукта), они могут устанавливать измеримые цели, которые команда должна достичь. Это позволяет понять справляется ли команда с поставленными задачами, есть ли прогресс и успеваем ли мы реализовать продукт до установленного дедлайна. Благодаря такому подходу намного проще корректировать ход выполнения тех или иных задач, что в результате дает возможность мотивировать и поддерживать команду на максимальном уровне их самоотдачи проекту.

Таким образом можно сделать вывод, что для реализации любого проекта обязательно придется что-то менять, искать новые решения, генерировать необычные идеи. И только если подстраиваться под постоянно меняющиеся условия работы и требования заказчиков, можно найти верные способы действий. Гибкая методология управления проектами Scrum, становится верным помощником в этом деле.

Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.

Две популярные Agile-методологии

Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными. Перед тем, как разобраться в разнице между ними, вспомним кратко о том, что их объединяет.

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.

По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:

— проблемы, решением которых мы занимаемся, существует в жизни пользователя.
— эти проблемы существенные.
— пользователь будет за них платить
— есть рынок, и это не проблема одного человека.
— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).

Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.

После окончания спринта выполненные фичи заливаются на продакшн, а невыполненные — переносятся в другой спринт. Как правило, фичи, которые делаются во время спринта, не меняются: что было на старте спринта — должно быть сделано любой ценой к окончанию спринта.

На Kanban мы посмотрим там, где он и возник. Представьте себе конвейер, на котором делают детали для машин Toyota. Есть станок, он делает зеркала для машин. Он умеет делать левые зеркала, правые зеркала, задние и зеркала для солнцезащитного козырька. Принцип прост: нажми на кнопку, поменяй режим — получи новую продукцию.

Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (вы выбрали «максималку» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.

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

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.

Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.

Во-первых, это WIP (Work in progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем от выгорания: они делают только одну задачу в единицу времени.

А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, пока полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где ты остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника. Как мы это контролируем? Вот здесь должно быть понятно:

Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач — наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это все издержки, которые понижали наш КПД. Тогда мы подключили на проект еще одного QA и проблема была решена.

Swimlanes

Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает — в рабочее время. Вы делегируете задачу вашему лиду или devops – «Поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует ее закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.

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

Также у нас есть очень полезный Swimlane под названием Someday. Туда мы сублимируем задачи, которые «да-да, обязательно сделаем когда-нибудь» Это реально помогает убрать все лишнее с глаз, чтобы люди могли сконцентрироваться на главном. А эти задачи, как правило, остаются там навсегда.

Sub-columns

У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он ее переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенес задачу на тест, у QA нарушен этот лимит. Стало две задачи.

Допустим, программист не будет переносить задачу на Тестирование и оставит ее в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In progress и Done. И когда программист заканчивает задачу, он переносит ее в Done. Когда тестировщик освободится, он возьмет новую задачу из под-колонки Done колонки Программирование и перенесет ее в свою колонку Тестирование.

Заключение

Подводя итоги, хочу отметить, что Scrum — гибкая методика разработки, а Kanban — еще более. Всему свое время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning poker. Scrum помогает детально погрузить команду в суть продукта.

А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на нее реагировать. Вы начинаете работать над HADI циклами — вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Все увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.

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

А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!

Сегодня большинство компаний используют методологию Agile при разработке программного обеспечения. У Agile есть разные системы с похожими принципами и конечными результатами, но они различаются по структуре и подходу к управлению. Какой из них лучше всего подходит для вашего проекта? Это Скрам или Канбан? Или оба?

В преддверии старта курса Agile Project Manager поговорили об этом с экспертом Otus - Олегом Мельником.

Олег Мельник

Technical Lead в компании Proxify, а также преподаватель в OTUS

Agile

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

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

Scrum

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

Фактически, термин «scrum» происходит от scrimmage , позиции игрока в регби, образованной членами команды, толкающими друг друга, чтобы получить мяч. Соответственно, основная идея структуры - это регулярное сотрудничество внутри команды, направленное на устранение коммуникационных пробелов. Таким образом, становятся ясными цели проекта и задачи, возникающие на его пути.

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

Команда относительно небольшая, обычно 3–9 человек. Product owner и клиент устанавливают все правила , Scrum Master выступает в роли фасилитатора и коуча, а разработчики привержены своим обязанностям.

Команда Scrum поставляет программное обеспечение постепенно, с пометкой «Готово», чтобы максимизировать обратную связь и повысить эффективность.

Kanban

Подобно Scrum, Kanban - это управленческий подход, предназначенный для удовлетворения меняющихся требований. Он ориентирован на непрерывную поставку работающего программного обеспечения без установления строгих правил. Как правило, он состоит из нескольких небольших команд, работающих независимо над конкретными задачами, размещенными на доске Канбан. Гибкость - один из основных принципов Канбана. «Канбан» в переводе с японского означает рекламный щит. Следовательно, визуализация доски является основным организационным инструментом для фреймворка Канбан.

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

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

Отличия

Рабочие роли и обязанности

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

В Kanban менеджер является организатором проекта, где команды разработчиков сотрудничают и помогают друг другу независимо от того, над какой стороной проекта они работают. Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.

Какая команда работает лучше? Это зависит от характера проекта. Проект разработки программного обеспечения, требующий строгого набора правил, будет лучше управляться командой Scrum. Напротив, если проект требует непрерывной реализации , гибкая команда Kanban подойдет лучше. Таким образом, тип команды зависит от гибкости проекта, делегирования задач и организации.

Планирование и сроки поставки

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

Канбан не заботится о времени. Речь идет о прозрачности, эффективности и продолжительности. Если Scrum - это «марафон», то Канбан - это «путешествие». В Scrum продукт доставляется часто, в то время как в Kanban он доставляется как единое целое, когда это будет готово.

Планирование времени лучше или нет?

В идеале руководство должно отвечать ожиданиям клиента относительно того, когда будет выпущен продукт. Скрам определенно лучший вариант для доставки вашего продукта в отведенное время. Из-за спринтов Scrum желателен для проектов, в которых клиент и руководство фиксируют прогресс. Отсутствие согласованного расписания в канбане предназначено для более сложных проектов в долгосрочной перспективе, когда работа выполняется точно, а не в спешке.

Производительность и измерение

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

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

Является ли одна гибкая методология более продуктивной, чем другая? Конечно же нет. Не существует правильного рецепта гибкого управления. Это зависит от потребностей проекта. Просто дайте понять: каковы цели проекта? Какой рабочий процесс лучше всего подходит членам команды? Каков спрос со стороны конечного пользователя?

И Scrum, и Kanban усиливают управление проектом, но по-другому. Так зачем выбирать только один из них? Что, если есть третий метод, сочетающий в себе их лучшие качества?

Scrumban?

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

Визуализация рабочих элементов из системы Канбан представлена в Scrum. Рабочие элементы Scrum, находящиеся в процессе выполнения, подробно описаны на доске Kanban. Диаграммы применяются для выявления слабых мест и выявления возможностей для улучшения. Следовательно, Scrumban будет иметь растущую прозрачность, где каждый может видеть, что происходит с проектом.

Команда Scrum становится более специализированной. Обычно есть рабочие роли, но делегирование обязанностей более гибкое. Таким образом, команда работает в полную силу . Члены команды мотивированы работать вместе, как в Scrum, но у них есть индивидуальные задачи. Scrumban помогает повысить эффективность обязательств в команде.

Команда Scrum иногда может прийти к незавершению нескольких задач из-за ограничений по времени. При применении метода планирования Канбан задачи полностью завершаются до перехода в столбец «Готово». Вместо того, чтобы выпускать рабочие элементы раз в 2–3 недели в Sprints, существует постоянная поставка рабочего программного обеспечения. Качество превыше времени. Таким образом, в Scrumban есть улучшения по запросу, чтобы максимизировать поток работы.

Поэтому, не любите Scrum. Самыми важными стали метрики Канбан, а не скорость. Улучшение проекта выявляется внутри каждой команды самостоятельно. Это позволяет более достоверно оценивать прогресс.

Однако в Scrumban структура Sprint по-прежнему присутствует для обратной связи с командами.

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

Scrumban - это инновационный гибкий подход, при котором руководство стремится повысить эффективность проектов разработки программного обеспечения. Это обеспечивает гибкость Scrum и измерение потока работы Kanban. Качество работы улучшается за счет минимизации потерь времени и выполнения задач вовремя, но с максимальной загрузкой.

На этом все. А тех, кто желает подробнее узнать о курсе, познакомиться с преподавателями и почерпнуть еще больше полезной информации, приглашаем на бесплатный демоурок по теме: "Как уточнять статусы задач и подружиться с соседями".

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

Max Rehkopf

Просмотр тем

Описание. Сравнив Kanban и Scrum, мы рассмотрим две различные стратегии для внедрения системы разработки или управления проектами по методике Agile. Методики Kanban предполагают непрерывность и большую подвижность, а Scrum основывается на коротких структурированных спринтах работы.

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

Указать на различия между методологиями scrum и kanban несложно, но это даст лишь поверхностное представление. Хотя методологии различаются, их принципы в целом одинаковы. Обе помогают улучшить качество продуктов (и сервисов) и избавляют от множества проблем.

Итак, на чем мы остановились?

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

Суть Kanban в визуализации работы, ограничении объема незавершенной работы и достижении максимальной эффективности (или скорости). Kanban-команды стремятся максимально сократить время, которое уходит на выполнение проекта (или пользовательской истории) от начала до конца. Для этого они используют доску Kanban и непрерывно совершенствуют свой рабочий процесс.

Задача команд Scrum — поставить работающее ПО за ряд промежутков времени, которые называются спринтами. Они стремятся создавать циклы обучения для быстрого сбора и учета отзывов клиентов. Scrum-команды используют особые роли, создают специальные артефакты и проводят регулярные собрания, чтобы работа шла в нужном русле. Лучше всего методика Scrum описана в руководстве по Scrum.

Scrum

Kanban

Learn through experiences, self-organize and prioritize, and reflect on wins and losses to continuously improve.

Use visuals to improve work-in-progress

Regular, fixed-length sprints (i.e. two weeks)

Sprint planning, sprint, daily scrum, sprint review, sprint retrospective

Visualize the flow of work, limit work-in-progress, manage flow, incorporate feedback loops

Product owner, scrum master, development team

No required roles

Scrum — структурированный agile-подход

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

График Scrum

В Scrum высокий темп работы достигается путем ее деления на спринты продолжительностью от двух до максимум четырех недель с точными датами начала и окончания. Из-за узких временных рамок сложные задания приходится делить на более мелкие истории, и команда быстрее учится. Сможет ли команда за это время поставить пригодный для использования код? Вот в этом — главный вопрос.

Ключевыми точками в спринте являются собрания по планированию спринта и по обзору итогов спринта, а также ретроспективы. Кроме того, в ходе спринта проходят ежедневные scrum-совещания (стендапы). Эти scrum-собрания не отнимают много сил и проводятся на регулярной основе.

Роли в Scrum

В scrum четко обозначены три роли.

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

Кто руководит командой scrum? По факту никто. Команды scrum проповедуют принцип самоорганизации; в них все участники равны, хоть и исполняют разные обязанности. Команду объединяет общая цель: поставить ценный продукт клиентам.

Ключевые показатели

Скорость — сумма очков оценки сложности, отражающая объем работы, которую выполнили за спринт. Это базовый показатель для команд scrum. От него зависит, какой объем работы команда возьмет на себя в будущих спринтах. Если команда в среднем за спринт может заработать 35 очков оценки сложности (скорость = 35), она не примется за бэклог спринта, содержащий задач на 45 очков.

Отношение к изменениям

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

Подробнее о методологиях scrum см. в статье Что такое scrum?.

Kanban — непрерывное совершенствование, гибкие процессы

Суть Kanban — в визуализации работы, ограничении объема незавершенной работы (WIP) и быстром перемещении задач от стадии «Выполняется» на стадию «Завершено».

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

Модель Kanban

В основе kanban лежит непрерывная структура рабочего процесса, дающая командам свободу действий и возможность меняться вместе с изменениями приоритетов. Рабочие задачи представлены карточками на доске kanban и перемещаются из одной стадии рабочего процесса (столбца) в другую. Обычно рабочий процесс подразделяется на стадии «Предстоит сделать», «В процессе», «На проверке», «Заблокировано» и «Завершено». Но это не самый интересный способ разбить процесс.

Возможность создавать собственные столбцы в зависимости от того, как работает ваша команда, — лучшая особенность Kanban. Моя команда поставляет контент, поэтому задачи проходят столбцы (упрощенно) «Бэклог», «Приоритеты расставлены», «Схема набросана», «Написание», «Оформление», «Техническая экспертиза» и «Поставлено». С помощью нашей доски мы узнали, что поставляем примерно одну порцию контента в неделю, и поняли, где у нас проблемные места. (Да, это именно «Техническая экспертиза»!)

Подходы к релизу

В kanban обновления выпускаются по мере готовности; регулярный график или заранее определенные сроки отсутствуют как таковые.

Теоретически в рамках kanban не требуется устанавливать точный срок для завершения задания. Если задание выполняется раньше (или позже), результат выпускается по мере необходимости: для выпуска не нужно ждать контрольной точки, например собрания по обзору итогов спринта.

Роли в Kanban

Доска Kanban принадлежит всей команде. Некоторые команды привлекают к участию тренера по agile, но Kanban, в отличие от Scrum, не предусматривает роль «kanban-мастера», который отвечал бы за устранение шероховатостей в процессе работы. Команда несет коллективную ответственность за совместное выполнение заданий на доске и поставку результатов.

Ключевые показатели

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

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

Другое средство борьбы с проблемными местами — лимиты незавершенной работы (WIP). Они позволяют ограничить максимальное количество карточек, которые могут находиться в любом столбце одновременно. Когда лимит WIP достигнут, специальный инструмент, например Jira Software, помечает этот столбец, и команда направляет свое внимание на эти задачи, чтобы передать их на следующие стадии.

Отношение к изменениям

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

Подробнее о методике kanban см. в статье Что такое kanban?.

Сравнение инструментов Scrum и Kanban

Сторонники agile не склонны рассуждать об инструментах. Нередки случаи, когда выбор инструмента определяет выбор методологии, а выбор методологии определяет принципы, которых придерживается команда. Мы же считаем, что процесс принятия решения должен идти в обратном направлении.

Только после того, как вы освоили принципы scrum и пришли к выводу, что scrum полностью отвечает вашим потребностям, следует выбирать оптимальный инструмент scrum. То же можно сказать и про kanban. Конечно, наше мнение предвзято, но мы считаем, что Jira Software, лучший инструмент для разработки ПО, используемый agile-командами, обеспечивает любые потребности.

Jira позволяет создавать проекты специально под scrum и kanban, чтобы вы могли реализовывать принципы каждой методологии. Кроме того, вы всегда можете обратиться за помощью к нашим руководствам по применению scrum с помощью Jira Software и применению kanban с помощью Jira Software.

Kanban или Scrum — не можете выбрать?

Применять Scrum и Kanban — значит следовать всем правилам Agile. Эти методики прошли проверку временем и, откровенно говоря, им сложно что-либо противопоставить. Переиначив известный девиз IBM, можно сказать, что еще никого не уволили за выбор Scrum.

Но решение необязательно должно быть категоричным. Сотни команд используют гибридные модели, разработанные под влиянием и Scrum, и Kanban. В Jira Software мы предусмотрели все необходимое и создали проекты команды.

Проекты команды, как видно из названия, позволяют командам самим выбирать возможности Agile, которые им нужны. Это могут быть элементы Scrum, Kanban или их сочетание. Необязательно брать за основу одну методологию в первый же день работы. В проектах команды можно поэтапно добавлять все более и более мощные возможности по мере понимания того, что подходит команде (а что нет).

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

Что бы вы ни выбрали, не спешите менять методологию. Пусть какие-нибудь рабочие задачи из бэклога пройдут весь путь до стадии «Завершено», и только потом спросите команду, что удалось, а что нет. Знакомьтесь со Scrum и Kanban, задавайте эти вопросы, и в конечном счете вы познаете радость следования Agile.

Max Rehkopf

Просмотр тем

Доска Kanban — это инструмент управления Agile-проектами, который помогает наглядно представить задачи, ограничить объем незавершенной работы и добиться максимальной эффективности (или скорости). Она может помочь командам Agile и DevOps упорядочить повседневную работу. С помощью карточек и столбцов на доске Kanban команды по техническим вопросам и сервисные команды могут понять, какой объем работы следует взять на себя, и выполнить этот объем, придерживаясь принципов непрерывного совершенствования.

Методика Kanban проделала долгий путь от своих истоков в сфере бережливого производства, за что стоит поблагодарить небольшую, но эффективную группу ее сторонников. Труд Дэвида Андерсона, в котором были обозначены принципы методики Kanban, способствовал проникновению Kanban в мир разработки ПО и обслуживания, а книга Джима Бенсона и Тониан Де Мариа Personal Kanban (Kanban в личных целях) помогла распространению Kanban в самых разных областях.

Я использую доски Kanban каждый день и уже не представляю свою жизнь без них. Приведенные здесь идеи и рекомендации появились в результате объединения моего личного опыта, итогов исследования и разговоров с Заком Найсом, Китом Ноттинсоном и Джимом Бенсоном.

Я обращаюсь к Kanban снова и снова из-за ценностей Kanban и (как ни странно) отсутствия правил. В Kanban ценятся уважение к людям и постоянное совершенствование.

Составляющие доски Kanban

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

Видимые сигналы. Первыми на доске Kanban бросаются в глаза карточки (стикеры, листки и пр.). Kanban-команды выносят записи обо всех проектах и рабочих задачах на карточки; одна карточка, как правило, соответствует одному проекту или рабочей задаче. Для Agile-команд каждая карточка обозначает одну пользовательскую историю. Увидев эти сигналы на доске, участники команды и заинтересованные стороны смогут без труда понять, над чем работает команда.
Столбцы. Еще одним отличительным признаком доски Kanban являются столбцы. Они символизируют конкретные действия, которые в совокупности составляют «рабочий процесс». Карточки перемещаются по рабочему процессу до стадии завершения. Рабочие процессы могут быть простыми и состоять лишь из столбцов «Предстоит сделать», «В процессе» и «Завершено», а могут быть гораздо более сложными.
Ограничения незавершенной работы (WIP). Ограничения WIP — это максимальное количество карточек, которое может находиться в одном столбце одновременно. Если для столбца выбрано ограничение WIP, равное 3, то в нем не может быть более трех карточек. Когда количество карточек в столбце достигает максимума, команда должна сосредоточить усилия на этих карточках и передать их дальше, чтобы на эту стадию рабочего процесса могли поступить новые карточки. Ограничения WIP нужны, чтобы выявлять проблемные места в рабочем процессе и добиваться максимальной скорости работы. Ограничения WIP помогают на ранних этапах понять, не взяла ли команда на себя слишком много задач.
Точка принятия обязательств. На доске у Kanban-команд часто присутствует бэклог. Клиенты и участники команды вносят в него идеи по проектам, к которым команда может обратиться, когда будет готова. В точке принятия обязательств команда выбирает ту или иную идею, после чего начинается работа над проектом.
Точка поставки продукта. Точка поставки продукта знаменует завершение рабочего процесса команды Kanban. Многие команды принимают за точку поставки продукта момент, когда продукт или сервис передаются в распоряжение клиента. Цель команды — как можно быстрее перенести карточки из точки принятия обязательств в точку поставки продукта. Время, за которое карточка проходит из одной точки в другую, называется временем выполнения. Kanban-команды постоянно совершенствуются, стремясь свести время выполнения к минимуму.

Доска Kanban с этими пятью составляющими несомненно приведет вашу команду к успеху. Но сейчас я хочу познакомить вас с противоположной точкой зрения.

Джим Бенсон считает, что в Kanban есть только два правила: ограничивайте незавершенную работу и визуализируйте работу. Если следовать в работе только этим правилам, доска Kanban будет выглядеть совсем иначе. И в этом нет ничего плохого! Джим советует использовать только эти два правила в начале своего знакомства с Kanban, потому что «чем больше вы установили правил, тем меньше ситуаций, в которых их будет целесообразно применять».

Виды и примеры досок Kanban

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

Реальные доски

Самый простой пример доски Kanban — реальная доска, поделенная на вертикальные столбцы. Команды размечают маркерную или меловую доску и наклеивают на нее стикеры. Эти стикеры передвигаются по рабочему процессу, отражая ход работы.

Одно из преимуществ реальной доски заключается в том, что ее нельзя «выключить». Нельзя открыть новую вкладку на огромной маркерной доске на колесиках, стоящей возле стола. Такую доску легко подготовить, легко показать другим, и часто с ее помощью проще всего доносить информацию в определенных командах. Тем не менее реальные доски не подходят для удаленных команд или людей с ужасным почерком, как у меня.

Optimizely создает программное обеспечение, помогающее компаниям понять, какой вариант веб-сайта или продукта больше всего нравится пользователям. В этой компании рабочие задачи самых разных размеров отслеживают при помощи Jira, но Кит Ноттонсон, старший директор по развитию, заметил одно упущение.

Команды вели в Jira бурную деятельность по отдельности, но между собой не общались. Чтобы привлечь внимание всех к одному общему делу, Кит соорудил основательную реальную доску Kanban, которую назвал «стеной работы».

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

«Сначала стена состояла из столбцов "Предстоит сделать", "Выполняется" и "Завершено", но со временем сотрудники начали обсуждать друг с другом, как мы работаем», — говорит Кит. Он рассказал, что благодаря таким обсуждениям стена разрасталась и развивалась и за несколько недель у компании Optimizely появилось более осмысленное представление о процессе работы.

Сильной стороной доски Optimizely является наличие точки принятия обязательств и точки поставки продукта. Когда границы проекта определены и он отвечает определенным критериям, техническая команда выбирает проект и берет на себя обязательство по его выполнению. Затем проект передается в Jira, чтобы представляющие особый интерес данные и взаимодействия в процессе итоговой поставки не ускользнули от внимания команды.

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

Цифровые доски

Когда система Kanban снискала успех у команд по разработке ПО и технических команд, доски Kanban претерпели цифровую трансформацию. Географически распределенные команды могут обращаться к цифровым доскам Kanban удаленно и в разное время.

Trello — это простое средство для быстрого создания цифровой доски Kanban. Всего за несколько нажатий можно подготовить доску с цифровыми списками, символизирующими стадии Kanban-процесса. Работать с доской и управлять ею может вся ваша команда.

Например, можно создать списки «Бэклог», «На очереди», «В процессе» и «Готово». Каждое задание представлено в виде карточки, которая перемещается из списка в список по мере того, как задание попадает в очередь, над ним работают и его выполняют.

Цифровая доска Kanban обладает следующими преимуществами: скорость подготовки, простота предоставления совместного доступа и возможность отслеживать неограниченное количество обсуждений и комментариев в любое время по мере реализации проекта. Откуда бы и когда бы ни обращались участники команды к доске Kanban, они увидят самый актуальный статус проекта. А еще рабочий процесс Kanban в Trello можно использовать для ведения личных списков текущих дел, как показано на этом примере доски.

Бывают совсем простые цифровые доски Kanban, в то время как некоторые более продуманы и предусматривают больше возможностей настройки. Командам, которым нужны дополнительные функции, например ограничения WIP и контрольные графики, следует выбирать инструмент с более широкими возможностями, такой как Jira Software. В Jira по умолчанию доступен шаблон проекта Kanban, чтобы команды Kanban могли без промедления приступить к работе. Команда может просто создать проект, настроить рабочий процесс и доску в зависимости от нужд, установить ограничения WIP, создать дорожки swimlane и даже включить бэклог, чтобы было удобнее расставлять приоритеты.

Сравнение досок Kanban и Scrum

Различия между Kanban и Scrum довольно незначительны. Многие сходятся во мнении, что команды Scrum используют доску Kanban, но с процессами, артефактами и ролями, принятыми в Scrum. И все же в некоторых аспектах эти две методики разительно отличаются.

У спринтов в Scrum есть дата начала и дата окончания, в то время как в Kanban работа ведется без перерыва.
В команде Scrum четко разграничены роли (владелец продукта, команда разработчиков и Scrum-мастер), а в Kanban формальные роли отсутствуют. Обе методики требуют от команд навыков самоорганизации.
Доска Kanban используется на протяжении всего жизненного цикла проекта, а доска Scrum обнуляется и обновляется после каждого спринта. содержит определенное количество заданий, которые нужно выполнить к заданному сроку.
Доски Kanban дают больше свободы в том, что касается заданий и времени их выполнения. В зависимости от потребностей можно менять приоритеты, людей, ответственных за выполнение заданий, и содержание заданий.

Обе Agile-методики, Kanban и Scrum, популярны среди разработчиков ПО. Подробные сведения см. в нашем подробном сравнительном анализе Kanban и Scrum.

Начало работы с досками Kanban

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

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

Рабочий процесс в Kanban — процесс командный, поэтому первым делом ваша команда должна сплотиться! Для удобства разделите работу на отдельные активности, из которых будет состоять рабочий процесс (столбцы). После этого вы можете решить, как и когда добавлять на доску новые задания (карточки). Будет ли у вас служба техподдержки, через которую клиенты будут передавать идеи, или команда будет проводить совещания для составления и размещения новых карточек?

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

Когда точка принятия обязательств и точка поставки продукта определены, можно начинать работу. Со временем процесс будет совершенствоваться на основании замечаний команды. Kanban требует от участников всех уровней постоянно проявлять инициативу. Эта философия называется «кайдзен». Уважение к людям и постоянное совершенствование в Kanban превыше всего. Следуя этим ценностям, вы очень быстро овладеете этой методологией.

Читайте также: