Kanban доска примеры использования

Обновлено: 26.01.2025

Kanban/Agile/Scrum/Lean — гибкие методологии разработки

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

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

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

Разработка любого продукт имеет свой жизненный цикл, который можно свести к следующим этапам:

Генерирование идей
Отбор идей
Разработка и проверка концепции продукта (что именно и для кого мы делаем)
Разработка и проверка маркетинговой стратегии (по каким каналам мы сможем продавать)
Бизнес-аналитика (unit-анализ, проверка сходимости экономики)
Разработка и проверка товара
Пробный маркетинг (вывод на рынок MVP – минимально жизнеспособного продукта)
Коммерциализация (масштабирование)

Жизненный цикл разработки продукта Горбунова Карина

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

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

Но не все знают, что получили развитие эти методы с Пути Тойоты — Dao Toyota.

Dao Toyota

Тойота как компания, занимающаяся производством автомобилей, образовалась в 1933 году как отдельное подразделение фирмы Toyoda Automatic Loom, которая ранее выпускала станки для текстильной промышленности. До Второй мировой войны компания процветала, но после — Японию оказалась на проигравшей стороне. В следствии оккупации и инфляции компания Тойота была на грани банкротства. Для того, чтобы выйти из кризиса, владелец и основатель компании Киичиро Тойода был вынужден максимально сокращать расходы. Он вводит политику жесткой экономии, которая закладывает фундамент основного принципа компании – «производства с нулевым запасом». Так появилась философия бережливого производства Тойота. Сподвижником и последователем Киичиро Тойода стал Тайити Оно, который в 1954 году занял пост директора компании. Но уже с середины 50-х годов он начал выстраивать особую систему организации производства, названную производственной системой Toyota или Toyota Production System (TPS).

Принципы ведения бизнеса на Toyota:

Тайити Оно сформировал 14 основных принципов управления компанией и сгруппировал их в четыре категории:

Принципы ведения бизнеса на Toyota:

TPS — следующая ступень в развитии эффективного бизнеса после системы массового производства, которую изобрел Генри Форд. За пределами Toyota, TPS часто называют бережливым производством — lean production (этот термин введен Джоном Крафчиком в 1988 году для обозначения методов организации производства, принятых в Toyota).

Т.е. философию Dao Toyota смело можно назвать прародителем как продуктового подхода, так и современных методологий разработки продукта.

Dao Toyota, Lean и Kanban

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

Перепроизводство (лишний созданный продукт);
Ожидание (потеря времени);
Лишняя транспортировка или передвижение;
Излишняя обработка (например, за счет плохого качества инструмента);
Избыток запасов;
Лишние движения;
Дефекты;
Неиспользованный человеческий потенциал (это пункт добавил Джеффри К. Лайкер в своей книге «Dao Toyota14 принципов менеджмента ведущей компании мира»);

Для максимальной эффективности выстраивания рабочего процесса и устранения потерь в Toyota используется метод Kanban и Lean бережливое производство. Сначала подробнее рассмотрим Lean.

Производственная система Toyota TPS представляет собой уникальный подход к производству. Именно она породила движение за бережливое производство, которое (вместе с концепцией шести сигм) стало одной из доминирующих тенденций в разработке. Однако есть мнение, что несмотря на схожесть TPS и Lean, первое – это путь конкретной компании, а Lean production – набор методов и инструментов, которые базируются на философии Toyota, но могут быть реализованы на других производствах.

Сам термин «Бережливое производство» был введен Джоном Крафчиком в 1988 г. в рамках его работы в Международной автомобильной программе Массачусетского технологического институту. Исследования Крафчика в области бережливого производство были использованы Деймсом Вомеком и Дэниелем Джонсом в книге «Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании». Именно они определили этот термин в 1998 году. Бережливое производство, согласно Джеймсу П. Вомек и Дэниелу Т. Джонсу включает пять этапов:

Определение ценности для потребителя;
Выстраивание последовательного потока создания этой ценности;
Обеспечение непрерывности этого потока;
Обеспечение «вытягивания» от заказчика;
Стремление к совершенству;

