Kanban что это

Методология Kanban: доски, принципы и возможности управления

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

Вы когда-нибудь собирали вместе группу людей, чтобы создать продукт или запустить проект? В качестве бонусов — жёсткий дедлайн, объемное техзадание и несговорчивый заказчик. Получилось? Всему этому мы учим на курсе «Руководитель digital-проектов».

Волшебной таблетки для решения всех проблем не существует. Но есть методы, которые упрощают работу команды. Один из них ― Kanban.

Что такое Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Цель Kanban

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

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

Доски Kanban

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

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

Как устроен Kanban в проектах

У каждого проекта есть план процесса работ. Сначала мы его анализируем и разделяем доску на столбцы, которые отражают этапы. Например, для процесса создания IT-проекта этапы могут быть такими:

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

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

C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект.

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

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

Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, поэтому каждый может увидеть свой вклад и ценность для проекта.

В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жёстких правил, но есть принципы, на которые можно опираться.

Как помогает визуализация

Визуализация помогает видеть картину целиком и корректировать отдельные её части, понимая, как изменения затронут весь проект. Получить результат точно в срок возможно, если контролировать нагрузку команды. Определите количество задач: сколько команда реально способна решать в установленные сроки. Например, в «Проектировании» одновременно ― не больше двух задач, а на «Тестировании» ― только одна. Всё в зависимости от возможностей команды.

Ситуация: разработчик ещё не закончил с текущей задачей, а ему уже поступила следующая. Он не успевает и тормозит всю работу.

Решение: прекратить передавать задачи в разработку и дать программисту время закончить текущую.

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

Ситуация: на этапе тестирования продукта возникли трудности. Нужно больше времени.

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

Чем отличаются
Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Но это не совсем так.

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

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

Команда уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Как внедрить Kanban

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

Заключение

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

В Skillbox есть курс, который прокачает вас в управлении проектами. Вы сможете внедрять в свою работу любые agile-системы и будете уверены в результате.

Источник

Что такое канбан и как не «похоронить» проект в Trello

История канбана

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

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

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

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

Принципы канбана

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

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

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

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

Применение канбана

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

Канбан-метод придумал американский эксперт в области менеджмента Дэвид Андерсон с целью оптимизации процессов в интеллектуальных профессиях (разработчики, маркетологи, дизайнеры и так далее). Его применяют многие крупные мировые компании: Microsoft, Intel, Hewlett-Packard, Meizu. В России интересные кейсы у Тинькофф Банка, HeadHunter, REG.RU.

Производственный «канбан» подходит для оптимизации процессов на различных предприятиях, а также в рамках lean manufacturing (бережливого производства). Например, применительно к компании «Газпром нефть» метод зарекомендовал себя как инструмент, который повышает эффективность снабжения месторождений, где компания ведет или планирует вести добычу.

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

«В Mail.ru Cloud Solutions используется Scrum. Обе эти методологии относятся к Agile-подходам, но сильно различаются между собой. Канбан позволяет выполнять потоковые работы и оценивать пропускную способность, Scrum — решать новые задачи разной сложности, дробить их на подзадачи, контролировать и корректировать ход работ и скорость выполнения. Поэтому канбан подойдет, например, для call-центра или отдела техподдержки, но не для разработчиков», — рассказывает Мурад Бяшимов, руководитель команды Mail.ru Cloud Solutions.

Канбан-доска

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

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

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

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

Ключевые правила работы с канбан-доской:

Ошибки в применении канбана

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

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

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

Ошибка 3. Не фиксировать срочные задачи на канбан-доске. В результате происходят перекосы рабочего процесса.

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

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

Ошибка 6. Не актуализировать статус задачи (например, задача выполнена, а на доске она еще в процессе работы). Это может создать неправильное представление о загрузке команды и статусе проекта.

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

Ошибка 8. Перегружать команды: если в одной колонке больше 15 карточек, то ее уже сложно воспринимать комплексно в контексте других задач, создается локальный «захлеб». Решение — добавлять более крупные задачи и дробить их внутри на подзадачи (например, используя чек-листы).

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

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

