Это не официальный сайт wikipedia.org 01.01.2023

Канбан-доска — Википедия
Википедия

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

Канба́н-доска́ является одним из инструментов, который может использоваться при внедрении метода управления разработкой «Канбан».

Такие доски можно рассматривать как вариацию на тему традиционных канбан-карточек. Вместо сигнальных карточек, которые обычно обозначают потребность или пропускную способность, вместе с доской используются магниты, пластиковые фишки, цветные шайбы или стикеры для представления рабочих элементов и процессов.[1] Каждый из этих объектов представляет собой этап производственного процесса и движется по доске, по мере прогресса. Такое движение соответствует движению процесса производства. [2] Доска, как правило, разделена на три логические секции: «ожидание», «работа в процессе» и «завершенная работа». Сотрудники перемещают заметки в ту секцию доски, которая соответствует статусу задачи. [3]

Пример канбан-доски

ПриложениеПравить

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

Самые простые доски состоят из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). [4]

Наиболее популярная интерпретация канбан-доски для гибкой методологии разработки или, так называемой, lean-разработки включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), пишется код (coding), тестируется (testing), подтверждается (approval) и сделано (done). Также распространена практика именования столбцов иначе, например: далее, разработка, готово, одобрение клиента, перенос изменений на рабочий сервер[5].

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

 

  • Канбан для маркетинговых команд[6]
  • Канбан для HR команд[7]
  • Управление личными задачами: так называемый «Личный Канбан»[8] был описан и стал популярен благодаря Джиму Бенсону.[9]

Основные принципыПравить

  • визуализация рабочего процесса
  • ограничение работы, которая находится в процессе[10]
  • перемещение задач от колонки к колонке
  • мониторинг, адаптация и оптимизация[11]

Онлайн-канбан-доскаПравить

Хотя первоначально канбан-доска была реализована в физической форме, многие команды, особенно распределенные, пришли к пониманию удобства использования онлайн-досок [12].

Развитие онлайн-досок в стиле Kanban получило новый толчок в последнее время. Обусловлено это необходимостью работы по методологии 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:

  • Blockers — задачи и баги, которые надо править в режиме реального времени. Пример – сломанная регистрация.
  • Tasks and Bugs – обычные текущие задачи и баги.
  • Someday — задачи, которые потеряли актуальность по той или иной причине.

Система схожа с квадрантом Эйзенхауэра. Важные и срочные вопросы — это Blockers. Важные, но несрочные — Tasks and Bugs. Неважные и срочные, а также неважные и несрочные — это Someday. К слову, отсутствие горизонтальных колонок — один из факторов, подтверждающих чего не хватает Trello для Agile разработки.

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 — необходимое, но не достаточное условие для успеха продукта или проекта.

См. такжеПравить

ПримечанияПравить

  1. ↑ Kanban Guide: Demand Scheduling for Lean Manufacturing, Compiled by Nilesh R Arora. Add ValueConsulting Inc., India 2001, p. 11.
  2. ↑ J. M. GrossKenneth, R. McInnis: Kanban Made Simple—Demystifying and Applying Toyota's Legendary ManufacturingProcess. Amacom, USA 2003, p. 50. ISBN 0-8144-0763-3
  3. ↑ Kanban Guide: Demand Scheduling for Lean Manufacturing, Compiled by Nilesh R Arora. Add ValueConsulting Inc., India 2001, p. 11
  4. ↑ H. Kniberg, M. Skarin: Kanban and Scrum making the most of both. C4Media, Publisher of InfoQ.com, USA 2010, p. 31.
  5. ↑ codeweavers. [http://codeweavers.net/agile-design-kanban-with-our-web-designers/ Agile Design: Kanban with our Web Designers - Design, Process Updates | Codeweavers Blog | Staffordshire Software Development House]  (неопр.). Codeweavers.net (17 августа 2012). Дата обращения: 7 ноября 2014. Архивировано 29 августа 2012 года.
  6. ↑ J. Dager: Why you should use Kanban in Marketing?,http://business901.com/blog1/why-you-should-use-kanban-in-marketing/ Архивная копия от 18 июня 2013 на Wayback Machine
  7. ↑ Kanban for Short Intense Projects: How We Used Kanban to Visualize Our Hiring Process Workflow and Make Our Lives Easier  (неопр.). Personal Kanban (19 января 2011). Дата обращения: 17 августа 2012. Архивировано 12 июля 2012 года.
  8. ↑ Benson, Jim, and Tonianne DeMaria Barry. Personal Kanban: Mapping Work, Navigating Life. Modus Cooperandi Press, 2011.
  9. ↑ Willeke, Marian HH. "Agile in Academics: Applying Agile to Instructional Design." Agile Conference (AGILE), 2011. IEEE, 2011.
  10. ↑ Building Your First  (неопр.). Personal Kanban (август 2009). Дата обращения: 17 августа 2012. Архивировано 19 августа 2012 года.
  11. ↑ J. Boeg, Priming Kanban,
  12. ↑ Eckenfels, M. Tolle Tafeln (нем.) // Linux Magazin. — Germany: Linux New Media, 2014. — Июнь. — С. 44—45. — ISSN 1432-640X.

Внешние ссылкиПравить

Источник — https://ru.wikipedia.org/w/index.php?title=Канбан-доска&oldid=128235391