Kanban framework что это
Kanban is a popular framework used to implement agile and DevOps software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Адаптация канбан
Применение «чистого» канбан не предусматривает выполнение некоторых операций, обязательных при применении скрам. Но этот метод управления проектами достаточно гибок и позволяет, если подобные действия кажутся полезными, добавлять их в рабочий процесс.
Ретроспективные совещания — это один из самых важных видов совещаний. Именно на таких совещаниях члены команды могут поговорить о том, чего удалось достичь, о том, что прошло не совсем удачно, о том, что можно улучшить. Ретроспективное совещание — это спокойное мероприятие, на котором можно рассказать о своих проблемах и поздравить с успехом тех, кто отлично справился со своими задачами.
Несмотря на то, что ретроспективные совещания не являются необходимыми в канбан (в скрам они проводятся в конце каждого спринта), мы сочли их ценными мероприятиями и не стали от них отказываться. На самом деле, мы даже начали проводить их еженедельно, а не каждые две недели, как раньше. Это позволило нам быстрее реагировать на возникновение каких-либо проблем. Мы, кроме того, используем эти совещания для того чтобы анализировать метрики команды и проверять рабочие процессы на наличие проблем и узких мест.
Мы сохранили и ещё один элемент из наших скрам-времён, который необязательно применять при использовании канбан. Речь идёт об оценке времени, необходимого для работы над пользовательской историей. Это делается в ходе уточнения задач, которые входят в историю. В скрам подобные оценки используются для того чтобы лучше понять то, что «поместится» в спринт. Можно подумать, что, так как в канбан нет спринтов, то оценка историй тут не нужна. Но, на самом деле, это не так.
Оценка сроков, необходимых на выполнение пользовательской истории помогает обеспечить то, что все члены команды одинаково видят объём задач, который необходимо решить в ходе работы над историей. Если кто-то даёт истории оценку в 8 баллов, а кто-то — в 3, очевидно то, что нужно продолжить обсуждение этого вопроса. Кто-то может, оценивая сроки, учитывать какие-то проблемы, о которых другие не знают. В чьём-то понимании в объём работ по пользовательской истории должно входить что-то такое, что другие в таком качестве не рассматривают.
Собственно говоря, всё это подталкивает членов команды к дискуссиям.
Когда происходит нечто подобное, становится очевидным то, что не у всех есть чёткое понимание того, какой объём работ нужно выполнить по некоей пользовательской истории.
Ещё один часто встречающийся сценарий выглядит так: вся команда даёт трудоёмкости истории довольно высокую оценку (обычно это — всё, что больше 8 баллов). Это говорит о неуверенности. Это значит, что либо речь идёт о большом объёме работы, либо — о решении очень сложных задач, что вызывает у членов команды неприятные ощущения. В подобном случае лучше всего будет разделить пользовательскую историю на несколько более мелких историй и чётче определить цели работ.
Visual metrics
One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports kanban teams use are control charts and cumulative flow diagrams.
A control chart shows the cycle time for each issue as well as a rolling average for the team.
The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success.
A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockages by seeing the number of issues increase in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blockage in these states can increase the likelihood of massive integration conflicts when the work does get merged upstream.
Continuous delivery
Continuous delivery (CD) is the practice of releasing work to customers frequently. Continuous integration (CI) is the practice of automatically building and testing code incrementally throughout the day. Together they form a CI/CD pipeline that is essential for development teams (especially for DevOps teams) to ship software faster while ensuring high quality.
Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on precisely that: optimizing the flow of work out to customers
Kanban cards
In Japanese, kanban literally translates to "visual signal." For kanban teams, every work item is represented as a separate card on the board.
The main purpose of representing work as a card on the kanban board is to allow team members to track the progress of work through its workflow in a highly visual manner. Kanban cards feature critical information about that particular work item, giving the entire team full visibility into who is responsible for that item of work, a brief description of the job being done, how long that piece of work is estimated to take, and so on. Cards on virtual kanban boards will often also feature screenshots and other technical details that is valuable to the assignee. Allowing team members to see the state of every work item at any given point in time, as well as all of the associated details, ensures increased focus, full traceability, and fast identification of blockers and dependencies.
Kanban boards
The work of all kanban teams revolves around a kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.
Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.
The kanban methodology relies upon full transparency of work and real-time communication of capacity. Therefore, the kanban board should be seen as the single source of truth for the team's work.
▍Метрики канбан
Я полагаю, что метрики — это самая важная из сильных сторон канбан. В канбан имеется множество различных метрик, которые помогают лучше понять то, что происходит с командой. Например:
- Пропускная способность команды (throughput). Количество пользовательских историй, работы по которым завершены в заданный промежуток времени.
- Время цикла (cycle time). Число дней, которое уходит на завершение работ по истории с момента начала работы. Здесь используются такие показатели, как доверительные интервалы. Наиболее распространенным является доверие на 85%.
- Кумулятивная диаграмма потока (cumulative flow diagram). Такая диаграмма позволяет визуализировать процесс решения задач по пользовательским историям. Выглядеть эта диаграмма должна примерно так, как показано ниже.
Кумулятивная диаграмма потока
Существует плагин для Jira, который позволяет пользоваться всеми этими метриками. Это — ActionableAgile for Jira — Agile Metrics. Он помогает исследовать метрики, имеющие отношение к деятельности команды, используя ту же платформу, что используется для управления работой.
Fewer bottlenecks
Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.
For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.
Сравнение досок Kanban и Scrum
Различия между Kanban и Scrum довольно незначительны. Многие сходятся во мнении, что команды Scrum используют доску Kanban, но с процессами, артефактами и ролями, принятыми в Scrum. И все же в некоторых аспектах эти две методики разительно отличаются.
- У спринтов в Scrum есть дата начала и дата окончания, в то время как в Kanban работа ведется без перерыва.
- В команде Scrum четко разграничены роли (владелец продукта, команда разработчиков и Scrum-мастер), а в Kanban формальные роли отсутствуют. Обе методики требуют от команд навыков самоорганизации.
- Доска Kanban используется на протяжении всего жизненного цикла проекта, а доска Scrum обнуляется и обновляется после каждого спринта. содержит определенное количество заданий, которые нужно выполнить к заданному сроку.
- Доски Kanban дают больше свободы в том, что касается заданий и времени их выполнения. В зависимости от потребностей можно менять приоритеты, людей, ответственных за выполнение заданий, и содержание заданий.
Обе Agile-методики, Kanban и Scrum, популярны среди разработчиков ПО. Подробные сведения см. в нашем подробном сравнительном анализе Kanban и Scrum.
Всё дело в метриках
Нельзя оценить эффективность (или неэффективность) работы, не имея специализированных метрик. Рассмотрим метрики, применяемые в скрам и в канбан.
Скрам — это уже не совсем «гибкая методология разработки»
Я пришёл к выводу о том, что в скрам слишком большое внимание уделяется процессу работы. Или, как минимум, люди обращают на это слишком много внимания, что выражается в следующем:
Учитывая всё вышесказанное, я могу отметить, что члены моей команды начали чувствовать недовольство от происходящего. Это повлияло на качество того, что мы создавали. Программисты больше заботились о том, чтобы уложиться в срок, чем о том, чтобы достичь нужного уровня качества.
В этот момент мы начали поиск других возможностей организации работы, поиск другого agile-фреймворка, который лучше подошёл бы к используемым нами методам работы.
Тогда мы нашли Kanban (канбан).
Sub-columns
У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он ее переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенес задачу на тест, у QA нарушен этот лимит. Стало две задачи.
Допустим, программист не будет переносить задачу на Тестирование и оставит ее в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In progress и Done. И когда программист заканчивает задачу, он переносит ее в Done. Когда тестировщик освободится, он возьмет новую задачу из под-колонки Done колонки Программирование и перенесет ее в свою колонку Тестирование.
Заключение
Подводя итоги, хочу отметить, что Scrum — гибкая методика разработки, а Kanban — еще более. Всему свое время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning poker. Scrum помогает детально погрузить команду в суть продукта.
А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на нее реагировать. Вы начинаете работать над HADI циклами — вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Все увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.
Какую бы из Agile-методологий вы не выбрали, вы можете качественно реализовать ее с помощью платформы для управления проектами Hygger.io.
А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!
Max Rehkopf
Просмотр тем
Доска Kanban — это инструмент управления Agile-проектами, который помогает наглядно представить задачи, ограничить объем незавершенной работы и добиться максимальной эффективности (или скорости). Она может помочь командам Agile и DevOps упорядочить повседневную работу. С помощью карточек и столбцов на доске Kanban команды по техническим вопросам и сервисные команды могут понять, какой объем работы следует взять на себя, и выполнить этот объем, придерживаясь принципов непрерывного совершенствования.
Методика Kanban проделала долгий путь от своих истоков в сфере бережливого производства, за что стоит поблагодарить небольшую, но эффективную группу ее сторонников. Труд Дэвида Андерсона, в котором были обозначены принципы методики Kanban, способствовал проникновению Kanban в мир разработки ПО и обслуживания, а книга Джима Бенсона и Тониан Де Мариа Personal Kanban (Kanban в личных целях) помогла распространению Kanban в самых разных областях.
Я использую доски Kanban каждый день и уже не представляю свою жизнь без них. Приведенные здесь идеи и рекомендации появились в результате объединения моего личного опыта, итогов исследования и разговоров с Заком Найсом, Китом Ноттинсоном и Джимом Бенсоном.
Я обращаюсь к Kanban снова и снова из-за ценностей Kanban и (как ни странно) отсутствия правил. В Kanban ценятся уважение к людям и постоянное совершенствование.
Составляющие доски Kanban
Дэвид Андерсон выделяет пять составляющих досок Kanban: видимые сигналы, столбцы, лимиты незавершенной работы, точка принятия обязательств и точка поставки продукта.
- Видимые сигналы. Первыми на доске Kanban бросаются в глаза карточки (стикеры, листки и пр.). Kanban-команды выносят записи обо всех проектах и рабочих задачах на карточки; одна карточка, как правило, соответствует одному проекту или рабочей задаче. Для Agile-команд каждая карточка обозначает одну пользовательскую историю. Увидев эти сигналы на доске, участники команды и заинтересованные стороны смогут без труда понять, над чем работает команда.
- Столбцы. Еще одним отличительным признаком доски Kanban являются столбцы. Они символизируют конкретные действия, которые в совокупности составляют «рабочий процесс». Карточки перемещаются по рабочему процессу до стадии завершения. Рабочие процессы могут быть простыми и состоять лишь из столбцов «Предстоит сделать», «В процессе» и «Завершено», а могут быть гораздо более сложными.
- Ограничения незавершенной работы (WIP). Ограничения WIP — это максимальное количество карточек, которое может находиться в одном столбце одновременно. Если для столбца выбрано ограничение WIP, равное 3, то в нем не может быть более трех карточек. Когда количество карточек в столбце достигает максимума, команда должна сосредоточить усилия на этих карточках и передать их дальше, чтобы на эту стадию рабочего процесса могли поступить новые карточки. Ограничения WIP нужны, чтобы выявлять проблемные места в рабочем процессе и добиваться максимальной скорости работы. Ограничения WIP помогают на ранних этапах понять, не взяла ли команда на себя слишком много задач.
- Точка принятия обязательств. На доске у Kanban-команд часто присутствует бэклог. Клиенты и участники команды вносят в него идеи по проектам, к которым команда может обратиться, когда будет готова. В точке принятия обязательств команда выбирает ту или иную идею, после чего начинается работа над проектом.
- Точка поставки продукта. Точка поставки продукта знаменует завершение рабочего процесса команды Kanban. Многие команды принимают за точку поставки продукта момент, когда продукт или сервис передаются в распоряжение клиента. Цель команды — как можно быстрее перенести карточки из точки принятия обязательств в точку поставки продукта. Время, за которое карточка проходит из одной точки в другую, называется временем выполнения. Kanban-команды постоянно совершенствуются, стремясь свести время выполнения к минимуму.
Доска Kanban с этими пятью составляющими несомненно приведет вашу команду к успеху. Но сейчас я хочу познакомить вас с противоположной точкой зрения.
Джим Бенсон считает, что в Kanban есть только два правила: ограничивайте незавершенную работу и визуализируйте работу. Если следовать в работе только этим правилам, доска Kanban будет выглядеть совсем иначе. И в этом нет ничего плохого! Джим советует использовать только эти два правила в начале своего знакомства с Kanban, потому что «чем больше вы установили правил, тем меньше ситуаций, в которых их будет целесообразно применять».
Kanban for software teams
Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.
While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and cards, and even those can be virtual.
Цифровые доски
Когда система Kanban снискала успех у команд по разработке ПО и технических команд, доски Kanban претерпели цифровую трансформацию. Географически распределенные команды могут обращаться к цифровым доскам Kanban удаленно и в разное время.
Trello — это простое средство для быстрого создания цифровой доски Kanban. Всего за несколько нажатий можно подготовить доску с цифровыми списками, символизирующими стадии Kanban-процесса. Работать с доской и управлять ею может вся ваша команда.
Например, можно создать списки «Бэклог», «На очереди», «В процессе» и «Готово». Каждое задание представлено в виде карточки, которая перемещается из списка в список по мере того, как задание попадает в очередь, над ним работают и его выполняют.
Цифровая доска Kanban обладает следующими преимуществами: скорость подготовки, простота предоставления совместного доступа и возможность отслеживать неограниченное количество обсуждений и комментариев в любое время по мере реализации проекта. Откуда бы и когда бы ни обращались участники команды к доске Kanban, они увидят самый актуальный статус проекта. А еще рабочий процесс Kanban в Trello можно использовать для ведения личных списков текущих дел, как показано на этом примере доски.
Бывают совсем простые цифровые доски Kanban, в то время как некоторые более продуманы и предусматривают больше возможностей настройки. Командам, которым нужны дополнительные функции, например ограничения WIP и контрольные графики, следует выбирать инструмент с более широкими возможностями, такой как Jira Software. В Jira по умолчанию доступен шаблон проекта Kanban, чтобы команды Kanban могли без промедления приступить к работе. Команда может просто создать проект, настроить рабочий процесс и доску в зависимости от нужд, установить ограничения WIP, создать дорожки swimlane и даже включить бэклог, чтобы было удобнее расставлять приоритеты.
Swimlanes
Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает — в рабочее время. Вы делегируете задачу вашему лиду или devops – «Поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует ее закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.
В данном случае у нас есть Swimlane под названием Blockers. Все задачи, которые требуют решения в режиме реального времени, ставятся в этом блоке. Программисты немедленно прекращают свою текущую задачу, ставят ее на паузу и начинают делать блокер.
Также у нас есть очень полезный Swimlane под названием Someday. Туда мы сублимируем задачи, которые «да-да, обязательно сделаем когда-нибудь» Это реально помогает убрать все лишнее с глаз, чтобы люди могли сконцентрироваться на главном. А эти задачи, как правило, остаются там навсегда.
В чем разница между Scrum и Kanban?
Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.
После окончания спринта выполненные фичи заливаются на продакшн, а невыполненные — переносятся в другой спринт. Как правило, фичи, которые делаются во время спринта, не меняются: что было на старте спринта — должно быть сделано любой ценой к окончанию спринта.
На Kanban мы посмотрим там, где он и возник. Представьте себе конвейер, на котором делают детали для машин Toyota. Есть станок, он делает зеркала для машин. Он умеет делать левые зеркала, правые зеркала, задние и зеркала для солнцезащитного козырька. Принцип прост: нажми на кнопку, поменяй режим — получи новую продукцию.
Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (вы выбрали «максималку» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.
Основная разница между Scrum и Канбан — в длине итераций. В Scrum итерации — 2 недели, в Kanban задачи программисту можно «подсовывать» хоть каждый день.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.
Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.
Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.
Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.
Во-первых, это WIP (Work in progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем от выгорания: они делают только одну задачу в единицу времени.
А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, пока полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где ты остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника. Как мы это контролируем? Вот здесь должно быть понятно:
Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач — наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это все издержки, которые понижали наш КПД. Тогда мы подключили на проект еще одного QA и проблема была решена.
▍Метрики скрам
При применении скрам используются следующие метрики и графики:
- Скорость команды (velocity). Количество этапов пользовательской истории, завершённых во время каждого спринта.
- Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач (commitment vs. done). Процент пользовательских историй, по которым были взяты обязательства, и работы по которым были успешно завершены.
- Диаграмма сгорания задач (Burndown Chart). Диаграмма, которая визуализирует ход работ по пользовательским историям во время конкретного спринта.
«Скорость» не измеряет скорость выпуска готовых подсистем продукта. Эта метрика оценивает лишь количество выполненных этапов работы, имеющих отношение к некоей пользовательской истории. Если на работу над историей уходит больше времени, чем было запланировано, эта метрика оказывается бессмысленной.
«Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач» вообще не должно рассматриваться как метрика. Эта «метрика» сопоставляет обязательства с результатами. Не стоит и говорить о том, что это может привести к тому, что люди будут закрывать и повторно открывать задачи только для того, чтобы они были бы «выполнены».
«Диаграмма сгорания задач» — это то, на что лично я никогда не обращал особого внимания. В основном это так из-за того, что подобные диаграммы часто выглядят примерно так, как показано ниже.
Диаграмма сгорания задач
Почему это так? Предположим, вы начинаете с пустой доски, и приступаете к параллельной работе, например, с тремя пользовательскими историями. Работы по этим историям, вероятно, будут вестись с одинаковой скоростью — именно поэтому на диаграмме сгорания задач можно видеть такие мощные нисходящие движения. Более того, если в команде имеется всего один тестировщик, который должен тестировать результаты выполнения работ по всем задачам, то он окажется узким местом команды.
Две популярные Agile-методологии
Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными. Перед тем, как разобраться в разнице между ними, вспомним кратко о том, что их объединяет.
Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
- Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
- MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
- Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.
По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:
— проблемы, решением которых мы занимаемся, существует в жизни пользователя.
— эти проблемы существенные.
— пользователь будет за них платить
— есть рынок, и это не проблема одного человека.
— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).
- Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).
Scrum vs. kanban
Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another.
Regular fixed length sprints (ie, 2 weeks)
Some teams blend the ideals of kanban and scrum into "scrumban." They take fixed-length sprints and roles from scrum and focus on work in progress limits and cycle time from kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on.
Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling.
Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.
В большинстве недобросовестных статей и тренингах любая методология представляется как магическая серебряная пуля, которая мигом решит проблемы коммуникации, враз спасет от некомпетентности отдельных членов команды. В общем, поможет именно вам решить именно ваши проблемы. В текущем году я поступаю в магистратуру Белорусский Государственный Университет по специальности «технологии управления персоналом» и планирую рассмотреть подробно плюсы и минусы, а также ограничения применимости наиболее распространенных методологий разработки программного обеспечения.
В процессе работы я часто сталкивался с непониманием и неверным трактовкам инструментов методологий, применения модной методологии без учета контекста. После прочтения статьи я понял что проблема скорее глобальная, чем локальная. Предлагаю сегодня немного рассмотреть Kanban, его историю, основные принципы, и возможные границы применения.
Если вам не хочется читать — я сделал видео, где на пальцах описываю историю и основные принципы метода Канбан.
История термина
Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.
Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала — 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики — количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.
В упрощенном варианте, Kanban включает в себя два простых правила:
- производственная станция имеет план производства деталей («backlog»). План отсортирован по приоритету, и может меняться в любое время (к примеру станция производящая слишком много левых зеркал должна иметь возможность переключиться на правые как можно скорее);
- количество задач, выполняемых на станции одновременно ограничено (т.е. производить не более заданного количества зеркал одновременно). Это ограничение необходимо для управления скоростью производства на станции, а также скоростью реагирования на изменения плана.
Настоящее время
В последнее время, Kanban набирает большую популярность в производстве программного обеспечения. Некоторые команды считают эту методологию исключительно полезной, некоторые используют по принципу «культа Карго». Основываясь на моем эмпирическом опыте чистый Kanban плохо работает для продуктовых команд (читай — «основной конвейер»), но отлично работает с командами поддержки, такими как:
- группы поддержки программного обеспечения, где не важен «план», но важна скорость реагирования на изменения;
- группы тестирования, работающие отдельно от групп разработки;
- службы поддержки;
- другие примеры «неосновных производств».
Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой. Предлагаю рассмотреть пример использования Kanban в разработке программного обеспечения. Заранее прошу простить за некрасивые иллюстрации. Давайте представим себе команду из одного разработчика, работающего над небольшим проектом. План разработки (backlog) отсортирован в порядке приоритета кусков работы, лимит команды на задачи в процессе — 1 шт.
- изменить лимит на количество задач в работе;
- добавить задачу с более высоким приоритетом (к примеру p0) для того чтоб она была взята как можно скорее;
В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, наш разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. В общем все! Kanban — это не просто, просто. Это очень просто!
- данная методология плохо работает с большими командами (больше 5 человек);
- в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами;
- ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования.
Заключение
В заключение, хочу добавить, что сравнение любых методологий по принципу «кто круче» не продуктивно и контр-конструктивно (капитан очевидность). Каждая, более-менее распространенная, методология имеет свои плюсы, минусы и границы применения. Дополнительно, Agile-методологии в принципе накладывают большие требования на сработанность и опыт членов команды.
В случае возникновения интереса к теме продолжу рассмотрение Kanban'a подробнее. В последствии, предлагаю разобрать по полочкам и картинкам Scrum и RUP.
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Kanban articles
What is a kanban board?
A kanban board is a physical or digital project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency(or flow).
Working with WIP limits for kanban
Learn how to use work in progress limits, the 4 goals for agile teams using WIP limits, and why WIP limits are important. Get started here.
Kanban vs scrum
Discover if Kanban or Scrum is a better framework for your agile team. Learn the key differences between the two frameworks.
Kanplan: where your backlog meets kanban
Kanplan adds the backlog and backlog grooming concepts of scrum to kanban, using the backlog instead of the To Do column to plan and prioritize work.
Learn kanban with Jira Software
Step-by-step instructions on how to drive a kanban project, prioritize your work, visualize your workflow, and minimize work-in-progress with Jira Software
From “to-do” to “done” with Jira kanban boards
The Jira Software kanban board is designed to help teams continuously improve cycle time and increase efficiency.
Kanban is enormously prominent among today's agile and DevOps software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.
When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.
Planning flexibility
A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.
Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises.
Kanban articles
What is a kanban board?
A kanban board is a physical or digital project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency(or flow).
Working with WIP limits for kanban
Learn how to use work in progress limits, the 4 goals for agile teams using WIP limits, and why WIP limits are important. Get started here.
Kanban vs scrum
Discover if Kanban or Scrum is a better framework for your agile team. Learn the key differences between the two frameworks.
Kanplan: where your backlog meets kanban
Kanplan adds the backlog and backlog grooming concepts of scrum to kanban, using the backlog instead of the To Do column to plan and prioritize work.
Learn kanban with Jira Software
Step-by-step instructions on how to drive a kanban project, prioritize your work, visualize your workflow, and minimize work-in-progress with Jira Software
From “to-do” to “done” with Jira kanban boards
The Jira Software kanban board is designed to help teams continuously improve cycle time and increase efficiency.
Kanban is enormously prominent among today's agile and DevOps software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.
When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.
Итоги
Скрам навсегда останется в наших сердцах как первая широко распространившаяся agile-методология. Но по мере того, как компании переходят к схемам непрерывного развёртывания решений, использование спринтов, ограниченных по времени, больше не имеет смысла.
Всегда будут существовать особые проекты, в которых скрам способен отлично себя показать. Правда, учитывая то, что в компаниях всё чаще пользуются agile-методологиями, канбан постепенно выйдет на первое место, сместив с него скрам.
Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.
Что такое канбан?
Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах. В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено». Данный фреймворк позволял Toyota более эффективно выделять ресурсы в ситуациях, когда где-то на производственной линии возникали узкие места.
Затем, когда стало ясно, что применение канбан способно повысить скорость разработки ПО, канбан перенесли и в сферу технологий.
Сравнение фреймворков скрам и канбан
В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка. Несмотря на то, что скрам занимает первое место, канбан постепенно распространяется всё сильнее. А что если их сравнить?
Если взять за основу скрам и сравнить его с канбан, то получится следующее:
- В канбан нет итераций, ограниченных по времени (спринтов).
- Канбан не требует оценки сроков выполнения работ по пользовательским историям.
- В канбан нет концепции «обязательств». К выполнению задач приступают тогда, когда это нужно.
- В канбан имеется несколько метрик, которые позволяют оценивать на доске время, необходимое на выполнение работ по пользовательской истории.
- В канбан (очевидно) не нужен скрам-мастер.
Канбан даёт команде разработчиков достаточно высокий уровень гибкости. Пользовательские истории, в сравнении со скрам, выполняются в более свободной манере. Но свобода — это ответственность. Несмотря на то, что канбан не требует того, что разработчики каждые две недели берут на себя какие-то обязательства, применение этого метода управления разработкой предусматривает собственные средства контроля за работой. Это, например, такие метрики, как время цикла и пропускная способность системы.
Shortened time cycles
Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow – from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.
Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a bottleneck of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too.
In a kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process.
Виды и примеры досок Kanban
Доски Kanban можно применять во многих сферах, от производства до управления персоналом и разработки ПО с использованием методик Agile и DevOps. От того, к какой сфере нужно приспособить Kanban, часто зависит выбор доски — цифровой или физической. В ходе исследования я узнал о случае, когда для выполнения строительного заказа стоимостью 58 млн долларов использовалась физическая доска, размещенная в трейлере. С другой стороны, я лично общался с очень многими командами разработчиков ПО, которые используют цифровые доски Kanban.
Реальные доски
Самый простой пример доски Kanban — реальная доска, поделенная на вертикальные столбцы. Команды размечают маркерную или меловую доску и наклеивают на нее стикеры. Эти стикеры передвигаются по рабочему процессу, отражая ход работы.
Одно из преимуществ реальной доски заключается в том, что ее нельзя «выключить». Нельзя открыть новую вкладку на огромной маркерной доске на колесиках, стоящей возле стола. Такую доску легко подготовить, легко показать другим, и часто с ее помощью проще всего доносить информацию в определенных командах. Тем не менее реальные доски не подходят для удаленных команд или людей с ужасным почерком, как у меня.
Optimizely создает программное обеспечение, помогающее компаниям понять, какой вариант веб-сайта или продукта больше всего нравится пользователям. В этой компании рабочие задачи самых разных размеров отслеживают при помощи Jira, но Кит Ноттонсон, старший директор по развитию, заметил одно упущение.
Команды вели в Jira бурную деятельность по отдельности, но между собой не общались. Чтобы привлечь внимание всех к одному общему делу, Кит соорудил основательную реальную доску Kanban, которую назвал «стеной работы».
На доске разместили все проекты, над которыми работала техническая команда. Показатели, имена участников команды и статус работы теперь были у всех на глазах. Всем стало проще понимать полный объем работы, но вскоре у доски обнаружилось более любопытное достоинство.
«Сначала стена состояла из столбцов "Предстоит сделать", "Выполняется" и "Завершено", но со временем сотрудники начали обсуждать друг с другом, как мы работаем», — говорит Кит. Он рассказал, что благодаря таким обсуждениям стена разрасталась и развивалась и за несколько недель у компании Optimizely появилось более осмысленное представление о процессе работы.
Сильной стороной доски Optimizely является наличие точки принятия обязательств и точки поставки продукта. Когда границы проекта определены и он отвечает определенным критериям, техническая команда выбирает проект и берет на себя обязательство по его выполнению. Затем проект передается в Jira, чтобы представляющие особый интерес данные и взаимодействия в процессе итоговой поставки не ускользнули от внимания команды.
Кит рекомендует командам начинать с реальной доской Kanban, потому что благодаря подобным обсуждениям с ранних пор достигается высокая скорость итераций рабочего процесса и задачи быстро проходят все стадии.
The benefits of kanban
Kanban is one of the most popular software development methodologies adopted by agile teams today. Kanban offers several additional advantages to task planning and throughput for teams of all sizes.
Начало работы с досками Kanban
Работа в Kanban идет по принципу «начните с того, над чем работаете прямо сейчас». Это значит, что для начала работы с Kanban не нужно бросать текущую работу. Для успешного применения методики Kanban нужно соблюсти следующие три условия.
- Вы понимаете текущие процессы в том виде, в котором они протекают в действительности, и придерживаетесь системы текущих ролей, обязанностей и должностей.
- Вы готовы практиковать постоянное совершенствование и развитие через эволюционирование.
- Вы поощряете инициативность на всех уровнях, от рядовых участников до руководящих лиц.
Рабочий процесс в Kanban — процесс командный, поэтому первым делом ваша команда должна сплотиться! Для удобства разделите работу на отдельные активности, из которых будет состоять рабочий процесс (столбцы). После этого вы можете решить, как и когда добавлять на доску новые задания (карточки). Будет ли у вас служба техподдержки, через которую клиенты будут передавать идеи, или команда будет проводить совещания для составления и размещения новых карточек?
Кроме того, стоит определить размер карточки и объем работы, который она покрывает. Выберите способ оценки продолжительности или сложности работы для всех карточек. Если какое-то задание слишком объемное или сложное, разбейте его на несколько карточек.
Когда точка принятия обязательств и точка поставки продукта определены, можно начинать работу. Со временем процесс будет совершенствоваться на основании замечаний команды. Kanban требует от участников всех уровней постоянно проявлять инициативу. Эта философия называется «кайдзен». Уважение к людям и постоянное совершенствование в Kanban превыше всего. Следуя этим ценностям, вы очень быстро овладеете этой методологией.
Читайте также: