Начнем с того, что Agile и Lean – это, в первую очередь, образы мышления (наборы принципов и ценностей), некоторые авторы также называют их системами мировоззрения и/или философией. При этом если Agile в том числе определяют, как набор методов и методологий[1], то Lean в большей степени принято называть философией или идеологией. Kanban же – непосредственно метод улучшения процессов разработки, удовлетворяющий ценностям обеих систем.

В хронологическом порядке Lean появился чуть раньше. Его зарождение связывают с послевоенной Японией. Экономика в тот момент переживала не самые лучшие времена, страна испытывала дефицит ресурсов. Поскольку бизнес стремился быть эффективным даже в таких условиях, на предприятиях зарождались принципы и методики, которые впоследствии стали известны как «бережливое производство» (Lean manufacturing). Смысл философии Lean заключается в том, чтобы создавать большую ценность для потребителя, затрачивая на это меньше ресурсов компании. При этом бережливость в Lean стоит на втором плане, главную роль играет именно создание ценности, клиентоориентированность. «Следовать Lean — значит дать клиенту то, что он хочет, сколько хочет и когда хочет» – Тайити Оно – топ-менеджер Toyota и один из главных идеологов Lean. Именно его считают основателем концепции бережливого производства (lean production), а производственную систему Toyota первой рабочей моделью. В первом десятилетии двадцать первого века Lean был приспособлен для разработки ПО Томом и Мэри Поппедник.

Ценности Lean:

1. Ликвидировать потери. Выявить работы, не создающие ценность, и избавиться от них.

2. Усилить обучение. Использование обратной связи с целью улучшения своей работы.

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

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

5. Объединять сотрудников. Сплоченная команда работает быстрее и эффективнее.

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

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

В основе Agile или гибкой методологии разработки (agile software development) лежат подходы и практики, основанные на ценностях и принципах Манифеста, выпущенного в феврале 2001 года в штате Юта США.

Главные идеи манифеста:

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

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

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

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

Не отрицая важности того, что справа, больше ценится то, что слева.

На основании главных ценностей Agile были сформулированы основные принципы гибкой методологии:

1. Наш наивысший приоритет – это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.

2. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.

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

4. Наиболее эффективный и действенный способ передачи информации – это встреча членов команды разработки ПО.

5. Представители бизнеса и команда разработки должны работать над проектом вместе.

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

7. Рабочее программное обеспечение – это главная мера прогресса проекта.

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

9. Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.

10. Простота – это искусство не делать лишней работы.

11. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.

12. Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий.

Таким образом, и Lean, и Agile нацелены на эффективность бизнес-процессов. Первый вышел из производства, а потом адаптировался в IT, второй был сразу разработан айтишниками. Обе системы сопоставимы по многим критериям, однако Lean в большей степени делает акцент на удовлетворении ценностей клиента и ликвидации потерь, Agile – на гибкости процессов и взаимодействия их участников. Это не говорит о том, что, то, что есть у одного, отсутствует у другого. Речь, скорее, о фокусе внимания. Так или иначе, главная цель одна – создать лучший продукт, удовлетворяющий ожиданиям потребителя, используя при этом меньшее количество ресурсов.

Как отмечалось выше, Kanban – это метод, направленный на улучшения процессов разработки, который «базируется на визуализации нематериальной деятельности, умственного труда, в целях правильной работы сервиса, достижения баланса между работой запрошенной потребителем и возможностями сервиса»[2]. С этой целью используются поточные системы (Канбан доски).

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

Название метода происходит от японского «канбан» (знак, карточка, указатель). Toyota начала применять его в 1960-х для названия систем, которые использовались в производстве для ограничения количества незавершенной работы. Однако метод, о котором идет речь в настоящей работе получил свое название в 2007 году вслед за тем, как Дэвид Андерсон провел презентации по этому методу управления в Microsoft (Андерсон, 2005) и Corbis.

Kanban относят как к Agile-методологий, так и к Lean – мышлению. Авторы работы «Постигая Agile. Ценности, принципы, методологии» вообще отмечают, что Lean – это важная часть Agile[3]. Кто-то считает наоборот, либо разделяет эти две системы. Оставим эту дискуссию философам.

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

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

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

Сотрудничество: одна из задач Kanban-метода — совершенствование того, как люди делают работу совместно.

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

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

Лидерство: способность вдохновлять окружающих на действия своим примером, словами и идеями.

Понимание: главным образом, знание (и индивидуальное и организационное) о себе самом в целях дальнейшего развития.

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

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

Вывод: Len и Agile представляют собой не взаимоисключающие системы мышления, направленные на повышение эффективности производства, обладающие оправленными наборами ценностей и принципов. Kanban – метод улучшения процессов разработки, соответствующий ценностям обеих систем.

[1]Э. Стеллман, Д. Грин. Постигая Agile. Ценности, принципы, методологии. С. 12

[2] Д. Дж. Андерсон, Э. Кармайкл. Канбан. Краткое руководство. С. 9

[3] Э. Стеллман, Д. Грин. Постигая Agile. Ценности, принципы, методологии. С. 273

[4] Д. Дж. Андерсон, Э. Кармайкл. Канбан. Краткое руководство. С. 11