Ошибка 11. Отсутствие приоритетов и ответственных за исполнение задач.

Сервисы для ведения канбан-досок

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

Trello — самый популярный и интуитивно понятный сервис, подходящий для проектов из разных сфер. Здесь можно создавать любое количество досок с разным составом команды (в бесплатной версии есть ограничение на количество досок). К карточкам можно добавлять разноцветные метки, прикреплять вложения и оставлять комментарии. Число колонок не ограничено. Однако по мере эволюции процесса, когда компания будет применять разные практики, инструментов этого сервиса может стать недостаточно, возникнет потребность расширить функционал. Именно поэтому Trello купила компания Atlassian, чтобы аудитория органически перетекала в схожий, но платный и более сложный инструмент — JIRA, откуда пользователь уже сможет перейти на еще более широкий пакет софта в облаке, если ему нужно, например, хранить документацию по проекту, или обсуждать задачи более удобный образом.

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

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

Kaiten — российский сервис, максимально адаптированный к применению всех инструментов канбана и позволяющий собирать большой объем аналитики.

В целом сервисов для применения канбана довольно много: Сonceptboard, Taskify, Targetprocess, Favro, Higger, Smartsheet, TargetProcess, SwiftKanban, LeanKit, Miro, Blossom, ZenHub, MeisterTask, Kanbanchi, Breeze, ProofHub, Битрикс24, YouTrack, Asana, Kanbanery.

Как не «похоронить» проект в канбане

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

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

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

В создании материала также участвовали:

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

Источник

Канбан в 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. Почувствуйте разницу.

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

Источник

13 причин перейти на Kanban. И никаких суеверий

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

Что такое Kanban?

Разберем следующий пример, рассмотрев две ситуации.

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

Вторая ситуация – шоурум Toyota в наши дни. Покупатель выбирает модель и вносит оплату. Однако на складе Toyota в этот момент нет вашего цвета автомобиля. Заказ отправляется в головной офис Toyota. Вам сообщают сроки, когда машина будет доставлена. Только с этого момента автомобиль начинают производить. Специально для вас. Налицо принцип: сперва продажа, потом производство. Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.

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

Одной из ключевых составляющих JIT-принципа является Kanban. Доски и карточки Kanban – это своеобразные светофоры в системе just in time. Kanban дает возможность бизнесу быть реактивным по отношению к потребностям клиента вместо прогнозирования потребностей, как это случилось в первой описанной ситуации.

Можно спроецировать похожий пример на область разработки ПО:

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

Случается и обратная ситуация: у QA скапливается очень много задач и он/она не успевает все вовремя проверять. В этом случае, срок выпуска продукта также откладывается.

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

Для чего разработке ПО нужен Kanban?

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

13 причин перейти на Kanban

Вот 13 причин, по которым стоит внедрять Канбан в IT компании, которые занимаются разработкой ПО:

1.Определение узких мест

Переход на Kanban доски с обычных списков задач сразу показал нам узкое место: в колонке Testing скапливалась большая очередь задач. Наш QA не справлялся с проверкой задач. Он брал задачи на проверку с большой задержкой. После того, как тестировщик возвращал задачу на доработку, программист уже успевал ее забыть. Приходилось снова смотреть код и вспоминать детали. Как понимаете, это драгоценное время. Команде потребовался еще один тестировщик.
Kanban доска позволяет увидеть узкие места в вашем процессе, где образуются очереди. В Hygger.io c этой задачей помогают справиться WIP лимиты. Если у вас больше или меньше задач, чем нужно — колонка подсвечивается красным или желтым цветом соответственно.

2. Точный порядок выпуска фич

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

3. Приоритет главным задачам

Kanban учит отдавать главное внимание главным вещам. Тому, что реально добавляет ценности продукту. Мы смогли «опустить» вниз множество бесполезных багов и доработок. Это дало результат.
Отличать важные баги от менее приоритетных – непростая задача для менеджера продукта, но здесь ему на помощь приходит функция Swimlanes. Это горизонтальные колонки на Kanban доске. Как правило, у программистов на доске присутствуют такие Swimlanes:

4. Концентрация на работе

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