Таким образом, Lean — это не методология, так как в ней нет набора готовых инструментов. Это часть философии эффективной разработки, которая вышла из философии Toyota и впоследствии стала частью философии Agile. Lean бережливое производство призвано бороться со всеми видами потерь. В основе данной философии лежат принцип вытягивания и принцип «точно в срок» (Just in Time).

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

Принцип «точно в срок» (Just in time) предполагает, что система планирования и организации работы компании построена так, что все необходимые элементы поступают в производственный процесс в нужный момент и в необходимом количестве. Также этот принцип предполагает бездефектное производство, так как брак может сломать всю четкую систему планирования.

К Lean бережливому производству можно отнести следующие методы организации труда и разработки:

Правило 5 Сигм (сейчас правило 5 Сигм выросло в правило 6 Сигм, в статье указан шестой пункт Дисциплина и привычка) — правильно организованное рабочее место:

Сортировка (нужное под рукой, не очень нужное – дальше от рабочей зоны);
Соблюдение порядка (ненужные вещи не должны мешать процессу);
Содержание в чистоте;
Стандартизация (процесс должен быть прописан в инструкциях);
Совершенствование (нужно постоянно развиваться и узнавать новое);
Дисциплина и привычка;

Poka-Yoke – «защита от дурака».

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

Метод быстрой переналадки оборудования (SMED)

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

Kanban. Остановимся на этом методе подробнее.

Слово Kanban имеет японское происхождение и переводится как «рекламный щит, вывеска».

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

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

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

Доска Kanban Горбунова Карина

Визуализация – доска с карточками-задачами (user-stories в разработке продукта). Доска может быть физическая или виртуальная.
Имеется план разработки, отсортированный по приоритету (backlog в разработке продукта). Может меняться в любой момент.
Ограничение одновременно выполняемых задач.
Постоянная оптимизация процессов.

Из этих принципов можно сформулировать и ограничения метода:

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

Модели разработки. Agile

Параллельно с внедрением различных методологий в производстве, развивается процесс разработки программного обеспечения. Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х — начале 70-х годов 20 века в связи с резким увеличением производительности ЭВМ при значительном снижении его стоимости. Именно в этот период программирование из простого кодирования становится инженерной дисциплиной и обрастает дополнительными видами деятельности, такими как разработка требований, создание документации, планирование, тестирование, проектный менеджмент и т.п. Появляются различные методы и практики, а из них стандарты и методологии.

Формируется жизненный цикл разработки ПО, который в общем виде можно представить так:

Жизненный цикл разработки ПО Горбунова Карина

Методология разработки может быть жесткой (или традиционной), например, по каскадной модели, или гибкой.

Каскадная модель (waterfall) была представлена доктором У. Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывается компетентными сотрудниками, документируется и передаётся дальше. Вся работа идет последовательно от этапа к этапу. Пока предыдущий этап полностью не завершен, следующий запрещено начинать. Подходит для консервативных бюрократических структур. Каскадная модель — это пример жесткой методологии разработки.

Основные идеи Agile:

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

Сам по себе Agile не является полноценным методом управления проектами, это философия управления разработкой, аналогично тому, как TPS – философия управления производством. Lean, Kanban и другие методы управления проектами, основанные на идеях TPS, адаптированы под разработку ПО с помощью Agile. Если попытаться представить схему взаимодействия этих понятий, то получится сложная структура связанных друг с другом принципов, философий и методологий (под XP можно подразумевать другие инструменты гибкой методологии разработки):

Взаимодействие различных методологий гибкой разработки

Основное преимущество Agile заключается в его гибкости. Этот подход можно любым способом менять под себя. Вот почему так много других систем управления проектами основываются именно на нём.

Agile, помимо Kanban и Lean, включает в себя такие практики, подходы и методологии, которые помогают создавать продукт более эффективно, например:

