Что относится к инструментам канбан тест

Канбан: система эффективного управления проектами

Рассказываем, что такое система канбан и как применять ее в учёбе.

Что такое канбан

Канбан (с японского — «бирка», «карточка», «знак») — японская система оптимизации и управления проектами и производством. Её придумали и впервые внедрили на заводах Toyota в начале 1960-хх годов. Постепенно преимущества системы оценили и в других странах. Сейчас она применяется для управления проектами по всему миру.

Основа канбана — использование специальных карточек, на которых отражается вся информация о процессе работы. Работники Toyota на этих карточках отмечают каждый этап производства: сколько сырья выдано, сколько деталей сделано, кто отвечает за проверку деталей на брак, куда деталь будет передана дальше и так далее.

Система канбан позволяет:

Как это работает

Карты канбан делятся на два основных вида — карты заказа и карты отбора. На каждый продукт или выполняемую работу заводится одна карта заказа и одна карта отбора.

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

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

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

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

Как учиться с помощью канбана

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

Для управления любым проектом, в том числе учебным, критически важно:

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

Основные достоинства канбан

Визуализация

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

Ограничение незавершённых производств

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

Фокусировка на работе

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

Внимание к деталям

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

Применяя канбан, можно так оптимизировать учебный процесс, чтобы всё успевать точно в срок, не переутомляться и получить именно тот результат, который требуется.

Хотите получать новые статьи во «ВКонтакте»? Подпишитесь на рассылку полезных статей

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter

Источник

Что относится к инструментам канбан тест

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Software Testing

Разделы портала

Про инструменты

Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.

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

Для правильной оценки эффективности процесса тестирования и его улучшения, он должен быть описан и доведен до сведения команды. Описание процесса тестирования помогает сделать процесс тестирования понятным и прозрачным для всей команды и снизить количество неопределенности в повседневной работе. В ходе выполнения задач в процесс тестирования вносятся изменения по методу PDCA (это аббревиатура, образованная словами Plan-Do-Check-Act, также известная как Цикл Деминга):

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

В Kanban есть daily — ежедневное обсуждение, которое проводят, рассматривая задачи, а не работу конкретных людей, как в Scrum. Начинается обсуждение с самой важной – правой колонки, затем переходим левее, отвечая на вопрос “Что нам мешает передвинуть задачу в следующую колонку?”. Самые ценный задачи находятся в правой части.

Итак, перейдем к самому процессу тестирования:

У нас есть несколько тестовых стендов, а также фича-стенды, где происходит тестирование нового функционала. Тестирование срочных задач происходит на фича-стенде с последующей выкладкой в прод.

Для запланированных задач карточки с задачами/багами переходят с левой части в правую.

По шагам это происходит следующем образом:

Источник

Методология Kanban: секреты эффективного использования

Методология Kanban: секреты эффективного использования

Менеджер МСФО в ООО «Эм Эм Эс Коммьюникейшнз» (входит в рекламный холдинг Publicis Russia)

Суть методологии

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

Основные элементы метода Канбана появились в 2007 году, они представляли собой доску с тремя столбцами — «сделать», «выполняется», «готово». Методология использует диаграммы, списки и статистику, чтобы показать этапы рабочего потока, а также его эффективность. Это помогает оценить результат любого идущего проекта. Канбан также использует фактор ограничения по количеству задач, которые могут выполняться в оно и то же время. Делается это для предотвращения чрезмерного напряжения и загрузки на отдельных участках работы.

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

Познакомимся с основными компонентами доски Kanban более подробно:

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

Положительные эффекты от применения системы Канбан

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

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

Доски Канбан в облаке — это самый эффективный способ для команды идти по одному пути. Они обеспечивают доступ ко всей информации с любого устройства в любое время, и отображают действия в настоящем времени.

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

Так, возможность создавать доски Kanban появилась в решении «1С:Управление нашей фирмой». Чтобы упорядочить и оптимизировать задачи, можно сформировать личные или командные доски — для планирования своих дел или задач рабочей группы. Также их можно использовать для обзвона клиентов, наведения порядка в ежедневных задачах или планирования мероприятий. Подробнее об этом можно почитать здесь >>>

Кому стоит применять Kanban методику на практике

Итак, кто же может использовать Канбан?

Как внедрить Kanban в свою практическую деятельность

Выделяют пять шагов, необходимых для реализации Канбана.

1. Составление карты действующих рабочих процессов

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

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

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

2. Визуализиция работы

Важно помнить, что цель системы Канбан — это понимание и управление общей работой команды.

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

3. Анализ рабочего потока

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

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