5. Панорамный вид

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

6. Гибкость

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

Чем чаще такты, тем команда разработки становится более гибкой. Для нашей команды идеальный такт составляет 8-12 часов. Крупные задачи обязательно декомпозируются.

7. Не нужно оценивать фичи

Scrum забирал много времени на оценку фич перед стартом спринта. С Kanban потребности в оценке нет. Когда сделаем, тогда и будет сделано.

8. Больше дела

Scrum предполагает много коммуникации. Начало спринта сопровождается планированием: анализом и оценкой задач. Каждую неделю обязательны стенд-апы. После окончания спринта проводится ретроспектива. По итогу, вся коммуникация отнимает около 30% времени. А ведь это время команда могла бы потратить на работу.

9. Командный дух

С Kanban команда начинает работать более согласованно. Сейчас тестировщик проверяет фичу практически сразу после того, как ее сделал программист. Аналогично и в других областях: у дизайнеров, UX, редакторов, сейлзов.

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

10. Ошибаться раньше — быстрее находить решение

В Scrum мы «заливаем» фичи на production только в конце спринта. Примерно раз в 3 недели. В Kanban — практически сразу после приемки тестировщиком. Раз в несколько дней.

Так мы быстрее узнаем, зашла фича пользователям или нет. Если нет — где-то произошла ошибка. А нам важно ошибаться первыми. Это вовсе не означает, что мы любители ошибаться. Но если мы узнаем об ошибке первыми, мы первыми будет знать и решать, что делать.

11. Больше потока

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

12. Больше знаний – лучше для проекта

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

13. Концентрация на одной задаче

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

В качестве заключения

Может показаться, что мы настаиваем на том, что Kanban лучше Scrum. Но это не так. Всему свое время. Опыт Hygger позволяет утверждать: Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.

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

Источник

Методология Kanban: введение

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

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

Если вам не хочется читать — я сделал видео, где на пальцах описываю историю и основные принципы метода Канбан.

История термина

Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.

Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала — 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики — количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.

В упрощенном варианте, Kanban включает в себя два простых правила:

Настоящее время

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

Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Предлагаю рассмотреть пример использования Kanban в разработке программного обеспечения. Заранее прошу простить за некрасивые иллюстрации. Давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе — 1 шт.

В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, наш разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. В общем все! Kanban — это не просто, просто. Это очень просто!

Заключение

В заключение, хочу добавить, что сравнение любых методологий по принципу «кто круче» не продуктивно и контр-конструктивно (капитан очевидность). Каждая, более-менее распространенная, методология имеет свои плюсы, минусы и границы применения. Дополнительно, Agile-методологии в принципе накладывают большие требования на сработанность и опыт членов команды.

В случае возникновения интереса к теме продолжу рассмотрение Kanban’a подробнее. В последствии, предлагаю разобрать по полочкам и картинкам Scrum и RUP.

Более подробно, и наглядно можно посмотреть в:

Источник

14 Лучших Kanban Инструментов в 2019 Году

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

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

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

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

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

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

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

Что включает в себя мощное Канбан ПО

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

Тем не менее, существуют решения, которые выполняют работу лучше и эффективнее других. Рассмотрим главные критерии для поиска лучшего Канбан-инструмента:

Лучшие Канбан инструменты для управления проектами

У вас, по сути, есть два пути:

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

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

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

Trello

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

Сомнения: Trello не имеет своего собственного учета времени, поэтому вам придется платить за другое программное обеспечение (например, Everhour или Toggle). Кроме того, в Trello нет функций WIP limits, Swimlanes и диаграмм Burndown.

Hygger

Hygger — яркий представитель нового поколения PM-инструментов, который отлично подходит продуктовым компаниям, стартапам и организациям средних размеров. Сервис предоставляет удобные to-do листы с кастомными полями, Канбан досками, функциями Swimlanes, WIP limits и Timelines.

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

Hygger предлагает определять приоритеты с помощью простых методов (Eisenhower matrix, Value vs Effort, Value vs Risk), а также продвинутых техник (ICE и RICE, Weighted Scoring).

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

Asana