экстремальное программирование (Extreme Programming, XP);
фреймворк для управления проектами Scrum;
разработку, управляемую функциональностью (Feature-driven development, FDD);
разработку через тестирование (Test-driven development, TDD);
методологию «чистои комнаты» (Cleanroom Software Engineering);
итеративно-инкрементальный метод разработки (OpenUP);
методологию разработки Microsoft Solutions Framework (MSF);
метод разработки динамических систем (Dynamic Systems Development Method, DSDM);

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

Если Agile – это принципы и философия, то Scrum – это набор конкретных правил и регламентов, которые говорят о том, как именно организовывать работу. Довольно часто можно встретить Scrum в сочетании со словом фреймворк, а не словом методология. Фреймворк — это более сформированная методология со строгими правилами.

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

Итак, в Scrum все роли и процессы чётко прописаны. Основные категории Scrum – это команда, события, артефакты и метрики.

Product owner – управляет бэклогом. BackLog – набор требований, которые надо реализовать для того, чтобы продукт был готов. Задачи product owner собрать BackLog, сделать его понятным для команды, выставить приоритеты. BackLog постоянно обновляется в зависимости от текущих целей разработки.
Development team – команда разработки. Люди должны быть кросс-функциональны, т.е. иметь унифицированные компетенции (каждый должен уметь делать все).
Scrum master – координирует команду. Специалист по Scrum, досконально знает этапы, церемонии, артефакты Scrum разработки.

Sprint – время, за которое создается инкремент продукта — готовый для конечного пользователя продукт.
Планирование Sprint’а – участвует вся команда. На планировании Спринта решается, каким будет инкримент, и как организовать работу, чтобы успеть сделать все задачи. Выбираются задачи из бэклога продукта (формируется бэклог спринта).
Ежедневные митинги (daily meeting) – на них обсуждается, что сделано за предыдущий день, что будет делаться сегодня, какие проблемы мешают достижению целей спринта.
Sprint review meeting (обзор спринта) — подведение итогов спринта, демонстрация инкремента продукта для product owner или заказчика. Все члены команды участвуют в этом митинге.
Ретроспектива – на нем высказываются о прошедшем спринте: что было сделано хорошо, то надо улучшить в следующем спринте.

Бэклог продукта;
Refinement — уточнение бэклога продукта (уточнение и упорядочение бэклога). Проводит product owner;
Definition of ready — критерии подготовленности – фокус на требованиях к задачам в бэглоге до планирования итерации;
Definition of done — критерии готовности – определяются на планировании спринта, сводится фокус на инкременте, который надо проверить на соответствие общей идеи продукта.
Пользовательские истории (user stories) – задачи бэклога и спринта.
Покер планирование (Planning poker) — оценка сложности user stories.
Бэклог спринта — максимальное кол-во user stories в спринте
Инкремент продукта.

Velocity (скорость) – среднее кол-во задач, которое команда выполняет в спринт;
Capacity (ёмкость) — доступное время команды;
Диаграмма сгорания задач;
Накопительная диаграмма потока;

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

Agile методология

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

Среди преимуществ Scrum можно выделить:

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

К недостаткам Scrum относятся:

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

Заключение

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

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

В завершение хочется обратить внимание, что для успешного применения гибких методологий в разработке, требуется сильная корпоративная культура и осознанная команда. Т.е., как и в системе TPS, на первое место выходит человек. Об этом не стоит забывать, внедряя современные технологичные ИТ решения в свой бизнес.

Показать ещё 15 комментариев Популярные По порядку Написать комментарий.

От названия статьи уже немного кровавые слёзки, страшно читать дальше

Это примерно "Борщ/морковь/еда/кола - виды салатной солёности"

Андрей, т.к. статья теоретическая, то мне было интересно разобраться что из чего следует и почему. Сейчас со всех сторон тренеры по Agile советуют, как лучше запустить у себя гибкие методологии, а потом внедрить Kanban и "может быть вам нужен Scrum мастер?". Поэтому название символизирует для меня именно сборную солянку терминов, в которых среди моих знакомых досконально никто не разбирается. Статья была моей попыткой разобраться. Прочитала 10ки статей до того, как ее написать. Но если вы посоветуете что-то, где будет более структурировано все расставлено по полочкам, буду признательно

