История Kanban

Методология разработки ПО KANBAN.

История Kanban

 

Kanban- гибкая методология разработки программного обеспечения, ориентированная на задачи.

Kanban-система организации производства и снабжения позволяющая реализовывать принцип «точно в cрок»:

• Разработана фирмой «Тайота» в 1959 году
• В переводе с японского означает карточка

 

Основная задача:

• Уменьшить количество «выполняющейся в данный момент  работы»

 

Три основные правила Kanban:  

 

 

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

В Kanban разработке ПО:

 

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

 

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

 

• Уменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачи
• Быстрое выявление проблемных задач
• Вычисление времени на выполнение усредненной задачи

Kanban-доска

 

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

• «To do» — тут карточки со всеми

задачами по всем проектам.

• «Doing» — тут карточки с задачами,

над которыми сейчас идет работа.

• «Done» — полностью завершенные

задачи.

 

Kanban-доска

       Цели проекта:

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

 

     Очередь задач:

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

 

      Проработка дизайна:

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

   Разработка:

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

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

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

 

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

 

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

Kanban против Scrum :

 

• Сходства:
• Оба – и Lean, и Agile.
• Оба используют вытягивающие системы планирования.
• Оба ограничивают НЗР.
• Оба используют прозрачность для обеспечения улучшения процесса.
• Оба ориентированы на ранние и частые поставки продукта.
• Оба полагаются на самоорганизующиеся команды.
• Оба требуют деления задач на более мелкие.
• В обоих случаях план релиза постоянно оптимизируется на основе эмпирических данных (производительности/ времени выполнения задачи).

 

Kanban против Scrum :  
Отличия:

 

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

Kanban против Scrum :  
Отличия:

 

Наличие burndown-диаграммы обязательно.	Наличие каких-либо обязательных диаграмм не требуется
НЗР ограничивается косвенно (за спринт).	НЗР ограничивается явно (по статусам).
Оценки задач обязательны	Оценки задач опциональны
Нельзя добавлять задачи в текущую итерацию	Можно добавлять новые задачи, когда это возможно.
За backlog спринта отвечает только одна конкретная команда.	Kanban-доска может совместно использоваться несколькими группами или отдельными лицами.
Предписаны 3 роли (Product Owner / Scrum Master / Команда).	Нет предписанных ролей
Scrum-доска очищается между спринтами.	Kanban-доска является неизменной
Приоритезированный Product Backlog обязателен	Приоритезация не является обязательной.