Asana – не менее популярный сервис с доступными iOS и Android приложениями, который хорош в управлении задачами, отслеживании дедлайнов и постановке приоритетов. Asana позволяет качественно следить за статусом выполнения задач и статусом проекта в целом.

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

Сомнения: Платформа вряд ли будет полезна маркетинговым и креативным агентствам или сервис-компаниям.

Favro

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

Функция Breakdown в Favro помогает разбить ваши проекты на различные задачи. Инструмент интегрирован с Google Drive и Dropbox, что позволяет прикреплять файлы к доске планирования.

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

MeisterTask

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

Канбан доски MeisterTask помогают пользователям просматривать и управлять текущими действиями и активными проектами, создавать планы проектов и сотрудничать с членами команды. Платформа предлагает интеграцию с GitHub, DropBox, Zendesk и Bitbucket.

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

Kanbanchi

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

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

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

Paymo

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

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

Breeze

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

Инструмент основан на принципах Agile и Lean и включает в себя следующие основные функции: списки задач, отслеживание времени, бюджетирование проекта, отчетность, календарь, экспорт данных, неограниченное количество пользователей, поддержка Android и iOS, интеграция с Google Drive и Dropbox, и т.п.

Сомнения: Малое количество инструментов, с которыми Breeze может быть интегрирован.

Blossom

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

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

Сомнения: Нет бесплатного плана для личного использования. Интеграционные возможности — только отправление обновлений на канал Slack.

ProofHub

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

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

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

ZenHub

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

Инструмент можно использовать для организации, планирования и запуска спринтов. Нет необходимости в специальном обучении — ZenHub широко используется как командой разработчиков, так и продуктовиками. Основными функциями являются Kanban-доски, списки дел, графики Burndown, оценки времени, интеграция со Slack и др.

Сомнения: Zenhub не предоставляет достаточно аналитических и отчетных функций. В UX есть некоторые «причуды», которые могут периодически отвлекать и беспокоить.

Taiga

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

Сервис можно легко интегрировать с GitHub, GitLab, Webhooks, Bitbucket и Gogs. Доступны мобильные приложения для Android, iOS и Windows.

Сомнения: Интерфейс выглядит немного старомодно. Экраны довольно сложные — это немного запутывает работу с разными их видами.

LeanKit

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

LeanKit предлагает удобный способ соединения досок проектов на уровне команды и проекта и предоставляет пользователям полную видимость. Вы также получите модуль отчетности и аналитики с полезными показателями и метриками. Платформа поддерживает интеграцию с JIRA, Zendesk, Pivotal Tracker и другими инструментами.

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

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

Источник

Что такое Канбан и как внедрить методологию в компании

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

Что такое Kanban

Канбан — это система организации для управления задачами в бизнес-процессах. Инструмент позволяет оптимизировать работу команды через разделение объемных этапов на отдельные операции. Цель внедрения Канбан — контроль за рабочим процессом и отслеживание нагрузки специалистов.

Канбан: краткая история

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

Гипермаркеты

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

Автомобильные заводы

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

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

Разработка ПО

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

Где можно применять канбан-методологию

С помощью системы Канбан вы сможете гибко планировать задачи, контролировать сроки, повысить эффективность работы и видеть весь процесс наглядно. Метод применим в разных сферах: IT, маркетинге, строительстве. Главное, чтобы в бизнесе можно было выделить этапы и типы работ.

Промышленное производство

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

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

Управление IT-проектами

В этом случае детали и запчасти заменяет ПО, а сотрудников производства — программисты, тестировщики и другие разработчики IT-проектов. Например, для создания сайта подключают дизайнера. Он рисует 2–3 макета будущего ресурса и после утверждения один из них передает в работу программисту. По макету программист пишет этот сайт, а затем тестировщик выявляет ошибки. Каждый специалист занимается своим делом, исходя из того объема работы, который выполнил предыдущий участник проекта.

Чтобы сайт компании приносил прибыль, нужно повышать его конверсию. Виджеты Calltouch автоматически обрабатывают обращения клиентов с сайта и лидформ TikTok, Facebook* (продукт компании Meta, которая признана экстремистской организацией) и ВКонтакте, а также собирают заявки в нерабочее время. Скрипт перезвонит клиентам, как только колл-центр начнет работать. Используйте бесплатные виджеты и оплачивайте только минуты разговора.