Essential Kanban Condensed resources.kanban.university

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

Не знал про Тойоту, очень позновательно!

Да, за Тойоту отдельное спасибо!

Я так из статьи и не понял, каки образом реализуется принцип «точно в срок» используя Канбан в ИТ, автор может пояснить по подробнее?

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

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

За счет чего?
Почему это принцип «точно в срок»?
А не принцип «когда вы мне все это сделаете»?
В чем разница?

Карина! Спасибо! Подписался по колокольчику)

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

Например, в скрам-артефактах собрано все подряд, чего и нет в скрам-гайде: definition of ready, planning poker даже не упоминаются в гайде.
Скрам не появился в 1986. В 1986 вышла статья The New New Development game, где упоминается термин Scrum из регби. Только в 1993-1995 годах оформились первые идеи с виде фреймворка.

Про Канбан-метод - ну совсем мимо кассы.
Agile - это не методология, не управления и не проектами. И фраза "Lean, Kanban и другие методы управления проектами" убивает наповал. И т.д.

Было бы здорово услышать от автора пояснения про описанные в статье особенности Канбан метода. Особенно про ограничения.

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

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

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

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

Мы у себя применяем классы обслуживания. Например, они задаются SLA на сервисы, например на уровень критичности ошибок.
В таком случае критические ошибки с приоритетным SLA, берутся в работу без очереди. Чтобы это стало возможным с небольшим влиянием на "обычные" задачи, резервируется определенный % от ресурсов команды, который не используется под планирование "обычных" задач. Если "критических" ошибок не случилось за какой-то период, "обычные" задачи можно сделать быстрее.

И это только по одному ограничению. А что с остальными? Вы их тоже не рассматривали?

"Сложно отслеживать качество выполнения задачи и эффективность отдельного сотрудника."
Почему? В чем вы видите сложности? Почему их нет в сравниваемом Scrum (раз они не указаны в минусах)?

"Команда должна работать как единый механизм, если кто-то тормозит процесс, страдают все. В связи с этим метод плохо работает для команды более 5 человек." Почему вы так решили? Как быть с примерами, когда по процессу, построенному с помошью Канбан метода успешно работают команды в 10-20 человек? Вы не указали этот минус для Scrum - в нем нет такой проблемы?

"Сложно совместить кросс-функциональные команды на одной доске." — в чем вы видите проблему сложности?

"Не предназначен для долгосрочного планирования." — почему вы так решили?

Изучите kanban с помощью Jira Software

Claire Maynard

Просмотр тем

Учебное руководство по kanban

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

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

Вы только начинаете знакомство c разработкой программного обеспечения по методике Kanban и (или) с помощью Jira Software.

Вы создали аккаунт Jira Software.

Что такое Kanban?

Методика kanban, подобно scrum, помогает командам выпускать ПО быстро и часто. Однако с kanban команды получают большую свободу действий с точки зрения планирования и исполнения. Работа выполняется не в рамках ограниченных по времени спринтов, а непрерывно, при этом команда берет отдельные рабочие задачи из бэклога и продвигает их на стадию «Завершено».

Шаг 1. Создание проекта kanban

При входе в Jira Software вам будет предложено создать проект. На этапе выбора типа проекта выберите проект разработки программного обеспечения по методике kanban.

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

Этап 2. Настройка рабочего процесса

Создав проект Kanban в Jira Software, вы получаете готовый рабочий процесс со столбцами Backlog (Бэклог), Selected for Development (Выбрано для разработки), In Progress (В процессе) и Done (Завершено). Владелец продукта может добавлять задания в бэклог и перемещать их в столбец Ready for Development (Готово к разработке), когда задания или пользовательские истории будут подготовлены. Участники команды могут затем выбирать задания из этого столбца и перемещать их в столбцы In Progress и Done. Если ваш процесс разработки отличается от приведенного примера, добавить или удалить этап рабочего процесса не составит труда. Например, многие команды добавляют в свой рабочий процесс этап оценки качества или проверки.