Совместно с командой следует определить несколько изменений, которые следует внести, но делать их не сразу, а — это важно — по одному. Если сразу будет много изменений, это не позволит увидеть или измерить эффект от вносимых корректировок. Поэтому разумно определить приоритеты того, что надо оптимизировать, исходя из их наибольшего влияния на поток.

4. Ограничение количества незавершенных процессов

Уже построена доска процессов, виден поток работы, возможно, разработаны решения по улучшению. Теперь следует применить одну из самых важных концепций Канбана — ограничение количества незавершенных процессов (далее НЗП).

Ограничение НЗП — это сознательная практика контроля объема работы в системе на одном этапе. Компания получит множество преимуществ от ограничения НЗП, а именно:

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

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

5. Измерение и улучшение

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

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

Заключение

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

Источник

Канбан в IT (Kanban Development)

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Для начала напишу про происхождение термина Канбан.

Этот термин пришёл к нам из Японии благодаря широко известной в узких кругах производственной системе Тойота. Хотелось бы, чтобы как можно больше людей прочитало про эту систему и основные принципы, заложенные в неё — бережливое производство, постоянное развитие, ориентацию на клиента и т.п. Все эти принципы описаны в книге Тайити Оно Производственная система Тойоты, которая переведена на русский.

Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка или доска.
На заводах Тойота карточки Канбан используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что вы ставите двери на Тойоты Короллы. У вас около рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то вы знаете, что пора заказать новые двери. Вы берете карточку Канбан, пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у вас закончатся оставшиеся 5 дверей. И именно так и происходит — когда вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно — вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше — система сама легко подстраивается под изменения.

Основная задача карт Канбан в этой системе — это уменьшать количество «выполняющейся в данный момент работы» (work in progress).
Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько — это задача для того, кто их устанавливает. Только он знает свои потребности, и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойоте и сейчас многие производственные компании по всему миру его внедряют или уже внедрили.

Но это всё относится к производству, а не к разработке программного обеспечения.
А что же такое Канбан разработка применительно к ПО, и чем она отличается от других гибких методологий, буть то SCRUM или XP?

Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой — «Уменьшение выполняющейся в данный момент работы (work in progress)».
В-третьих, Канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM:
— В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
— В Канбан задачи больше и их меньше
— В Канбан оценки сроков на задачу опциональные или вообще их нет
— В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

А теперь посмотрите на этот список и задумайтесь — что остается от гибкой методологии, если мы удаляем спринты, увеличиваем размеры задач и перестаем мерять скорость работы команды? Ничего?
Как вообще можно говорить о контроле за разработкой, если мы убираем основные инструменты контроля — сроки, скорость работы и спринты? Для меня этот вопрос является чуть ли не самым важным.
менеджеры всегда думают о контроле и пытаются его получить, хотя на самом деле никогда его не имеют. Контроль разработки со стороны менеджера — это фикция. Если команда не хочет работать, то как ее не контролируй, она провалит проект.
Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.
Например, общеизвестная проблема SCRUM — это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт — 2 недели, то 2 дня из 2 недель — это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса — на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы — тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера — это создать приоритизированный пул задач, а задача команды — выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Команда для работы использует Канбан-доску. Например, она может выглядеть так (взял тут):

Столбцы слева направо:

Цели проекта:
Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7».

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

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

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

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

Деплоймент:
У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то — просто закомитить код в репозиторий.

Закончено:
Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.

В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна — она должна быть добавлена в «Очередь задач».

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в строку «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан — это уменьшение времени прохождения задачи от начала до стадии готовности.
Никто не даст точный ответ, какие должны быть эти лимиты, но попробуйте для начала разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду.
Под «разработчиками» я понимаю не только программистов, но и других специалистов. Например, для столбца «Тестирование» разработчики — это тестеры, т.к. тестирование — это их обязаность.

Задачи на такой доске — это не просто задачи, а то, что называется Минимальной Маркетинговой Фичей, то есть фича, которую можно «продать» клиентам.
Хорошая проверка для ММФ — это вопрос себе «А стал бы я писать про эту фичу в блоге компании?». Если нет — это не ММФ.

Что нового и полезного дает такая доска с лимитами?

Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. — делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце «очередь задач», а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.

Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что «мы — команда» и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее.

В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.

Весь Канбан можно описать всего тремя основными правилами:
1. Визуализируйте производство
— Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
— Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.

Всего 3 правила!
Например, в SCRUM — 9 базовых правил. В XP — 13, а в классическом RUP — аж более 120. Почувствуйте разницу.

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

Источник