Увеличение продаж

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

Google Drive: что это и как с ним работать

Google Drive: что это и как с ним работать

Ускорение воронки продаж в B2B-бизнесе

Принципы работы с воронкой продаж:

Построить полноценную воронку продаж от показов рекламы до ROI можно в сквозной аналитике Calltouch. Благодаря этой системе все каналы трафика под контролем: ни один лид не пропадет. Все отчеты формируются в удобных дашбордах и позволяют оценивать эффективность и вовлеченность ЦА каждого рекламного инструмента. Выведите ваш маркетинг на новый уровень, увеличивая прибыльность компании.

Личное планирование

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

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

Как помогает визуализация

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

Есть две разновидности системы. Оба варианта применяют на производстве, но при необходимости могут адаптировать и под другие виды деятельности.

Тарный канбан

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

Система заказов по тарному канбану работает следующим образом:

Карточный канбан

Это карточки Канбан, которые показывают:

Цвет бирки может быть:

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

Принципы Канбан

Система Канбан основана на принципах:

Инструменты

При работе с Канбан используют:

Преимущества и недостатки

К достоинствам Канбан относят:

Сравнение Kanban и Scrum

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

Применение Канбан

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

Метод применяют многие IT-компании, например, Microsoft. Канбан внедряют на промышленных производствах, HR-сервисах, закупках.

Примеры применения системы канбан на предприятии

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

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

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

Например, процесс коммуникации с новыми клиентами разделяют на несколько шагов: от первого контакта до подписания бумаг. Для каждого этапа есть регламент, подготовленные образцы документов, скрипты. Это упрощает общение с клиентами и минимизирует временные затраты на работу.

Как внедрить Канбан в компанию

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

Есть шесть правил внедрения метода в организацию:

Визуализируйте поток работы

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

Ограничьте число одновременно выполняемых задач

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

Управляйте потоком задач

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

Обсудите правила работы

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

Анализируйте деятельность

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

Экспериментируйте и улучшайте рабочие процессы

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

Приложения и программы для Канбана

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

Trello

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

Kanbantool

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

LeanKit Kanban

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

Kanbanize

Worksection

Jira Software

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

Маркировка товаров: что это такое и с какими товарами делать

Источник

Kanban

Использование методологии Kanban при разработке ПО

Просмотр тем

Что такое Kanban?

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

Начните бесплатно с шаблоном Kanban для Jira

Статьи о Kanban

Что такое kanban-доска?

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

Использование лимитов незавершенной работы в Kanban

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

Сравнение Kanban и Scrum

Определите, что больше подойдет вашей agile-команде, — Kanban или Scrum. Узнайте, в чем главные различия этих платформ.

Kanplan: Kanban и бэклог

Kanplan позволяет использовать бэклог и методики его ведения из Scrum в Kanban. Бэклог используется вместо столбца «Сделать» для планирования и приоритизации работы.

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

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

Задачи на досках Kanban в Jira — от постановки до выполнения

Доска Kanban в Jira Software помогает командам непрерывно улучшать время циклов и повышать эффективность работы.

Хотя методика Kanban зародилась более 50 лет назад, она невероятно популярна среди современных Agile- и DevOps-команд разработчиков. В конце сороковых годов XX века компания «Тойота» начала использовать модель заполнения полок в супермаркетах, чтобы оптимизировать технологический процесс. Супермаркеты выставляют ограниченное количество товаров, которого при этом достаточно для удовлетворения потребительского спроса. Таким образом оптимизируется поток товаров между супермаркетом и потребителем. Если уровень запасов соответствует потребительскому спросу, значительно увеличивается эффективность управления складом, ведь избыточных запасов — которые тоже нужно где-то хранить — становится меньше. При этом супермаркет по-прежнему гарантирует, что нужный потребителю товар всегда есть в наличии.