Чтобы настроить столбцы и рабочий процесс, нажмите Board (Доска) в правом верхнем углу бэклога и выберите Configure (Настроить).

На странице настройки доски выберите Columns (Столбцы) в боковой панели. С помощью кнопок справа можно добавить статус или столбец; нажатием значка корзины столбец можно удалить. Когда вы закончите настройку столбцов рабочего процесса, нажмите кнопку Back to board (Вернуться на доску) в правом верхнем углу.

Шаг 3. Добавление заданий, багов и пользовательских историй в бэклог

Что такое пользовательские истории?

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

Чтобы создать пользовательскую историю, в качестве примера представим веб-сайт.

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

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

Шаг 4. Расстановка приоритетов в бэклоге

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

Расстановка приоритетов в kanban

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

При добавлении задач на доску может быть целесообразно сопровождать их меткой о приоритетности. Тогда при расстановке приоритетов самые важные задачи будут видны сразу. По умолчанию в kanban на доску добавляются дорожки: одна — для элементов с высоким приоритетом, которые сопровождаются меткой Expedite (Срочный), другая — для всего остального. Различные инструменты, например метки, и возможности позволяют относить рабочие задачи к разным категориям.

Что такое «дорожки»?

С помощью дорожек можно отнести задачи к разным категориям, чтобы команда agile понимала, над какими задачами нужно работать в первую очередь. Чтобы отредактировать дорожки по умолчанию, перейдите в окно настройки доски в правом верхнем углу бэклога и выберите Swimlanes (Дорожки) в боковой панели. На появившемся экране можно добавлять дорожки, назначая задачам категории с помощью языка JQL.

Шаг 5. Выбор работы из бэклога

В рамках методики Kanban участники команды берут элементы из столбца Backlog (Бэклог) или Selected for Development (Выбрано для разработки) и переносят в столбец In Progress (В процессе).

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

Зачем нужно ограничивать объем незавершенной работы?

Вы можете установить лимиты незавершенной работы (WIP), то есть минимальный и максимальный объемы работы, содержащиеся в каждом столбце доски. Ограничения WIP помогают уменьшить объем работы, которая близка к завершению: команды вынуждены сосредоточиться на меньших группах задач. Это значительно повышает качество работы команды на всех стадиях процесса. Ограничения WIP также помогают выявить проблемные места в конвейере поставки программного обеспечения команды, прежде чем ситуация станет непоправимой. Благодаря этому клиенты чаще получают поэтапно поставляемую ценность. Вот почему ограничения WIP так высоко ценятся в Agile-разработке. Подробнее см. здесь.

В Jira Software можно добавить нижний и верхний пределы для каждого столбца в разделе Columns (Столбцы) окна настройки доски.

Шаг 6. Проведение совещаний в команде

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

Что такое ежедневный стендап?

Обязательный состав участников: команда разработчиков и владелец продукта

Необязательно: заинтересованные стороны в команде

Когда проходит: раз в день, как правило, утром

Продолжительность: не более 15 минут. Не занимайте конференц-зал и не давайте участникам стендапа садиться. Если все будут стоять, собрание не займет много времени.

Методика agile: scrum и kanban.

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

«Что мне удалось завершить вчера?»
«Над чем я буду работать сегодня?»
«Есть ли препятствия в моей работе?»

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

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

Шаг 7. Использование контрольного графика

Вы можете регулярно сверяться с контрольным графиком, чтобы отслеживать ход работы команды.

Что такое контрольный график?

На контрольном графике выводится следующая информация.

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

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

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

Шаг 8. Использование бэклога kanban (необязательно)

Многим командам нравится гибкость Kanban, но иногда начинает казаться, что первый столбец доски (бэклог) переполнен — и с этим ничего нельзя поделать. Поэтому мы добавили бэклог в проекты разработки программного обеспечения по методике Kanban.

Бэклог Kanban — это бэклог для доски, расположенный в другой вкладке проекта. Так у менеджеров по продукту появляется больше пространства, специально предназначенного для составления бэклога и расстановки приоритетов в нем, а команде больше не приходится отвлекаться от текущей работы. Менеджер по продукту может перемещать работу из бэклога в столбец Ready for development (Готово к разработке), чтобы предупреждать команду о предстоящей работе.

