Kanban/Agile/Scrum/Lean — гибкие методологии разработки

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

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

Что же такое продукт и продуктовый подход? Продукт – это не товар и не услуга в общем смысле. Продукт – это то, за что готовы платить ваши клиенты. Так, продукт компании BMW, это не средство передвижения, это драйв, удовольствие за рулем, статус и безопасность. Соответственно, продуктовый подход – это процесс создания ценности для удовлетворения потребности клиента. Создание продукта — это ключевой этап любого бизнеса. В особенности этот этап важен для бизнеса, связанного с производством высокотехнологичных и инновационных товаров.

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

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

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

Но не все знают, что получили развитие эти методы с Пути Тойоты — Dao Toyota.

Тойота как компания, занимающаяся производством автомобилей, образовалась в 1933 году как отдельное подразделение фирмы Toyoda Automatic Loom, которая ранее выпускала станки для текстильной промышленности. До Второй мировой войны компания процветала, но после — Японию оказалась на проигравшей стороне. В следствии оккупации и инфляции компания Тойота была на грани банкротства. Для того, чтобы выйти из кризиса, владелец и основатель компании Киичиро Тойода был вынужден максимально сокращать расходы. Он вводит политику жесткой экономии, которая закладывает фундамент основного принципа компании – «производства с нулевым запасом». Так появилась философия бережливого производства Тойота. Сподвижником и последователем Киичиро Тойода стал Тайити Оно, который в 1954 году занял пост директора компании. Но уже с середины 50-х годов он начал выстраивать особую систему организации производства, названную производственной системой Toyota или Toyota Production System (TPS).

Тайити Оно сформировал 14 основных принципов управления компанией и сгруппировал их в четыре категории:

Принципы ведения бизнеса на Toyota:

TPS — следующая ступень в развитии эффективного бизнеса после системы массового производства, которую изобрел Генри Форд. За пределами Toyota, TPS часто называют бережливым производством — lean production (этот термин введен Джоном Крафчиком в 1988 году для обозначения методов организации производства, принятых в Toyota).

Т.е. философию Dao Toyota смело можно назвать прародителем как продуктового подхода, так и современных методологий разработки продукта.

Книгу по принципам ведения бизнеса Toyota можно прочесть по ссылке: https://vl.ucoz.org/_ld/0/44_dao_toyota.pdf.

Помимо принципов ведения бизнеса, в Toyota сформировали основные виды потерь. К потерям относится все, что не создает ценности для продукта:

Для максимальной эффективности выстраивания рабочего процесса и устранения потерь в Toyota используется метод Kanban и Lean бережливое производство. Сначала подробнее рассмотрим Lean.

Производственная система Toyota TPS представляет собой уникальный подход к производству. Именно она породила движение за бережливое производство, которое (вместе с концепцией шести сигм) стало одной из доминирующих тенденций в разработке. Однако есть мнение, что несмотря на схожесть TPS и Lean, первое – это путь конкретной компании, а Lean production – набор методов и инструментов, которые базируются на философии Toyota, но могут быть реализованы на других производствах.

Сам термин «Бережливое производство» был введен Джоном Крафчиком в 1988 г. в рамках его работы в Международной автомобильной программе Массачусетского технологического институту. Исследования Крафчика в области бережливого производство были использованы Деймсом Вомеком и Дэниелем Джонсом в книге «Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании». Именно они определили этот термин в 1998 году. Бережливое производство, согласно Джеймсу П. Вомек и Дэниелу Т. Джонсу включает пять этапов:

Таким образом, Lean — это не методология, так как в ней нет набора готовых инструментов. Это часть философии эффективной разработки, которая вышла из философии Toyota и впоследствии стала частью философии Agile. Lean бережливое производство призвано бороться со всеми видами потерь. В основе данной философии лежат принцип вытягивания и принцип «точно в срок» (Just in Time).

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

Принцип «точно в срок» (Just in time) предполагает, что система планирования и организации работы компании построена так, что все необходимые элементы поступают в производственный процесс в нужный момент и в необходимом количестве. Также этот принцип предполагает бездефектное производство, так как брак может сломать всю четкую систему планирования.