Компания «Тойота» применила эту систему в своих цехах, чтобы лучше соотнести внушительные складские запасы и реально используемые в производстве материалы. Для отслеживания объемов производства в цехе (и взаимодействия с поставщиками) в режиме реального времени использовалась специальная карточка, или Kanban, которую рабочие передавали между командами. Когда в корзине заканчивались используемые на участке производства материалы, на склад передавали Kanban с указанием необходимого материала, нужного количества и т. д. На складе уже стояла новая корзина с этим материалом: ее отправляли в цех, а складские работники отсылали поставщику свой Kanban. У поставщика корзина с этим материалом тоже была готова, и он отправлял ее на склад. Конечно, в современном мире сообщения передаются совсем не так, как в сороковых, но смысл остается тем же — все основано на процессе «своевременного» производства (JIT).

Kanban для команд разработчиков ПО

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

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

Kanban-доски

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

Доски нужны, чтобы визуализировать работу команды, стандартизировать процесс, а также найти и устранить блокеры и зависимости. И не важно, в какой форме они представлены — в физической или в цифровой. На стандартной Kanban-доске процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако доску можно настроить в соответствии с процессом, принятым в той или иной команде, в зависимости от ее размеров, структуры и целей.

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

Kanban-карточки

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

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

Преимущества Kanban

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

Гибкость планирования

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

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

Сокращение времени цикла

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

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

Меньше узких мест

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

К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода можно установить лимит WIP, равный 2. Число может показаться маленьким, но на все есть свои причины: разработчики предпочитают писать собственный код, а не проверять чужой. Низкий лимит стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода. В конечном итоге это сокращает общее время цикла.

Наглядность

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

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

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

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

Непрерывная поставка

Непрерывная поставка (CD) предполагает частую поставку релизов продукта клиентам. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе они образуют конвейер CI/CD, без которого сложно обойтись командам разработчиков (особенно командам DevOps), если они хотят быстрее выпускать качественное ПО.

Kanban и CD идеально дополняют друг друга, поскольку обе методики основаны на своевременной (и последовательной) поставке ценности. Чем быстрее команда сможет выпустить инновационное решение на рынок, тем более конкурентоспособным будет ее продукт. Kanban-команды сконцентрированы именно на оптимизации процесса поставки продуктов клиентам.

Сравнение Scrum и Kanban

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

Регулярные спринты фиксированной продолжительности (например, 2 недели)

Непрерывный процессПодходы к релизуВ конце каждого спринта после одобрения владельцем продуктаПоставка выполняется непрерывно или на усмотрение командыРолиВладелец продукта, Scrum-мастер, команда разработчиковРолей нет, в некоторых командах работают тренеры по agileКлючевые показателиСкорость командыПродолжительность циклаОтношение к изменениямВ ходе спринта команды стремятся избегать изменений в прогнозах спринта: изменения приведут к неверным выводам относительно оценки задачИзменение может произойти в любой момент

Некоторые команды объединяют идеалы Scrum и Kanban в Scrumban. Из Scrum берут роли и спринты фиксированной длительности, а из Kanban — ориентацию на время цикла и лимиты незавершенной работы. Но если ваша команда только начинает использовать Agile, мы настоятельно рекомендуем выбрать одну методологию и некоторое время следовать только ей. Поэкспериментировать вы всегда успеете.

Источник

Scrum vs Kanban: в чем разница и что выбрать?

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

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

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

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

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

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

Источник

Эффективный Kanban: Мифы и реальность

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

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

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

Моя отправная точка

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

Ценности, кроющиеся за шестью основными практиками канбана, немного сложнее, не потому, что практики не основаны на ценностях, а потому, что между практиками и ценностями нет буквального соответствия. Я выбрал еще четыре ценности (теперь их уже восемь): прозрачность, баланс, организация потока и сотрудничество. Тем не менее, мне показалось, что будет полезно отойти от представленной очевидной последовательности, и я был вынужден добавить еще одну дополнительную ценность – ориентированность на клиента. Итого получилось девять ценностей.

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

Девять основных ценностей системы канбан

1. Понимание

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

