Жизненный цикл разработки ПО. Все о Kanban

Как и описанный ранее Scrum, Kanban является одним из возможных способов реализации гибкой (Agile) методологии разработки. Изначально Kanban был разработан на основе Производственной системы Тойоты и спроектирован таким образом, чтобы наилучшим образом соответствовать концепции бережливого производства. В общих чертах ее можно описать как стремление к минимизации затрат за счет снижения количества выполняемой в данный момент работы (Work In Progress, далее — WIP). Принципы бережливого производства широко применяются на производственных предприятиях и их применение позволяет избежать переизбытка произведенных материалов, а также выявить возможные узкие места в жизненном цикле производства.

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

Три принципа Kanban

Существуют три основных принципа, которые помогут вам применить Kanban в вашем проекте:

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

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

Как использовать Kanban

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

1. Разделение процесса разработки на этапы

В зависимости от специфики поставленной задачи, могут быть выделены разные этапы разработки. Главное требование состоит в том, чтобы они соответствовали трем основным стадиям: “Что должно быть сделано”, “Что делается” и “Что сделано”. Вот пример того, как может быть разбит на этапы процесс разработки ПО:

1. Бэклог проекта
2. Требования
3. Дизайн
4. Разработка
5. Тестирование
6. Деплоймент
7. Закончено

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

После того, как вы разбили процесс производства на этапы, вы можете создать Kanban-доску.

2. Визуализация с помощью Kanban-доски

Этот этап является наиболее важным во всей Kanban-методологии. Само слово “Kanban” имеет японское происхождение и состоит из двух слов: “Кан” — видимый, визуальный, и “Бан” — доска.

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

Вот пример такой доски, которая использовалась в ИксБи Софтваре для работы над проектом “Workforce and Facility Management Suite” (приложение для бизнес-администрирования проектов):

Каждой задаче соответствует своя карточка. В данном случае доска была разделена на четыре части:

• ToDo содержит задачи, полученные от заказчика. Каждая задача отмечена цветом, который соответствует степени ее важности.
• После того, как поступившие от заказчика задачи были проанализированы и был запланирован срок их реализации, они перемещаются в область Estimated.
• Когда разработчик начинает работу над определенной задачей, он перемещает ее в область In Progress. На этом шагу разработчик отмечает задачу персональной меткой, которая дает понять, кто именно ответственен за реализацию конкретной задачи.
• После того, как задача решена, она перемещается в область Done.

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

Kanban относится к разряду так называемых Pull (от англ. “pull” — тянуть) систем. На практике это означает, что член команды разработчиков “перетаскивает” задачу из предыдущего этапа, давая понять разработчикам, ответственным за предыдущий этап, что они могут начать работу над следующей задачей. Такой подход также снижает WIP, в отличие от Push (от англ. “push” – толкать) систем, в которых на каждом этапе выполняется максимально возможный объем работы, который передается на следующий этап независимо от того, какой объем работы в данный момент выполняется.

3. Поиск слабых мест

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

4. Оптимизация процесса разработки

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

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

Заключение

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