К Lean бережливому производству можно отнести следующие методы организации труда и разработки:

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

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

Слово Kanban имеет японское происхождение и переводится как «рекламный щит, вывеска».

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

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

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

Основные принципы:

Из этих принципов можно сформулировать и ограничения метода:

Параллельно с внедрением различных методологий в производстве, развивается процесс разработки программного обеспечения. Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х — начале 70-х годов 20 века в связи с резким увеличением производительности ЭВМ при значительном снижении его стоимости. Именно в этот период программирование из простого кодирования становится инженерной дисциплиной и обрастает дополнительными видами деятельности, такими как разработка требований, создание документации, планирование, тестирование, проектный менеджмент и т.п. Появляются различные методы и практики, а из них стандарты и методологии.

Формируется жизненный цикл разработки ПО, который в общем виде можно представить так:

Методология разработки может быть жесткой (или традиционной), например, по каскадной модели, или гибкой.

Каскадная модель (waterfall) была представлена доктором У. Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывается компетентными сотрудниками, документируется и передаётся дальше. Вся работа идет последовательно от этапа к этапу. Пока предыдущий этап полностью не завершен, следующий запрещено начинать. Подходит для консервативных бюрократических структур. Каскадная модель — это пример жесткой методологии разработки.

Среди гибких моделей разработки наиболее известна модель Agile. Концепция Agile не нова, поскольку гибкое управление проектами широко использовалось еще с 1957 года. Но как философия разработки, Agile пришла благодаря публикации «Манифеста Agile» в 2001 году (можно ознакомиться по ссылке: https://agilemanifesto.org/iso/ru/manifesto.html) . В этом документе особое внимание уделяется взаимодействию участников и возможности изменений, которых не хватает жесткой методологии управления проектами. В манифесте сформулированы 4 ценности и 12 принципов гибкой разработки (вспомним, что у Тайити Оно были сформированы 14 основных принципов управления компанией, сгруппированные в четыре категории).

Основные идеи Agile:

Сам по себе Agile не является полноценным методом управления проектами, это философия управления разработкой, аналогично тому, как TPS – философия управления производством. Lean, Kanban и другие методы управления проектами, основанные на идеях TPS, адаптированы под разработку ПО с помощью Agile. Если попытаться представить схему взаимодействия этих понятий, то получится сложная структура связанных друг с другом принципов, философий и методологий (под XP можно подразумевать другие инструменты гибкой методологии разработки):

Основное преимущество Agile заключается в его гибкости. Этот подход можно любым способом менять под себя. Вот почему так много других систем управления проектами основываются именно на нём.

Agile, помимо Kanban и Lean, включает в себя такие практики, подходы и методологии, которые помогают создавать продукт более эффективно, например:

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

Если Agile – это принципы и философия, то Scrum – это набор конкретных правил и регламентов, которые говорят о том, как именно организовывать работу. Довольно часто можно встретить Scrum в сочетании со словом фреймворк, а не словом методология. Фреймворк — это более сформированная методология со строгими правилами.

Scrum появился в 1986 году как способ «наладить взаимодействие нескольких команд, работающих ради единой цели», согласно его изобретателям Икуджиро Нонаке и Такеучи Хиротаке, Scrum сочетает в себе идеи традиционного проектного управления и Agile, являясь одновременно структурированным и гибким способом управления проектами.

Итак, в Scrum все роли и процессы чётко прописаны. Основные категории Scrum – это команда, события, артефакты и метрики.

Scrum команда:

Scrum события:

Scrum артефакты:

Метрики:

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

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

Среди преимуществ Scrum можно выделить:

К недостаткам Scrum относятся:

Итак, в этой статье я попыталась структурировать и описать развитие во времени различных методологий разработки.

У каждого инструмента есть свои плюсы и минусы, свои ограничения и сферы применения. Чем именно пользоваться, будет зависеть от вашего конкретного продукта.

В завершение хочется обратить внимание, что для успешного применения гибких методологий в разработке, требуется сильная корпоративная культура и осознанная команда. Т.е., как и в системе TPS, на первое место выходит человек. Об этом не стоит забывать, внедряя современные технологичные ИТ решения в свой бизнес.

#scrum #agile #lean #kanban #toyota