Настаивайте на понимании, потому что потенциально «работоспособный» процесс, суть и назначение которого никто не может объяснить, и есть признак того, что вы забыли, чего вы добиваетесь.
Миф о процессах, блог Rands in Repose

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

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

2. Соглашение

Соглашение упоминается во втором основополагающем принципе: «Предварительно договоритесь о проведении важных изменений». Мне нравится говорить по-другому: ожидаете ли вы успеха в реализации изменения без этого [предварительного соглашения]? Может ли получиться, что именно из-за отсутствия соглашения ваш прогресс столкнется с ограничениями? Или, возможно, есть некая договоренность, но недостаточно подробная: то есть, вы согласны, что проблема существует, но не видите ее причин или воздействия (то есть, отсутствует понимание)?

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

3. Уважение

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

Как и в жизни, хорошо руководить осуществлением изменений с уважением. Увеличатся ли ваши шансы на успех, если вы начнете намекать, что люди плохо выполняют работу или не играют никакой важной роли? Скорее всего, нет. Полезно ли подозревать их в неблагонадежности? Опять же, нет. Но разве уважать – значит просто «быть хорошим»? И снова нет:

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

Такое уважение требует мужества, и это ведет нас к следующей ценности.

4. Лидерство

Лидерство упоминается во многих историях успеха, но только в 2012 году его добавили в основополагающие принципы в виде: «Поощрять инициативу на всех уровнях в организации — от каждого работника до высшего руководителя».

Многое уже написано о лидерстве, и я не буду писать еще больше, только сделаю несколько быстрых наблюдений:

5. Поток

Обращаясь к практикам, мы начинаем с третьей: «Управление потоком».

В этой практике слово «управление» говорит о тактической организации и принятии решений, направленных на работу, ориентированную на оптимальный результат (речь об эффективности). Хоть и с переменным успехом, в какой-то степени это – универсальная стратегия.

Поток («flow») же добавляет словосочетанию более специфическое значение – ощущение плавности и предсказуемости. С учетом этих ощущений систематическое решение вопросов, связанных с задерживающими факторами, становится инструментом для улучшений, который приводится в пример в методологии Lean.

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

6. Ориентированность на клиента

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

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

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

7. Прозрачность

Прозрачность лежит в основе сразу трех основных практик канбана: первого «Визуализировать работу», четвертого «Сделать политики понятными всем», и пятого (еще одно нововведение 2012 года) «Реализовать обратную связь».
Канбан провозглашает прозрачность на нескольких уровнях:

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

8. Баланс (равновесие)

Вторая основная практика – «Ограничение числа задач в работе (WIP)». Есть несколько преимуществ в этом ограничении:

Более подробную информацию о значении баланса в методе канбан можно найти в выступлении Дэвида Андерсона «Когда канбан вам не подходит» [видео], [слайды]. Мое выступление «Когда канбан – это не просто» [видео], [слайды] включает в себя объяснение понятий разнообразия и устойчивости.

9. Сотрудничество

Сотрудничество фигурирует в шестой (и последней) основной практике «Улучшить сотрудничество, развиваться экспериментально [с использованием моделей и научного подхода]».

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

Полная формулировка этой практики включает упоминание о систематической работе, направленной на улучшение понимания через наблюдения, построение моделей, эксперименты и замеры (эмпиризм).

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

Канбан признает основы методологии Lean, теорию ограничений и Agile, принципы теории массового обслуживания и комплексные науки и оказывает [на развитие компаний] такое же разнообразное влияние, как понятие Lean Startup. Отдельные последователи канбана имеют свои собственные любимые модели – я, например, опираюсь на А3, GROW, и Influencer.

Почему достаточно девяти ценностей?

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

А вот и другие ценности, которые я определил:

Как заставить ценности работать

Давайте посмотрим на наши девять ценностей:

Понимание, Соглашение, Уважение,
Лидерство, Поток, Ориентирование на клиента,
Прозрачность, Баланс, Сотрудничество.

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

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

Вам кажется, что в вашей текущей [рабочей] среде чего-то не хватает? Опять же, о чем это говорит вам? Помогает ли это определить вещи, которые действительно необходимо правильно организовать?

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

Источник