Войдите как пользователь с глобальным правом администратора Jira.
На верхней панели выберите Jira Administration >Applications (Администрирование Jira > Приложения), затем прокрутите страницу вниз до раздела Jira Software.
Под заголовком Jira Software Labs выберите интересующие вас возможности.
Burnup Chart (диаграмма Burnup)
Kanban backlog (бэклог Kanban)

Расширенные методики

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

Шаг 9. Автоматизация повторяющихся задач

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

Некоторые наиболее распространенные правила автоматизации для Kanban можно найти в библиотеке шаблонов Jira Automation.

Шаг 10. Использование ограничений столбцов

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

Задать ограничения столбцов на доске можно в разделе Columns (Столбцы) окна настройки доски. Установите там нижний и верхний пределы для каждого столбца.

Если количество задач в столбце Selected for Development (Выбрано для разработки) или In Progress (В процессе) превышает 10, верхняя часть этих столбцов окрасится в красный цвет:

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

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

Чтобы узнать, как это сделать, обратитесь к разделу «Настройка столбцов».

Шаг 11. Использование сводной диаграммы процесса

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

В Jira Software на сводной диаграмме процесса показаны стадии, на которых пребывали задачи команды в течение определенного периода времени.

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

Сводная диаграмма процесса оптимально подходит для прогнозирования потенциальных проблемных мест.

Канбаньте с умом: 3 правила и 6 вредных советов для ведения канбан-доски

Я руковожу разработкой Granatum и являюсь product owner платформы. В этой статье я хочу рассказать о том, как мы используем канбан в ежедневной работе, и поделиться с вами своими лайфхаками и набитыми шишками.

Пример классической канбан-доски в три колонки на Granatum

Канбан сейчас однозначно ассоциируется с IT-сферой и программированием. Однако эта система впервые появилась на заводе Toyota еще в 1959, а уже в 1962 году ее начали использовать повсеместно. В основе канбана — работа главного конвейера для поставки деталей точно в срок, чтобы они не залеживались на складе.

В IT-отрасли эта система используется с 2005 года в таких компаниях, как Microsoft и Corbis. Интересный пример — бренд одежды «12 Storeez»: канбан здесь начали внедрять на уровне топ-менеджмента, создав доску, объединяющую задачи по всему процессу производства — от идеи до склада.

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

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

Основные принципы канбана

Обобщив свой 10-летний опыт применения этого фреймворка в работе, я сформулировала для себя 6 важных принципов:

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

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

«бэклог», или склад идей;
“в работе” — то, что выбрано для работы в данный момент. Важно назначать каждую такую задачу конкретному ответственному;
“приемка/проверка” — этап перед окончательным завершением работы, на котором происходит проверка соответствия критериям приемки или согласование и утверждение;
“завершено“ — финальная стадия.

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

3. У каждой задачи есть ответственный: поощряйте лидерские качества сотрудников, чтобы они не боялись брать на себя ответственность.

4. Организуйте не команду, а работу, то есть конкретные задачи — и пусть ваши сотрудники соорганизуются вокруг этих задач.

5. У канбана есть свой ритм: выработайте оптимальный для вашей команды темп и придерживайтесь его.

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

Где, как и для чего вести канбан-доску

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

Мы используем канбан и для маркетинговых активностей, в том числе для организации собственных конференций, которые проводим 1-2 раза в месяц: задачи для разных участников стекаются на доску, где каждому удобно их отслеживать, отражать статус и передавать таск дальше. Такая организация работы очень полезна и наглядна и для руководителя: реальная картина видна здесь и сейчас, и дополнительные программы типа excel или google docs уже не нужны. Всё четко и понятно.

Сервисов для ведения канбан-досок онлайн сегодня довольно много: jira, trello, bitrix24, wrike, TargetProcess, SwiftKanban, LeanKit и многое другое. Мы работаем в jira и bitrix24.

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